Is it normal for 2-digit ms ping reply from internal gateway?

[RabbitSF]

I work for a school that has the Cisco network devices including ASA, switches, WiFi controller & APs. Recently one of the parents told me that when he ping our internal gateway from his phone he got something like "64 bytes from 10.20.0.1: icmp_seq=5 ttl=255 time=22.225 ms" which seems to be not right. He said the reply time normally should be one digit only instead of two digits (22.225ms in this case). 

Is that true? 

I ran a ping to the gateway 10.20.0.1 from my laptop and the replies are mostly two digits between 10ms and 30ms. But when I ping the APs , switches, the wifi controller or the ASA firewall, they mostly have one digit replies. Can anyone tell me what would be causing the problem and should I look into something to troubleshoot? 

Thanks much in advance!

[Jon Marshall]

Firstly what device the gateway ? 

Secondly is it really a problem ie. are there any issues in terms of performance in the network ?

Jon

[RabbitSF]

The gateway is WS-C3850-24P (two of them together)

There is no performance issue with the network. One of the APs in a classroom got offline and there was no wifi so that parent ran a speedtest and found out the ping reply was not normal. That's how the topic brought up. 

[Jon Marshall]

No performance issue equals no problem :) 

Seriously though if the network is working well personally I don't spend time looking into things like this but I accept others might see it differently. 

Jon

[Deepak Kumar]

Hi,

Are you testing over the LAN or WLAN? Try to test from both media and share the output. Sometimes this delay is noticed over wifi due to many reasons as high density, Channel Busy, Overload on the AP or controller, Switching issue, etc. Office this delay is not good in the LAN. 

Also, share the Traceroute command output.

Regards,

Deepak Kumar

[RabbitSF]

It happens on both LAN and WLAN. 

I ran twice of traceroute, see below.

$ traceroute to www.google.com (172.217.14.196), 64 hops max

  1   10.20.0.1  17.948ms  23.434ms  21.646ms

  2   xxx.xxx.xxx.xxx  2.905ms  2.353ms  2.300ms

  3   68.87.194.73  2.793ms  1.863ms  1.696ms

  4   162.151.78.89  5.837ms  8.864ms  3.368ms

  5   68.86.143.93  6.832ms  4.348ms  7.109ms

  6   96.112.146.22  5.015ms  4.104ms  4.118ms

  7   *  *  *

  8   108.170.237.22  7.129ms  6.132ms  6.108ms

  9   108.170.242.83  5.434ms  4.850ms  4.698ms

10   74.125.253.190  5.424ms  4.473ms  6.058ms

11   209.85.253.8  26.639ms  26.099ms  26.401ms

12   216.239.46.209  25.854ms  25.552ms  25.637ms

13   72.14.236.175  26.060ms  25.599ms  25.633ms

14   74.125.243.177  27.069ms  28.162ms  26.543ms

15   209.85.254.171  27.173ms  26.469ms  26.340ms

16   172.217.14.196  26.489ms  25.487ms  25.574ms

$ traceroute to www.google.com (172.217.14.196), 64 hops max

  1   10.20.0.1  9.308ms  10.167ms  9.123ms

  2  xxx.xxx.xxx.xxx  3.269ms  2.266ms  6.954ms

  3   68.87.194.73  2.519ms  2.535ms  6.927ms

  4   162.151.78.89  3.813ms  3.219ms  3.405ms

  5   68.86.143.93  3.868ms  4.152ms  3.637ms

  6   96.112.146.22  4.636ms  4.066ms  4.220ms

  7   *  *  *

  8   108.170.237.118  6.633ms  5.918ms  6.079ms

  9   108.170.242.237  6.766ms  5.067ms  6.764ms

10   72.14.237.147  5.104ms  4.596ms  4.834ms

11   209.85.253.8  27.162ms  26.261ms  26.649ms

12   216.239.46.209  26.232ms  41.858ms  25.603ms

13   108.170.226.97  26.656ms  26.714ms  26.558ms

14   74.125.243.193  26.278ms  25.650ms  25.768ms

