arp
20 TopicsARP/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!6.4KViews0likes22CommentsHow 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.3.1KViews0likes1CommentF5 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 you1.9KViews0likes5CommentsProxy 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, Brian1.3KViews0likes3CommentsARP 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 ?704Views0likes9CommentsLTM 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.607Views0likes3Commentssnmp 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 ?507Views0likes1CommentMove vIP to other cluster
Hello, So I have a 11.5.1 cluster where we are having some problems. We have a fresh 12.1.1 cluster ready to take over some vIPs for testing. I would like to flawlessly move vIPs from the old cluster to the new one. I prefer not to import the configuration to evade corrupt config or duplicate address problems. Current method: Disable ARP on the old Virtual Address & enable this on the new one + wait for the ARP entry to expire on the L3 switches. However, I can never ping the virtual address when enabled on the new cluster. Ideas? The switch sees the new MAC address, but the ping does not reply. (nor when I ping the vIP from the new bigip itself.) To move it back to the old cluster, I disabled ARP on the new cluster and re-enabled it on the old cluster. Then I needed to wait for the ARP entry to expire on the switches. (Comparable to https://devcentral.f5.com/articles/ruby-and-icontrol-migrating-virtual-addresses-using-arp )Solved506Views0likes4CommentsARP Request on shared vlan in vCMP-guest
Hi experts! My plan was to install a second vCMP-guest on my BIG-IP 5200v-box. But for some reson only one of the vCMP-guest recives the ARP broadcast request and not the other when i use the same shared VLAN, in this case DMZ6. tcpdump -ni DMZ6 -e -p arp - shows that only one of the guest recives the arp-requests. Egress arp-request works as excpected, from both guests. Same version software - 13.1.0.1 b0.0.8 . Any ideas are appreciated! Thanks /OttoSolved501Views0likes2Comments