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

[Ondrej Zajicek]

On Wed, Sep 30, 2015 at 07:29:38PM +0200, Christian Tacke wrote:
> 
> Hi,
> 
> 
> On Wed, Sep 30, 2015 at 00:54:01 +0200, Ondrej Zajicek wrote:
> [...]
> > 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)?
> 
> I have no answer on this, all options have their point to
> them, really. I wanted to chime in with another "/32
> magic" scenario:
>
> ...
> 
> So I *could* ask for an option to automatically announce
> /32 stubnets for (specific) local interfaces in addition to
> the normal /24 being announced. But instead:

Hi

The current code generating stub networks (both regular
and /32) is a mess and there are several issues with it.
Currently either regular stub net or /32 (or nothing)
is generated based on plenty of factors (iface type,
address type, link state and whether it is configured
passive/stub).

One idea to clean it up would be to have two independent
options:

propagate stub network yes|no|auto
propagate stub host yes|no|auto

Where 'auto' for stub host (/32) would mean 'not covered by stub network'.

The default values auto/auto would be mostly equivalent to the current
behavior.


> One brainstorm idea is a "stubnet filter". Normal filters
> could be used. Routes get run through it before being
> announced. So for the original problem, one could do "if
> it's a /32 then reject;" or "if it's a /32 then set metric
> to 10000" (so that the summary network would also be 10000
> and better routes would be used). It wouldn't directly help
> my problem, because I would want to create an additional
> route.

That is a good idea, perhaps even more useful for filtering summarized
prefixes between areas than for stubnets, but it is not something that
is a complete solution to these problems (as default 'accept all'
should be more or less equivalent to the current behavior).

One issue is that the current filtering code is hardwired to regular
routes.

-- 
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/20151001/c0a4710e/attachment.asc>