15   209.85.254.237  26.635ms  26.466ms  30.244ms

16   172.217.14.196  26.186ms  25.910ms  25.770ms

[Deepak Kumar]

HI,

What is on your gateway 10.20.0.1 (ASA/Switch)? What are CPU/RAM and bandwidth use on pick and normal time?

Is it possible to share a Low-level diagram, interface statistics, Any security policies as ACL, etc? The network is flat L3 network/Mixed network or Layer 3 network?

Regards,

Deepak Kumar

[paul driver]

Hello

---

@RabbitSF wrote:

I work for a school that has the Cisco network devices including ASA, switches, WiFi controller & APs. Recently one of the parents told me that when he ping our internal gateway from his phone he got something like "64 bytes from 10.20.0.1: icmp_seq=5 ttl=255 time=22.225 ms" which seems to be not right. He said the reply time normally should be one digit only instead of two digits (22.225ms in this case). 

Is that true? 

I ran a ping to the gateway 10.20.0.1 from my laptop and the replies are mostly two digits between 10ms and 30ms. But when I ping the APs , switches, the wifi controller or the ASA firewall, they mostly have one digit replies. Can anyone tell me what would be causing the problem and should I look into something to troubleshoot? 

Thanks much in advance!

I agree with Jon if it isnt broken then dont try to fix it!

FYI - The TTL and RTT are deterministic in relation to how many bytes you send and the BW size of the interfaces the packet traversing.

My understanding the following formula's can be used for Throughput and RTT calculation.
Throughput = byte size*8bit/RTT 
RTT = byte size*8bit/BW_bits

The below example is in relation to the values you originally posted with a 64byte packet transfer for calculated throughput :

Packet=64 Byte
RTT =44 mill approx 
Total  throughput =11.6MB approx

Packet=64Byte
RTT =30 mill approx 
Total  throughput =17MB approx

Packet=64Byte
RTT =20 mill approx 
Total  throughput =25.5MB approx

[RabbitSF]

Sorry, took me a while to reply. 

Please see attached LAN diagram. Each red box is one IDF/MDF. The orange lines are fiber cables. The physical connection is a little weird. The ASA should be directly connected to the core switches (the 3850s in the server room) usually, but it's not the case in our LAN. The server room is Not at the same location as the MPOE. I asked our IT Consultant why we have such problem and below is his reply,

"..... One other thought that crossed my mind is the loop you have in your network as well. You have lowerschool with Internet connection with VLAN's etc. That connection then is carried to the firewall, then trunked over the fiber to the core switch. That same trunk also carries ALL other vlans back to lower school. So this would put more strain onto the core switch and the switchstack downstairs. Yeah now that I think about it this could be the cause. Originally your services couldn't get to the Server Room so we had to deploy in this manner. Always, I wanted to relocate the ASA but we needed more fiber strands than what were available to the core for all the IDF's. Wow, it is all coming back. Yep, I am sure because of the multi-traversal of the data packet over the connections that is where your issues are. ......"

Does this make sense now why the ping response takes longer? But I still don't quite understand.

If you understand what he said, I will have further questions. 

Thanks much!

[RabbitSF]

Is there anybody can take a look at my reply above again? Thanks much!

[Joseph W. Doherty]

You might not have any problem at all.

Ping was principally designed to detect if a host is "alive", not as a precision network latency test tool. Cisco devices like Cisco switches need to process a ping using their control plane, which on a switch, often does not have dedicated hardware as does forwarding transit traffic. Further, in the "pecking order" of control plane tasks, replying to a ping is low priority, so often a busy Cisco device's ping response times are more reflective of how busy the device is. Lastly, on switches, since the "critical" work is done by dedicated hardware, the switch's CPU often isn't very powerful compared to a like priced software based router.

BTW, some Cisco devices support a SLA responder function, which can internally timestamp the arrival of the ping request, and so it then can compute the internal delay of processing the ping request. Effectively, the ping reply then can show a much, much more accurate network latency, as the internal processing latency is subtracted out. I believe this also requires the device to make a "special" ping request to obtain this.