Forum Discussion
Issues processing GARP were an initial thought until you mentioned the problem persists even with MAC masquerading. Given that (and the timeframe being around the Cisco-default 300 second MAC address aging) have you looked at neighboring switch MAC/CAM tables when the issue appears? In the MAC masquerading configuration, are the neighboring switches associating the shared MAC with the correct port (port associated to the active unit)?
I've seen partial traffic loss issues when the neighboring device couldn't process all of the GARP traffic on failover. But this only impacted some of the traffic, and was resolved with MAC masquerading (as then only the neighboring switch has to update the MAC table; L2-L3 mapping doesn't change).
K25241134 Describes a race-condition issue where the BIGIP transitioning to Offline sends GARPs, but the workaround is to configure MAC masquerade.
Outside of this issue, can F5_A successfully operate and handle traffic in a steady-state condition? No issues with traffic handling on that device outside of a ~5 minute outage when the traffic-group transitions from F5_B to F5_A?
How are the two units connected to the rest of the network? Have also seen partial traffic loss in a Cisco HSRP/vPC environment when admin forgot to enable 'peer-gateway' as described in K12440. Impact depends on how traffic is flowing through the network.