VIP with irule hosting HTTP response not responding to ARP
As per the title, if i static arp on the client i get to the HTTP page and get the expected response. I have TCPDumped the interface and can see the incomming ARP frames, F5 just isn't responding. 12:08:57.957310 arp who-has 192.168.16.23 tell 192.168.16.145 12:09:00.769257 arp who-has 192.168.16.23 tell 192.168.16.145 12:09:01.458528 arp who-has 192.168.16.23 tell 192.168.16.145 12:09:02.457333 arp who-has 192.168.16.23 tell 192.168.16.145 12:09:06.767878 arp who-has 192.168.16.23 tell 192.168.16.145 12:09:07.457120 arp who-has 192.168.16.23 tell 192.168.16.145 12:09:08.457004 arp who-has 192.168.16.23 tell 192.168.16.145 12:09:17.133658 arp who-has 192.168.18.23 (ff:ff:ff:ff:ff:ff) tell 192.168.18.23 12:09:17.143121 arp who-has 192.168.18.23 (ff:ff:ff:ff:ff:ff) tell 192.168.18.23 12:09:17.152998 arp who-has 192.168.18.23 (ff:ff:ff:ff:ff:ff) tell 192.168.18.23 12:09:17.163152 arp who-has 192.168.18.23 (ff:ff:ff:ff:ff:ff) tell 192.168.18.23 12:09:17.173184 arp who-has 192.168.18.23 (ff:ff:ff:ff:ff:ff) tell 192.168.18.23 Yes ARP is enabled on the Virtual Address. root@(dc1-f5-swg)(cfg-sync In Sync)(/S1-green-P:Eval:Active)(/GUEST-SWG-PARTITION)(tmos) list ltm virtual-address /GUEST-SWG-PARTITION/192.168.18.23%2 ltm virtual-address 192.168.18.23%2 { address 192.168.18.23 mask 255.255.255.255 partition GUEST-SWG-PARTITION traffic-group /Common/traffic-group-1 } root@(dc1-f5-swg)(cfg-sync In Sync)(/S1-green-P:Eval:Active)(/GUEST-SWG-PARTITION)(tmos) list ltm virtual-address /GUEST-SWG-PARTITION/192.168.18.23%2 arp ltm virtual-address 192.168.18.23%2 { arp enabled } Anyone seen anything like this or have any ideas? 6 HF5 cheers
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 ?
LTM in Azure - VIP not responding
I have 2 machines in the Azure cloud, both on the same subnet / vnet 10.1.1.0/24 I can ping the Self IP of the LTM 10.1.1.100 but not the VIP 10.1.1.200 - if we were in the "real world" then the LTM isn't ARPing for the .200 address but as this is cloud and there's no L2 I'm wondering how I get this to work .. Any tips anyone? Tnx
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 you
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 ?
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!
NAT and Enabled On
Hi, I tried to figure out how Enabled On works for NAT entries (v13 VE). I am a bit surprised by results and would like to find out if this is kind of bug or correct behavior. Scenario: Two vlans: ext, int NAT with: NAT Address in ext vlan, NAT Origin Address - IP of host_int in int vlan Results for Enabled On All - communication from/to host_int working ext - communication from/to host_int working - why? I understand why communication to host is working but why from host (initiated by host_int) int - no communication working, target host in ext vlan is receiving for example ping request but ARP request to resolve NAT Address MAC is not working - no reply from BIG-IP. Seems a bit strange but maybe there is logic here. Same if host in external vlan tries to reach host_int (see as well notes at the end) no vlan - no communication working - that is expected One issue not directly related to BIG-IP. Is that usual host behavior to issue ARP request for src IP of ping request? After receiving ping request target host knows MAC of src IP. Is that kind of security measure to verify if src MAC in ping request really exists on attached network? Of course it's done when there is no MAC in ARP cache? Win 2008 Srv target host. Strange is that when MAC is in ARP cache on target host reply is returned - BIG-IP is passing it back to host_int (case with NAT Enabled on int vlan). But right after this reply MAC is removed from ARP cache. Next request triggers ARP resolution but it fails and reply is not send back. If MAC is added as static entry on target host then communication from host_int is working (no ARP resolution is needed so target host knows where to send reply) Communication to host_int is not working in this case - seems that BIG-IP is silently dropping ping request send to NAT Address. Another issue noticed: when two different NAT entries were created (IPs in the same subnets as described) and one of them was set to Enabled on - no vlan and latter on even disabled then another stopped to work - there were no ARP replies send from BIG-IP for this second NAT address. After removing second NAT entry everything started to work - is that normal, or maybe just behavior on VE? Piotr