Ping: Check to see if a host is alive
The ping command is embarrassingly simple, but in many situations it is all you need. It sends an ICMP ECHO_REQUEST packet to a target host and waits to see if the host answers back. Despite its simplicity, ping is one of the workhorses of network debugging.
You can use ping to check the status of individual hosts and to test segments of the network. Routing tables, physical networks, and gateways are all involved in processing a ping, so the network must be more or less working for ping to succeed. If ping doesn't work, you can be pretty sure that nothing more sophisticated will work either. However, this rule does not apply to networks that block ICMP echo requests with a firewall. Make sure that a firewall isn't interfering with your debugging before you conclude that the target host is ignoring a ping. You might consider disabling a meddlesome firewall for a short period of time to facilitate debugging.
Every vendor provides a ping. Most versions of ping run in an infinite loop unless a packet count argument is given. Under Solaris, ping-s provides the extended output that other versions use by default. Once you've had your fill of pinging, type the interrupt character (usually Here's an example:
% ping beast
The output for beast shows the host's IP address, the ICMP sequence number of each response packet, and the round trip travel time. The most obvious thing that the output above tells you is that the server beast is alive and connected to the network.
On a healthy network, ping can allow you to determine if a host is down. Conversely, when a remote host is known to be up and in good working order, ping can give you useful information about the health of the network. ping packets are routed by the usual IP mechanisms, and a successful round trip means that all networks and gateways lying between the source and destination are working correctly, at least to a first approximation.
The ICMP sequence number is a particularly valuable piece of information. Discontinuities in the sequence indicate dropped packets. Despite the fact that IP does not guarantee the delivery of packets, a healthy network should drop very few of them. Lost-packet problems are important to track down because they tend to be masked by higher-level protocols. The network may appear to function correctly, but it will be much slower than it ought to be, not only because of the retransmitted packets but also because of the protocol overhead needed to detect and manage them.
To track down the cause of disappearing packets, first run traceroute (see the next section) to discover the route that packets are taking to the target host. Then ping the intermediate gateways in sequence to discover which link is dropping packets. To pin down the problem, you need to send a statistically significant number of packets. The network fault will generally lie on the link between the last gateway that you can ping without significant loss of packets and the gateway beyond it.
The round trip time reported by ping gives you insight into the overall performance of a path through a network. Moderate variations in round trip time do not usually indicate problems. Packets may occasionally be delayed by tens or hundreds of milliseconds for no apparent reason; that's just the way IP and UNIX work. You should expect to see a fairly consistent round trip time for the majority of packets, with occasional lapses. Many of today's routers implement rate-limited responses to ICMP packets, which means that a router may delay responding to your ping if it is already dealing with a lot of ICMP traffic.
The ping program allows you to send echo request packets of any size. By using a packet larger than the MTU of the network (1,500 bytes for Ethernet), you can force fragmentation to take place. This practice will help you to identify media errors or other low-level issues such as problems with a congested ATM network.
Under Solaris and HP-UX, you simply add the desired packet size to the end of the ping command:
% ping cuinfo.cornell.edu 1500
Red Hat Linux and FreeBSD require you to specify the desired size in bytes with the -s flag. Because excessively large packets can cause network problems, FreeBSD restricts the use of this option to root. (Note: The 1998 Ping of Death attack that could crash both UNIX and Windows systems was executed simply by transmission of an overly large ping packet. When the fragmented packet was reassembled, it filled the default memory buffer and crashed the machine.)
# ping -s 1500 cuinfo.cornell.edu
Use the ping command with the following caveats in mind. First, it is hard to distinguish the failure of a network from the failure of a server with only the ping command. A failed ping just tells you that something is wrong.
Second, a ping does not guarantee much about the target machine's state. Echo request packets are handled within the IP protocol stack and do not require a server process to be running on the probed host. A response guarantees only that a machine is powered on and has not experienced a kernel panic. You'll need higher-level methods to verify the availability of individual services such as HTTP and DNS
ping beast (10.1.1.46): 56 data bytes
64 bytes from 10.1.1.46: icmp_seq=0 ttl=255 time=0.808 ms
64 bytes from 10.1.1.46: icmp_seq=1 ttl=255 time=0.400 ms
64 bytes from 10.1.1.46: icmp_seq=2 ttl=255 time=0.390 ms
^C
--- beast ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.390/0.533/0.808/0.195 ms
6%
3%
