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@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."