Can someone please comment at least on the differing behaviour of zebrad with respect to routes of type "ra" and "kernel"?
Should "ra" be trated like "kernel"? If not, why? -- Alex On Mon, 21 Mar 2016 14:57:17 +0100, g...@switch.ch said: > 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 _______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
