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

[Christian Tacke]

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:

I have a multi homed non-router box A (read: "stub router"
in ospf).  One of its interfaces is P.P.P.A/24.  We also
have a main router in that network P.P.P.R/24.  Basicly,
it's our ISP's network.  Also both are connected to our
internal network 10.0.0.A/24 and 10.0.0.R/24.  The router
announces P.P.P.0/24 into our internal network.  That's
good, okay.  Now if internal boxes want to reach P.P.P.A
they will go via the 10.0.0.R into the ISP network and then
to P.P.P.A instead of 10.0.0.A.  For the way back, A knows
a shorter way, directly into the internal network. 
Assymetric routing, not really nice.  What I am currently
doing: I have a script that auto generates "stubnet IP/32 {
cost 1; };" lines for each relevant ip and puts them in
bird's config.  That way the internal network knows, that
there is a better way to reach that IP.  Yes, internal
boxes could use the internal IP of A, but that's not how
those things are currently.  My solution works, I am happy.

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:

So what I wonder really: Is there a way to solve the
original problem and other "/32 magic" problems in a more
generic way?

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.


Cheers

Christian

-- 
www.cosmokey.com