VRRP: macvlan interface remains up even if lower layer interface is down - traffic is discarded as a result

[andrejota]

Description

When the lower layer interface on which a macvlan interface is created goes down (e.g. lost carrier, admin down, ...) VRRP-specific macvlan interfaces remain active. This means that the local route to the network that VRRP interface connects to also remains active.

This leads to discarding of traffic that could be routed to destination via alternative route instead of the still-present connected route kept up by the macvlan interface that is still active.

Version

FRRouting 10.0 (__CENSORED__) on Linux(6.8.10-1.trp).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
configured with:
    '--build=x86_64-redhat-linux' '--host=x86_64-pc-linux-gnu' '--with-sysroot=yes' '--prefix=/usr' '--libdir=/usr/lib64' '--localstatedir=/var' '--runstatedir=/run' '--sysconfdir=/etc' '--disable-doc' '--disable-ripd' '--disable-ripngd' '--disable-ospfd' '--disable-ospf6d' '--disable-nhrpd' '--disable-eigrpd' '--disable-babeld' '--disable-watchfrr' '--disable-pbrd' '--disable-sharpd' '--disable-fabricd' '--disable-pathd' '--disable-ospfapi' '--disable-protobuf' '--enable-multipath=64' '--enable-user=quagga' '--enable-group=quagga' '--enable-vty-group=quagga' '--enable-pcre2posix' '--with-libpam' 'build_alias=x86_64-redhat-linux' 'host_alias=x86_64-pc-linux-gnu' 'AR=x86_64-pc-linux-gnu-ar' 'LD=x86_64-pc-linux-gnu-ld' 'OBJCOPY=x86_64-pc-linux-gnu-objcopy' 'RANLIB=x86_64-pc-linux-gnu-ranlib' 'STRIP=x86_64-pc-linux-gnu-strip' 'PKG_CONFIG=x86_64-pc-linux-gnu-pkg-config' 'PKG_CONFIG_LIBDIR=__CENSORED__/sys/usr/lib64/pkgconfig' 'CC=x86_64-pc-linux-gnu-gcc' 'CPP=x86_64-pc-linux-gnu-gcc -E' 'CXX=x86_64-pc-linux-gnu-g++'

How to reproduce

• Configure VRRP as per documentation on two routers: r1, r2 assuming r1 and r2 are connected to the same switch.
• Configure additional direct link between r1, r2 (approximates otherwise complex routing topology)
• Configure any router protocol that exchanges local address information between r1 and r2 via the direct link. OSPF will probably do though I'm using IS-IS.

Disconnect switch cable (or set link down) on router r1, leaving the direct r1-r2 link and r2 link to switch connected.

Try to access any IP address of r1 from any address that r1 VRRP interface directly connects to.

Expected behavior

All routable (specifically interface and loopback) addresses of router r1 are still reachable from all parts of the network. Router r1 can still correctly route packets to all valid destinations.

Actual behavior

r1 VRRP interface remains up which results in router r1 discarding all egressing traffic that is routed to or via network behind the disconnected link. Furthermore, because link up means that network route is not withdrawn from any routing protocols that redistribute connected routes, discarding isn't limited to router r1 and can affect other parts of the network.

While discarding from the rest of the network can be mitigated for example by using route-map filters for BGP that filter out VRRP interfaces, I don't know of any solution to restore full connectivity to router r1 itself.

Additional context

The issue was already raised and closed/rejected in #10364. While the statement "VRRP transitions to Master when it either has priority or has not heard from any other routers participating in the virtual router. " is technically correct, I believe that it misses the other effects of leaving the interface up. In this case, incorrectly leaving the connected route in place. This makes routing to the address of this network from the router impossible, because the system will continue forwarding packets via the macvlan interface (effectively discarding them) even if an alternative route to the same network exists.

Unless I'm missing something and there's a workaround that I do not know, I would consider VRRP implementation to be broken. While packets won't arrive over the disconnected link (duh!), in every topology where packets destined to this link reach the affected router, they will be discarded. A partial mitigation with route map filters excluding macvlan interface(s) is possible. I do not know of a complete mitigation native to FRR - only external processes emulating what I think FRR should be doing.

Checklist

• [X] I have searched the open issues for this bug.
• [X] I have not included sensitive information in this report.