Previously I have posted an article titled “How A Pathping Works“. In this article i demonstrated how a pathping can help identify where an issue lies if you are unable to connect to a webpage.
Sometimes however a pathping is overkill and you may only need to see where the connection fails. This is where a trace route comes in handy.
What Is A Trace Route
When communicating over the internet your requests are broken up into a series of small packets. These packets do not go directly from your PC to the recipient instead these packets jump from 1 server to another until finally they reach the destination.
A trace route makes use of the TTL field of the TCP protocol to show each step a packet goes through to reach the final destination. Each step within the trace route is called a hop.
How You Read The Results From A Pathping
Running a trace route is a very simple task. Firstly open a Dos prompt (click the link for instructions).
Once open you should see something similar to the screenshot below.
Now that we have the dos prompt we type the following command to carry out the trace route:
Of course you need to replace mywebsite.com with a site that you wish to carry out a trace route on. If you are having issues with your site then this would be the address for the site in question. If you are having issues with the internet in general replace it with a site that you know is reliable (google.com for example).
After pressing enter you will start to see a basic trace route being completed. As mentioned this is the route the information is taking when you are attempting to visit the site in question.
The following is the output that I received when I carried out a trace route to petermcdonald.co.uk (this site)
Now there are a few things that we need to look at in this output.
Firstly after we carry out a trace route we are presented with a message that states where we are carrying out a trace route too. Within square brackets we will be shown the IP address of the site. 1 thing to keep an eye out for is to ensure the IP looks correct. Ensure that the IP is not something like 192.168.x.x unless of course you are carrying out a trace route to a device on your network. IP’s within this range are on your network (or the network you are connected too if you are on a VPN).
Further down you can see a line for each hop on the network. The following is the information on each line:
- Hop number represented by a sequential number
- 3 figures representing the return time for packets to the hop (read “How A Ping Works” for further information on this). These figures are measured in milliseconds.
- The IP address or hostname for the hop
Let us look at each of these in turn.
The hop number is actually of no concern at all here. This simply makes it easy to find out which hop you are looking at and a quick glance shows how many hops occur. This can be ignored.
Hop Response Time
As mentioned there are 3 figures for each hop that shows how long it takes to receive a response when sending a packet to the IP address on this hop. These responses should occur so fast that it is necessary to measure this in milliseconds (in fact on hop 1 two out of the three packets returned within 1 millisecond)
In my example you can see that on hop 3 that there are no times for the packets. Instead we see 3 *. This indicates that we did not receive any packets in response. If you receive no responses from this hop but receive response from further hops do not be concerned. The device on this hop does not respond to such packets. If you receive 1 or 2 responses then I would look into carrying out a pathping (check out “How A Pathping Works” for instructions on how to do this.) as this indicates you have something called a packet loss issue which can cause no web issues or slow speeds.
The time taken to receive a response can indicate a problem. Under normal circumstances responses over 100 on hop 2 I would consider an issue however during the time of running this trace route I was downloading numerous files which will skew the results.
IP Address / Hostname
Lastly we see that each hop has an IP address, hostname or returns “Request timed out.” (this would occur as in my case on hop 3 if you do not receive a response to the packets sent). This is useful as it will help you identify where an issue starts.
So When Would I Use A Trace Route
There are numerous reasons why you would decide to carry out a trace route. Here are some of them:
You are unable to navigate to a webpage
If you are able to get webpages in general but unable to navigate to a specific webpage carrying out a trace route can help identify where the issue is. I for example run numerous websites and when I find there is an issue with the site I can carry out a trace route and see where it stops. If the trace route stops within my network then I know it is most likely my issue, if it stops within my ISP’s network then it could be a routing issue within my ISP or if it stops in or close to the data center that my site is situated in then it could be a routing issue or hardware issue at the data center. Of course if it completes right to the server then the issue has to be with the servers configuration.
If the issue is in the data center that provides the hosting for my server I would run a pathping before submitting a ticket. The information will be invaluable to them in identifying where the issue is located. I would however carry out the trace route first as the pathping takes up to 10 minutes as opposed to the 30 seconds a trace route takes.
You Have Issues Playing Online Games
If you are having issues playing online games then you could trace route to the server that the games are hosted on. In this instance I would look at the hop times to see if these dramatically increase. The higher the hop times the more lag will generally occur.
If you would like to learn more about the more advanced features of trace route take a look at this Microsoft tracert guide.
I hope you enjoyed this article. If you have any questions feel free to ask. I will no doubt tidy this article up over time and make amendments.