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
