13.3. Testing Basic Connectivity
The ping command tests whether a remote host can be reached from your computer. This simple function is extremely useful for testing the network connection, independent of the application in which the original problem was detected. ping allows you to determine whether further testing should be directed toward the network connection (the lower layers) or the application (the upper layers). If ping shows that packets can travel to the remote system and back, the user's problem is probably in the upper layers. If packets can't make the round trip, lower protocol layers are probably at fault.
Frequently a user reports a network problem by stating that he can't telnet (or ftp, or send email, or whatever) to some remote host. He then immediately qualifies this statement with the announcement that it worked before. In cases like this, where the ability to connect to the remote host is in question, ping is a very useful tool.
Using the hostname provided by the user, ping the remote host. If your ping is successful, have the user ping the host. If the user's ping is also successful, concentrate your further analysis on the specific application that the user is having trouble with. Perhaps the user is attempting to telnet to a host that provides only anonymous ftp. Perhaps the host was down when the user tried his application. Have the user try it again, while you watch or listen to every detail of what he is doing. If he is doing everything right and the application still fails, detailed analysis of the application with snoop and coordination with the remote system administrator may be needed.
If your ping is successful and the user's ping fails, concentrate testing on the user's system configuration, and on those things that are different about the user's path to the remote host when compared to your path to the remote host.
If your ping fails, or the user's ping fails, pay close attention to any error messages. The error messages displayed by ping are helpful guides for planning further testing. The details of the messages may vary from implementation to implementation, but there are only a few basic types of errors:
All of the tools mentioned here will be discussed later in this chapter. However, before leaving ping, let's look more closely at the command and the statistics it displays.
13.3.1. The ping Command
The basic format of the ping command on a Solaris system is:
ping host [packetsize] [count]
To check that ns.uu.net can be reached from crab, we send five 56-byte packets with the following command:
% ping -s ns.uu.net 56 5 PING ns.uu.net: 56 data bytes 64 bytes from ns.uu.net (184.108.40.206): icmp_seq=0. time=32.8 ms 64 bytes from ns.uu.net (220.127.116.11): icmp_seq=1. time=15.3 ms 64 bytes from ns.uu.net (18.104.22.168): icmp_seq=2. time=13.1 ms 64 bytes from ns.uu.net (22.214.171.124): icmp_seq=3. time=32.4 ms 64 bytes from ns.uu.net (126.96.36.199): icmp_seq=4. time=28.1 ms ----ns.uu.net PING Statistics---- 5 packets transmitted, 5 packets received, 0% packet loss round trip (ms) min/avg/max = 13.1/24.3/32.8
The -s option is included because crab is a Solaris workstation, and we want packet-by-packet statistics. Without the -s option, Sun's ping command prints only a summary line saying "ns.uu.net is alive." Other ping implementations do not require the -s option; they display the statistics by default, as the Linux example below shows:
$ ping -c5 ns.uu.net PING ns.uu.net (188.8.131.52) from 172.16.12.3 : 56(84) bytes of data. 64 bytes from ns.UU.NET (184.108.40.206): icmp_seq=0 ttl=244 time=98.283 msec 64 bytes from ns.UU.NET (220.127.116.11): icmp_seq=1 ttl=244 time=94.114 msec 64 bytes from ns.UU.NET (18.104.22.168): icmp_seq=2 ttl=244 time=66.565 msec 64 bytes from ns.UU.NET (22.214.171.124): icmp_seq=3 ttl=244 time=24.301 msec 64 bytes from ns.UU.NET (126.96.36.199): icmp_seq=4 ttl=244 time=37.060 msec --- ns.uu.net ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round trip min/avg/max/mdev = 24.301/64.064/98.283/29.634 ms
Both tests show a good wide area network link to ns.uu.net with no packet loss and a fast response. The round trip between almond and ns.uu.net took an average of only 24.3 milliseconds. A small packet loss, and a round trip time an order of magnitude higher, would not be abnormal for a connection made across a wide area network. The statistics displayed by the ping command can indicate low-level network problems. The key statistics are:
If the packet loss is high, the response time is very slow, or packets are arriving out of order, there could be a network hardware problem. If you see these conditions when communicating over great distances on a wide area network, there is nothing to worry about. TCP/IP was designed to deal with unreliable networks, and some wide area networks suffer a lot of packet loss. But if these problems are seen on a local area network, they indicate trouble.
On a local network cable segment, the round trip time should be near 0, there should be little or no packet loss, and the packets should arrive in order. If these things are not true, there is a problem with the network hardware. On an Ethernet, the problem could be improper cable termination, a bad cable segment, or a bad piece of "active" hardware, such as a hub, switch, or transceiver. Check the cable with a cable tester as described earlier. Good hubs and switches often have built-in diagnostic software that can be checked. Cheap hubs and transceivers may require the "brute force" method of disconnecting individual pieces of hardware until the problem goes away.
The results of a simple ping test, even if the ping is successful, can help you direct further testing toward the most likely causes of the problem. But other diagnostic tools are needed to examine the problem more closely and find the underlying cause.
Copyright © 2002 O'Reilly & Associates. All rights reserved.