Packet loss between Fortigate and B2250
Hello, I am having an issue that I have not been able to resolve, so hoping someone here can point me in the right direction. I have a Fortigate 3700D with 3x 40G interfaces aggregated, with 3x VLANS on the aggregate interface. Then I have 3x B2250´s configured where each blade has 1x 40G from the Fortigate, and configured as trunk with the vlans added. Now when I tried pinging the F5 locally from the Fortigate and from the internet with virtual IP configured, I got maybe 50% drops of packets, both icmp and dns lookups to the F5DNS server. This was with the Fortigate configured as L4 algorithm (layer 4) , and F5 as "Source/Destination IP address port". I then changed the Fortigate to L3 algorithm (layer 3), and I have a much better response rate on the icmp and dns packets (even though I would assume L4 is correct for the source/destination ip address port config on f5 side? So not sure why it works better now..) So while pings do not drop that often, I still get drops maybe every 7-8 time I try. When doing a tcpdump on the F5 I see that the icmp requests stop working everytime right after an ARP request is made from the Fortigate to the F5, as seen from screenshot attached. Might this be due to the F5 blades using different mac addresses, and the Fortigate being confused by that? (even though I set it to work on L3?.. Anyone know or can point me in the right direction? Thanks in advance!
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 cheerssnmp 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 youARP 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!