I've been using quagga for a long time to implement router-style "loopback" addresses on multi-homed hosts, i.e. I configure a /128 on the lo device and announce it via BGP. The host receives a default route ::/0 and I use BGP policies to select which interface to prefer for outbound traffic. At the same time, the host uses SLAAC to set up a default route on each interface as a fallback.
Here is an example using Quagga 0.99.22.4 on Linux 3.2.0 which works as desired: $ ip -6 r l | grep default default via fe80::2a94:fff:fefd:5bc0 dev eth2 proto zebra metric 10 default via fe80::2a94:fff:fefd:5bc0 dev eth0 proto kernel metric 1024 expires 1794sec hoplimit 64 default via fe80::2a94:fff:fefd:5bc0 dev eth2 proto kernel metric 1024 expires 1783sec hoplimit 64 default via fe80::2a94:fff:fefd:4940 dev eth3 proto kernel metric 1024 expires 1676sec hoplimit 64 default via fe80::2a94:fff:fefd:4940 dev eth1 proto kernel metric 1024 expires 1794sec hoplimit 64 zebrad> sh ipv6 ro Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv6, I - IS-IS, B - BGP, A - Babel, > - selected route, * - FIB route B>* ::/0 [20/10] via fe80::2a94:fff:fefd:5bc0, eth2, 03w3d01h C>* ::1/128 is directly connected, lo C>* 2001:620::1a/128 is directly connected, lo C>* 2001:620:0:ff::3/128 is directly connected, lo C>* 2001:620:0:800c::/64 is directly connected, eth0 C>* 2001:620:0:800d::/64 is directly connected, eth2 C>* 2001:620:0:800e::/64 is directly connected, eth1 C>* 2001:620:0:800f::/64 is directly connected, eth3 C * fe80::/64 is directly connected, eth3 C * fe80::/64 is directly connected, eth1 C * fe80::/64 is directly connected, eth2 C>* fe80::/64 is directly connected, eth0 zebrad> sh ipv6 ro ::/0 Routing entry for ::/0 Known via "bgp", distance 20, metric 10, best Last update 03w3d01h ago * fe80::2a94:fff:fefd:5bc0, via eth2 The BGP route is installed in the kernel with metric 10 as expected. If the host looses its BGP peers, it still has the default routes via SLAAC. On another system running Quagga 0.99.23.1 and Linux 3.16.0, the BGP route doesn't get installed: $ ip -6 r l | grep default default via fe80::207:7dff:fe76:5980 dev eth0 proto ra metric 1024 expires 1631sec hoplimit 64 default via fe80::207:7dff:fe76:5940 dev eth4 proto ra metric 1024 expires 1709sec hoplimit 64 zebrad> sh ipv6 ro Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv6, I - IS-IS, B - BGP, A - Babel, > - selected route, * - FIB route B ::/0 [20/1] via fe80::207:7dff:fe76:5940, eth4, 04w3d23h K>* ::/0 via fe80::207:7dff:fe76:5940, eth4 C>* ::1/128 is directly connected, lo C>* 2001:620::10/128 is directly connected, lo C>* 2001:620:0:8018::/64 is directly connected, eth0 C>* 2001:620:0:8019::/64 is directly connected, eth4 C * fe80::/64 is directly connected, eth4 C>* fe80::/64 is directly connected, eth0 zebrad> sh ipv6 ro ::/0 Routing entry for ::/0 Known via "bgp", distance 20, metric 1 Last update 04w3d23h ago fe80::207:7dff:fe76:5940, via eth4 Routing entry for ::/0 Known via "kernel", distance 0, metric 1024, best * fe80::207:7dff:fe76:5940, via eth4 The difference is that zebrad now picks up one of the default routes from SLAAC with an administrative distance of 0, which makes it impossible to override with BGP. The obvious difference is that the 3.16 kernel uses proto "ra" instead of proto "kernel" for the routes learned via SLAAC (i don't know in which kernel version this started to happen). I'm totally unfamiliar with the Quagga code, but a glance at zebra/rt_netlink.c:netlink_routing_table() seems to suggest that routes of type "kernel" are always ignored due to if (rtm->rtm_protocol == RTPROT_KERNEL) return 0; Since the routes in question are now using proto "ra", they are no longer ignored, hence the different behaviour of zebrad. So, my question is whether this is really how it's supposed to be. If so, how can I override it? I do believe that I should be able to do that. If it's a bug, maybe routes of type RTPROT_RA should be ignored as well? -- Alex _______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev