![]() | ![]() |
[11]For more on the background of ping as well as a review of the book The Story About Ping, an alleged allegory of the ping program, visit Muuss's web page at http://ftp.arl.mil/~mike/ping.html.
In this example, no response was received before the program timed out:sol1# ping 205.153.63.30 205.153.63.30 is alive sol1#
Note that ping can be used with an IP number or with a hostname, as shown by these examples. Other implementations will, by default, repeatedly send ECHO_REQUESTs until interrupted. FreeBSD is an example:sol1# ping www.microsoft.com no answer from microsoft.com sol1#
The execution of the program was interrupted with a Ctrl-C, at which point the summary statistics were printed. Without an interrupt, the program will continue indefinitely. With the appropriate command-line option, -s, similar output can be obtained with Solaris.bsd1# ping www.bay.com PING www.bay.com (204.80.244.66): 56 data bytes 64 bytes from 204.80.244.66: icmp_seq=0 ttl=112 time=180.974 ms 64 bytes from 204.80.244.66: icmp_seq=1 ttl=112 time=189.810 ms 64 bytes from 204.80.244.66: icmp_seq=2 ttl=112 time=167.653 ms ^C --- www.bay.com ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 167.653/179.479/189.810/9.107 ms bsd1#
The following times were for the same link only moments later:64 bytes from 205.153.60.42: icmp_seq=0 ttl=30 time=225.620 ms 64 bytes from 205.153.60.42: icmp_seq=1 ttl=30 time=213.652 ms 64 bytes from 205.153.60.42: icmp_seq=2 ttl=30 time=215.306 ms 64 bytes from 205.153.60.42: icmp_seq=3 ttl=30 time=194.782 ms 64 bytes from 205.153.60.42: icmp_seq=4 ttl=30 time=199.562 ms ...
There is nothing wrong here. The difference is that a file download was in progress on the link during the second set of measurements. In general, you can expect very good times if you are staying on a LAN. Typically, values should be well under 100 ms and may be less than 10 ms. Once you move onto the Internet, values may increase dramatically. A coast-to-coast, round-trip time will take at least 60 ms when following a mythical straight-line path with no congestion. For remote sites, times of 200 ms may be quite good, and times up to 500 ms may be acceptable. Much larger times may be a cause for concern. Keep in mind these are very rough numbers. You can also use ping to calculate a rough estimate of the throughput of a connection. (Throughput and related concepts are discussed in greater detail in Chapter 4, "Path Characteristics".) Send two packets with different sizes across the path of interest. This is done with the -s option, which is described later in this chapter. The difference in times will give an idea of how much longer it takes to send the additional data in the larger packet. For example, say it takes 30 ms to ping with 100 bytes and 60 ms with 1100 bytes. Thus, it takes an additional 30 ms round trip or 15 ms in one direction to send the additional 1000 bytes or 8000 bits. The throughput is roughly 8000 bits per 15 ms or 540,000 bps. The difference between two measurements is used to eliminate overhead. This is extremely crude. It makes no adjustment for other traffic and gives a composite picture for all the links on a path. Don't try to make too much out of these numbers. It may seem that the TTL field could be used to estimate the number of hops on a path. Unfortunately, this is problematic. When a packet is sent, the TTL field is initialized and is subsequently decremented by each router along the path. If it reaches zero, the packet is discarded. This imposes a finite lifetime on all packets, ensuring that, in the event of a routing loop, the packet won't remain on the network indefinitely. Unfortunately, the TTL field may or may not be reset at the remote machine and, if reset, there is little consistency in what it is set to. Thus, you need to know very system-specific information to use the TTL field to estimate the number of hops on a path. A steady stream of replies with reasonably consistent times is generally an indication of a healthy connection. If packets are being lost or discarded, you will see jumps in the sequence numbers, the missing numbers corresponding to the lost packets. Occasional packet loss probably isn't an indication of any real problem. This is particularly true if you are crossing a large number of routers or any congested networks. It is particularly common for the first packet in a sequence to be lost or have a much higher elapsed time. This behavior is a consequence of the need to do ARP resolution at each link along the path for the first packet. Since the ARP data is cached, subsequent packets do not have this overhead. If, however, you see a large portion of the packets being lost, you may have a problem somewhere along the path. The program will also report duplicate and damaged packets. Damaged packets are a cause for real concern. You will need to shift into troubleshooting mode to locate the source of the problem. Unless you are trying to ping a broadcast address, you should not see duplicate packets. If your computers are configured to respond to ECHO_REQUESTs sent to broadcast addresses, you will see lots of duplicate packets. With normal use, however, duplicate responses could indicate a routing loop. Unfortunately, ping will only alert you to the problem; its underlying mechanism cannot explain the cause of such problems. In some cases you may receive other ICMP error messages. Typically from routers, these can be very informative and helpful. For example, in the following, an attempt is made to reach a device on a nonexistent network:64 bytes from 205.153.60.42: icmp_seq=0 ttl=30 time=1037.367 ms 64 bytes from 205.153.60.42: icmp_seq=1 ttl=30 time=2119.615 ms 64 bytes from 205.153.60.42: icmp_seq=2 ttl=30 time=2269.448 ms 64 bytes from 205.153.60.42: icmp_seq=3 ttl=30 time=2209.715 ms 64 bytes from 205.153.60.42: icmp_seq=4 ttl=30 time=2493.881 ms ...
Since the router has no path to the network, it returns the ICMP DESTINATION_HOST_UNREACHABLE message. In general, you will receive a Destination Host Unreachable warning or a Destination Network Unreachable warning if the problem is detected on the machine where ping is being run. If the problem is detected on a device trying to forward a packet, you will receive only a Destination Host Unreachable warning. In the next example, an attempt is being made to cross a router that has been configured to deny traffic from the source:bsd1# ping 172.16.4.1 PING 172.16.4.1 (172.16.4.1): 56 data bytes 36 bytes from 172.16.2.1: Destination Host Unreachable Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 5400 5031 0 0000 fe 01 0e49 172.16.2.13 172.16.4.1 36 bytes from 172.16.2.1: Destination Host Unreachable Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 5400 5034 0 0000 fe 01 0e46 172.16.2.13 172.16.4.1 ^C --- 172.16.4.1 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss
The warning Communication prohibited by filter indicates the packets are being discarded. Be aware that you may be blocked by filters without seeing this message. Consider the following example:bsd1# ping 172.16.3.10 PING 172.16.3.10 (172.16.3.10): 56 data bytes 36 bytes from 172.16.2.1: Communication prohibited by filter Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 5400 5618 0 0000 ff 01 0859 172.16.2.13 172.16.3.10 36 bytes from 172.16.2.1: Communication prohibited by filter Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 5400 561b 0 0000 ff 01 0856 172.16.2.13 172.16.3.10 ^C --- 172.16.3.10 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss
The same filter was used on the router, but it was applied to traffic leaving the network rather than inbound traffic. Hence, no messages were sent. Unfortunately, ping will often be unable to tell you why a packet is unanswered. While these are the most common ICMP messages you will see, ping may display a wide variety of messages. A listing of ICMP messages can be found in RFC 792. A good discussion of the more common messages can be found in Eric A. Hall's Internet Core Protocols: The Definitive Guide. Most ICMP messages are fairly self-explanatory if you are familiar with TCP/IP.bsd1# ping 172.16.3.10 PING 172.16.3.10 (172.16.3.10): 56 data bytes ^C --- 172.16.3.10 ping statistics --- 6 packets transmitted, 0 packets received, 100% packet loss
In the first case, the destination was a 200-MHz Pentium with a PCI adapter. In the second, the destination was a 50-MHz 486 with an ISA adapter. It is not surprising that the first computer was more than five times faster. But remember, it may not be clear whether the limiting factor is the source or the receiver unless you do multiple tests. Clearly, use of this option could cripple a host. Consequently, the option requires root privileges to run and may not be included in some implementations. The -l option takes a count and sends out that many packets as fast as possible. It then falls back to normal mode. This could be used to see how the router handles a flood of packets. Use of this command is also restricted to root. The -i option allows the user to specify the amount of time in seconds to wait between sending consecutive packets. This could be a useful way to space out packets for extended runs or for use with scripts. In general, the effect of an occasional ping packet is negligible when compared to the traffic already on all but the slowest of links. Repeated packets or packet flooding can, however, add considerably to traffic and congestion. For that reason, you should be very circumspect in using any of these options (and perhaps ping in general). The amount and form of the data can be controlled to a limited extent. The -n option restricts output to numeric form. This is useful if you are having DNS problems. Implementations also typically include options for more detailed output, typically -v for verbose output, and for fewer details, typically -q and -Q for quiet output. The amount and nature of the data in the frame can be controlled using the -s and -p options. The packet size option, -s, allows you to specify how much data to send. If set too small, less than 8, there won't be space in the packet for a timestamp. Setting the packet size can help in diagnosing a problem caused by path Maximum Transmission Unit (MTU) settings (the largest frame size that can be sent on the path) or fragmentation problems. (Fragmentation is dividing data among multiple frames when a single packet is too large to cross a link. It is handled by the IP portion of the protocol stack.) The general approach is to increase packet sizes up to the maximum allowed to see if at some point you have problems. When this option isn't used, ping defaults to 64 bytes, which may be too small a 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.[12] 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.bsd1# ping -f 172.16.2.12 PING 172.16.2.12 (172.16.2.12): 56 data bytes ..^C --- 172.16.2.12 ping statistics --- 27585 packets transmitted, 27583 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.303/0.310/0.835/0.027 ms bsd1# ping -f 172.16.2.20 PING 172.16.2.20 (172.16.2.20): 56 data bytes .^C --- 172.16.2.20 ping statistics --- 5228 packets transmitted, 5227 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.535/1.736/6.463/0.363 ms
[12]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 don't work as expected.
[13]"Systems Administration: You Can't Get There from Here," Server/Workstation Expert, May 1999. This article can be found in PDF format at http://sw.expert.com/C4/SE.C4.MAY.99.pdf.The opposite can be true as well. Often ping will fail when the connection works for other uses. For various reasons, usually related to security, some system administrators may block ICMP packets in general or ECHO_REQUEST packets in particular. Moreover, this practice seems to be increasing. I've even seen a site block ping traffic at its DNS server.
[14]At one time, you could test your site by going to http://www.netscan.org, but this site seems to have disappeared.Finally, as a good network citizen, you should install filters on your access router to prevent packets that have a source address not on your network from leaving your network. This limits not only Smurf Attacks but also other attacks based on spoofed addresses from originating on your network. These filters should also be applied to internal routers as well as access routers. (This assumes you are providing forwarding for other networks!) If you follow these steps, you should not have to disable ICMP traffic. For more information on Smurf Attacks, including information on making these changes, visit http://www.cert.org/advisories/CA-1998-01.html. You might also look at RFC 2827.
[15]For more information on this attack, see http://www.cert.org/advisories/CA-1996-26.html.
Notice that five hosts are being probed at the same time and that the results are reported in the order replies are received. This works the same way ping works, through sending and receiving ICMP messages. It is primarily designed to be used with files. Several command-line options are available, including the -f option for reading a list of devices to probe from a file and the -u option used to print only those systems that are unreachable. For example:bsd1# fping 172.16.2.10 172.16.2.11 172.16.2.12 172.16.2.13 172.16.2.14 172.16.2.13 is alive 172.16.2.10 is alive 172.16.2.12 is alive 172.16.2.14 is unreachable 172.16.2.11 is unreachable
The utility of this form in a script should be self-evident.bsd1# fping -u 172.16.2.10 172.16.2.11 172.16.2.12 172.16.2.13 172.16.2.14 172.16.2.14 172.16.2.11
This provides basically the same information as ping. The -v option simply provides a few more details. The program defaults to TCP and ECHO. Command-line options allow UDP packet or the other services to be selected. When ping was first introduced in this chapter, we saw that www.microsoft.com could not be reached by ping. Nor can it be reached using echoping in its default mode. But, as a web server, port 80 should be available. This is in fact the case:bsd1# echoping -v lnx1 This is echoping, version 2.2.0. Trying to connect to internet address 205.153.61.177 to transmit 256 bytes... Connected... Sent (256 bytes)... 256 bytes read from server. Checked Elapsed time: 0.004488 seconds
Clearly, Microsoft is blocking ICMP packets. In this example, we could just as easily have turned to our web browser. Sometimes, however, this is not the case. An obvious question is "Why would you need such a tool?" If you have been denied access to a network, should you be using such probes? On the other hand, if you are responsible for the security of a network, you may want to test your configuration. What can users outside your network discover about your network? If this is the case, you'll need these tools to test your network.bsd1# echoping -v -h /ms.htm www.microsoft.com:80 This is echoping, version 2.2.0. Trying to connect to internet address 207.46.130.14 (port 80) to transmit 100 bytes... Connected... Sent (100 bytes)... 2830 bytes read from server. Elapsed time: 0.269319 seconds
In this case, I've used the MAC address, but the IP address could also be used. The -v option is for verbose, while -c3 limits the run to three probes. Verbose doesn't really add a lot to the default output, just the first line identifying the source. If you just want the packets sent, you can use the -q, or quiet, option. This tool has several uses. First, it is a way to find which IP addresses are being used. It can also be used to work backward, i.e., to discover IP addresses given MAC addresses. For example, if you have captured non-IP traffic (e.g., IPX, etc.) and you want to know the IP address for the traffic's source, you can use arping with the MAC address. If you just want to check connectivity, arping is also a useful tool. Since ARP packets won't be blocked, this should work even when ICMP packets are blocked. You could also use this tool to probe for ARP entries in a router. Of course, due to the nature of ARP, there is not a lot that this tool can tell you about devices not on the local network.bsd2# arping -v -c3 00:10:7b:66:f7:62 This box: Interface: ep0 IP: 172.16.2.236 MAC address: 00:60:97:06:22:22 ARPING 00:10:7b:66:f7:62 60 bytes from 172.16.2.1 (00:10:7b:66:f7:62): icmp_seq=0 60 bytes from 172.16.2.1 (00:10:7b:66:f7:62): icmp_seq=1 60 bytes from 172.16.2.1 (00:10:7b:66:f7:62): icmp_seq=2 --- 00:10:7b:66:f7:62 statistics --- 3 packets transmitted, 3 packets received, 0% unanswered 2 packets transmitted, 2 packets received, 0% unanswered
![]() | ![]() | ![]() |
3.2. Testing Adapters | ![]() | 3.4. Microsoft Windows |
Copyright © 2002 O'Reilly & Associates. All rights reserved.