Using Ping Options More Effectively

I feel sorry for ping.  Ping has been beaten up, abused, misunderstood, banned and even tossed aside.

Ping was originally used to check if a device was up or down, period.  Back in the day, equipment failure was very common. I chuckle thinking back at those sales people that used Mean Time Between Failure to sell their equipment. As network analysts, we needed a way to see if our hardware or equipment failed and ping did the trick.

Over the years, SNMP was introduced to aid in network visibility, but we still used ping for simple up and down checks. In the 90s, bandwidth limits were becoming an issue, so we used ping response time results to determine if a device or link was slowing us down.

In the mid 1990s the “ping of death” appeared.  In summary, ping was used to crash, reboot, or kill a large number of systems by sending a certain amount of payload. This was the first nail in ping’s coffin. Since then, ping and ICMP have been used for floods, attacks, and tunneling, which led to many system admins to simply block all ICMP.

Back to troubleshooting, wherever possible, I still use ping since there are many things we can figure out to aid us in resolving issues or conducting an application baseline. The first point to make is that all ping tools are created equally.  I always keep my eyes open and test new utilities all the time. I also test utilities to ensure they work as advertised. Regardless if the software is free or paid, it should work as advertised. Packet loss will affect your application negatively as much as latency will.

Microsoft’s native ping utility has changed from operating system version to version.  I will use the ping command in Windows 7 and cover some of the options I use and why.


I like to point out that the default payload for Microsoft’s ping is 32 bytes and I encourage technicians to use payload sizes that better represent application payload sizes.

In the ping below, you can see a 25% increase in round-trip time latency by simply changing the payload size.


When reviewing ping results, you want to see consistent values as much as possible.  My rule of thumb is, “results become less consistent with the addition of more equipment and distance”.
Fragmentation issues are always tricky to troubleshoot. I can’t stress enough the importance for you to figure out if your protocols allow fragmentation or not. The process to figure this out is pretty straightforward; capture a packet and look in the IP header to see what the “Don’t fragment flag” is set for. In the screenshot below, the Not set means that the packet allows fragmentation. Don’t forget to check in both directions and as close to each device as possible.

Ping test

If you want to test for fragmentation issues or just determine what your maximum MTU is, use the –l option and capture/review those ping packets. In the screenshot below, I pinged using a payload size of 999 bytes.

Ping

When I reviewed the trace, I can see that my packets were fragmented into 2 packets.

Ping test

If I was to repeat the same test with a Do Not Fragment Option -f, I would get a different response:

Ping

The trace file identifies the supported MTU and who reported it. This is where things can get confusing. If a network device or firewall was blocking ICMP, this ICMP packet would never make it back to the client.

Ping

The Time To Live Option is very helpful when you want to determine if the number of hops are increasing or changing. For example, in the diagram below, you might want to ensure that the path isn’t reverting back to the extra hop.

Ping

Other ping options worth looking for in your favorite ping tool; GUI, ping interval, size sweep, reporting and QOS options. For Microsoft operating systems, I like to use hrping since it is maintained, portable, and offers these additional options. Here are some of the extra options when you type hrping at the prompt:

 

I tested the –c option to send five pings at a time and used Wireshark to confirm that hrping did in fact send the five pings at once:

Ping

Last test; I used the sweep option to ping 192.168.1.1 10 times with packet sizes ranging from 900 to 1500 with an increment, or step of 100 bytes:

Packets: sent=10, rcvd=10, error=0, lost=0 (0.0% loss) in 4.516607 sec
RTTs in ms: min/avg/max/dev: 4.061 / 5.585 / 9.972 / 1.800
Bandwidth in kbytes/sec: sent=2.524, rcvd=2.524
Correlation: 65.7%, estimated speed: 69.87 kbytes/sec

And for those of you who can not use ICMP or ping in your environment, use the UDP port option in hrping, or try cryping.

NetBeez’s implementation of the ping test includes options that are available and used by Cisco network engineers, such as:

  • DF bit
  • Packet size
  • Interval
  • Count
  • ToS

wifi monitoring