Alex - I haven't answered because I don't know the answers to your question without some research and investigation. Unfortunately routing protocols are complicated and It's sometimes a non-trivial amount of work to answer someone's question.
donald On Mon, Apr 25, 2016 at 3:13 AM, <g...@switch.ch> wrote: > > 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 >
_______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
