Reading Tracert data
Reading the Command Output of Tracert
This is sample output from the Windows tracert command.
Example: tracert Output
H:\>tracert www.example.com
Tracing route to example.com [10.10.242.22]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.0.1
2 * * * Request timed out.
3 6 ms 5 ms 6 ms 68.85.162.74
4 13 ms 8 ms 9 ms pos-0-3-0-0-cr01.newyork.ny.ibone.comcast.net [68.86.90.57]
5 95 ms 100 ms 90 ms xe-10-1-0.edge1.NewYork2.exampleISP1.net [10.1.169.45]
6 10 ms 8 ms 9 ms ae-33-89.car3.NewYork1.exampleISP1.net [10.2.16.133]
7 10 ms 9 ms 10 ms 192.205.33.93
8 84 ms 86 ms 84 ms tbr2.n54ny.ip.exampleISP2.net [172.25.3.110]
9 86 ms 86 ms 86 ms cr2.n54ny.ip.exampleISP2.net [172.30.16.133]
10 85 ms 84 ms 85 ms cr2.wswdc.ip.exampleISP2.net [172.30.3.38]
11 84 ms 85 ms 84 ms cr1.attga.ip.exampleISP2.net [172.30.1.173]
12 85 ms 86 ms 84 ms cr2.dlstx.ip.exampleISP2.net [172.30.28.174]
13 84 ms 84 ms 84 ms cr2.la2ca.ip.exampleISP2.net [172.30.28.178]
14 107 ms 84 ms 85 ms gar5.la2ca.ip.exampleISP2.net [172.30.129.25]
15 85 ms 85 ms 85 ms 172.30.255.74
16 85 ms 86 ms 84 ms mdf001c7613r03-gig-10-1.lax1.example.com [10.10.193.242]
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
NOTE: CTRL+C can be pressed to stop the traceroute. In this example, the final *s’ are due to a firewall blocking traceroute packets. This is perfectly normal.
The first line of the tracert output describes what the command is doing. It lists the destination system (example.com), destination IP address (10.10.242.22), and the maximum number of hops that will be used in the traceroute (30).
The remainder of the output shows information on each hop, which is typically a router, in the path between the sender and the final destination. It’s important to note that the number of hops isn’t an important factor that affects latency. What is most important is the physical distance the packet travels and how it moves between ISPs on the Internet. In this example, the traffic traverses this route:
- Starts in Boston and travels toward New York.
- In New York, it transfers to ISP1.
- Before leaving New York, it transitions to ISP2.
- Then it travels south and west through Washington DC, Atlanta, and Dallas.
- From Dallas, it travels to Los Angeles.
- The final destination is Los Angeles where it leaves ISP2 for the end server.
By car, this distance is well over 3,000 miles, but a fiber path does not always follow the same path as U.S. interstate highways. The fiber path distance is often further than road miles. It’s also important to note this is only half of the total round trip and the return path could be very different.
Reading Each Line
Look at Hop 4 below to get familiar with the type of information shown for each hop. It lists the hop number, three measurements for Round Trip Time (RTT), the system Name and IP Address reached at that hop.
Example: Hop 4:
Hop RTT1 RTT2 RTT3 Name [IP Address]
4 13 ms 8 ms 9 ms pos-0-3-0-0-cr01.newyork.ny.ibone.comcast.net [68.86.90.57]
Hop number: The specific hop number in the path from the sender to the destination.
Round Trip Time (RTT): The time it takes for a packet to get to a hop and back, displayed in milliseconds (ms). By default, tracert sends three packets to each hop, so the output lists three roundtrip times per hop. RTT is sometimes also referred to as latency. An important factor that may impact RTT is the physical distance between hops.
If an asterisk (*) appears for RTT, then a packet was not returned within the expected timeframe.
- One or two asterisks for a hop do not necessarily indicate packet loss at the final destination. Many Internet routers intentionally discard ping or traceroute packets, but this has no bearing on applications that use these routers. This practice is called ICMP Rate Limiting and is used to prevent routers from being impacted by denial-of-service attacks.
- Three asterisks followed by the “Request timed out” message may appear for several reasons. See the “Request timed out” Message sections that follow.
Name: The fully qualified domain name (FQDN) of the system. Many times the FQDN may provide an indication of where the hop is physically located. If the Name doesn’t appear in the output, the FQDN wasn’t found. It isn’t necessarily indicative of a problem, if an FQDN isn’t found.
IP Address: The Internet Protocol (IP) address of that specific router or host associated with the Name.
"Request timed out" Message - At the Beginning of a traceroute
A “Request timed out” message at the beginning of a traceroute is very common and can be ignored. This is typically a device that doesn’t respond to ICMP or traceroute requests, as shown in Hop 2.
Example Hop 2:
2 * * * Request timed out.
"Request timed out" Message - At the End of a traceroute
There are several reasons why a “Request timed out” message may appear at the end of a traceroute, such as in Hops 17 through 19.
- The destination’s firewall or other security device is blocking the request. Even if a firewall is preventing the final hops at the destination from showing up in traceroute output, the destination is likely still reachable using the application you’re interested in (e.g. web/HTTP).
- There could be a problem on the return path from the target system. Remember the round trip time measures the time it takes for a packet to travel from your system to a destination system and back. The forward route and the return route often follow different paths. If there is a problem on the return route, it may not be evident in the command output.
- There may be a connection problem at that particular system or the next system.
Example Hops 17 through 19:
Let's Look at the Numbers - Examining Trends
How do you know if the values for RTT are normal or if they indicate a potential problem? You need to look at the overall picture depicted in your output.
The following section describes several trends that can occur. As you’ll see, a temporary spike may at first glance appear questionable, but may also have a perfectly good explanation.
Continue reading to learn how to examine the command output for trends, and help isolate possible issues.
Remember that you’re most interested in the destination or final visible hops in a traceroute. Even if a firewall is preventing the final hops at the destination from showing up in traceroute output, the destination is likely still reachable using the application you’re interested in (e.g. web/HTTP).
Is the RTT/Latency Acceptable on the Last Visible Destination?
In principle, RTT values of less than 150 ms from your home to the final destination shouldn’t impact internet applications. Many applications work just fine with latencies even higher than that, but for sites that are US-based they should fall below 150 ms and usually are < 100 ms.
Example Hops 17 Through 19:
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
Latency over an uncongested network is primarily dependent on the physical fiber distance between the source (your PC) and the destination (e.g. server). If the source and destination are thousands of miles apart, average latency values of 100-120 ms are acceptable as communication is limited by the speed of light over the entire physical fiber distance.
Example: Hop 16
Hop 16 is the last visible hop in the sample shown previously. The round trip times for Hop 16 are acceptable because the round trip times are within expected ranges.
16 85 ms 86 ms 84 ms mdf001c7613r03-gig-10-1.lax1.example.com [10.10.193.242]
Do You Notice High Latency on Middle Hops, But Not at the Last Visible Destination?
Traceroute results that show higher latency on middle hops, but not at the last visible destination do not indicate a network problem. Traceroute packets can be treated as low priority and may be delayed or dropped, particularly at major public Internet exchanges. The measurement that’s important is the last hop or destination.
Example Hop 5:
Hop 5 is a middle hop that shows higher RTTs, possibly because the packets are being treated as low priority. The packets are flowing through the router, however, and the RTTs on the final destination are acceptable for the distance the packets have traveled (Hop 16).
5 95 ms 100 ms 90 ms xe-10-1-0.edge1.NewYork2.exampleISP1.net [10.1.169.45]
Is There Increased Latency at Middle Hops Which Remains Constant to the Last Visible Destination?
Traceroute results that show increased latency on a middle hop, which remains similar all the way through to the destination, do not indicate a network problem. This can be an artifact of a Multiprotocol Label Switching (MPLS) network.
Example Hop 8:
Starting at Hop 8, you can notice that the RTTs jump up to the 84 to 86 ms range. The RTT stays relatively constant to the last visible destination, so a problem isn’t indicated.
6 10 ms 8 ms 9 ms ae-33-89.car3.NewYork1.exampleISP1.net [10.2.16.133]
7 10 ms 9 ms 10 ms 192.205.33.93
8 84 ms 86 ms 84 ms tbr2.n54ny.ip.exampleISP2.net [172.25.3.110]
9 86 ms 86 ms 86 ms cr2.n54ny.ip.exampleISP2.net [172.30.16.133]
10 85 ms 84 ms 85 ms cr2.wswdc.ip.exampleISP2.net [172.30.3.38]
11 84 ms 85 ms 84 ms cr1.attga.ip.exampleISP2.net [172.30.1.173]
12 85 ms 86 ms 84 ms cr2.dlstx.ip.exampleISP2.net [172.30.28.174]
13 84 ms 84 ms 84 ms cr2.la2ca.ip.exampleISP2.net [172.30.28.178]
14 107 ms 84 ms 85 ms gar5.la2ca.ip.exampleISP2.net [172.30.129.25]
15 85 ms 85 ms 85 ms 172.30.255.74
16 85 ms 86 ms 84 ms mdf001c7613r03-gig-10-1.lax1.example.com [10.10.193.242]
Do You See Increasing Latency from the Middle Hop to the Destination?
A traceroute that shows dramatically increased latency on a middle hop, which then increases steadily through to the destination, can indicate a potential network issue. Packet loss or asterisks (*) on many of the middle hops may also indicate a possible network level issue.
This is the type of trend that you will want to report. A steady trend of increasing latency is typically an indication of congestion or a problem between two points in the network and it requires one or more parties to correct the problem. We may be able to assist in the reporting of these issues and sometimes may be able to correct them with the aid of other ISPs.
Example Hops 7 Through 11:
The new traceroute output below, illustrates increasing latency from the middle hop to the destination. Starting at Hop 7, you notice the RTTs jump up dramatically and that they are out of range. The RTTs for the final destination are well over speed of light expectations.
H:\>tracert www.example2.com
Tracing route to example2.com [192.168.32.15]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.0.1
2 * * * Request timed out.
3 6 ms 5 ms 6 ms 68.85.162.74
4 13 ms 8 ms 9 ms pos-0-3-0-0-cr01.newyork.ny.ibone.comcast.net [68.86.90.57]
5 95 ms 100 ms 9 ms xe-10-1-0.edge1.NY.exampleISP1.net [10.78.169.45]
6 10 ms 8 ms 9 ms ae-33-89.car3.NY.exampleISP1.net [10.68.16.133]
7 893 ms * ms 799 ms nyc-edge-03-inet.example2.com 192.168.33.4
8 809 ms 808 ms * ms nyc-core-01.inet.example2.com [192.168.33.10]
9 985 ms 947 ms 983 ms alt-core-03.inet.example2.com [192.168.32.11]
10 1028 ms 1010 ms 953 ms 192.168.32.15
Trace complete.
Comments
0 comments
Please sign in to leave a comment.