Diagnose Dataflow Problems: The Traceroute

Leading on from yesterday’s post about how to do a ping test we move on to another test which might uncover more information about where dataflow problems may be occurring.

In a nutshell, a traceroute shows you all of the various entities (also known as “hops”) on the Internet that sit between you and a particular endpoint. Sometimes, there will only be a few hops between you and a site if it is local to yourself or otherwise there will be more if the target resides further away (like overseas or internationally). The traceroute is very much like a ping test for each hop to help you work out where a data flow problem may lie.

So how do you do a traceroute?

1. Press Window + R,
2. Type in “cmd” and press Enter to bring up a command prompt,
3. Type in “traceroute <address>” where <address> is a web address like google.com.au or an IP address like 139.145.5.51 (which is the BigPond primary DNS) and press Enter.

You should then get something like this:

Typical Traceroute

As you can see, there are only four hops between my computer and the TPG website and most of the response times are quite reasonable. You will notice that the first response for the third hop was over 500ms but the other responses were fairly quick. Depending on whether or not this sort of latency is a regular occurrence (as a result of repeating the test) this may not be an issue.

Furthermore, latency is less of an issue for activities such as web browsing (to a degree) and e-mail but can cause issues with real-time activities such as VoIP phone calls, video calls, Skype and gaming (which is why playing games on servers as close to you as possible is always best).

One thing to note is that sometimes you won’t get a response from a particular hop like in the example below:

Traceroute with Unresponsive Hop

Hop 9 appears to be unresponsive but this can be as a result of settings on that particular machine that stop it from responding to pings. If you get responses after such hops then you can probably ignore it but if you don’t get any responses from hops further downstream then that may be cause for concern. Ideally though you will be able to get a response from the endpoint with low latency (so up to 150ms for local sites and up to 350ms for international sites).

The whole point of the traceroute is to try and uncover whether or not a hop between you and a site is overly slow or congested when attempting to troubleshoot poor dataflow inside your home network, within your ISP’s network or somewhere outside of your ISP’s network. If results consistently point to something in your ISP’s network then you can try discussing this with them (although your mileage may vary) or you can switch to another ISP with a better network. Otherwise, if it appears that something in your home network is slowing thing down then you might need to do further troubleshooting (of which I will cover a few potential causes tomorrow).