We were also linked the following SOL article from support but we have monitored the switch and checked the logs/statistics and have confirmed the switches are not dropping any ARP traffic: SOL7332: Gratuitous ARPs may be lost after a BIG-IP failover event This is to verify whether the unit is sending GARPs after failover or not.
#VPC MAC ADDRESS LEARNING MANUAL#
We have another maintenance window scheduled for this Wednesday evening to perform another manual failover on our DEVQA vCMP instance where I will be setting up a tcpdump on the unit that will become Active to capture all ARP traffic. The HSRP virtual-address is used as the default gateway by the nodes. Each VLAN has an SVI on both upstream Nexus switches and we are utilizing HSRP with a virtual-address. They only send return traffic through the F5s for traffic entering through the virtual-server. Note, the F5s are not utilized as the default gateway by the nodes. We are also utilizing Auto-Last Hop so return traffic passes through the original source VLAN instead of using the single default route we have tied to the single route-domain. We are utilizing Auto-Map for all virtual-servers instead of using SNAT pools. All virtual-servers share the same subnet as their designated VLAN/floating-IP. Every VLAN has 2 Self-IPs and 1 Floating IP address. Each partition has multiple VLANs allocated to it.
Each partition has only one default route-domain. We have multiple partitions on each vCMP instance. They e-mailed me and linked me the following SOL article: SOL11880: BIG-IP objects may not send gratuitous ARP requests during failover
We have not heard anything definitive back from support yet. After ACE failover, the MAC tables/ARP caches immediately updated.
Similar cabling setup (two port-channels to two separate Catalyst 6509 switches with an ACE30 module in each switch). Failover on the ACE platform worked perfectly. We recently migrated from the Cisco ACE30 platform. Does anybody have any ideas what the issue might be? If I need to provide more information about our configuration, let me know. I have opened a support case with F5 and we have yet to determine where the issue lies. As a test I went in and manually disabled all virtual-servers and then enabled them and all MACs updated immediately. We have confirmed the upstream core switches are not dropping any GARPs. I found an SOL article that talks about when GARPs can be missed after failover: SOL7332: Gratuitous ARPs may be lost after a BIG-IP failover event. Eventually the ARP entries age out for all virtual servers and get refreshed with the correct MAC address.
#VPC MAC ADDRESS LEARNING FULL#
The ARP time out on the Nexus 7Ks is 1500 seconds (default) so it takes 25min after a failover for a full network recovery. For traffic to virtual-servers, we are using Auto-MAP to SNAT to the floating Self-IP and using Auto-Last Hop so return traffic passes through the correct source VLAN. Each partition only has a single route-domain the VLANs are allocated to. We have multiple partitions on each vCMP instance with several VLANs associated with each partition. However, the ARP tables on the Nexus 7K Core switches do not get updated so all the virtual-servers continue to have the MAC address associated with F5ADC01. If F5ADC01 is Active and we force it Standby, it immediately changes to Standby and F5ADC02 immediately takes over the Active role. We are having an issue during automatic or manual failover where the MAC addresses for the virtual-servers are not being updated. When I look at the MAC address tables on both 7K1 and 7K2, I can see all the individual F5 MACs for each VLAN we have configured on the F5 vCMP instances. Each F5 5250v has a 10G uplink to two core switches (Cisco Nexus 7010) configured as an LACP port-channel on the F5 side and a Port-Channel/vPC on the Nexus side. We have two Fv appliances configured with 2 vCMP instances each in an HA pair (Active/Standby).