In previous articles we’ve built some useful servers. But this time let’s take a look at one of the most powerful network troubleshooting tools ever written: the mighty “ping” command.
You may have used this program and wonder why I’d devote an entire article to it, but if you don’t know how to ping, you definitely need to keep reading.
Ping was developed by a fellow named Mike Muuss back in 1983 for the express purpose of troubleshooting fundamental IP network issues. The name is borrowed from sonar systems: You “ping” a host and then wait for a reply, much as a submarine might ping an object in the water, then wait for the echo.
Ping uses the Internet Control Message Protocol or ICMP, which operates at a relatively low level. You can imagine that it’s underneath any server software running on the PC.
This has implications: If someone yells, “Our Web server is down,” I’ll try “ping www.crawfordbroadcasting.com.” If I can ping it, that tells me that the server machine itself is powered on and that the network connection is OK. I need to check the Apache Web server for a problem. But if I can’t ping it, I’ll call Denver and ask my colleague Amanda Alexander to go make sure no one turned it off or unplugged the network cable by accident.
Ping is useful because it tests everything in your network settings. It checks the physical connection as well. The sequence of a typical ping goes something like this:
- If you use a domain name, a Domain Name Server is used to determine the IP address.
- If you use an IP address (or once the IP address has been fetched from a Domain Name Server), the netmask is used to determine if it’s on your local network.
- If the address is local, Address Resolution Protocol is used to find the physical address of the local target.
- If the address is external, ARP is used to find the physical address of your gateway (this is typically the “default gateway” in your network settings).
- Now that the target has been located, an ICMP ECHO_REQUEST is sent to it.
- The target responds with an ICMP ECHO reply. The ping command calculates the time needed for the round trip and displays it.
Therefore, for a ping to work, all of your network settings must be correct, and your network connection must be good. This makes it a complete, one-stop test of the network in one go.
CAVEAT: CHECK YOUR FIREWALLS
Some firewalls block pings, which actually violates published standards. RFC1122 states that support for ICMP ECHO_REQUEST and ICMP ECHO — which are what a ping uses — is “mandatory.” In spite of this, some public servers block pings to avoid denial-of-service attacks. Some hackers will send a flood of ping requests at the target to bog it down. Other security experts recommend that ping replies be disabled because of the way that some crackers search for computers to exploit: They’ll ping an entire block of network addresses and then take a look at the responses for desirable targets.
However, on your own internal network, I strongly recommend that every machine should respond to ping requests. Most network-capable appliances, from printers to Web-capable remote controls, do not block ping echoes; they’re ready to respond out of the box. But Windows, in particular, will block ICMP by default. You need to either enable it in the firewall, or enable file and printer sharing. Do a Web search on your specific OS; for example, go to Google and try “opensuse linux ping firewall” or something like that.
The bottom line is to ensure that everything on your internal, local network(s) can respond to a ping.
NO TROUBLE TO USE
Ping is easy. Simply open a command prompt and type in “ping,” followed by the IP address or domain name that you’re trying to reach. The various ping programs included with various operating systems behave a bit differently. For example, Windows automatically stops after four ping attempts, while on Linux, by default, the ping will keep repeating until you press CTRL-C to stop it.
Ping Test of a Printer on the Local Network
Fig. 1 shows a typical response; I’ve pinged an HP printer on our network.
The positive result tells me that the printer has a working connection on our local network, that my connection is configured properly (at least for the local network) and that the target printer is powered up and is running.
If I see this, and yet I still can’t print, I’ll check my PC’s printer settings, and then go ensure that the printer hasn’t experienced an error.
Fig. 1 also shows the response times in milliseconds; this is for the complete round trip from your PC to the target and then back. The first response usually takes the longest, because the target has to be located. Once it has been found, subsequent pings are a bit faster. We’ll return to that in a moment; now let’s ping a remote site (see Fig. 2).
We’ll try Google, because it does reply to pings (they have so many servers distributed around the globe that I guess they figure, “Good luck trying to swamp us!”). This adds another useful test: “google.com” must be translated to an IP address, which means that our ping command is going to use our DNS settings. Because it’s a remote IP address, it’ll use a gateway. This tells me that my laptop’s DNS and default gateway are correct.
Ping Test of a Remote Address (google.com)
This one-two procedure (ping someone on the local network, then ping Google) is a standard test that we use daily. It’s much faster than pulling up a Web browser to see if we can get onto the Internet, then waiting for a timeout if there’s a problem. As a general rule, if a ping doesn’t respond within one second, unless you’re trying a host on the other side of the planet, just press “CTRL-C” to stop the test. You’ve got a problem that needs to be fixed.
RESPONSE TIMES AND LATENCY
The response times are interesting, too, and here’s a super tip: When transporting audio-over-IP, if you have access to more than one Internet service or microwave link, move your connection around and do some pings to see which is the fastest. Audio-over-IP needs low latency; you want virtually no delay between send and receive. Note that if you test encrypted links you’ll also confirm what you’ve probably suspected: Encrypted links can be significantly slower, because you have the overhead of encryption and decryption.
Ping isn’t the best tool for checking network quality; a hardware analyzer or the analysis software built into many microwave links nowadays is better. But you can still see gross errors and dropouts on a remote connection. You’d see wildly varying response times — the first might be 50 ms, the next is 400 ms, and so on — or even missed replies entirely. On a microwave data link, this is commonly caused by interference. Here’s the bottom line: if you get even one ping reply, the remote host is connected and powered up. It’s trying to respond. If you have wildly different ping response times and/or dropped pings, you’ve got a problem with network quality.
MORE INTERPRETATION
Again, imagine the flow of the signal as you troubleshoot. You’re sending out an ICMP ECHO_REQUEST and the remote host should return the corresponding ECHO reply within one second if everything is OK.There are three possible unsuccessful outcomes.
If you get “Timed Out” — i.e., the ping never completes at all — this means just what it says. Ping sent the echo request but timed out waiting for a reply. If you are certain that the remote target is powered up and is working, you should troubleshoot on your end.
If the ping returns “Network Unreachable,” first check your physical network connection. Next, if you’re trying to reach the local network, check your netmask and IP address. If you can’t ping the Internet, check your default gateway.
If you see “Unknown Host” or something like that, check your DNS settings. Your PC is unable to translate names like “google.com” into the appropriate IP address for the ping.
On that last one, it’s useful to keep handy a couple of known IP addresses on the Internet that you can ping. For example, I know that our Web server in Denver is at 173.8.230.33; if I can ping that IP address, but “ping www.crawfordbroadcasting.com” doesn’t work, I’ve got a DNS problem. If you can’t ping either, either your Internet connection is down or your gateway is set incorrectly.
Remember, the results in Figs. 1 and 2 will vary from one OS to the next. Learn how your version of ping responds to different problems. Do a ping with your network cable unplugged and note the result; then do a ping with the target unplugged. Learn to recognize what the various replies mean and you can troubleshoot network issues much more quickly and easily.
If you want more information, do a Web search on “ping,” or read the Wikipedia article.There are more advanced versions of ping available on the Internet, too, some which will allow you to scan an entire network and do other fancy tricks. But the default ping program included with Windows, Mac OS and Linux is still plenty good enough. Learn to use it!
Stephen M. Poole, CBRE-AMD, CBNT, is chief engineer of Crawford Broadcasting in Birmingham, Ala. Find past Radio IT Management columns at radioworld.com under the Business tab.
