unable to ping VIP from server with the F5 as the DGW

In our current setup, we have a cluster of servers that utilize the F5 load balancer as their default gateway. This load balancer operates as a high availability (HA) pair, with the default gateway set to the floating IP of the F5 device. Additionally, on this very same F5 load balancer, there exists another subnet hosting virtual IPs for other servers within the network, where the F5 is not configured as the default gateway.

The issue at hand is that the servers utilizing the F5 as their gateway are encountering difficulties in reaching the IP addresses within the other subnet on the same F5 device. Specifically, they are unable to establish connectivity via ping to either the virtual IPs or the self IPs of the devices located in the other subnet.

The VIPs in the 10.1.216.x network are reachable everywhere else.

ping 10.1.216.113

Pinging 10.1.216.113 with 32 bytes of data:
Request timed out.
Reply from 10.1.228.3: Destination host unreachable.
Request timed out.
Reply from 10.1.228.3: Destination host unreachable.

Ping statistics for 10.1.216.113:
Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),

ping 10.1.216.10

Pinging 10.1.216.10 with 32 bytes of data:
Request timed out.
Request timed out.

Ping statistics for 10.1.216.10:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

ping 10.1.216.11

Pinging 10.1.216.11 with 32 bytes of data:
Reply from 10.1.216.11: bytes=32 time<1ms TTL=254
Reply from 10.1.216.11: bytes=32 time<1ms TTL=254
Reply from 10.1.216.11: bytes=32 time=1ms TTL=254

Ping statistics for 10.1.216.11:

ping 10.1.216.12

Pinging 10.1.216.12 with 32 bytes of data:
Request timed out.
Request timed out.

Ping statistics for 10.1.216.12:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Windows IP Configuration

Ethernet adapter Ethernet0:

Connection-specific DNS Suffix . :
IPv4 Address. . . . . . . . . . . : 10.1.228.27
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.228.1

Any sugestions?

application delivery

Tim_Patrick
Jul 07, 2023
so if it was suggested and I didnt see it I apoligize. The fix for me was to go to the virtual server that I was trying to access from the host nework (10.1.228.x) which used the F5 as its gateway and add the VLAN to the VLAN and tunnels section. it only had the ext vlan present and when I created the new network and new vlan (int_vlan) I needed to add it to that in order for it to connect to the VIPS

Tim_Patrick
Altostratus
Jul 07, 2023
so if it was suggested and I didnt see it I apoligize. The fix for me was to go to the virtual server that I was trying to access from the host nework (10.1.228.x) which used the F5 as its gateway and add the VLAN to the VLAN and tunnels section. it only had the ext vlan present and when I created the new network and new vlan (int_vlan) I needed to add it to that in order for it to connect to the VIPS
whisperer
MVP
Jun 28, 2023
You are probably running into asyn routing. So definitely look into VIP bounceback:
https://community.f5.com/t5/technical-forum/vip-bounceback/td-p/189691
Sounds like the destination servers may be tryin to get back to the sources servers locally, rather than going through the F5. SNAT automap on the VIPs may help here as well.
Mohamed_Ahmed_Kansoh
MVP
Jun 28, 2023
Hi Tim_Patrick ,
First don't rely on Ping/ICMP in your test , as F5 Bigip will reply to your Ping/ICMP packets if the Server B UP and will not forward traffic to server B itself.

I see you are trying to test reachability from Server A to Server B .
also you mentioned that VIP subnet 10.1.216.X can be reached from elsewhere. ( please test this by taking TCPdump on your Active F5 Bigip unit ) that Server A can reach well to bigip.

>> Second thing , you need to configure ( SNAT Auto map on Virtual server setting ( 10.1.216.113 ) ) as you said , Bigip is not the default gateway for Server B I guess.
Make sure Bigip can reach to servers which hosted by this ( VIP = 10.1.216.113 ) Ping this server from F5 bigip itself . to identify more where the issue exists.

Take this Pcap , and share the capture with me for further investigation if this available with you >>

tcpdump -nnnveti 0.0:nnnp host 10.1.228.27 -s0 -S -w /var/log/TEST_PCAP.pcap

Take it through F5 bigip bash while trying to access server B VIP.
Please send your virtual server configuration as well to have a look.

