Is it reliable to depend on Ping for packet drops?

[Adrian_T]

I am wondering why does my Ping at first shows Success rate is 100 percent (1000/1000)

and then when I try it for 3 consecutive times it will show a packet drops?'

I would like to expand my knowledge how to read properly ping and traceroute.

1.) How would you know if there is a latency in the traceroute

2.) Is it reliable to use ping for packet drops

Can you please enlighten me Thanks!

This is the network

149.123.56.60 -> Data center -> 203.117.5.123

First Ping

Killbill#ping 203.117.5.123 so 149.123.56.60 re 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 203.117.5.123, timeout is 2 seconds:
Packet sent with a source address of 149.123.56.60
Success rate is 100 percent (1000/1000)

Second Ping

Killbill#ping 203.117.5.123 so 149.123.56.60 re 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 203.117.5.123, timeout is 2 seconds:
Packet sent with a source address of 149.123.56.60
Success rate is 96 percent (960/1000)

Third Ping

Killbill#ping 203.117.5.123 so 149.123.56.60 re 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 203.117.5.123, timeout is 2 seconds:
Packet sent with a source address of 149.123.56.60
Success rate is 98.4 percent (984/1000)

[Julio E. Moisa]

Hi

Latency is not a bad term, Latency is basically the time used by a packet to be moved from the point A to the point B.

About the traceroute you will see 3 times, each hop or node is tested 3 times and basically it represent the round trip:

About Ping,

You don't have a lot of lost packets on your images but it could be generated by the traffic passing through these links, type or interfaces, bandwidth, congestion, etc. you can also certify the uplinks to discard any physical problem.

You could see the interfaces executing: show interface <interface to analyze> 

In order to see if there are packet dropped. 

Hope it is useful.

:-)

[Thomas Yarger]

In addition to Julio, 

* You may see high response times if the router CPU utilization is high when the pack arrives on the ingress interface. Causes inaccurate response times not directly associated with network latency. 

* The internet is full of firewalls, you might be better off using a TCP Traceroute tool.

* The path the packet is taking could be asymmetric. I would keep that in mind as well. 

:) 

[Adrian_T]

Hi Thomas,

Can you cite an example for this?

* You may see high response times if the router CPU utilization is high when the pack arrives on the ingress interface. Causes inaccurate response times not directly associated with network latency. 

[Adrian_T]

Ok I have here an interface status, I have few questions so that I know where to check and must do if I detected packet drops.

1.) Where exactly should I analyze if I want to check if there is any packet drops?

2.) If ever there is abnormalities in the interface, what should be the next step of troubleshooting?

GigabitEthernet0/0 is up, line protocol is up

  Hardware is CN Gigabit Ethernet, address is 3cw0.2cfc.f740

  Description: WAN

  Internet address is 119.179.28.124/30

  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation ARPA, loopback not set

  Keepalive set (10 sec)

  Full Duplex, 1Gbps, media type is RJ45

  output flow-control is XON, input flow-control is XON

  ARP type: ARPA, ARP Timeout 04:00:00

  Last input 00:00:00, output 00:00:00, output hang never

  Last clearing of "show interface" counters never

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 175

  Queueing strategy: fifo

  Output queue: 0/40 (size/max)

  5 minute input rate 6000 bits/sec, 12 packets/sec

  5 minute output rate 10000 bits/sec, 15 packets/sec

     53168537 packets input, 969080221 bytes, 0 no buffer

     Received 725934 broadcasts (0 IP multicasts)

     0 runts, 0 giants, 0 throttles

     518 input errors, 0 CRC, 0 frame, 259 overrun, 0 ignored

     0 watchdog, 0 multicast, 0 pause input

     44747946 packets output, 2861269627 bytes, 0 underruns

     0 output errors, 0 collisions, 0 interface resets

     5 unknown protocol drops

     0 babbles, 0 late collision, 0 deferred

     22 lost carrier, 0 no carrier, 313230 pause output

     0 output buffer failures, 0 output buffers swapped out

[Julio E. Moisa]

Hi,

1.) Where exactly should I analyze if I want to check if there is any packet drops?

The following information can provide information about the lost packet. Now the error also could generate packet problems. 

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 175

518 input errors, 0 CRC, 0 frame, 259 overrun, 0 ignored

     0 watchdog, 0 multicast, 0 pause input

     44747946 packets output, 2861269627 bytes, 0 underruns

     0 output errors, 0 collisions, 0 interface resets

  22 lost carrier, 0 no carrier, 313230 pause output

2.) If ever there is abnormalities in the interface, what should be the next step of troubleshooting?

I good recommendation is always verify the physical layer (layer 1), it includes cabling, port or SFP. Then you can move to other layers to verify if a misconfiguration could generate packet loss.

Hope it is useful

:-)

[Georg Pauwen]

Hello,

in addition to Julio's post, any response times you get from pinging on the public Internet are at the very least questionable. Most providers treat ICMP traffic as low priority, so it gets sent to scavenger or default queues. Sometimes it is throttled to mitigate DDoS attacks. So PING is maybe not the most reliable method to measure latency and packet drops...

[auliakhoirunnisa]

Sorry if maybe my questions are out of topic but i also need help about traceroute. Recently I apply a failover technique with 2 ISP so I have 2 upstream links. I run a traceroute to identify which link the packet go through. In the middle of traceroute I disable the current link used so I can see if the failover works or not. The result is RTO, but it still reach the destination. why it could happen? is it because i have another link? if its true, why doesnt the traceroute give the information of the second link that it uses to reach the destination?

Please anyone help, I do this for my final project in college and the due is very close.

Thank you.

[Julio E. Moisa]

Hi

You could receive a request timeout message for many reason, if you are able to reach the destination, it could be by a packet filtering through the way. Basically you are not receiving a echo-reply. 

[Joseph W. Doherty]

1.) How would you know if there is a latency in the traceroute

Do you mean addition queuing latency?  If so, that might be revealed by RTT times that vary for the same hop.  Ping implementations that list min/avg/max times for a series also may indicate this too.

BTW, RTT times may also vary due to different paths takes by the packets (both to the target and back).

2.) Is it reliable to use ping for packet drops

No, it's not.  Remember, ping's original purpose was to try to determine if a host is reachable, loosing a few packets and/or being slow to respond don't really impact that purpose.

Today, ping packets can be part of a DoS attack, so hosts might consider ping (or traceroute) packets as "suspect".  I.e. devices may block all pings or rate limit processing them.