PhoneBoy Explains: Ping and Traceroute

This week, I'm gonna tell you about a couple of tools you can use to find out why you can't connect to your favorite sites on the Internet.

You're surfing along on the internet, shredding thru some radical web pages and you found a cool link and then you hit the wall. "The host is not responding" This could be happening for any number of reasons:

  1. The network connection between you and the host is haneously slow or non-existantant.

  2. The host, for whatever reason, not running the service you're interested in (e.g. web server, IRC server)

  3. The host is actually not responding.
Have you ever wanted to know how the geeks figure this out? Well, I'm about to tell you our secret, and it's a lot easier than you think. There are two tools that many of us use: Ping and Traceroute. I will explain each:

Ping is used to verify that a host is "alive" and "on the network." Basically, it sends out a small packet over the network to the host that says "are you alive?". If the host is alive and capable of responding, it will send a respond back "Yes, I'm alive". Aside from just checking to see if the hosts are "alive", you can get a feel for how long it is taking for packets to travel from one system to another. You can also see if packets are being "dropped" or "lost" by telling your ping client to "ping" a certain number of times. Once the client has pinged the system that many times, it will give you statistics telling you, on the average, how long it took to receive pings back, and what percentage of "packets" were lost.

Now that you know the connection between you and your favorite host is not as good as you'd like, wouldn't it be nice to know who to blame for it? This is where traceroute comes in. Traceroute, as the name implies, traces the route the connection takes between your machine and the destination. Admittedly, on the air, it would be difficult to "show you" the results of a traceroute, but I will tell you some interesting things I found out using traceroute:
 

  1. I discovered that most of the packets between my girlfriend's Internet Provider in Seattle and my Internet provider in the Bay Area were travelling thru a articular net provider. Thru their routers, I was experiencing unbearable delays and packet loss, which made an interactive telnet session impossible. I sent a polite letter to my Internet Service Provider asking them to talk to this other provider about their problem.

  2. I found out which two routers my requests for a site were looping between, thus making the site appear "down" when really, it's just two routers who love to talk to each other.
  1. I've discovered that I could not get into a site becuase someone's router was not programmed to route that particular network address correctly. Again, a polite message to that Internet Service Provider fixed the problem.
How did Traceroute tell me all this? As Traceroute does it's thing, it prints out each machine or router that delivers your network packets to the final destination. It also pings each delivery point three times, giving time, in milliseconds, for each ping on the same line as the host.

After doing several different traceroutes, you will get a feel for what's normal or abnormal. If you see a star where a time should be, that ping "timed out." If you see lots of stars, it means packets are getting dropped all over the place. If you see a several lines of three stars without a machine name, someone's router is broken or the  machine is down.

Ping Examples

Here are some examples of Ping. These are rather represenative of my experience and interperted thru my eyes. Your mileage or opinion may vary. Don't take this as the gospel. All of these pings happened from a Unix shell account at approximately 3pm on 6/8/96. The site used has a T3 (45 MB/s) connection to the Internet. Keep away from small children. Batteries not included. Enlarged to show texture.

This is a ping I made to surfsoft.com. I had it ping surfsoft 30 times. Some ping clients allow you to specify the number of pings it does. Others won't. 30 is a good number because you get a feel for responsiveness over time. As each backet gets returned, you get a time back (in milliseconds). After the ping program was done pinging, it returns statistics telling you how many packets made it, how many got lost, and min/max/avg response times.

