Traceroute Command Overview

To Run Traceroute, Follow the Steps Below:

Windows (XP, 2000, 98, or ME) 

1. Click Start and then click Run.
2. Type cmd and then click OK.
3. Type tracert, the IP address or website name and then click Enter. 

Mac OS 10.x 

1. Go to the Finder and choose Applications.
2. Select the Network Utility from the Utilities folder.
3. Choose the traceroute tab.
4. Enter an IP address or website name and start the trace.

Gathering and Using Traceroute Information

Follow these guidelines when you run the traceroute command:

• Run the command at the time you’re experiencing a problem and compare the results with times when you’re not.
• Since the Windows tracert command is only a single snapshot of the network at a point in time, run the command multiple times to ensure that a fair sampling of data is collected. Post or report the traceroute that best represents a summary of all of the data you’ve collected.
• Copy and paste the command output to a file, as follows:
  1. For Windows CMD, right-click in the window, and chose Mark
  2. Left-click, hold and drag over the text you want to select.
  3. Once the text is fully highlighted, right-click again to copy it into the clipboard.
  4. Move your cursor to the window where you want to paste it and press CTRL-v. 
• If you’re having problems with only one particular site or application, it’s likely that the issue is localized to the owner of that site or application. Send your data to the support forums for the site or application to get resolution.
• If the problem isn’t limited to a particular site or application, contact or chat with us. You can also post the issue to our web-based support forums.

Reading the Command Output 

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.

NOTES: 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:

1. Starts in Boston and travels toward New York.
2. In New York, it transfers to ISP1.
3. Before leaving New York, it transitions to ISP2.
4. Then it travels south and west through Washington DC, Atlanta, and Dallas.
5. From Dallas, it travels to Los Angeles.
6. The final destination is Los Angeles where it leaves ISP2 for the end server.

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 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:

"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.

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.

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).

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.

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.

Is There High Latency Starting From the First Few Hops?