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