PING surfsoft.com (165.227.30.250): 56 data bytes
64 bytes from 165.227.30.250: icmp_seq=0 ttl=250 time=151 ms
64 bytes from 165.227.30.250: icmp_seq=1 ttl=250 time=172 ms
64 bytes from 165.227.30.250: icmp_seq=2 ttl=250 time=136 ms
64 bytes from 165.227.30.250: icmp_seq=3 ttl=250 time=144 ms
64 bytes from 165.227.30.250: icmp_seq=4 ttl=250 time=150 ms
64 bytes from 165.227.30.250: icmp_seq=5 ttl=250 time=147 ms
64 bytes from 165.227.30.250: icmp_seq=6 ttl=250 time=158 ms
64 bytes from 165.227.30.250: icmp_seq=7 ttl=250 time=142 ms
64 bytes from 165.227.30.250: icmp_seq=8 ttl=250 time=172 ms
64 bytes from 165.227.30.250: icmp_seq=9 ttl=250 time=152 ms
64 bytes from 165.227.30.250: icmp_seq=10 ttl=250 time=141 ms
64 bytes from 165.227.30.250: icmp_seq=11 ttl=250 time=148 ms
64 bytes from 165.227.30.250: icmp_seq=12 ttl=250 time=144 ms
64 bytes from 165.227.30.250: icmp_seq=13 ttl=250 time=143 ms
64 bytes from 165.227.30.250: icmp_seq=14 ttl=250 time=156 ms
64 bytes from 165.227.30.250: icmp_seq=15 ttl=250 time=155 ms
64 bytes from 165.227.30.250: icmp_seq=16 ttl=250 time=168 ms
64 bytes from 165.227.30.250: icmp_seq=17 ttl=250 time=144 ms
64 bytes from 165.227.30.250: icmp_seq=18 ttl=250 time=139 ms
64 bytes from 165.227.30.250: icmp_seq=19 ttl=250 time=161 ms
64 bytes from 165.227.30.250: icmp_seq=20 ttl=250 time=163 ms
64 bytes from 165.227.30.250: icmp_seq=21 ttl=250 time=156 ms
64 bytes from 165.227.30.250: icmp_seq=22 ttl=250 time=149 ms
64 bytes from 165.227.30.250: icmp_seq=23 ttl=250 time=173 ms
64 bytes from 165.227.30.250: icmp_seq=24 ttl=250 time=169 ms
64 bytes from 165.227.30.250: icmp_seq=25 ttl=250 time=175 ms
64 bytes from 165.227.30.250: icmp_seq=26 ttl=250 time=159 ms
64 bytes from 165.227.30.250: icmp_seq=27 ttl=250 time=171 ms
64 bytes from 165.227.30.250: icmp_seq=28 ttl=250 time=153 ms
64 bytes from 165.227.30.250: icmp_seq=29 ttl=250 time=143 ms
 

----surfsoft.com PING Statistics----
30 packets transmitted, 30 packets received, 0% packet loss
round-trip min/avg/max = 136/154/175 ms

Here's a not-so-bad one. We're getting about 20% packet loss here. Notice than the difference between successive icmp numbers on this one:

PING www.cris.com (199.3.12.172): 56 data bytes
64 bytes from 199.3.12.172: icmp_seq=0 ttl=249 time=124 ms
64 bytes from 199.3.12.172: icmp_seq=1 ttl=249 time=109 ms
64 bytes from 199.3.12.172: icmp_seq=2 ttl=249 time=98 ms
64 bytes from 199.3.12.172: icmp_seq=3 ttl=249 time=124 ms
64 bytes from 199.3.12.172: icmp_seq=5 ttl=249 time=97 ms
64 bytes from 199.3.12.172: icmp_seq=8 ttl=249 time=112 ms
64 bytes from 199.3.12.172: icmp_seq=9 ttl=249 time=107 ms
64 bytes from 199.3.12.172: icmp_seq=10 ttl=249 time=104 ms
64 bytes from 199.3.12.172: icmp_seq=11 ttl=249 time=104 ms
64 bytes from 199.3.12.172: icmp_seq=13 ttl=249 time=112 ms
64 bytes from 199.3.12.172: icmp_seq=14 ttl=249 time=106 ms
64 bytes from 199.3.12.172: icmp_seq=15 ttl=249 time=121 ms
64 bytes from 199.3.12.172: icmp_seq=18 ttl=249 time=100 ms
64 bytes from 199.3.12.172: icmp_seq=20 ttl=249 time=108 ms
64 bytes from 199.3.12.172: icmp_seq=21 ttl=249 time=118 ms
64 bytes from 199.3.12.172: icmp_seq=22 ttl=249 time=104 ms
64 bytes from 199.3.12.172: icmp_seq=24 ttl=249 time=123 ms
64 bytes from 199.3.12.172: icmp_seq=25 ttl=249 time=109 ms
64 bytes from 199.3.12.172: icmp_seq=26 ttl=249 time=110 ms
64 bytes from 199.3.12.172: icmp_seq=27 ttl=249 time=110 ms
64 bytes from 199.3.12.172: icmp_seq=28 ttl=249 time=108 ms
64 bytes from 199.3.12.172: icmp_seq=29 ttl=249 time=104 ms
 

