ping is a diagnostic tool used for verifying connectivity between two hosts on a network. It sends Internet Control Message Protocol (ICMP) echo request packets to a remote IP address and watches for ICMP responses. The author of the initial version of the ping program that we use today was Mike Muss. Many other people have tweaked, rewritten and variously abused ping since then.

The name ping itself is somewhat colorful. Some people claim that it is an acronym standing for Packet INternet Groper, but this is not the case. ping was named after the sound a sonar tracking system makes. There even is a story claiming that a system administrator wrote a script that repeatedly pinged a host on the network and made an audible "pinging" alert for each success. The system administrator then was able to go through his network methodically checking BNC connectors until he found the dodgy connector that had been plaguing his network. When the noises stopped, he'd found the culprit.

ping used to be a good indicator of a machine's general ability to receive and send IP packets. If you could ping a host, you also could make an FTP or HTTP connection. With the wider advent of packet filtering for security, though, this is becoming less true. Many firewalls explicitly disallow ICMP packets on the twin grounds that people don't need to know what your internal network looks like and any protocol can be used to launch an attack, even ICMP.

Deciding whether to let ICMP through your firewall is a tough call to make. There certainly are good uses for ICMP, but there also are attacks based on ICMP. For example, the "ping of Death" uses oversized ping packets to overload the IP stack of the target--often with spectacular results. If you choose to allow ICMP into your network, make sure you've thought about the repercussions.

Additional flavors of the ping command exist that have been written for other purposes. Among the most common is fping, which was written to ping a range of addresses. It commonly is used in network scanners and monitors, such as saint and mon. Another variation is the Net::Ping module, which provides a Perl implementation of ping functionality that can be used easily from within a script without calling an external program. You might use the script something like this:

Example 1. Using Net::Perl

#!/usr/bin/perl -w

use strict;
use Net::Ping;
	  
my $host = $ARGV[0];
	  
my $p = Net::Ping->new("icmp");
	  
if ($p->ping($host)) {
    print "$host is alive.\n";
} else {
    print "$host is not reachable.\n";
}

ping most often is used without additional arguments and is shut off with Ctrl-c. The result looks like this:

[pate@cherry pate]$ ping mango
PING mango (192.168.1.1) from 192.168.1.10 : 56(84) bytes of data.
64 bytes from mango (192.168.1.1): icmp_seq=0 ttl=255 time=0.5 ms
64 bytes from mango (192.168.1.1): icmp_seq=1 ttl=255 time=0.3 ms
64 bytes from mango (192.168.1.1): icmp_seq=2 ttl=255 time=0.3 ms
64 bytes from mango (192.168.1.1): icmp_seq=3 ttl=255 time=0.3 ms
64 bytes from mango (192.168.1.1): icmp_seq=4 ttl=255 time=0.3 ms
64 bytes from mango (192.168.1.1): icmp_seq=5 ttl=255 time=0.3 ms

--- mango ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 0.3/0.3/0.5 ms
[pate@cherry pate]$ 

This output can be split into three sections. The first section, the single line starting with the word PING, shows an overview of the command. The second section, the lines beginning with 64 bytes shows a running tally of the responses received. The third section, everything after the line --- mango ping statistics ---, shows a summary of the results. In this case, the results are good: none of the packets was dropped and they all were passed fairly quickly.

This example also illustrates another important point: you should not rely on a single packet to diagnose your network. A series of five or ten packets is much better, as you can count up to 40% data loss as congestion on a network. Even a single dropped packet can be attributed to a busy host on the other end.

Several useful options can be used with the ping command. These are summarized in the following table:

These options can be combined to make ping even more helpful. One thing you cannot see is that the ping command used in the previous section is likely to take several seconds to run and report back. Using the -f option, though, can reduce the time spent waiting for the command. Combining this with the -c 10 and the -q options can give you quicker results and easier output to read:

	[root@cherry /root]# ping -c 10 -fq mango
PING mango (192.168.1.1) from 192.168.1.10 : 56(84) bytes of data.

--- mango ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.9 ms
[root@cherry /root]# 

Note: The -f and -l options can be used only by root, as they can cause serious network degradation if misused.

If it might be of some benefit to test larger packets, using ping -c10 -s 1024 -qf sends larger packets for you. This can be especially useful where you suspect problems with fragmented packets.

To see the route that your packets are traversing, you can use ping -c10 -R, which produces the following output:

PING tbr.nailed.org (206.66.240.72) from 192.168.1.10 : 56(124) bytes of data.
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=0 ttl=239 
time=217.2 ms
RR: 	192.168.1.10
	216.41.39.90
	serial0.mmgw32.bos1.Level3.net (209.244.39.25)
	208.218.130.22
	166.90.184.2
	so-6-0-0.mp2.NewYork1.level3.net (209.247.10.45)
	137.39.52.10
	180.ATM7-0.BR2.NYC9.ALTER.NET (152.63.22.229)
	lo0.XR2.NYC9.ALTER.NET (137.39.4.175)

64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=1 ttl=239 
	time=1940.8 ms	(same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=2 ttl=239 
	time=250.6 ms	(same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=3 ttl=239 
	time=230.3 ms	(same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=4 ttl=239 
	time=289.8 ms	(same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=5 ttl=239 
	time=1261.4 ms	(same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=6 ttl=239 
	time=469.4 ms	(same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=7 ttl=239 
	time=1272.3 ms	(same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=8 ttl=239 
	time=353.1 ms	(same route)
64 bytes from bigfun.whirlycott.com (206.66.240.72): icmp_seq=9 ttl=239 
time=1281.1 ms	(same route)

--- tbr.nailed.org ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 217.2/756.6/1940.8 ms

Note: The record route option specified by the -R option is not honored by all routers and hosts. Further, it contains limited space to hold router addresses. Therefore, traceroute may be a better tool for identifying the path packets take through a network.

Overall, the ping command is a useful tool for your troubleshooting kit and should not be overlooked.

Copyright (c) 2000, Pat Eyler and New Riders Publishing. Originally published in Linux Gazette issue 56. It is presented under the Open Publication License, with no additional terms applied.