how-to block ads
Traceroute can be executed from a windows "command window" (aka a DOS box) with the command
e.g. tracert www.dslreports.com
The result will look something like this ...
On the left is the "hop number" ... this corresponds with the router or system in *outward bound order*.
The next 3 numbers are the time it took to go to that hop and back on 3 tries
The right is the IP address and system name for that router or system
What we are looking for is relative consistency and progression of the times consistent with the distances from you to the system in question.
In the example above,
Hop 1 is my home router so you expect a very fast response from it.
Hop 2 is the CMTS and that's the time to go from you, out your modem and back again. With DOCSIS modems, you expect this to be 7 to 12 mS
Hops 3 & 4 are routers in the Fallowfield "head end" facility in Ottawa. Notice the time at hop 4 is even faster than hops 2 and 3. This can happen because it is able to respond to the ping faster. And since we're talking milliseconds here, small variations are to be expected.
Hop 5 is a Rogers router somewhere in Toronto (note that it is un-named, like the CMTS and my own router)
The times Ottawa to Toronto are consistent with the total times shown.
Hop 6 is a Rogers gateway router in the TORIX facility on Front street Toronto.
Hop 7 is a nac.net router again at TORIX
Hops 8, 9 & 10 are nac.net routers in New York City. Note the jump to 90 mS on hop 10. This may be caused by network congestion somewhere along the way or it may be caused by loading on the router. Note that routers give pings very low priority and may drop them altogether, which can be seen next ...
Hop 11 is in fact dslreports.com which is hosted at nac.net DSLreports has chosen to disable ICMP ping response to prevent ping attacks. So, the timed out (as indicated by the askerisks) conditions here are absolutely normal.
So, when you do a tracert, your ping request to DSLreports as in this example can be expected to take the route shown above *to get there*. Note that this is NOT NECESSARILY the route that the reply packet from DSLreports will follow. This is a common confusion when interpreting a tracert.
Taking the example above, let's say that hop 8 looked like this instead ...
and all the rest of the hops were as shown.
First reaction says that there's a problem here. The reality is that there is in fact no problem here.
Because the subsequent hops are normally accepted times to the location, this means that this particular router has ping responses on very low priority, so takes a long time to respond ... but that it is forwarding packets with normal speeds since subsequent hops are normal. One can safely ignore the odd numbers here.
Now again taking the same example, say hop 8 looked like that and hops 9 & 10 looked like this
In this case we can now say that there is a problem ... but we cannot determine from the tracert exactly where and what the problem is ... that takes network engineers working in conjunction with other companies engineers to work out.
The problem starts at hop 8, which can mean that
So, what can you do? Report it as a problem to Rogers and if it's on their network, they'll see to it, but if it's say on nac.net, they MAY contact nac.net and work with nac.net to resolve the issue. You can also report it to nac.net yourself, but you may get some resistance since you aren't a customer of theirs directly.
So bottom line is that tracert can give clues as to where problems are ... but can't be definitive.
One place it can be definitive is to the first hop if it's your own router ... if say the pings to my router were 300mS, I'd know that there's a definite problem between my system and the router. It could be someone else clogging up the router such as a someone stealing my wireless signal! It could be a faulty NIC on my compute(s)r. It could be spyware on my systems.
If you're not using a router and you get poor pings on the first hop, it can be your system, your modem or a very poor connection.