How to read a traceroute
In this tutorial:
There are times when it seems your website may respond slowly. Slow response time may indicate a problem. Most just assume the server is overloaded and call their technical support. Many times, the support representative will ask for a ping and traceroute report. While we have instructions on running this report, it can seem rather cryptic when looking at it.
It doesn't take a degree or any kind of special training to decode a traceroute report. In fact, we will teach you how in this article. This way, if you ever have slow response from your site, you can run a report and quickly determine whether you need to contact our Live Support team.
How a Traceroute works
Whenever a computer connects to a website, it must travel a path that consists of several points, a little like connecting the dots between your computer and the website. The signal starts at your local router in your home or business, then moves out to your ISP, then onto the main networks. From there it may have several junctions until it gets off the Internet highway at the local network for the website and then to the webserver itself.
A traceroute displays the path that the signal took as it traveled around the Internet to the website. It also displays times which are the response times that occurred at each stop along the route. If there is a connection problem or latency connecting to a site, it will show up in these times. You will be able to identify which of the stops (also called 'hops') along the route is the culprit.
How to read a Traceroute
Once the traceroute is run, it generates the report as it goes along the route. Below is a sample traceroute:
C:\>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 172.16.10.2 2 * * * Request timed out. 3 2 ms 2 ms 2 ms vbchtmnas9k02-t0-4-0-1.coxfiber.net [18.104.22.168] 4 12 ms 13 ms 3 ms 22.214.171.124 5 7 ms 7 ms 7 ms chndbbr01-pos0202.rd.ph.cox.net [126.96.36.199] 6 10 ms 8 ms 9 ms ip10-167-150-2.at.at.cox.net [188.8.131.52] 7 10 ms 9 ms 10 ms 100ge7-1.core1.nyc4.he.net [184.108.40.206] 8 72 ms 84 ms 74 ms 10gr10-3.core1.lax1.he.net [220.127.116.11] 9 76 ms 76 ms 90 ms 10g1-3.core1.lax2.he.net [18.104.22.168] 10 81 ms 74 ms 74 ms 22.214.171.124 11 72 ms 71 ms 72 ms www.inmotionhosting.com [126.96.36.199]
As you can see, there are several rows divided into columns on the report. Each row represents a "hop" along the route. Think of it as a check-in point where the signal gets its next set of directions. Each row is divided into five columns. A sample row is below:
10 81 ms 74 ms 74 ms 188.8.131.52
Let's break this particular hop down into its parts.
|Hop #||RTT 1||RTT 2||RTT 3||Name/IP Address|
|10||81 ms||74 ms||74 ms||184.108.40.206|
Hop Number - This is the first column and is simply the number of the hop along the route. In this case, it is the sixth hop.
RTT Columns - The next three columns display the round trip time (RTT) for your packet to reach that point and return to your computer. This is listed in milliseconds. There are three columns because the traceroute sends three separate signal packets. This is to display consistency, or a lack thereof, in the route.
Domain/IP column - The last column has the IP address of the router. If it is available, the domain name will also be listed.
Checking the hop times
The times listed in the RTT columns are the main thing you want to look at when evaluating a traceroute. Consistent times are what you are looking for. There may be specific hops with increased latency times but they may not indicate that there is an issue. You need to look at a pattern over the whole report. Times above 150ms are considered to be long for a trip within the continental United States. (Times over 150ms may be normal if the signal crosses an ocean, however.) but issues may show up with very large numbers.
Increasing latency towards the targetIf you see a sudden increase in a hop and it keeps increasing to the destination (if it even gets there), then this indicates an issue starting at the hop with the increase. This may well cause packet loss where you will even see asterisks (*) in the report.
1 10 ms 7 ms 9 ms 172.16.10.2 2 78 ms 100 ms 32 ms ip10-167-150-2.at.at.cox.net [220.127.116.11] 3 78 ms 84 ms 75 ms 100ge7-1.core1.nyc4.he.net [18.104.22.168] 4 782 ms 799 ms * ms 10gr10-3.core1.lax1.he.net [22.214.171.124] 5 * ms 899 ms 901 ms 10g1-3.core1.lax2.he.net [126.96.36.199] 6 987 ms 954 ms 976 ms 188.8.131.52 7 1002 ms 1011 ms 999 ms www.inmotionhosting.com [184.108.40.206]
High latency in the middle but not at beginning or end
If the hop immediately after a long one drops back down, it simply means that the router at the long hop set the signal to a lower priority and does not have an issue. Patterns like this do not indicate an issue.
1 <1 ms <1 ms <1 ms 220.127.116.11 2 30 ms 7 ms 11 ms 10.10.0.2 3 200 ms 210 ms 189 ms 18.104.22.168 4 111 ms 98 ms 101 ms ip10-167-150-2.at.at.cox.net [22.214.171.124] 5 99 ms 100 ms 98 ms 126.96.36.199
High latency in the middle that remains consistent
If you see a hop jump but remain consistent throughout the rest of the report, this does not indicate an issue.
1 <1 ms <1 ms <1 ms 188.8.131.52 2 30 ms 7 ms 11 ms 10.10.0.2 3 93 ms 95 ms 92 ms 184.108.40.206 4 95 ms 99 ms 101 ms ip10-167-150-2.at.at.cox.net [220.127.116.11] 5 99 ms 100 ms 98 ms 100ge7-1.core1.nyc4.he.net [18.104.22.168] 6 95 ms 95 ms 95 ms 10g1-3.core1.lax2.he.net [22.214.171.124] 7 95 ms 96 ms 94 ms 126.96.36.199]
High latency in the beginning hops
Seeing reported latency in the first few hops indicates a possible issue on the local network level. You will want to work with your local network administrator to verify and fix it.
Timeouts at the beginning of the report
If you have timeouts at the very beginning of the report, say within the first one or two hops, but the rest of the report runs, do not worry. This is perfectly normal as the device responsible likely does not respond to traceroute requests.
Timeouts at the very end of the report
Timeouts at the end may occur for a number of reasons. Not all of them indicate an issue, however.
- The target's firewall may be blocking requests. The target is still most probably reachable with a normal HTTP request, however. This should not affect normal connection.
- The return path may have an issue from the destination point. This would mean the signal is still reaching, but just not getting the return signal back to your computer. This should not affect normal connection.
- Possible connection problem at the target. This will affect the connection.
Do I need to contact my hosting company?
Once you have found a hop that seems to have an issue, you can identify its location and determine where the issue lies. It may be within your network, your ISP, somewhere along the route, or within your hosting provider's domain.
The first hop is within your own network. The next hop is your ISP. The last couple of hops are likely within your hosting providers' domain and control, so if the issue is there, they may be able to fix it for you. If it is anywhere prior to that, the issue is simply along the route and is within neither your nor your hosting provider's control.
2014-09-10 11:55 am
IDK, probably the best one I have read and I have read MANY!
Having s SERIOUS issue with latency just on my pc using cable modem connecting to my website. No other website has this issue. Can take 20-30 seconds to load. If I use a proxy server, takes 2-3 seconds.
If I connect to cable modem via WiFi with my Samsung Galaxy S5, go to website, problem is there. If I kill WiFi and connect with AT&T carrier, response to website is 1-3 seconds; not 20-30 when using cable modem.
Now you guys have me interested in your hosting service.
2015-01-02 10:15 pm
you can't improve it.
I knew nothing at all about tracer routes until I read your article.
Thank you very much.
2015-02-15 11:43 pm
How is the #10 hop number the 6th? Is there a reason that the origional poster didnt specify? Im completely new to this and ive been looking for an hour now about hop numbers and this threw me completely off
2015-02-16 3:17 pm
Thanks for the questions. The traceroutes supplied above are samples for the purposes of the tutorial. If you have a specific question about traceroutes, please let us know.
2015-02-25 11:50 am
is asterisks the same as n/a , just before my latency goes high , a hop has n/a
2015-02-27 10:02 am
It is not uncommon to have a hop or two in a trace with asterisks. If the asterisks continued throughout the trace and the trace never got to it's destination, that's obviously bad. But one or two hops in there with asterisks could mean that router is not sending responses to pings.
2015-02-25 11:54 am
rout has 9 hops , 1st 4 hops around 36 ms , then 5th hop shows n/a , 6th hop jumps to 138ms is that normal
2015-02-27 10:03 am
If the 7th hop was under 100ms, then it is likely that hop 6 set your packet to a lower priority. That would not indicate a traffic or latency issue.
2015-04-24 9:55 pm
Hello Clemson Guy,
The normal reason you'll see a repetition in the trace is due to network configuration. It might be an internal and external portion of the network. The timeout in between is probably the result of a firewall. This is a guess on my part at this point because I'm not familiar with your network configuration. This postalso describes a result similar to yours. If you want further confirmation, then look for a local network engineer, to look at the traceroute for you. You can also submit a ticket request (if you're a customer of InMotion) to the InMotion Hosting live technical support team. They can look at the traceroute result in more depth.
2015-05-03 6:49 pm
I'm having an impossible time connecting to certain sites, one of which is google. I can't connect to facebook or google using chrome or IE , but I can connect to all sites using firefox. Ironically, I can connect to bing using IE and chrome. I suspect that I have some vicious malware because Norton *cough cough* has been losing it's mind, and can't even run NPE now.
Someone suggested that I run a traceroute on google.com to see what was going on, but I don't understand any of these results. Any help is appreciated.C:\Users\XXXXXXK>tracert www.google.comTracing route to www.google.com [188.8.131.52]over a maximum of 30 hops: 1 2 ms 1 ms <1 ms 192.168.1.1 2 12 ms 28 ms 35 ms 184.108.40.206 3 20 ms 9 ms 9 ms 220.127.116.11 4 12 ms 11 ms 12 ms xe-7-1-7-0-ar01.whitemarsh.md.bad.comcast.net [18.104.22.168] 5 22 ms 26 ms 19 ms he-3-5-0-0-cr01.newyork.ny.ibone.comcast.net [22.214.171.124] 6 15 ms 25 ms 17 ms he-0-11-0-0-pe02.111eighthave.ny.ibone.comcast.net [126.96.36.199] 7 22 ms 56 ms 16 ms 50-248-116-186-static.hfc.comcastbusiness.net [188.8.131.52] 8 21 ms 17 ms 17 ms 184.108.40.206 9 19 ms 24 ms 18 ms 220.127.116.11 10 32 ms 34 ms 31 ms 18.104.22.168 11 19 ms 17 ms 23 ms 22.214.171.124 12 119 ms 17 ms 18 ms 126.96.36.199 13 22 ms 18 ms 19 ms iad23s24-in-f20.1e100.net [188.8.131.52]Trace complete.
2015-05-04 7:53 am
I took a look at your traceroute and everything looks fine. There is no indicator of latency or of the signal not making the trip properly. You may have some sort of issue locally or within your browsers. Unfortunately we are unable to assist with local issues. But the trace definitely looks normal.
2015-06-10 11:50 am
thanks for the nice article.
when i do a traceroute in my system - i see a lot of "*" beyond 15 hops. however, when i try using http to access the target i am able to do it. Any idea what the problem might be? i read "*" meant loss of data packets. Does a "*" indicate slow network connectivity always?
i see the following
1 192.168.0.1 (192.168.0.1) 2.045 ms 1.619 ms 1.457 ms
2 ras.beamtele.net (184.108.40.206) 1.947 ms 2.646 ms 1.777 ms
3 ras.beamtele.net (220.127.116.11) 3.927 ms 2.427 ms 2.337 ms
4 ras.beamtele.net (18.104.22.168) 2.888 ms 2.905 ms 3.108 ms
5 22.214.171.124.static-hyderabad.vsnl.net.in (126.96.36.199) 3.171 ms 2.532 ms 3.103 ms
6 * * *
7 * * *
8 * * *
9 if-8-1600.tcore1.pye-paris.as6453.net (188.8.131.52) 124.681 ms 125.289 ms 128.638 ms
10 if-2-2.tcore1.pvu-paris.as6453.net (184.108.40.206) 124.533 ms 123.979 ms 124.822 ms
11 xe-0-1-0.mpr1.cdg11.fr.zip.zayo.com (220.127.116.11) 121.835 ms 120.686 ms 120.923 ms
12 * * *
13 ae5.cr2.dca2.us.zip.zayo.com (18.104.22.168) 212.859 ms 206.206 ms 214.113 ms
14 xe-0-0-0.mpr1.iad6.us.zip.zayo.com (22.214.171.124) 222.660 ms 217.433 ms 218.426 ms
15 126.96.36.199.t01076-01.above.net (188.8.131.52) 208.801 ms 211.877 ms 216.963 ms
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
64 * * *
2015-06-11 3:45 am
Typically, the *** is indicating a firewall preventing a return in your traceroute. However, if it's timing out repeatedly at the end, then there may be another issue at hand. If you are a customer of InMotion Hosting, please submit the traceroute to our live support team through a support ticket in order to have the issue properly investigated. Otherwise, you will need to have the issue investigated by your ISP or your host's support.
2015-06-19 4:54 pm
1 <1 ms <1 ms <1 ms 192.168.0.1
2 8 ms 8 ms 12 ms 10.98.48.1
3 60 ms 62 ms 59 ms 192.168.49.65
4 19 ms 19 ms 23 ms 10.224.253.13
5 58 ms 59 ms 59 ms 10.224.252.1
6 59 ms 58 ms 68 ms xe-4-3-3.bar1.Phoenix1.Level3.net [184.108.40.206]
7 82 ms 78 ms 92 ms ae-1-60.edge8.SanJose1.Level3.net [220.127.116.11]
8 79 ms 88 ms 98 ms ae-1-60.edge8.SanJose1.Level3.net [18.104.22.168]
9 79 ms 78 ms 87 ms 22.214.171.124
10 78 ms 78 ms 79 ms 126.96.36.199
11 97 ms 97 ms 95 ms 188.8.131.52
12 96 ms 97 ms 95 ms 184.108.40.206
13 97 ms 97 ms 96 ms 220.127.116.11
This is my traceroute to a game server thats in portland oregon (I live in Idaho) what can I do to get my ISP to put me on a priority line because it hasn't always been like this... they keep telling me they have no control over their own routing.
2015-06-22 3:02 pm
Thank you for contacting us. Once your ISP leaves the Data Center they are essentially at the mercy of the backbone they are using, since there are a limited amount of lines connecting some areas.
A better approach may be to perform a traceroute at the time you are experiencing issues. This will provide specific evidence that you can forward to your ISP.
They should then be able to contact their backbone provider and address the route problem.