MAC Address Not Updated After F5 LTM Failover

[ohforce55]

Hi,

I have F5 LTM Active and standby boxes. After the active box fails over to the standby box, if I check the MAC address in the switch (3750) which is connected to the LTM boxes, I still see the mac address of the active box..

I have to do clear arp in order to make the MAC address to be updated. I'm looking for solutions that the MAC address can be updated immediately as the LTM box fails over without doing clear arp.

I read some articles regarding the issue and found some solutions but am not sure if these will help. Please advise.

1. Use MAC masquerading address in LTM boxes. Or increase hold-queue in the switch.

https://support.f5.com/csp/article/K7332

I don't see any dropped packet on the interface but F5 recommends to increase the hold queue in the switch because the ARP packet is just ignored although the interface still receives the packet. Currently the hold queue is set to 75.

2. Adjust the ARP rate limit.

https://devcentral.f5.com/questions/arp-mac-tables-not-updating-on-core-switches-after-f5-ltm-failover-garp-issue-48953   (Just see the answer from the article).

The guy increased the rate limit but for my case, the arp inspection is disabled so it already has no limit.

If you know anything besides the ones I mentioned above, please let me know.

Thank you in advance!

[educruz]

Good day,

When the F5 LTM performs a failover, I would expect that it sends something called "Gratuitous ARP".
This ARP packet is useful to inform other hosts (such as the Cat3750 switch), that the MAC is no longer advertised via the previous "NIC".

On the other hand, ideally, the moment the Cat3750 switch receives and processes this gARP packet, it should flush the old entry and learn the new one. This completes a successful failover.

My theory is that either the F5 does not send a gARP, or the switch fails to process it.

My suggestion is that a packet capture is taken at the F5 to see if such gARP is sent in the first place. You can also do some conditional debugging at the Cat3750 (debug condition interface Gi x/y/z), followed by debug arp to see if such packet is ever received.

Alternatively, you may try to reload/upgrade the Cat3750 to see if some bug does not allow the Cat3750 switch the proper processing of gARP packets, although I would prefer to have evidence and not just upgrade.

Hope this helps,

Eduardo.

[ohforce55]

Hi,

Thank you for your detail explanations!

I used MAC masquerade solution on F5 and it resolved the issue.

Thank you so much!