Ping is implemented by using the required ICMP Echo
function, documented in RFC 792 that all hosts should implement. Of course,
administrators can disable ping messages (this is rarely a good idea, unless
security considerations dictate that the host should be unreachable anyway),
and some implementations have (gasp) even been known not to implement all
required functions. However, ping is usually a better bet than almost any
other network software.
Many versions of ping are available. For the remainder
of this discussion, I assume use of BSD UNIX's ping, a freely available, full-featured
ping available for many UNIX systems. Most PC-based pings do not have the
advanced features I describe. As always, read the manual of whatever version
you use.
What Ping can tell you
Ping places a unique sequence number on each packet
it transmits, and reports which sequence numbers it receives back. Thus, you
can determine if packets have been dropped, duplicated, or reordered.
Ping checksums each packet it exchanges. You can detect some forms of damaged
packets.
Ping places a timestamp in each packet, which is echoed back and can easily
be used to compute how long each packet exchange took - the Round Trip Time
(RTT).
Ping reports other ICMP messages that might otherwise get buried in the system
software. It reports, for example, if a router is declaring the target host
unreachable.
Some routers may silently discard undeliverable packets.
Others may believe a packet has been transmitted successfully when it has
not been. (This is especially common over Ethernet, which does not provide
link-layer acknowledgements) Therefore, ping may not always provide reasons
why packets go unanswered.
Ping cannot tell you why a packet was damaged, delayed, or duplicated. It
can not tell you where this happened either, although you may be able to deduce
it.
Ping cannot give you a blow-by-blow description of every host that handled
the packet and everything that happened at every step of the way. It is an
unfortunate fact that no software can reliably provide this information for
a TCP/IP network.
Using ping
Ping should be your first stop for network troubleshooting. Having problems
transferring a file with FTP? Don't fire up your packet analyzer just yet.
Leave your TDR in the box for now. Relax. Put on some Yanni. Don't even ``su''
- ping is a non-privileged command on most systems. Start one running and
just watch it for at least two minutes. That's enough time for most periodic
network problems to show themselves. Once you've seen about a hundred packets,
you should be getting a good feeling for how this host is responding. Are
the round-trip times consistent? Seeing any packet loss? Are the TTL values
sane? Start pinging other hosts. Try the machine next to you - the problem
might be closer than you think. Try the last router - maybe the remote system
is overloaded (especially if it's a popular Internet site like this one).
Don't know what the last router is? Use traceroute or guess - changing the
last number in the IP address to 1 usually gets you something interesting.
Check other sites with similar network topologies (other remote LAN sites,
or other Internet sites, or other sites using the same backbone). Starting
to learn something about how your network is responding? Good. And - oh, yeah,
go check that FTP. It's probably done by now.
What you might see
Dropped packets
A unfortunate fact of life. Detect them by noting when the sequence numbers
skip, and the missing number does not appear again later. This is probably
caused by a router queueing packets for a relatively slow link, and the queue
simply grew too large. Early TCP implementations dropped packets at a truly
alarming rate, but things have gotten better. Even so, there are common situations,
typically involving crowded wide-area networks, in which even modern TCP implementations
can't operate steady-state without dropping packets. There's no reason to
pull your out hair over this, since TCP will retransmit missing data, but
this won't make your network run faster. Also, if you have fast links that
aren't showing much congestion, the cause of trouble may be elsewhere - link-level
failures are the next most common cause of packet loss. I'd suggest using
the techniques mentioned above to narrow down as much as possible where packets
are being dropped, and try to understand why this is happening, even if fixing
it is beyond your control.
Fluctuating Round Trip Times
Another fact of life. Pretty much caused by the same things that cause packet
loss. Again, not serious cause for alarm, but don't expect optimum performance
from TCP. Remember that TCP generates an internal RTT estimate that affects
protocol behavior. If the actual RTT changes too much, TCP may never be able
to make a satisfactory estimate. Both dropped packets and RTT fluctuations
may occur in a periodic nature - a batch of slow packets every 30 seconds,
for instance. If you see this symptom, check for routing updates or other
periodic traffic with the same period as the problem. Poor network performance
can often be traced to slow links being clogged with various kinds of automated
updates.
Connectivity that comes and goes
Again, look for periods between problems that are multiples of some common
number - 10 and 15 seconds are good things to check. If a router is sending
error messages when connectivity disappears, that router's the first place
to start looking. However, just because you can always reach hop 5, for instance,
doesn't mean that your problem isn't hop 3. Hop 3's router may be erroneously
timing out routing information for your target, but handling hop 5's routing
information just fine. Of course, check hop 5 first if that's where your packets
seem to check out but never leave.
Ping works fine but TELNET/FTP/Mail/News/...
doesn't
Good news - it's (probably) not a hardware problem. Use a packet tracer of
some sort to see what TTL values are being generated by your hosts. If they're
too low, you can see this kind of behavior. It could also be a software or
configuration problem - can other machines connect to the offending host?
Can it talk to itself? On the other hand, it could be a hardware problem,
if one of your links is showing data-dependent behavior. The telltale symptom
is when FTP (for example) can transfer some files fine, but others always
have problems. Once you've found an offending file, trying breaking it into
smaller and smaller pieces and see which ones don't work. If the pieces becomes
too small to detect problems, duplicate them several times to get a larger
file. Once you've found a small pattern that you suspect is causing your grief,
see if you can load it into ping packets (BSD PING's `-p' switch) and reproduce
trouble.
Web 
Index