Page MenuHomeVyOS Platform

router-advert: allow turning off radvd RemoveAdvOnExit, FlushRDNSS and FlushDNSSL for VRRP setups
Closed, ResolvedPublic

Description

I run two VyOS routers as a VRRP pair that share the link-local address fe80::1, and both send router advertisements from it, using the source-address option added in T4809:

set service router-advert interface eth2 source-address 'fe80::1'

When I rebooted the VRRP master, IPv6 pings from a host on the segment to internet addresses lost 1.6 seconds. A capture on one host showed the master's radvd sending a final RA from fe80::1 with router lifetime 0 (and RDNSS lifetime 0) about 30 ms after keepalived began stopping, while the master still held the VIP. The host removed its IPv6 default route and only put it back when the backup's RA from fe80::1 arrived 1.65 seconds later. IPv4 pings to internet addresses lost nothing.

This is radvd's RemoveAdvOnExit, which defaults to on. Because the RA source is the shared address, hosts read the zero lifetime as the shared router going away, though the backup is taking over that same address. The radvd.conf man page covers this case:

RemoveAdvOnExit on|off
Upon shutdown, send a final advertisement with zero Router Lifetime. This should cause the router and routes to be immediately removed from the receiving end-nodes' route table. This may need to be disabled ("off") in an vrrp or carp setup.

FlushRDNSS and FlushDNSSL (both default on) do the same for the advertised DNS servers and search list. None of the three can be set from the VyOS CLI today. The related RemoveRoute already is, as route <prefix> no-remove-route.

It does not happen on every shutdown. On an earlier reboot of the same router I saw no zero-lifetime RA and no loss, with the same stop order in the journal. I have not worked out what differs between the two runs.

Validation on my routers

I edited the installed radvd.conf.j2 on the master to emit RemoveAdvOnExit off; and FlushRDNSS off; on the fe80::1 interfaces only, then rebooted it. There was no zero-lifetime RA from fe80::1, the host's default route was never removed (polled every 0.1 s), and IPv6 pings to internet addresses lost nothing. One interface that sends RAs from its own link-local address was left unedited, and it still sent its zero-lifetime RA 20 ms after keepalived began stopping, so radvd did reach its goodbye path on that shutdown. In radvd's stop_advert_foo() the final RA is only sent when RemoveAdvOnExit is on, so with it off the result does not depend on shutdown timing. That is one reboot with the change, not a long soak. I did not check whether hosts dropped the advertised resolvers, and I do not use DNSSL. I included both because they work the same way and the man page lists them together.

Proposed fix

Three valueless per-interface options following the existing no-* names:

set service router-advert interface <if> no-remove-on-exit       # RemoveAdvOnExit off
set service router-advert interface <if> no-flush-name-server    # FlushRDNSS off
set service router-advert interface <if> no-flush-dnssl          # FlushDNSSL off

Nothing is rendered when they are unset, so the generated radvd.conf stays the same for existing configs. I have a patch with a smoketest and will put up a PR against rolling. In a VM running the 2026.10.07-0712 nightly with the patched packages, the router-advert smoketest passes (11 tests), and with the options set, stopping radvd sends no zero-lifetime RA where it did without them.

Related tasks

  • T8180: VRRP-aware control of RAs. It is about RAs on the same kind of VRRP setup, and the answer there points at source-address. With source-address in place, the zero-lifetime goodbye still goes out from the shared address.
  • T4809: added source-address for this same fe80::1 VRRP setup.

Before filing I searched vyos.dev for RemoveAdvOnExit, FlushRDNSS, router-advert vrrp, radvd shutdown and router lifetime, and found nothing beyond T8180 and the older T840.

Environment

  • VyOS 2026.09.25-2211-rolling on both routers
  • radvd 2.20
  • VRRP (keepalived) with a link-local VIP fe80::1, RAs sent with source-address fe80::1
  • KVM guests on Proxmox VE

Details

Version
2026.09.25-2211-rolling
Is it a breaking change?
Perfectly compatible
Issue type
Feature (new functionality)