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

[Ondrej Zajicek]

On Mon, Sep 28, 2015 at 08:58:35PM +0100, Israel G. Lugo wrote:
> 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.
>
> ...
> 
> 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.

Hello

You are right with your analysis of the issue. I agree that in your case
it does not make sense, but unfortunately, the behavior is IMHO more or
less correct with regard to RFC 2328. I am not sure how it should be
modified to be consistent and to make sense in your setting. /32 local
definitely should be propagated (at least by default). Perhaps ignoring
zero metric /32 from triggering summarization? Or ignoring any local stub
network? Or some more general configurable limit for summarization (like
minimal cost)?

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

Perhaps you could try to use stubnet option with hidden + summary
suboptions to hide these /32 routes to not trigger the summary networks.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20150930/e116d465/attachment.asc>