[quagga-dev 14963] Re: IPv6 BGP default route ignored when using SLAAC

gall at switch.ch gall at switch.ch
Wed Mar 30 11:36:20 BST 2016


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, gall at 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 at lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-dev




More information about the Quagga-dev mailing list