Bird 1.6.3 removing IPv6 device routes on Linux (3.10.0)

Ben Arblaster ben at andatche.com
Wed Jan 31 15:06:22 CET 2018


Hi,

I’m seeing an issue with bird 1.6.3 where IPv6 device routes are unexpectedly removed from the kernel table on Linux (3.10.0, CentOS 7) when bird removes a matching route learned via another protocol (in this case OSPF).

To reproduce, I’ve rigged up a very simple test with two bird6 instances running OSPF in a single area 0 over a ptp tunnel. Configs are here - https://gist.github.com/andatche/ca5b5ac120e09b6b8171ec5ca95d2e25	

If I add an address/network (e.g. fd00::1/64) to an interface (dummy0) on host A, the route is flooded by A, learned by B and correctly installed in the kernel table on B:

fd00::/64 via fe80::5efe:ae2:b006 dev tun0 proto bird metric 1024	

If I then add the same address/network (e.g. fd00::1/64) to an interface (dummy0) on host B, at that instant a device route is installed in the kernel table alongside the existing route on host B and it now looks like this:

fd00::/64 dev dummy0 proto kernel metric 256	
fd00::/64 via fe80::5efe:ae2:b006 dev tun0 proto bird metric 1024	

Shortly after, bird picks up the new address/network on dummy0, recalculates the area and correctly selects the connected route as the new best. It then removes the old route via host A from the kernel table, as expected:

kernel1 < removed fd00::/64 via fe80::5efe:ae2:b006 on tun0	

However, this causes both the route via host A *and* the device route to be removed from the kernel table, leaving the kernel table on host B with no route to fd00::/64 at all.

# ip -6 route show fd00::/64
#

This is a change in behaviour from 1.4.5 and seems like a bug, rather than the expected behaviour?

Regards,
Ben

-- 
Ben Arblaster
e: ben at andatche.com
t: +447943860840
w: https://andatche.com



More information about the Bird-users mailing list