I'm starting to feel stupid talking to myself here. What are the magic words I need to say to get any kind of response to this issue?
It's a rather fundamental difference in behaviuor and it breaks my use case. Help, please. -- Alex On Wed, 30 Mar 2016 12:36:20 +0200, g...@switch.ch said: > 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 _______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
