Forum Discussion

keith_varga_107's avatar
keith_varga_107
Icon for Nimbostratus rankNimbostratus
Nov 16, 2015

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

  • 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's avatar
      Brad_Parker_139
      Icon for Nacreous rankNacreous
      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.
  • 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's avatar
      Brad_Parker
      Icon for Cirrus rankCirrus
      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.
  • 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.
    
  • Is there some way (or workaround) to get the realistic tracerts for our load balanced nodes?

     

    • Brad_Parker's avatar
      Brad_Parker
      Icon for Cirrus rankCirrus
      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.
  • 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's avatar
      Brad_Parker
      Icon for Cirrus rankCirrus
      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's avatar
      keith_varga_107
      Icon for Nimbostratus rankNimbostratus
      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's avatar
      Brad_Parker
      Icon for Cirrus rankCirrus
      We really need to lock that submit button after pressed the first time :-).
  • 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's avatar
      Renato_166638
      Icon for Nimbostratus rankNimbostratus
      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".