radvd lifetime question

[Tore Anderson]

* Nico Schottelius
> we got a network in which clients using dhcpcd withdraw the router
> advertisements sent by bird too early:
>
> --------------------------------------------------------------------------------
> Dec 19 06:33:15 bibimbap daemon.warn dhcpcd[18464]: wlan0: fe80::20d:b9ff:fe48:3bb8: router expired
> Dec 19 06:33:15 bibimbap daemon.warn dhcpcd[18464]: wlan0: part of a Router Advertisement expired
> Dec 19 06:38:22 bibimbap daemon.warn dhcpcd[18464]: wlan0: fe80::20d:b9ff:fe48:3bb8: router expired
> Dec 19 06:38:22 bibimbap daemon.warn dhcpcd[18464]: wlan0: part of a Router Advertisement expired
> Dec 19 06:39:30 bibimbap daemon.warn dhcpcd[18464]: wlan0: fe80::20d:b9ff:fe46:3bd4: router expired
> Dec 19 06:39:30 bibimbap daemon.warn dhcpcd[18464]: wlan0: part of a Router Advertisement expired
> --------------------------------------------------------------------------------

You should probably verify that the client is seeing (all) the RAs sent 
by BIRD. With such a tiny RA interval, you don't need much packet loss 
for the default router to expire.

Try: tcpdump -pnvi wlan0 'icmp6[0] == 134'

For what it is worth, wireless networks are particularly tricky, as 
broadcast/multicast packet delivery usually much less reliable than 
unicast. Also, battery-powered devices often ignore broadcast/multicast 
for extended periods of time in order to stay in low-power saving 
modes.(Some implementations explicitly try to reconfirm the default 
router by sending an RS after coming out of a low-power mode instead of 
expiring it right away.)

> The config in bird is:
>
> --------------------------------------------------------------------------------
> protocol radv {
>      # Pods / bridge
>      interface "eth0" {
>          max ra interval 10;
>
>          prefix 2a0a:5480::/64 { preferred lifetime 86400; };
>          prefix 2a0a:e5c0:13::/64 { skip; };
>          default preference high;
>      };
>      rdnss {
>        ns 2a0a:5480:0:a::a;
>        ns 2a0a:5480:0:a::b;
>        lifetime 86400;
>      };
> }
> --------------------------------------------------------------------------------
>
> This causes RAs to be sent that look like this:
>
> --------------------------------------------------------------------------------
> interface wlan0
> {
> 	AdvSendAdvert on;
> 	# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
> 	AdvManagedFlag off;
> 	AdvOtherConfigFlag off;
> 	AdvReachableTime 0;
> 	AdvRetransTimer 0;
> 	AdvCurHopLimit 64;
> 	AdvDefaultLifetime 30;
> 	AdvHomeAgentFlag off;
> 	AdvDefaultPreference low;
>
> 	prefix 2a0a:5480::/64
> 	{
> 		AdvValidLifetime 86400;
> 		AdvPreferredLifetime 86400;
> 		AdvOnLink on;
> 		AdvAutonomous on;
> 		AdvRouterAddr off;
> 	}; # End of prefix definition
>
>
> 	RDNSS 2a0a:5480:0:a::a 2a0a:5480:0:a::b
> 	{
> 		AdvRDNSSLifetime 86400;
> 	}; # End of RDNSS definition
>
> }; # End of interface definition
> --------------------------------------------------------------------------------
>
> It seems that the "AdvDefaultLifetime 30;" is wrong.

No, it is correct. You have set "max ra interval 10", and the default 
AdvDefaultLifetime is 3 times that value.

https://datatracker.ietf.org/doc/html/rfc4861#section-6.2.1

> --------------------------------------------------------------------------------
> /bird/bird.conf:897:31 Default lifetime must be in range 0-9000
> --------------------------------------------------------------------------------
>
> I read in the manpage of radvd that indeed 9000 is the max (not sure why
> that limit is at 9k though...), but what I am wondering is what is the
> right approach to this?
The upper limit of 9000 comes from RFC4861, see above link.
> p.s.: A low "max ra interval" allows us to run multiple, active routers
> in the same network and clients will quickly fall over to the second
> router, if one is not functioning correctly.

Setting AdvDefaultLifetime to 9000 would prevent quick failover, since 
that is what governs the default route timeout, not the RA interval.

I'd suggest considering a FHRP like VRRP for redundancy instead, then 
you can have long AdvDefaultLifetime and quick failover at the same 
time. With VRRP, everything about the default router (in particular its 
IPv6 link-local and Ethernet MAC addresses) stays the same following a 
failover, so clients do not need to change their routing tables to 
remain connected.

Tore