Forum Discussion
Thanks Kai!
I'm curious to learn any issues you have noticed with virtualized failovers without MAC Masquerade (dropped sessions, etc.).
So far I haven't experienced any "known" issues (at least I've not detected any).
Let me explain what is happening behind the scenes to understand the more or less "theoretical" impact the setting is fighting...
During a failover event, all your floating IPs (Selfs, VIPs, SNATs) are going to send a gratuitous ARP packet telling the entire network that a given IP is now using this MAC address.
Masquerade Enabled: You dont change the MAC for a given IP during a Failover. You still send those gratuitous ARP packets, but those are basically only used to tell your switches to forward traffic for your Masquerade MAC to a new switch port. Every L3 instances in your network will refresh the MAC table (nothing changed). Gratious ARP packets may become lost in transit, but luckily you probably send those for a bunch of floating IPs so that a single gratious ARP packet would be enough to train your switches to use a new port.
Masquerade Disabled: You change the MAC address of your floating IPs during failover. Gratious ARP needs now explain this change for every single floating IP to every single L3 instance in your network. The impact of gratuitous ARP packet loss is now in a exponential growth. The more floating IPs you use and the more L3 instances are connected to your network the more likely is a single packet loss. When a L3 instance missed to receive a gratuitous ARP packet, it will not be able to connect to the floating IP until ARP caches timed out. The issues will be sporadic and will probably only affect a few floating IPs and a few connected L3 devices...
Note: Beside of what was written above. Some L3 router are limiting the amount of gratuitous ARP packet to become processed per second. If their limit is configured to 250 and you going to failover 251 floating IPs, then this will always fail for 1 random floating IP.
Cheers, Kai