Image of Jeremy L. Gaddis, CCNA, CCNP (and Cortney, in case you were wondering)

Using ping for Troubleshooting and Verification

by Jeremy L. Gaddis on September 10, 2011 · 0 comments

Post image for Using ping for Troubleshooting and Verification

You’re probably familiar with underwater SONAR, which sends out pulses of sounds and listens for echoes. By measuring the amount of time it takes for the echoes to arrives, it is possible to locate objects in the water.

One tool in our troubleshooting toolbox, ping, works in a similar manner (indeed, that’s how it got its name). Ping sends out special Internet Control Message Protocol (ICMP) packets, called echo requests, to a remote computer or device and waits for a response, an echo reply, to arrive. We’ll talk more about ICMP later.

Ping measures the amount of time it takes for a response to be received, which can help us troubleshoot problems in the network. Likewise, a lack of response can be — but isn’t necessarily — indicative of network problems.

Are You There?

At it’s simplest form, ping allows us to verify if a remote host is accessible across the network. When we run the ping command, an echo request (“ping”) packet is sent to the target host which should respond by sending back an echo reply (“pong”) packet. If we receive a response, we know that the remote host is online.

NOTE: Unfortunately, many security professionals now use firewalls to block ICMP messages from passing through the network. This can make our job of troubleshooting more difficult. For our exercises, we’ll assume that ICMP messages aren’t being blocked.

The ping command is available on all of our routers, switches, and computers. Here’s the output that results from pinging the IP address 8.8.8.8 (one of Google’s public DNS servers) from my server:

$ ping -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=53 time=45.0 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=53 time=30.5 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=53 time=30.6 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=53 time=30.5 ms
64 bytes from 8.8.8.8: icmp_req=5 ttl=53 time=30.6 ms
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 30.542/33.471/45.018/5.777 ms

NOTE: The “-c 5″ option instructs the ping command to send five echo request packets and then quit.

We can obtain lots of useful information from running this simple command (some of which we won’t cover just yet). First, the fact that we received a response at all indicates to us that the remote host is online and that we have network connectivity with the host.

In addition, look at the statistics at the bottom of the output. Five pings were sent and five pongs were received, indicating that there is “0% packet loss” between the two hosts. The last line shows us at the average round-trip time (RTT) was 32.989 milliseconds. The minimum was 30.359 ms and the maximum was 39.751 ms, with a standard deviation of 3.618 ms.

Establishing baselines for this type of measurement is a great way to be alerted to issues in the network. If it normally takes, on average, 30 ms to reach a remote host, for example, and that suddenly increases to 100 ms, we may want to look into what caused the change.

Hello? Hello?

Life would be much easier for us if hosts were always online but, unfortunately, they aren’t. Let’s take a look at what happens if we ping a host that is offline or doesn’t exist.

$ ping -c 5 192.0.2.50
PING 192.0.2.50 (192.0.2.50) 56(84) bytes of data.

--- 192.0.2.50 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4030ms

In this case, as you can see, we sent five “pings” but received zero responses. This host is either not online or may not even exist.

Pinging Hostnames

In the above examples, we sent ICMP echo requests directly to a host by using its IP address. We can also use hostnames with the ping command. This has the added advantage of verifying that DNS (the system that translates hostnames to IP addresses) is working.

To demonstrate, let’s ping the hostname “google.com”:

$ ping -c 5 google.com
PING google.com (74.125.53.104) 56(84) bytes of data.
64 bytes from pw-in-f104.1e100.net (74.125.53.104): icmp_req=1 ttl=53 time=30.5 ms
64 bytes from pw-in-f104.1e100.net (74.125.53.104): icmp_req=2 ttl=53 time=30.7 ms
64 bytes from pw-in-f104.1e100.net (74.125.53.104): icmp_req=3 ttl=53 time=30.3 ms
64 bytes from pw-in-f104.1e100.net (74.125.53.104): icmp_req=4 ttl=53 time=30.2 ms
64 bytes from pw-in-f104.1e100.net (74.125.53.104): icmp_req=5 ttl=53 time=30.4 ms

--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 30.296/30.476/30.779/0.276 ms

In order to send the echo requests to the remote host, ping must first do a DNS lookup and obtain the IP address associated with the name “google.com”. As you can see, that IP address — or, in Google’s case, one of them — is 74.125.53.104. Once the IP address has been obtained, the pings can be sent.

$ ping -c 5 fakename.freeccnalabs.com
ping: unknown host fakename.freeccnalabs.com

In this case, I tried to ping the hostname “fakename.freeccnalabs.com” which, as you might guess, doesn’t exist. ping first tried to find out the IP address associated with this hostname but there isn’t one.

Lab Exercise

Summary

The ping utility, although going on 30 years old, is still one of the most useful troubleshooting tools available to us and you’ll use it extensively while preparing for the CCNA exam. We’ll cover it in more detail later, but for now be sure to work through the ping lab exercise to become familiar with how it works.

Another tool you’ll become intimately familiar with is traceroute, which shows us the path that packets take through a network on their way to the destination.

Image Source

Previous post:

Next post: