In the previous part of this article series, Using tracert and TTL to troubleshoot network connectivity problems, I explained that tracert could be used to help diagnose connectivity problems between local hosts, and hosts on remote networks. In that article, I showed you how to issue a basic tracert command. So in this article, I will continue the discussion by showing you how you can interpret the results.
For demonstration purposes, I have performed a tracert against www.espn.com. The only reason I chose this particular site is that it is one of the few sites that I know of off the top of my head that does not block Internet Control Message Protocol (ICMP) traffic.
You can see the output from the traceroute below. I will be referring to this output throughout the rest of the article:
Tracing route to www.espn.com [18.104.22.168] over a maximum of 30 hops:
1 2 ms 1 ms <1 ms 22.214.171.124
2 10 ms 10 ms 9 ms 126.96.36.199
3 9 ms 9 ms 9 ms 188.8.131.52
4 9 ms 8 ms 9 ms 184.108.40.206
5 10 ms 9 ms 10 ms 220.127.116.11
6 11 ms 14 ms 10 ms 18.104.22.168
7 11 ms 10 ms 11 ms gig-1-1-3.core01.ncchrl.infoave.net [22.214.171.124]
8 31 ms 31 ms 30 ms 126.96.36.199
9 38 ms 39 ms 40 ms hrndva1wcx2-pos15-3-oc48.wcg.net [188.8.131.52]
10 31 ms 31 ms 31 ms 184.108.40.206
11 31 ms 30 ms 31 ms 220.127.116.11
12 48 ms 35 ms 35 ms vlan99.csw4.Washington1.Level3.net [18.104.22.168]
13 32 ms 31 ms 33 ms ae-92-92.ebr2.Washington1.Level3.net [22.214.171.124]
14 60 ms 53 ms 54 ms ae-2.ebr3.Chicago1.Level3.net [126.96.36.199]
15 86 ms 71 ms 70 ms ae-3.ebr2.Denver1.Level3.net [188.8.131.52]
16 137 ms 103 ms 102 ms ae-2.ebr2.Seattle1.Level3.net [184.108.40.206]
17 95 ms 95 ms 95 ms ae-23-52.car3.Seattle1.Level3.net [220.127.116.11]
18 94 ms 95 ms 95 ms WALT-DISNEY.car3.Seattle1.Level3.net [18.104.22.168]
19 * * * Request timed out.
20 97 ms 95 ms 98 ms 22.214.171.124
If you look at the tracert above, you will notice that each line of the output contains several different pieces of information. The first piece of information, found on the leftmost side of each line, is the hop number. As I explained in the previous article, tracert works by sending a ping request to the specified host. Initially, the request's time-to-live (TTL) value is set to 1. This ensures that the request will fail after the first hop. Information about the hop is presented, and then the ICMP request is transmitted again, but this time with the TTL value set to 2. The process is repeated over and over again, increasing the TTL value by 1 each time, until the specified host is finally reached. In doing so, tracert is able to report how many hops the request had to make in order to reach the remote host. If you look at the last line of the output above, you will see that it begins with the number 20. That is because it took 20 hops to reach the specified host.
The next three pieces of information on each line display the length of time that it took to reach the router or host that the particular line refers to. If you look through the list, you will notice that the time links generally increase with each hop. There are two things that you really need to know about the time links that are displayed.
First, three separate time lengths are displayed for each hop. As I mentioned before, traceroute is based on the concept of sending multiple ICMP requests. When we worked with the ping command earlier in this article series, you saw that the ping command always returned four different values as a way of measuring packet loss. The same concept applies to traceroute, except that the length of time the request took is measured three times instead of four.
The second thing that you need to know about the response times is that an asterisk indicates that a request has timed out. This may or may not indicate a problem, depending on how the asterisk appears. If you look at hop number 19 in the output above, you will notice that all three response time values are presented as asterisks. When you see three asterisks in a row, it usually means that the device that is being pinged on at hop has its firewall configured to reject ICMP packets. This will cause each of the timers to time out, and the final column will simply display the words "Request Timed Out."
Keep in mind, however, that although this is usually the case, it is not the only possibility. Traceroute will also display three asterisks when the device in question is unreachable. Of course, that raises the question of how you can tell the difference between a site that blocks ICMP packets and a link failure. Well, it can be a little tricky.
At first glance, a link failure looks identical to what you see when a router or a host blocks ICMP requests. When a failure occurs, you are not going to see an error message. In fact, the process ends with the standard "Trace Complete" message.
There are two good signs that a link failure has occurred. One sign is that beyond a certain point in the trace, every result that is returned times out. Another sign of a link failure is that the tracert proceeds for a full 30 hops. Neither of these conditions guarantees that a link failure has occurred, even when they occur together. For example, my website, www.brienposey.com, is working fine at the moment, and yet when I run a tracert against it, both of these symptoms show up, as shown in the output below:
Tracing route to www.brienposey.com [126.96.36.199]
over a maximum of 30 hops:
1 1 ms 1 ms <1 ms 188.8.131.52
2 8 ms 12 ms 8 ms 184.108.40.206
3 9 ms 8 ms 9 ms 220.127.116.11
4 10 ms 9 ms 8 ms 18.104.22.168
5 10 ms 12 ms 11 ms 22.214.171.124
6 12 ms 10 ms 9 ms 126.96.36.199
7 15 ms 23 ms 13 ms gig2-2-1.c01.scclma.infoave.net [188.8.131.52]
8 13 ms 12 ms 13 ms 184.108.40.206
9 31 ms 30 ms * peer-01-ge-0-0-0-1.asbn.twtelecom.net [220.127.116.11]
10 56 ms 57 ms 55 ms bb2-p6-0.ipltin.sbcglobal.net [18.104.22.168]
11 55 ms 53 ms 55 ms ded2-g8-0.ipltin.sbcglobal.net [22.214.171.124]
12 59 ms 56 ms 56 ms Winnet-1148485.cust-rtr.ameritech.net [126.96.36.199]
13 64 ms 63 ms 68 ms 216-24-2-237.ip.win.net [188.8.131.52]
14 68 ms 68 ms 64 ms fa0-0.cust-gw2.noc.win.net [184.108.40.206]
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.
If you see an output like the one above, it may indicate that a link failure has occurred, but it does not guarantee it. The only way to know for sure is to try running a tracert against multiple sites to see whether you keep getting the same type of results. Keep in mind that higher-numbered hops are further away from you. The further away a failure is, the harder it will be to diagnose, because tests of other sites may take alternate routes. When you perform tracert tests against multiple sites, you will have to look at the routes that were actually taken to determine whether or not a link failure is occurring.
The final piece of information displayed on each row is the identity of the router or host that responded to the ICMP request. Tracert will identify each host or router by name whenever possible, but you will not always get a full name resolution. For example, if you look at the output above, you can see that about half of the routers are identified by name, while the others are not. In and of itself, that is not usually a big deal.
What you might find interesting is that the host that you are tracing the route to is not always going to be identified. For example, if you look at the very beginning of the first sample output above, you will notice that we entered the command TRACERT WWW.ESPN.COM. Immediately after doing so, tracert resolved www.espn.com to the IP address 220.127.116.11. If you skip ahead to the end of the sample output, you will notice that tracert eventually reaches its destination, but it does not identify the destination by name (at least, not in this case).
This behavior is not problematic, it is by design. The reason I showed you this is so that you would not try to perform a tracert to a site and think that the process failed because the destination host is not identified by name.
In this article, I have shown you how to decipher the output of a tracert. In the next article in this series, I will show you how to use the Route command to examine a machine's routing tables.
About the author:
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.
WindowsNetworking.com contains a wealth of networking information for administrators, featuring information on how to set up and troubleshoot networks of any size. It also includes a comprehensive archive of hundreds of reviewed networking software and hardware solutions. Frequently updated with articles and tips by a team of leading authors, WindowsNetworking.com remains a favorite within the networking community.
This was first published in June 2009