OSPF: directly attached summarized networks announced with metric 0 when link goes down
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. Perhaps a simplified example will help explain: protocol ospf campus { tick 1; ecmp yes; area 0.0.0.0 { stub no; interface "eth1" { check link yes; }; # export loopback address into OSPF interface "lo" { stub; }; } area 0.0.161.0 { stub yes; summary yes; interface "eth0.161", "eth0.197" { stub; check link yes; }; networks { # eth0.161 A.B.C.0/24; # eth0.197 D.E.F.0/24; } } Access interfaces are eth0.161 and eth0.197, respectively with IPs A.B.C.253/24 and D.E.F.253/24. These networks are announced as A.B.C.0/24 and D.E.F.0/24, with a default metric of 10. Now, if I physically pull the cable from eth0, the result is that A.B.C.0/24 and D.E.F.0/24 start to be announced with metric 0, effectively sinking all traffic to those networks. [1] If I remove the "networks" option, no summarization is done, and things work: when I remove the cable from eth0, BIRD stops announcing the /24's and starts announcing A.B.C.253/32 and D.E.F.253/32 (with metric 0). 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. Perhaps I am looking at this the wrong way. I would like to summarize my networks, since I have several more complex cases where a shorter prefix is subnetted into several longer ones. However, I would also like to not announce dead routes from downed links. I am used to things working like this from other routers (Quagga, for example) [2], but perhaps there is a better way to do it in BIRD? Is there something I should be doing differently? Or could this perhaps be a bug, and not intended behavior? [1] As far as I can ascertain, what's happening is: eth0 goes link DOWN, eth0.161 and eth0.197 go LOWERLAYERDOWN, and BIRD puts them in Loopback state. As such, BIRD starts announcing their IPs as /32 with metric 0. Since it now has a /32 inside the summary network, it will start announcing the entire summary network, with the metric of 0. [2] In the case of Quagga for example, when the physical interface goes link down, all directly attached routes are removed. The /32 loopback addresses are not left behind. Hence, there is nothing to summarize, hence it will not announce the faulty prefix. Regards, -- Israel G. Lugo Núcleo de Redes e Comunicações Direcção de Serviços de Informática Instituto Superior Técnico
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@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."
Hello, On 29-09-2015 23:54, 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)?
Thank you for being open to the issue. I think the first option (ignoring zero metric /32 from triggering summarization) would make sense, and would solve this problem in a safe way. If summarization is already taking place for another reason, the zero metric /32 should still be summarized; it would just not be enough to trigger the summarization. For example, if we have the following option: network { 10.0.0.0/16; }; With the following routes: 10.0.0.0/24 via 192.0.2.1 on eth0 IA (150/10) 10.0.1.0/24 via 192.0.2.1 on eth0 IA (150/10) 10.0.20.1/32 dev eth0 I (150/0) We should still summarize and announce just the 10.0.0.0/16: xnetwork 10.0.0.0/16 metric 10 But if the other routes go away for some reason, leaving just the local stub /32, then it will not trigger a summarization, and we announce as-is: stubnet 10.0.20.1/32 metric 0 If that seems good to you, I think it would be great. Perhaps it would even make sense to ignore any local stub network, however I'm not sure if that might affect some use case we're not thinking of.
Perhaps you could try to use stubnet option with hidden + summary suboptions to hide these /32 routes to not trigger the summary networks.
Thanks for the suggestion. I tried with: stubnet A.B.C.253/32 { hidden; summary; }; And with or without: networks { A.B.C.0/24 }; There was no change. However, I did manage to get it working like this: networks { A.B.C.253/32 hidden; A.B.C.0/24; }; It's not ideal, since I have to list and hide all the local IPs, and it doesn't announce the /32 in case of link down, but it's a good working compromise. Regards, -- Israel G. Lugo Núcleo de Redes e Comunicações Direção de Serviços de Informática Instituto Superior Técnico
On Wed, Sep 30, 2015 at 03:43:41PM +0100, Israel G. Lugo wrote:
Perhaps you could try to use stubnet option with hidden + summary suboptions to hide these /32 routes to not trigger the summary networks.
Thanks for the suggestion. I tried with:
stubnet A.B.C.253/32 { hidden; summary; };
And with or without:
networks { A.B.C.0/24 };
There was no change. However, I did manage to get it working like this:
I noticed that there is a bug where the original /24 prefix is used for matching even if /32 is really used due to loopback state. -- 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."
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
On 09/30/2015 06:29 PM, Christian Tacke wrote:
[...] 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. [...]
Have you considered using a loopback IP for accessing the A machine? That's how I would do it. I mean, place the IP on interface "lo" as a /32. Then you let OSPF announce it and everyone can access the machine from everywhere, using the most efficient route. That is of course assuming you 1) have additional IPs to assign and 2) can change the clients to use the new IP.
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.
So what you are proposing is basically to create an additional filter hook, inside the OSPF protocol. Something on the path between the OSPF protocol's route table and the LSAs being sent. Correct? Perhaps that may be useful. I do worry, however, that it may start to become too complex, or allow diverging too much from "standard" OSPF. -- Israel G. Lugo Núcleo de Redes e Comunicações Direcção de Serviços de Informática Instituto Superior Técnico
Hi, On Wed, Sep 30, 2015 at 19:18:38 +0100, Israel G. Lugo wrote: [...]
Have you considered using a loopback IP for accessing the A machine? That's how I would do it. I mean, place the IP on interface "lo" as a /32. Then you let OSPF announce it and everyone can access the machine from everywhere, using the most efficient route. That is of course assuming you 1) have additional IPs to assign and 2) can change the clients to use the new IP.
Yes, I have considered this. But since the ISP network is just a plain ethernet /29 without ospf/bgp, I would need to apply proxyarp or something else. All of that feels more complex than my "stubnet IP/32 ..." line in bird's configs.
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.
So what you are proposing is basically to create an additional filter hook, inside the OSPF protocol. Something on the path between the OSPF protocol's route table and the LSAs being sent. Correct?
Correct.
Perhaps that may be useful. I do worry, however, that it may start to become too complex, or allow diverging too much from "standard" OSPF.
Thanks for thinking more about it. That's what a brainstorm idea is for: Someone making thoughts about it. And you're very likely right: It might add a lot of configuration complexity that will confuse people. I wonder, whether some of this could be handled in a normal import filter instead? Cheers Christian -- www.cosmokey.com
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."
participants (3)
-
Christian Tacke -
Israel G. Lugo -
Ondrej Zajicek