15-Dec-2022 13:17 - edited 16-Dec-2022 06:48
We recently replaced some legacy LTM platforms with VEs in VMware. When VEs were activated, pools were green but virtual servers were unreachable. I figured out the problem was related to MAC masquerade (https://support.f5.com/csp/article/K13502).
I asked the VMware team if they could enable promiscuous mode on a portgroup via a VMware.com link referenced here (https://support.f5.com/csp/article/K31552842). They obliged and vips became accessible.
I do not know the history of why MAC masquerade was set. I’m wondering if it is recommended in most situations or only for specific ones. I’m also wondering if configuring promiscuous mode in VMware puts our VEs at risk or is otherwise bad.
Thoughts and opinions are welcome and appreciated!
I've disabled MAC masquerade in all virtualized deployments. The benefits of MAC masquerade are not that huge in contrast to impact that enabling promiscous mode may have on the remaining network environment.
On the other hand I always enable MAC masquerade for pysical deployments, since you dont have any negative side effects. Only pure benefits...
I'm curious to learn any issues you have noticed with virtualized failovers without MAC Masquerade (dropped sessions, etc.).
17-Dec-2022 02:05 - edited 17-Dec-2022 02:06
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.