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