47
packet to reveal some problems. Also remember that ping does not count the IP or ICMP header in the specified length so your packets will be 28 bytes larger than you specify.
You could conceivably see MTU problems with protocols, such as PPP, that use escaped characters as well.
[3]
With escaped characters, a single character may be replaced by two characters. The expansion of escaped characters increases the size of the data frame and can cause problems with MTU
restrictions or fragmentation.
[3]
Generally there are better ways to deal with problems with PPP. For more information, see Chapter 15 in Using and Managing PPP, by Andrew Sun.
The -p option allows you to specify a pattern for the data included within the packet after the timestamp. You might use this if you think you have data-dependent problems. The FreeBSD
manpage for ping notes that this sort of problem might show up if you lack sufficient transitions in your data, i.e., your data is all or almost all ones or all or almost all zeros. Some serial links are
particularly vulnerable to this sort of problem.
There are a number of other options not discussed here. These provide control over what interfaces are used, the use of multicast packets, and so forth. The flags presented here are from FreeBSD and are
fairly standard. Be aware, however, that different implementations may use different flags for these options. Be sure to consult your documentation if things dont work as expected.
3.3.2.4 Using ping
To isolate problems using ping, you will want to run it repeatedly, changing your destination address so that you work your way through each intermediate device to your destination. You should begin
with your loopback interface. Use either
localhost
or
127.0.0.1
. Next, ping your interface by IP number. Run ifconfig -a if in doubt. If either of these fails, you know that you have a problem with
the host. Next, try a host on a local network that you know is operational. Use its IP address rather than its
hostname. If this fails, there are several possibilities. If other hosts are able to communicate on the local network, then you likely have problems with your connection to the network. This could be your
interface, the cable to your machine, or your connection to a hub or switch. Of course, you cant rule out configuration errors such as media type on the adapter or a bad IP address or mask.
Next, try to reach the same host by name rather than number. If this fails, you almost certainly have problems with name resolution. Even if you have this problem, you can continue using ping to check
your network, but you will need to use IP addresses.
Try reaching the near and far interfaces of your router. This will turn up any basic routing problems you may have on your host or connectivity problems getting to your router.
If all goes well here, you are ready to ping remote computers. You will need to know the IP address of the intermediate devices to do this test. If in doubt, read the section on traceroute in the next
chapter. Realize, of course, that if you start having failures at this point, the problem will likely lie beyond your router. For example, your ICMP ECHO_REQUEST packets may reach the remote
machine, but it may not have a route to your machine to use for the ICMP ECHO_REPLY packets.
When faced with failure at this point, your response will depend on who is responsible for the machines beyond your router. If this is still part of your network, you will want to shift your tests to
machines on the other side of the router and try to work in both directions.
48
If these machines are outside your responsibility or control, you will need to enlist the help of the appropriate person. Before you contact this person, however, you should collect as much information
as you can. There are three things you may want to do. First, go back to using IP numbers if you have been using names. As said before, if things start working, you have a name resolution problem.
Second, if you were trying to ping a device several hops beyond your router, go back to closer machines and try to zero in on exactly where you first encountered the problem.
Finally, be sure to probe from more than one machine. While you may have a great deal of confidence in your local machine at this point, your discussion with the remote administrator may go much more
smoothly if you can definitely say that you are seeing this problem from multiple machines instead of just one. In general, this stepwise approach is the usual approach for this type of problem.
Sometimes, you may be more interested in investigating connectivity over time. For example, you might have a connection that seems to come and go. By running ping in the background or from a
script, you may be able to collect useful information. For example, with some routing protocols, updates have a way of becoming synchronized, resulting in periodic loading on the network. If you
see increased delays, for example every 30 seconds, you might be having that sort of problem. Or, if you lose packets every time someone uses the elevator, you might look at the path your cable takes.
If you are looking at performance over a long period of time, you will almost certainly want to use the -i option to space out your packets in a more network- friendly manner. This is a reasonable approach
to take if you are experiencing occasional outages and need to document the time and duration of the outages. You should also be aware that over extended periods of time, you may see changes in the
paths the packets follow.
3.3.3 Problems with ping
