UNIX System Administration Handbook - Evi Nemeth [371]
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 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 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