The command application (cmd.exe) is used to run a traceroute on Windows. Launching it is slightly different depending on your version of Windows:
To run the traceroute, type:
into the command prompt, where “domainname.com” is the name of the server to which you are having difficulty connecting.
The traceroute may take only a few seconds or a few minutes. Typically, the closer you are to the server, geographically, the more quickly the traceroute will complete.
If you have a Mac, you can use the built-in network tools to run a traceroute.
At the command line, type:
Let’s take a few sample traceroute outputs.
The output from that command shows a successful trace:
traceroute to msu.edu (188.8.131.52), 30 hops max, 40 byte packets
1 lw-dc2-hsrp-vlan132.rtr.server.com (184.108.40.206) 1.330 ms 1.420 ms 1.554 ms
2 lw-dc2-core4-po2.rtr.server.com (220.127.116.11) 1.092 ms 1.311 ms 1.451 ms
3 lw-dc1-core1-ge3-5.rtr.server.com (18.104.22.168) 1.596 ms 1.897 ms 2.209 ms
4 lw-dc1-border3-ge4.rtr.server.com (22.214.171.124) 1.657 ms 1.748 ms 1.894 ms
5 126.96.36.199 (188.8.131.52) 4.748 ms 5.382 ms 5.453 ms
6 cr81.dtrmi.ip.att.net (184.108.40.206) 12.893 ms 12.035 ms 11.043 ms
7 cr1.cgcil.ip.att.net (220.127.116.11) 11.509 ms 11.615 ms 11.769 ms
8 18.104.22.168 (22.214.171.124) 10.645 ms 10.711 ms 10.760 ms
9 126.96.36.199 (188.8.131.52) 9.473 ms 9.537 ms 9.605 ms
10 xe-0-0-0x14.msu6.mich.net (184.108.40.206) 15.047 ms 14.458 ms 14.487 ms
11 220.127.116.11 (18.104.22.168) 16.976 ms 20.066 ms 20.137 ms
12 cc-t1-ge1-23.net.msu.edu (22.214.171.124) 20.228 ms 20.432 ms 20.312 ms
13 www.msu.edu (126.96.36.199) 16.856 ms 17.071 ms 16.341 ms
It looks like gibberish, right? But it’s actually fairly easy to understand. After the traceroute command, the program tells you what it’s doing:
The numbers at the far left are the number of the hop, followed by the name and/or IP address of the router that hop is going through. You can see that this trace started within our server network, progressed through AT&T and found its way to msu.edu.
The set of three numbers on the right side of the lines indicate the amount of time, in milliseconds, it took for that hop to complete. Traceroute performs each hop three times.
In this example, there are no asterisks (which indicate a failure to respond within 5 seconds) and no inordinately long delays. If your traceroute to the server looks like this, you’re in good shape in terms of network connectivity.
Now, let’s look at a simulated traceroute that ends without reaching its destination:
server.com (188.8.131.52), 30 hops max, 40 byte packets
server.com (184.108.40.206) 0.947 ms 1.028 ms 1.101 ms
server.com (220.127.116.11) 1.275 ms 1.308 ms 1.385 ms
server.com (18.104.22.168) 1.849 ms 1.921 ms 1.980 ms
server.com (22.214.171.124) 92.082 ms 92.155 ms 92.347 ms
5 * * *
6 * * *
7 * * *
8 * * *
In this example, our trace failed because we deliberately ran it from our internal network (just to demonstrate what a failed trace would look like).
You can see that, beginning on the fifth hop, we have nothing but packet loss. The traceroute continued for the full 30 hops, each reporting * * * as it went.
If your traceroute to the server ends with asterisks like this one, and never displays an IP address or server name after the asterisks, that means that the connection was not able to be completed. This could be for a variety of reasons including:
However, if the traceroute picks back up following a series of asterisks and ultimately ends with a server name and IP address, it means that the connection was successful — regardless of how many hops exceeded the 5-second response time. This can be an indication of network issues along the routes used in those hops, but it does not indicate a network problem on either your end or the server’s.