OSPF: directly attached summarized networks announced with metric 0 when link goes down

[Israel G. Lugo]

Hello,

I have a question regarding BIRD's OSPF and summarized networks. Not
sure if I'm doing the right thing.

I've got access routers running BIRD, configured as ABR between area 0
and their respective user-facing areas.

Access networks are VLAN interfaces, e.g. eth0.161. Backbone connection
is a separate physical interface (eth1).

If the physical access interface (eth0) goes link down for some reason,
BIRD changes the VLAN OSPF interfaces (eth0.161) to Loopback state. It
stops announcing the directly connected prefixes on the VLAN interfaces,
but it keeps announcing a /32 for the interface's IP, with a metric of 0.

That in itself isn't the problem. It makes sense, as the IP belongs to
the machine. The problem is, if I use the "network" option (to define
summary LSAs), the /32 will be summarized to the entire prefix, making
it be announced again. What's worse, it is now announced with a metric
of 0, which means it will override any redundant routers I might have.

Perhaps a simplified example will help explain:

protocol ospf campus {
  tick 1;
  ecmp yes;
  area 0.0.0.0 {
    stub no;
    interface "eth1" { check link yes; };
    # export loopback address into OSPF
    interface "lo" { stub; };
  }
  area 0.0.161.0 {
    stub yes;
    summary yes;
    interface "eth0.161", "eth0.197" {
      stub;
      check link yes;
    };
    networks {
      # eth0.161
      A.B.C.0/24;
      # eth0.197
      D.E.F.0/24;
    }
}

Access interfaces are eth0.161 and eth0.197, respectively with IPs
A.B.C.253/24 and D.E.F.253/24. These networks are announced as
A.B.C.0/24 and D.E.F.0/24, with a default metric of 10.

Now, if I physically pull the cable from eth0, the result is that
A.B.C.0/24 and D.E.F.0/24 start to be announced with metric 0,
effectively sinking all traffic to those networks. [1]

If I remove the "networks" option, no summarization is done, and things
work: when I remove the cable from eth0, BIRD stops announcing the /24's
and starts announcing A.B.C.253/32 and D.E.F.253/32 (with metric 0).

I understand that literally, BIRD is doing what I asked it to do:
summarize A.B.C.0/24. As long as it has some valid route inside that
prefix (in this case the /32), it will announce the whole summarized
network, with a metric equal to the largest cost (RFC 2328, 12.4.3).

It would seem to me, though, that this case warrants special treatment.
The /32 only exists because the interface transited to Loopback state
when it lost the link.

Perhaps I am looking at this the wrong way. I would like to summarize my
networks, since I have several more complex cases where a shorter prefix
is subnetted into several longer ones. However, I would also like to not
announce dead routes from downed links. I am used to things working like
this from other routers (Quagga, for example) [2], but perhaps there is
a better way to do it in BIRD?

Is there something I should be doing differently? Or could this perhaps
be a bug, and not intended behavior?



[1] As far as I can ascertain, what's happening is: eth0 goes link DOWN,
eth0.161 and eth0.197 go LOWERLAYERDOWN, and BIRD puts them in Loopback
state. As such, BIRD starts announcing their IPs as /32 with metric 0.
Since it now has a /32 inside the summary network, it will start
announcing the entire summary network, with the metric of 0.

[2] In the case of Quagga for example, when the physical interface goes
link down, all directly attached routes are removed. The /32 loopback
addresses are not left behind. Hence, there is nothing to summarize,
hence it will not announce the faulty prefix.

Regards,

-- 
Israel G. Lugo
Núcleo de Redes e Comunicações
Direcção de Serviços de Informática
Instituto Superior Técnico


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20150928/4fbd1af1/attachment.asc>