Protocols device and direct getting out of sync
Hi, I've noticed that when adding addresses, BIRD will notice (i.e. "birdc show interface" will immediately show the newly-added address) but the direct protocol isn't notified until the periodic device scan triggers. The below console log with embedded comments shows what's happening. I'm running BIRD 1.4.0 and the config file contains simply: debug protocols all; protocol device {} protocol direct {} $ bird -d & [1] 22511 bird: device1: Initializing bird: direct1: Initializing bird: device1: Starting bird: device1: Scanning interfaces bird: device1: Connected to table master bird: device1: State changed to feed bird: Chosen router ID 87.238.42.150 according to interface em1 bird: direct1: Starting bird: direct1: Connected to table master bird: direct1: State changed to feed bird: Started bird: device1: State changed to up bird: direct1 < primary address 127.0.0.0/8 on interface lo added bird: direct1 < primary address 87.238.42.128/25 on interface em1 added bird: direct1 > added [best] 87.238.42.128/25 dev em1 bird: direct1 < primary address 100.66.7.5/32 on interface tun0 added bird: direct1 > added [best] 100.66.7.5/32 dev tun0 bird: direct1: State changed to up $ birdc show route; birdc show interface BIRD 1.4.0 ready. 100.66.7.5/32 dev tun0 [direct1 13:23:04] * (240) 87.238.42.128/25 dev em1 [direct1 13:23:04] * (240) BIRD 1.4.0 ready. lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=65536 127.0.0.1/8 (Primary, scope host) em1 up (index=2) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 87.238.42.150/25 (Primary, scope univ) tun0 up (index=5) PtP Multicast AdminUp LinkUp MTU=1500 100.66.7.6/32 (Primary, opposite 100.66.7.5, scope univ) $ ip address add 192.0.2.1/32 dev lo bird: direct1 < primary address 192.0.2.1/32 on interface lo removed bird: direct1 < secondary address 127.0.0.0/8 on interface lo removed The debug messages from BIRD show up instantly. Not sure why why they say «removed», as 127.0.0.1 is unchanged, while 192.0.2.1 was *added*. $ birdc show route; birdc show interface BIRD 1.4.0 ready. 100.66.7.5/32 dev tun0 [direct1 13:23:04] * (240) 87.238.42.128/25 dev em1 [direct1 13:23:04] * (240) BIRD 1.4.0 ready. lo DOWN (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=65536 192.0.2.1/32 (Primary, scope univ) 127.0.0.1/8 (Unselected, scope host) em1 up (index=2) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 87.238.42.150/25 (Primary, scope univ) tun0 up (index=5) PtP Multicast AdminUp LinkUp MTU=1500 100.66.7.6/32 (Primary, opposite 100.66.7.5, scope univ) So here it has clearly noticed that there's an new address on lo, but for some reason it's not showing up in BIRD's routing table. Also, for some reason "lo" is now marked DOWN? bird: device1: Scanning interfaces bird: direct1 < primary address 192.0.2.1/32 on interface lo added bird: direct1 > added [best] 192.0.2.1/32 dev lo bird: direct1 < secondary address 127.0.0.0/8 on interface lo added $ birdc show route; birdc show interface BIRD 1.4.0 ready. 100.66.7.5/32 dev tun0 [direct1 13:23:05] * (240) 87.238.42.128/25 dev em1 [direct1 13:23:05] * (240) 192.0.2.1/32 dev lo [direct1 13:24:05] * (240) BIRD 1.4.0 ready. lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=65536 192.0.2.1/32 (Primary, scope univ) 127.0.0.1/8 (Unselected, scope host) em1 up (index=2) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 87.238.42.150/25 (Primary, scope univ) tun0 up (index=5) PtP Multicast AdminUp LinkUp MTU=1500 So after the device scan, things look OK again. If I now proceed to add another address, it will instantly show up in the routing table, so this problem only appears to happen with the first address(es) I add (until the first time the device scan has been done after adding addresses), afterwards it seems to work fine. The impact of this behaviour is that it takes much longer than necessary for newly-added addresses to be advertised to the rest of the network (using RIP or OSPF or whatever). I can reduce the impact of the problem with using "protocol device { scan time 1; }" but it does seem a bit wasteful to poll the interfaces that often. Tore
On Fri, Feb 07, 2014 at 01:43:21PM +0100, Tore Anderson wrote:
Hi, I've noticed that when adding addresses, BIRD will notice (i.e. "birdc show interface" will immediately show the newly-added address) but the direct protocol isn't notified until the periodic device scan triggers. The below console log with embedded comments shows what's happening. I'm running BIRD 1.4.0 and the config file contains simply: ...
$ birdc show route; birdc show interface BIRD 1.4.0 ready. lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=65536 127.0.0.1/8 (Primary, scope host) 100.66.7.6/32 (Primary, opposite 100.66.7.5, scope univ)
$ ip address add 192.0.2.1/32 dev lo bird: direct1 < primary address 192.0.2.1/32 on interface lo removed bird: direct1 < secondary address 127.0.0.0/8 on interface lo removed
The debug messages from BIRD show up instantly. Not sure why why they say ?removed?, as 127.0.0.1 is unchanged, while 192.0.2.1 was *added*. ... So here it has clearly noticed that there's an new address on lo, but for some reason it's not showing up in BIRD's routing table. Also, for some reason "lo" is now marked DOWN?
Hello The main problem in your example is that primary address of the iface changed, which caused virtual restart of the iface, which caused the device to be down until the next scan and log messages about removal of addresses. The whole primary address selection is a relic of the past and will be removed in the future, currently you could fix your problem by explicitly declaring that 127.0.0.1 is the primary address on the loopback: protocol device { primary "lo" 127.0.0.1; } After that, any other manipulation of addresses on loopback should be seamless and immediate. -- 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."
* Ondrej Zajicek
The main problem in your example is that primary address of the iface changed, which caused virtual restart of the iface, which caused the device to be down until the next scan and log messages about removal of addresses. The whole primary address selection is a relic of the past and will be removed in the future, currently you could fix your problem by explicitly declaring that 127.0.0.1 is the primary address on the loopback:
protocol device { primary "lo" 127.0.0.1; }
After that, any other manipulation of addresses on loopback should be seamless and immediate.
Thank you! This workaround works very well, now any added addresses on the lo interface shows up as active in the BIRD routing table immediately, and most importantly, gets advertised to the upstream RIP neighbour immediately. The only remaining problem for me now is to make address *removals* be treated equally instantaneous. As I mentioned on this list Feb 5th, BIRD doesn't appear to withdraw routes with triggered updates, and it doesn't seem like it is possible to use BFD in conjunction with RIP either. Relying on the upstream's router's route timeout timer kind of sucks, since the invalid route can linger for minutes, during which traffic will be blackholed. Any suggestions on how to improve this? Best regards, Tore Anderson
participants (2)
-
Ondrej Zajicek -
Tore Anderson