----www.cris.com PING Statistics----
30 packets transmitted, 22 packets received, 26% packet loss
round-trip min/avg/max = 97/109/124 ms

Here's one I'd break out the traceroute on: 

PING scusun.scu.edu (129.210.17.1): 56 data bytes


----scusun.scu.edu PING Statistics----
30 packets transmitted, 0 packets received, 100% packet loss

Traceroute Examples

These examples are rather represenative of my experience and interperted thru my eyes. Your mileage or opinion may vary. Don't take this as the gospel. All of these pings happened from a Unix shell account on gate.woz.org at approximately 7:50pm on 6/2/96. It has a direct T1 connection to the Internet. Keep away from small children. Batteries not included. Enlarged to show texture.

Here's an exceptionally good traceroute to u.washington.edu, The ping times are very small (<100ms each) and there were no drops. 

traceroute to u.washington.edu (140.142.32.6), 30 hops max, 40 byte packets
 1  woz1 (204.33.18.1)  3 ms  2 ms  2 ms
 2  sjx-ca-gw31.netcom.net (163.179.200.201)  7 ms  7 ms  7 ms
 3  sjx-ca-gw3.netcom.net (163.179.200.1)  77 ms  20 ms  11 ms
 4  sjx-ca-gw1.netcom.net (163.179.1.29)  32 ms  9 ms  12 ms
 5  t3-1.scl-ca-gw3.netcom.net (163.179.220.194)  20 ms  19 ms  13 ms
 6  pb.mci.net (198.32.128.12)  14 ms  14 ms  15 ms
 7  core3-hssi3-0.SanFrancisco.mci.net (204.70.1.201)  16 ms  18 ms  16 ms
 8  core1-hssi-2.Seattle.mci.net (204.70.1.49)  31 ms  30 ms  45 ms
 9  border1-fddi-0.Seattle.mci.net (204.70.2.146)  32 ms  34 ms  32 ms
10  nwnet.Seattle.mci.net (204.70.52.6)  31 ms  31 ms  37 ms
11  uwbr1.cac.washington.edu (192.147.179.12)  32 ms  33 ms  33 ms
12  mightymite.cac.washington.edu (140.142.153.19)  39 ms  32 ms  34 ms
13  mx5.u.washington.edu (140.142.32.6)  31 ms  33 ms  32 ms
Interestingly enough, I did this traceroute a few moments earlier and got a few stars, like this: 
traceroute to u.washington.edu (140.142.32.6), 30 hops max, 40 byte packets
 1  woz1 (204.33.18.1)  3 ms  2 ms  2 ms
 2  sjx-ca-gw31.netcom.net (163.179.200.201)  7 ms  7 ms  7 ms
 3  * sjx-ca-gw3.netcom.net (163.179.200.1)  53 ms  16 ms
 4  sjx-ca-gw1.netcom.net (163.179.1.29)  28 ms  114 ms  25 ms
 5  t3-1.scl-ca-gw3.netcom.net (163.179.220.194)  17 ms  146 ms *
 6  pb.mci.net (198.32.128.12)  19 ms  60 ms  235 ms
 7  core3-hssi3-0.SanFrancisco.mci.net (204.70.1.201)  16 ms *  216 ms
 8  core1-hssi-2.Seattle.mci.net (204.70.1.49)  33 ms  32 ms  33 ms
 9  border1-fddi-0.Seattle.mci.net (204.70.2.146)  86 ms  340 ms  40 ms
