If you missed the previous articles in this series please read
If you would like to be notified when Brien M. Posey releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
In the previous part of this article series, 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 why I chose this particular site is because it is one of the few sites that I know of off the top of my head that does not block ICMP traffic. You can see the output from the trace route below. I will be referring to this output throughout the rest of the article.
C:\Users\Administrator>TRACERT www.espn.com
Tracing route to www.espn.com [199.181.132.250] over a maximum of 30 hops:
1 2 ms 1 ms <1 ms 147.100.100.100
2 10 ms 10 ms 9 ms 208.104.224.1
3 9 ms 9 ms 9 ms 208.104.1.13
4 9 ms 8 ms 9 ms 208.104.0.13
5 10 ms 9 ms 10 ms 208.104.0.1
6 11 ms 14 ms 10 ms 165.166.125.193
7 11 ms 10 ms 11 ms gig-1-1-3.core01.ncchrl.infoave.net [165.166.22.61]
8 31 ms 31 ms 30 ms 64.200.130.17
9 38 ms 39 ms 40 ms hrndva1wcx2-pos15-3-oc48.wcg.net [64.200.240.213]
10 31 ms 31 ms 31 ms 64.200.249.170
11 31 ms 30 ms 31 ms 4.68.110.5
12 48 ms 35 ms 35 ms vlan99.csw4.Washington1.Level3.net [4.68.17.254]
13 32 ms 31 ms 33 ms ae-92-92.ebr2.Washington1.Level3.net [4.69.134.157]
14 60 ms 53 ms 54 ms ae-2.ebr3.Chicago1.Level3.net [4.69.132.69]
15 86 ms 71 ms 70 ms ae-3.ebr2.Denver1.Level3.net [4.69.132.61]
16 137 ms 103 ms 102 ms ae-2.ebr2.Seattle1.Level3.net [4.69.132.53]
17 95 ms 95 ms 95 ms ae-23-52.car3.Seattle1.Level3.net [4.68.105.36]
18 94 ms 95 ms 95 ms WALT-DISNEY.car3.Seattle1.Level3.net [4.71.152.22]
19 * * * Request timed out.
20 97 ms 95 ms 98 ms 199.181.132.250
Trace complete.
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 requests TTL value is set to 1. This insures 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 amount 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, trace route is based on the concept of sending multiple ICMP requests. When we worked with the ping command earlier in this article series, you saw the ping command always returned four different values as a way of measuring packet loss. The same concept applies to trace route, 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 are 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 timeout, and the final column will simply display the words Request Timed Out.
Keep in mind though that although this is usually the case, it is not the only possibility. Trace route 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 guarantee that a link failure has occurred even when they occur together. For example, my Web site (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:
C:\Users\Administrator>TRACERT www.brienposey.com
Tracing route to www.brienposey.com [24.235.10.4]
over a maximum of 30 hops:
1 1 ms 1 ms <1 ms 147.100.100.100
2 8 ms 12 ms 8 ms 208.104.224.1
3 9 ms 8 ms 9 ms 208.104.1.9
4 10 ms 9 ms 8 ms 208.104.0.9
5 10 ms 12 ms 11 ms 208.104.0.5
6 12 ms 10 ms 9 ms 165.166.18.1
7 15 ms 23 ms 13 ms gig2-2-1.c01.scclma.infoave.net [165.166.22.17]
8 13 ms 12 ms 13 ms 66.192.166.9
9 31 ms 30 ms * peer-01-ge-0-0-0-1.asbn.twtelecom.net [64.129.249.10]
10 56 ms 57 ms 55 ms bb2-p6-0.ipltin.sbcglobal.net [151.164.242.59]
11 55 ms 53 ms 55 ms ded2-g8-0.ipltin.sbcglobal.net [151.164.42.159]
12 59 ms 56 ms 56 ms Winnet-1148485.cust-rtr.ameritech.net [66.73.221.254]
13 64 ms 63 ms 68 ms 216-24-2-237.ip.win.net [216.24.2.237]
14 68 ms 68 ms 64 ms fa0-0.cust-gw2.noc.win.net [216.24.30.69]
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.
Trace complete.
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, and see if you keep getting the same types 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. That in and of itself 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 199.181.132.250. 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 why 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.
Conclusion
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.
If you missed the previous articles in this series please read
If you would like to be notified when Brien M. Posey releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
Thanks for a great article. It was well written and to the point. I am a Linux Administration but cross training on Windows Administration.
Thanks! I’m glad that you liked it.