VRRP mastership results in arp cache flush
 

Hello,

When a VRRP backup becomes master and becomes owner of the VIP/VMAC on an interface, I notice that the arp cache is flushed. Why is this done?

In net/core/dev.c:
NETDEV_CHANGEADDR:
rt_cache_flush(dev_net(dev));
...

The ARP cache contains IP-MAC information of other devices in the network. Only the local interface's IP/MAC is getting updated so it should not ideally affect the cache of other devices.

Prior to the backup becoming master, there would have been an ARP entry for the VMAC/VIP in its ARP cache.

Logically, a node obviously shouldn't have an ARP entry for its own IP or MAC address, and I'm guessing that's probably why rt_cache_flush is being called. Having said that, I don't know what (if anything) would happen if such an entry were allowed to remain until it expired.

Flushing the ARP cache should have a negligible effect on performance, as it will immediately trigger ARP requests for any IPs involving active sessions. If you're seeing lost connections or performance degradation during failover, check if perhaps the ARP requests are being dropped by a switch with a broadcast limit or "storm control" setting.

Thank you. Perhaps we should only remove the VIP/VMAC arp entry and keep the rest as it is since others may not be related to VRRP?

Sure, you could do that.

But if you're seeing ARP-related issues during failover, that's a fault in and of itself. It could be related to the small ARP storm that occurs due to the cache flush, or it could be the switch not updating its MAC table fast enough when the VMAC suddenly appears at a different port.

Thanks for your response. I will check the switch and if updates are happening sooner than later.