10  nwnet.Seattle.mci.net (204.70.52.6)  31 ms  31 ms  36 ms
11  uwbr1.cac.washington.edu (192.147.179.12)  35 ms  32 ms  33 ms
12  mightymite.cac.washington.edu (140.142.153.19)  34 ms  31 ms  34 ms
13  mx5.u.washington.edu (140.142.32.6)  38 ms  34 ms *
What does this mean? Well this is pretty normal. If you saw the above consistantly, you might suspect a problem. It's when you get Traceroute's like this you begin to worry... 
traceroute to peak.usa1.com (204.249.225.253), 30 hops max, 40 byte packets
 1  woz1 (204.33.18.1)  3 ms  2 ms  2 ms
 2  sjx-ca-gw31.netcom.net (163.179.200.201)  7 ms  7 ms  7 ms
 3  sjx-ca-gw3.netcom.net (163.179.200.1)  67 ms  25 ms  10 ms
 4  sjx-ca-gw1.netcom.net (163.179.1.29)  195 ms  9 ms  9 ms
 5  * * t3-1.scl-ca-gw3.netcom.net (163.179.220.194)  17 ms
 6  * * *
 7  * * *
 8  * * *
 9  sl-mae-e-f0/0.sprintlink.net (192.41.177.241)  174 ms  94 ms  97 ms
10  sl-dc-8-H1/0-T3.sprintlink.net (144.228.10.41)  295 ms  109 ms *
11  sl-dc-6-F0/0.sprintlink.net (144.228.20.6)  122 ms  202 ms  83 ms
12  sl-pen-1-H2/0-T3.sprintlink.net (144.228.10.34)  91 ms  97 ms  96 ms
13  sl-pen-4-F0/0.sprintlink.net (144.228.60.4)  94 ms  90 ms  109 ms
14  sl-mass-1-S0-T1.sprintlink.net (144.228.64.54)  106 ms  126 ms  136 ms
15  wak-gw.usa1.net (204.249.225.1)  137 ms  109 ms  118 ms
16  cs8-wak-ma.usa1.net (204.249.225.17)  157 ms *  813 ms
17  peak.usa1.com (204.249.225.253)  676 ms  672 ms  676 ms
This has lots of interesting things: My last example here, I picked a host I knew was not available. The traceroute stops at router1.scu.edu. Given the host is in the scu.edu domain (scusun), this output suggests that is the case. 
traceroute to scusun.scu.edu (129.210.17.1), 30 hops max, 40 byte packets
 1  woz1 (204.33.18.1)  3 ms  2 ms  2 ms
 2  sjx-ca-gw31.netcom.net (163.179.200.201)  7 ms  7 ms  7 ms
 3  sjx-ca-gw3.netcom.net (163.179.200.1)  12 ms  10 ms  9 ms
 4  sjx-ca-gw1.netcom.net (163.179.1.29)  10 ms  8 ms  8 ms
 5  t3-1.scl-ca-gw3.netcom.net (163.179.220.194)  13 ms  13 ms  23 ms
 6  mae-w.bbnplanet.net (198.32.136.14)  13 ms  13 ms  12 ms
 7  paloalto-br2.bbnplanet.net (4.0.1.13)  150 ms  12 ms  210 ms
 8  paloalto-cr2.bbnplanet.net (131.119.0.195)  15 ms  14 ms  12 ms
 9  santaclara-cr1.bbnplanet.net (131.119.2.18)  29 ms 15 ms  20 ms
10  129.210.8.254 (129.210.8.254)  18 ms  19 ms  16 ms
11  router1.scu.edu (129.210.248.253)  58 ms  24 ms  18 ms
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Pinging and Tracerouting for yourself!

The most cool Ping/Traceroute utility for Windows 3.1 and Windows95 is available at http://www.csra.net/junodj

Windows 95 comes with ping and traceroute utilities. Use 'ping' and 'tracert' from a DOS window.

Last Update: 26 July 1997
Return to PhoneBoy's Internet Guide