Forum Discussion
ping return time <1ms but only on load balanced nodes
Hi Dev Central Team,
We're running 11.6 Hotfix 3 on a active/standby physical F5 pair.
We noticed that when we ping www.google.com (or any outside domain), that the time returned is less than 1 ms:
Pinging www.google.com [216.58.216.196] with 32 bytes of data:
Reply from 216.58.216.196: bytes=32 time<1ms TTL=255
Reply from 216.58.216.196: bytes=32 time<1ms TTL=255
However, if we do the same from a non-load balanced server, we get normal ms returned (14 ms in example):
Pinging www.google.com [216.58.216.196] with 32 bytes of data:
Reply from 216.58.216.196: bytes=32 time=14ms TTL=55
Reply from 216.58.216.196: bytes=32 time=14ms TTL=55
Any idea why that is? the load balanced node's default gateway is the F5.
thanks much, Keith
16 Replies
- Brad_Parker_139
Nacreous
Remember, BigIP is a full proxy. When you connect to an IP that is a listener, the BigIP responds. It doesn't just pass the packet through like a switch or router. This includes a ForwardingIP virtual server that you probably have configured(0.0.0.0/0) in order to use the BigIP as your default gateway. So, the public IPs you are pinging are being responded to by the BigIP because it is on your LAN.
- Brad_Parker_139
Nacreous
The TTLs are different for this very reason. 255 means that ICMP packet had no hops to be returned. 55, on the other hand, for your other servers means that returned packet took the 200 hops to be returned from google which is to be expected when the ping actually traverses all the layer 3 devices between it and your server.
- Brad_Parker
Cirrus
Remember, BigIP is a full proxy. When you connect to an IP that is a listener, the BigIP responds. It doesn't just pass the packet through like a switch or router. This includes a ForwardingIP virtual server that you probably have configured(0.0.0.0/0) in order to use the BigIP as your default gateway. So, the public IPs you are pinging are being responded to by the BigIP because it is on your LAN.
- Brad_Parker
Cirrus
The TTLs are different for this very reason. 255 means that ICMP packet had no hops to be returned. 55, on the other hand, for your other servers means that returned packet took the 200 hops to be returned from google which is to be expected when the ping actually traverses all the layer 3 devices between it and your server.
- Renato_166638
Nimbostratus
Did you try a traceroute? Your ping responses are pointing to different TTLs. - keith_varga_107
Nimbostratus
Here's the traceroutes
LB node: C:>tracert www.google.com
Tracing route to www.google.com [216.58.216.196] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms ord31s21-in-f4.1e100.net [216.58.216.196] Trace complete.
nonLB node: C:>tracert www.google.com
Tracing route to www.google.com [216.58.216.196] over a maximum of 30 hops: 1 <1 ms 35 ms 2 ms 10.33.143.8 2 <1 ms <1 ms <1 ms efi-prod-gw0.cust.stargate.net [216.151.85.3] 3 15 ms <1 ms <1 ms g0-1-0-432.car1.pitc.pitbpa.e-xpedient.com [208.40.160.97] 4 14 ms 20 ms 63 ms v4034.acm-core.expedient.com [209.166.144.197] 5 5 ms 4 ms 4 ms te1-4.4035.cr2.strlng.clevoh.e-xpedient.com [209.166.144.202] 6 15 ms 23 ms 20 ms ten2-4.cmk-node.expedient.com [216.130.11.129] 7 14 ms 14 ms 14 ms 74.125.49.130 8 15 ms 14 ms 14 ms 209.85.242.137 9 15 ms 15 ms 14 ms 216.239.51.225 10 15 ms 14 ms 14 ms ord31s21-in-f196.1e100.net [216.58.216.196] Trace complete.
- keith_varga_107
Nimbostratus
Is there some way (or workaround) to get the realistic tracerts for our load balanced nodes?
- Brad_Parker
Cirrus
Not if you are using the LTM as the default gateway in your config. What are you trying to get at with pings? Ping really isn't a metric to be used to gauge performance anyway as most devices classify it as low priority and may even discard it when under load.
- keith_varga_107
Nimbostratus
Hi Brad,
One of our customers is complaining of latency, and we wanted to run tracerts on our load balanced nodes to see issues with specific hops in the round trip to them. but, we cannot see the tracerts because of this issue.
Thanks Keith
- Brad_Parker
Cirrus
You could always run a traceroute from the BigIP itself if you wanted to see the hops upstream. But again like I said, ping is not a very good tool to determine performance. ICMP is not TCP. They are treated different by routers and such. - keith_varga_107
Nimbostratus
thanks much Brad. That's what i recommended as well (to just do the tracert from the router itself), but the application team still wants to know if there's a way around the behavior. - Brad_Parker
Cirrus
We really need to lock that submit button after pressed the first time :-).
- keith_varga_107
Nimbostratus
Just making sure: so i should close this thread with the understanding that it is not possible to get normal traceroute output from an F5 node itself, and no one from F5 can pose a workaround?
- Renato_166638
Nimbostratus
Actually, this is limited by your network design. Moreover, the only difference between tracerouting from the BIG-IP devices and its Nodes are the connection between them, so it looks like a valid test at least for me. That's why I prefer to keep the default gateway unchanged in server's configuration and use AutoMap as the option to BIG-IP access its nodes. I'm not "one from F5". - keith_varga_107
Nimbostratus
thanks Renato! that's something we can possibly try in a pinch.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com