ARP/MAC Tables Not Updating on Core Switches After F5 LTM Failover (GARP Issue?)
We have two F5 LTM 5250v appliances configured with 2 vCMP instances each in an HA pair (Active/Standby). 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. Port-Channel127/vPC127 = F5ADC01 Port-Channel128/vPC128 = F5ADC01 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. We are having an issue during automatic or manual failover where the MAC addresses for the virtual-servers are not being updated. If F5ADC01 is Active and we force it Standby, it immediately changes to Standby and F5ADC02 immediately takes over the Active role. 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. We have multiple partitions on each vCMP instance with several VLANs associated with each partition. Each partition only has a single route-domain the VLANs are allocated to. 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. We are not using MAC masquerading. The ARP time out on the Nexus 7Ks is 1500 seconds (default) so it takes 25min after a failover for a full network recovery. Eventually the ARP entries age out for all virtual servers and get refreshed with the correct MAC address. Obviously this is not acceptable. 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. We have confirmed the upstream core switches are not dropping any GARPs. As a test I went in and manually disabled all virtual-servers and then enabled them and all MACs updated immediately. I have opened a support case with F5 and we have yet to determine where the issue lies. Does anybody have any ideas what the issue might be? If I need to provide more information about our configuration, let me know. We are pretty new to the F5 platform. We recently migrated from the Cisco ACE30 platform. Failover on the ACE platform worked perfectly. Similar cabling setup (two port-channels to two separate Catalyst 6509 switches with an ACE30 module in each switch). After ACE failover, the MAC tables/ARP caches immediately updated. Thank You!
How does MAC Masquerading work exactly?
Hi, I am trying to grasp how exactly MAC Masquerading works, and how it behaves differently during a failover. Situation without MAC Masquerading Every floating Self IP & virtual IP will have a gARP anouncement with the new MAC address issued on the device becoming active, making the switches now route to the new device. Issues can arise if network equipment cannot handle the amount of gARPs. Situation with MAC Masquerading Every floating Self IP in the cluster has the same MAC address. Not sure about the vIPs. During failover, the switches need not learn a new MAC address but just learn it's now available on a new switch. (in our case, L3 switches with OSPF) So how do vIPs fit in the mac masquerade story? And how do switches learn the vIPs/floating Self IPs are now on this port without gARPs? The DevCentral articles do not discuss this in great detail.
F5 Gratuitous-ARP issue when failover
Hi Last night we upgrade F5 v. 11.5.4 to v.12.1.3 when we failover from old unit v.11.5.4 to newly unit v.12.1.3, We experience some IP has more request timeout than the rest (we ping ip of each vs (~20 ip) when failover) From my understanding, F5 will send G-ARP to neighbour unit when it's active. Is it possible that G-ARP that sent is drop so those IP experience longer downtime due to still using old ARP? or Is it because neighbour unit not use some G-ARP from F5? or Is there any possibilities that make neighbour unit not learn new ARP as expect? Thank youProxy ARP on F5 LTM
Folks, We have an LTM (version 10.2.4) configured inline with the servers being load balanced (so it's the gateway for the load balanced servers). There is a server that resides on a load balanced subnet that's attempting to perform a discovery process that sends arp requests and some of those arp requests are to servers the reside on another load balanaced subnet. When performing a packet capture of the arp activity I see the request being broadcast searching for the particular host on the other subnet: 15:00:54.548521 arp who-has 10.82.43.97 tell 10.82.42.100 But I never see the reply. I'd assume this is the expected behavior and the F5 will not proxy arp? Thanks, Brian
ARP problem with F5
Hi all, we have deployed BIG IP 13.1.0 in our customer and everything is working fine exept two things: The F5 has virtual server in network (let's call this network X) , which acts as forwarding proxy. The problem is that, communication between hosts in network X is very strange. When we ping from some host A to another host B the ping is successful, but the arp table on host A says that MAC address on host B is the F5 ?? F5 only has some address in this network, that's all. The second problem is that FTP is not working. When clients wants to reach some ftp severs outside the organization is not working. We have virtual servers for ftp, but still we face this problem.. What could be the problem ?
LTM 11.2 "How to Remove Incomplete ARP"
We have re IP'd some servers, but SYNC From Primary F5 to Standby Unit fails due to standby F5 holding incomplete ARP entries on old Re IP'd Servers. Gui does not show any ARP entry on dynamic ARP. TMOS, shows the incomplete ARP via "show /net arp all | grep 10.212.224.51" but deleting via "delete /net arp 10.212.224.51". Can anyone assist? Thank you.
snmp mac address and if index query
i normally query for all arp entries using the RFC1213-MIB mib and ipNetToMediaPhysAddress or ipNetToPhysicalPhysAddress oid; the typical output is something like: IP-MIB::ipNetToPhysicalPhysAddress.13.ipv4."172.18.x.y" = STRING: 0:d0:ff:ee:fc:a IP-MIB::ipNetToPhysicalPhysAddress.14.ipv4."127.2.0.1" = STRING: 0:23:e9:6e:97:0 IP-MIB::ipNetToPhysicalPhysAddress.17.ipv4."127.1.1.2" = STRING: 0:1:23:45:67:0 IP-MIB::ipNetToPhysicalPhysAddress.17.ipv4."127.1.1.3" = STRING: 0:1:23:45:67:1 IP-MIB::ipNetToPhysicalPhysAddress.17.ipv4."127.1.1.4" = STRING: 0:1:23:45:67:2 IP-MIB::ipNetToPhysicalPhysAddress.17.ipv4."127.1.1.5" = STRING: 0:1:23:45:67:3 IP-MIB::ipNetToPhysicalPhysAddress.19.ipv4."a.b.c.d" = STRING: 0:0:c:7:ac:97 (first an last ip's redacted) the number before the ipv4 bit usually corresponds to the ifIndex of the interface that the arp was seen on. however, on our ltm box: IF-MIB::ifIndex.80 = INTEGER: 80 IF-MIB::ifIndex.736 = INTEGER: 736 IF-MIB::ifIndex.752 = INTEGER: 752 IF-MIB::ifIndex.768 = INTEGER: 768 IF-MIB::ifIndex.784 = INTEGER: 784 IF-MIB::ifIndex.800 = INTEGER: 800 IF-MIB::ifIndex.816 = INTEGER: 816 IF-MIB::ifIndex.832 = INTEGER: 832 IF-MIB::ifIndex.848 = INTEGER: 848 IF-MIB::ifIndex.864 = INTEGER: 864 IF-MIB::ifIndex.880 = INTEGER: 880 IF-MIB::ifIndex.896 = INTEGER: 896 IF-MIB::ifIndex.912 = INTEGER: 912 IF-MIB::ifIndex.928 = INTEGER: 928 (as you can see the index's don't match). how can i match the ifIndex value from ipNetToPhysicalPhysAddress to a real physical description like that presented with sysInterfaceName ?