I'm running bird 1.2.4 on a series of FreeBSD OSPF routers. Had a backhoe go through some fiber this morning (really), and was surprised to find that bird didn't update routes automatically. The state of the interface in question looked like so, while bird was still happily reporting that it was available: bge1: flags=8802<UP,BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM> ether 00:18:8b:f6:e5:a8 inet x.x.x.x netmask 0xfffffffc broadcast x.x.x.x media: Ethernet autoselect (none) status: no carrier I performed a 'ifconfig bge1 down', and the failover routes immediately propagated. I've got a device scan in my config: protocol device { scan time 10; } I don't see anything else to add or modify in the config for checking interface status -- did I miss something? My anticipated behavior would be that a link down would perform a route update. It appears that interface state with the 'device' protocol is different or separate from its link state. Or maybe this is a FreeBSD (or Broadcom?) specific issue? Any ideas/suggestions appreciated. -- Mahlon E. Smith http://www.martini.nu/contact.html
On Tue, Nov 02, 2010 at 11:00:39AM -0700, Mahlon E. Smith wrote:
I'm running bird 1.2.4 on a series of FreeBSD OSPF routers.
Had a backhoe go through some fiber this morning (really), and was surprised to find that bird didn't update routes automatically.
...
I don't see anything else to add or modify in the config for checking interface status -- did I miss something? My anticipated behavior would be that a link down would perform a route update.
Hello BIRD currently does not check or use link up/down state. OSPF routers generally check reachability using HELLO packets, not by reported link state, although sometimes this is also implemented. Drawback of HELLO protocol (to check reachability) is that it has some timeout to find out that the neighbor became unreachable. By default, it is ~ 40 seconds, But it is possible to configure it to < 10 seconds (see hello/wait/dead interface options). -- 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."
On Tue, Nov 02, 2010 at 11:00:39AM -0700, Mahlon E. Smith wrote:
I'm running bird 1.2.4 on a series of FreeBSD OSPF routers.
Had a backhoe go through some fiber this morning (really), and was surprised to find that bird didn't update routes automatically.
...
I don't see anything else to add or modify in the config for checking interface status -- did I miss something? My anticipated behavior would be that a link down would perform a route update.
Hello
BIRD currently does not check or use link up/down state. OSPF routers generally check reachability using HELLO packets, not by reported link state, although sometimes this is also implemented. Drawback of HELLO protocol (to check reachability) is that it has some timeout to find out that the neighbor became unreachable. By default, it is ~ 40 seconds, But it is possible to configure it to < 10 seconds (see hello/wait/dead interface options).
I think BIRD really should check link state. Changing HELLO < 10 secs isn't going to make it much better and will also increase load and network bandwidth. Jocke
On 03/11/2010 2:28 AM, Joakim Tjernlund wrote:
On Tue, Nov 02, 2010 at 11:00:39AM -0700, Mahlon E. Smith wrote:
... Hello
BIRD currently does not check or use link up/down state. OSPF routers generally check reachability using HELLO packets, not by reported link state, although sometimes this is also implemented. Drawback of HELLO protocol (to check reachability) is that it has some timeout to find out that the neighbor became unreachable. By default, it is ~ 40 seconds, But it is possible to configure it to < 10 seconds (see hello/wait/dead interface options). I think BIRD really should check link state. Changing HELLO < 10 secs isn't going to make it much better and will also increase load and network bandwidth.
Jocke I second this. Verifying an interface's link state should be a pretty easy operation, and as I am planning on using BIRD in production fairly soon, this is a feature I would really appreciate.
-- M
On Tue, Nov 02, 2010, Ondrej Zajicek wrote:
BIRD currently does not check or use link up/down state. OSPF routers generally check reachability using HELLO packets, not by reported link state, although sometimes this is also implemented.
Hmm, in this particular case, bird is currently responsible for managing routes that go out through that interface. (Used for internet failover, on the external interface.) With the link state down, the OSPF daemon was still reachable to the internal network, so the HELLO check doesn't help me unless the /internal/ interface dies, or the entire router does. Is there an alternative way to accomplish what I'm after with bird? Any chance an option to the 'device' protocol to take link state into consideration when determining availability is on the roadmap? Thanks for the quick reply, Ondrej! -- Mahlon E. Smith http://www.martini.nu/contact.html
On Wed, Nov 03, 2010, Mahlon E. Smith wrote:
[...]
Is there an alternative way to accomplish what I'm after with bird? Any chance an option to the 'device' protocol to take link state into consideration when determining availability is on the roadmap?
Looks like the attached patch (against 1.2.4) does the trick. Obviously, this'll only work on *bsd systems, I'll leave other OSs to those more experienced than I. :) -- Mahlon E. Smith http://www.martini.nu/contact.html
On Wed, Nov 03, 2010 at 07:39:48AM -0700, Mahlon E. Smith wrote:
On Tue, Nov 02, 2010, Ondrej Zajicek wrote:
BIRD currently does not check or use link up/down state. OSPF routers generally check reachability using HELLO packets, not by reported link state, although sometimes this is also implemented.
Hmm, in this particular case, bird is currently responsible for managing routes that go out through that interface. (Used for internet failover, on the external interface.) With the link state down, the OSPF daemon was still reachable to the internal network, so the HELLO check doesn't help me unless the /internal/ interface dies, or the entire router does.
Although i agree with Joakim Tjernlund and others that link state change detection is useful to get faster response to internal network unreachability. I think that in your case you would need something slightly different. I understand that you have some (probably static) routes with gateway accessible through given (external) interface and you want to detect unreachability of the (external) gateway to add/remove that (static) routes. Detecting a link state is crude, because there might be many other kinds of problems that does not change link state. I would suggest to use some shell/perl script that ping to the gateway and according to its reachability it will enable/disable static protocol (with routes using that gateway) in BIRD. I plan to implement a link state change handling, but it will take some time, it is definitely more complicated than the patch you sent (for example, it should differentiate between administrative up/down and link state up/down). -- 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."
On Thu, Nov 04, 2010, Ondrej Zajicek wrote:
Although i agree with Joakim Tjernlund and others that link state change detection is useful to get faster response to internal network unreachability. I think that in your case you would need something slightly different.
I understand that you have some (probably static) routes with gateway accessible through given (external) interface and you want to detect unreachability of the (external) gateway to add/remove that (static) routes.
Yep, exactly. The static is then repropagated into the OSPF table, and a remote area with the same setup acts as failover.
Detecting a link state is crude, because there might be many other kinds of problems that does not change link state.
Agreed, although I'd maintain that in no case should a lack of link be a valid condition for bird to think the interface is available, regardless of the potential for other network problems.
I would suggest to use some shell/perl script that ping to the gateway and according to its reachability it will enable/disable static protocol (with routes using that gateway) in BIRD.
I completely missed that birdc had that capability. Neat.
I plan to implement a link state change handling, but it will take some time, it is definitely more complicated than the patch you sent (for example, it should differentiate between administrative up/down and link state up/down).
That's great to hear. I certainly didn't assume my patch would be used, I've just always thought it more polite to try when requesting a feature. Thanks for your attention to it. -- Mahlon E. Smith http://www.martini.nu/contact.html
On Thu, Nov 04, 2010 at 08:25:34AM -0700, Mahlon E. Smith wrote:
Detecting a link state is crude, because there might be many other kinds of problems that does not change link state.
Agreed, although I'd maintain that in no case should a lack of link be a valid condition for bird to think the interface is available, regardless of the potential for other network problems.
If you do not have redundancy, it is usually better to keep static routes installed even if the gateway is temorarily unreachable - if such routes are removed, packets for that destination are routed using less specific route (like default route), which is usually unexpected, useless and causes route loops. If you keep the routes, the packets for that destination are discarded with appropriate ICMP message (destination unreachable). So definitely, it should be configurable behavior. BTW, there is one corner case when route to interface with link down is valid and reachable - if you have one-way link (and asymmetric routing). -- 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."
On do, 2010-11-04 at 10:24 +0100, Ondrej Zajicek wrote:
I would suggest to use some shell/perl script that ping to the gateway and according to its reachability it will enable/disable static protocol (with routes using that gateway) in BIRD.
While we're on this topic... I'm facing a similar situation, where a bunch of publicly addressable hosts have a primary default route and a secondary. I was wondering if there is some reliable way of doing this kind of failover, or even if there is a ready-made solution out there. My concern with doing this myself is important scenarios I might be missing. For example, routers that drop pings under congestion. Or indeed if both my routers end up in an unreachable state, to not end up with an empty route table. I'm not on FreeBSD, but Linux myself. And I know Linux can do failover using the neighbour table and multiple routes with metrics. But all of this appears to be undocumented voodoo. What's really the proper way of doing this? Thanks, -- Stéphan
participants (5)
-
Joakim Tjernlund -
Mahlon E. Smith -
Marty Anstey -
Ondrej Zajicek -
Stéphan Kochen