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