Thanks, Bruce. I ask this because every time I run a UTM update that changes the Master role to another node in our cluster, I have to mass disable/enable all additional addresses under Interfaces and Routing > Interfaces > Additional Addresses. Otherwise, they don't get "re-ARPed", if that makes sense.
All additional addresses use a /32 mask. Obviously, I would like to avoid this step each time I update the UTM code.
These nodes are connected to a Cisco 6504-E Catalyst switch running IOS Version 12.2(33)SXH7.
The Sophos tech who is working the case says he has never heard of that issue, and recommends trying to change the subnet masks before the next firmware update to see if it makes a difference...
You may want to check out your switch / router configuration(s) ... I've had issues where switches / routers "held onto" old ARP entries -- in a similar fashion to what you are describing. Look in the area of how it handles ARP caches. If you are running 9.2xx on bare metal (not virtualized) I've several customers running HA, and we do internally here, and the switchover is seamless, even with 10 or 12 additional IPs defined on several different interfaces.
Your mention of bare metal just made a lightbulb go off... We started this cluster running on VMware but ended up using too much CPU so we moved to physical. The thing is, this was when 9.x had (has?) a problem with the HA virtual MAC stuff when running on VMware, so I had turned it off with "cc".
When I restored the config to the physical machines, that setting to not use a virtual MAC came with it, apparently:
# cc get ha advanced virtual_mac 0
So, should I be able to set this back to "on" without causing any problems? The next arp request should just return the new virtual MAC instead of the current physical one, right?