Thanks 🙂
- Tim_Patrick
  Altostratus
  Jun 29, 2023
  
  Mohamed, thanks for the reply.
  To clarify the VIP 10.1.216.113 can be accessed across all networks in our environment except for 10.1.228.x which sits behind the F5, the same F5 that is hosting the 10.1.216.x network
  
  you need to configure ( SNAT Auto map on Virtual server setting ( 10.1.216.113 ) ) Automap is configured for this VIP and all VIPS in the 10.1.216.x network(VIP range)
  
  devices in the 10.1.228.x network are unable to access devices in the 10.1.216.x range. The F5 is the default gateway.
  so for the traffic flow, when ServerA sends the traffic 10.1.216.113 it will got the F5, the same F5 where the VIP resides. The VIP is configured with Automap so when the servers in the VIP pool respnd it shoud go back through the F5 and not out an external router
  The F5 itself can ping the server from the 10.1.228.3 address
  config # ping -I 10.1.228.3 10.1.216.113
  PING 10.1.216.113 (10.1.216.113) from 10.1.228.3 : 56(84) bytes of data.
  64 bytes from 10.1.216.113: icmp_seq=1 ttl=255 time=0.197 ms
  64 bytes from 10.1.216.113: icmp_seq=2 ttl=255 time=0.285 ms
  but other devices in that same network are unable to access any network services in the 10.1.216.x network. They are able to access everything on the network out side of 10.1.216.x
  - Paulius
    MVP
    Jun 29, 2023
    Tim_Patrick Would you be able to provide either screencaptures or CLI output for the virtual servers (VS) in question? Sometimes a VS will not respond on a certain IP if you have it listening only on certain VLANS but without your configuration it makes it a bit difficult to figure out what your issue might be. As Mohamed_Ahmed_Kansoh mentioned, if you do not enable SNAT automap or SNAT pool list your traffic balancing to the servers in that segment that doesn't have the F5 as the default gateway will not work. You might receive a bit more helpful information for troubleshooting using a tcpdump for your traffic that you are generating. The nice thing about the tcpdump that Mohamed_Ahmed_Kansoh provided is when you open it in wireshark it will show you what VS you are bound to and what interfaces your traffic traverses from source to destination.
wtwiggs
Altocumulus
Jul 04, 2023
hi Tim_Patrick do you have a forwarding (layer 3) virtual server configured? if you do, can you share details of that configuration?
if you do not, then this could be a factor. if you need some additional background on setting up a forwarding virtual server then this is a good reference:
https://packetpushers.net/stateless-routing-f5-ltm/
also, check if your protocol is set to "all protocols" and not just tcp or udp on the forwarding vservers. this will prevent icmp (ping) packets from getting thru if not set to all protocols.
besides using SNAT (auto map is one option, or you can create a SNAT pool), you might also consider leaving SNAT off for this "routed" traffic and create a return route (either static route on the 10.1.216.113 server, with a gateway of 10.1.216.10 for the 10.1.228.0/24 network... or if you have the option to set the route on a router that the 10.1.216.x network is using?)... you could still use SNAT on virtual servers handling specific traffic that you are reverse proxying or load balancing, but for traffic that is "routing" thru the F5 you might find it easier (long term) preserve real IP thru the device.
we are extensively using "inline" F5's where it is either the default gateway (floating self IP as you are) or using the zebos routing with OSPF or BGP to establish the routes, and forwarding virtual servers (without SNAT)... this is on i5800 hardware with 10G and 40G interfaces... acting as a "stateless" router for all traffic, and specific services load balacned / reverse proxied... so the concept you are trying to accomplish is definitely do-able... just may need to ensure your F5 is ready to forward the packets (needs a "listener" aka forwarding virtual server) and routes (direct/connected, or static or dynamic, etc) and then even ICMP will pass thru without issue.
please share more details on your configuration, route tables, etc. and we should be able to get it working!
- wtwiggs
  Altocumulus
  Jul 04, 2023
  sorry I just reread your issue and my first response may not be on point... if I understand (more) correctly... it is just the VIPs and self IPs that you cannot ping?
  is it just from the 10.1.228.x network that you cannot ping those 10.1.216.x VIP/selfIP? can you ping them from the 10.1.216.x network?
  have you checked "Port Lockdown" on the self IP address properties (possibly set to default of "Allow None" and if so does "Allow All" work)?
  and have you checked the VLAN(s) the VIPs are listening on?
  here is a related possibility:
  https://my.f5.com/manage/s/article/K3475
  and a "forwarding (layer 3)" virtual server may still be needed, if not in place, so that the ping packets will "forward" thru from the interface acting as the gateway to the other interface(s) where the far end self IP or VIP is listening...
  hopefully some of this helps... please provide some additional configuration details, as we do have similar in place and working so I think we can get it working.
  - Tim_Patrick
    Altostratus
    Jul 07, 2023
    Wtwiggs, thanks for the response, I have included a file with a summary and screenshots of what I am experiencing. I did double check the port lockdown and it is set to allow all
    routing_issue.pdf727 KB