Hi Donald On Wed, 27 Apr 2016 07:36:50 -0400, Donald Sharp <[email protected]> said:
> 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. I understand that, but without at least an acknowledgement of the question I can't tell whether somebody feels repsonsible for the issue or I'm just being ignored. This case is probably not that complicated, though. There must be a reason why RTPROT_KERNEL is ignored already. It seems likely that the same reason can simply be applied to RTPROT_RA (which used to be covered by RTPROT_KERNEL in older kernels). I did check that this solves my problem and makes zebra produce the same routing table as with older kernels, see my reply to Michael's suggestion. -- Alex > donald > On Mon, Apr 25, 2016 at 3:13 AM, <[email protected]> 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, [email protected] 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, [email protected] 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 >> >> [email protected] >> >> https://lists.quagga.net/mailman/listinfo/quagga-dev >> >> > _______________________________________________ >> > Quagga-dev mailing list >> > [email protected] >> > https://lists.quagga.net/mailman/listinfo/quagga-dev >> >> _______________________________________________ >> Quagga-dev mailing list >> [email protected] >> https://lists.quagga.net/mailman/listinfo/quagga-dev >> _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
