Traceroute is an application that traces the path data takes from one computer to another. Basically a traceroute is a map that shows what stops or locations that data must pass through in order to go from one computer to another. To be an effective troubleshooting tool, the traceroute needs to be run from a computer experiencing the problem while the problem is occurring.
How Do I Run A Traceroute?
To Run a Traceroute in Windows
The command application (cmd.exe) is used to run a traceroute on Windows. Launching it is slightly different depending on your version of Windows:
- In Windows 7:
- click on the Start menu
- type “cmd” and press Enter to get a command prompt.
- In Windows 8:
- move your mouse to the bottom-left corner of the screen to bring up the Start icon.
- Right-click on Start and select Run.
- Then type “command” and press Enter to launch the application.
- Alternatively, you can type “command” into the Search field in the Charms menu after moving your mouse to the lower right corner of your desktop.
- In Windows 10, type “command” into the search menu and press Enter for a command prompt.
To run the traceroute, type:
tracert domainname.cominto 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.
To Run a Traceroute in Mac OS X
If you have a Mac, you can use the built-in network tools to run a traceroute.
- Launch Spotlight (with ⌘ + SPACE or by clicking on the magnifying glass in your menu) to search for and launch Network Utility.
- Select the Traceroute tab and enter the hostname or domain name.
- You also can perform a traceroute from the Terminal app. Simply enter:
traceroute domainname.com
To Run a Traceroute in Linux
At the command line, type:
traceroute domainname.comWhat Does the Traceroute Show You?
Let’s take a few sample traceroute outputs.
traceroute msu.eduThe output from that command shows a successful trace:
traceroute to msu.edu (35.8.10.134), 30 hops max, 40 byte packets 1 lw-dc2-hsrp-vlan132.rtr.liquidweb.com (67.43.8.129) 1.330 ms 1.420 ms 1.554 ms 2 lw-dc2-core4-po2.rtr.liquidweb.com (209.59.157.131) 1.092 ms 1.311 ms 1.451 ms 3 lw-dc1-core1-ge3-5.rtr.liquidweb.com (209.59.157.93) 1.596 ms 1.897 ms 2.209 ms 4 lw-dc1-border3-ge4.rtr.liquidweb.com (209.59.157.29) 1.657 ms 1.748 ms 1.894 ms 5 12.116.80.97 (12.116.80.97) 4.748 ms 5.382 ms 5.453 ms 6 cr81.dtrmi.ip.att.net (12.122.102.2) 12.893 ms 12.035 ms 11.043 ms 7 cr1.cgcil.ip.att.net (12.123.139.157) 11.509 ms 11.615 ms 11.769 ms 8 12.123.7.33 (12.123.7.33) 10.645 ms 10.711 ms 10.760 ms 9 12.90.96.6 (12.90.96.6) 9.473 ms 9.537 ms 9.605 ms 10 xe-0-0-0x14.msu6.mich.net (198.108.22.10) 15.047 ms 14.458 ms 14.487 ms 11 192.122.183.227 (192.122.183.227) 16.976 ms 20.066 ms 20.137 ms 12 cc-t1-ge1-23.net.msu.edu (35.9.101.209) 20.228 ms 20.432 ms 20.312 ms 13 www.msu.edu (35.8.10.134) 16.856 ms 17.071 ms 16.341 msIt looks like gibberish, right? But it’s actually fairly easy to understand. After the traceroute command, the program tells you what it’s doing:
- It has looked up the domain msu.edu
- It found msu.edu on the IP address of 35.8.10.134
- It now will attempt to find its way there using no more than 30 “hops” (stops along the way, or connections to routers), and it will send a packet of 40 bytes.
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 the Liquid Web 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.
Note: When troubleshooting network latency by analyzing the time of each hop, please be aware that distance from your geographic location to the server is a factor. Any single hop covering a large physical distance (such as when crossing an ocean) naturally will take longer to complete.
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 your
VPS 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:
traceroute liquidweb.comtraceroute to liquidweb.com (209.59.139.21), 30 hops max, 40 byte packets 1 lw-dc2-hsrp-vlan132.rtr.liquidweb.com (67.43.8.129) 0.947 ms 1.028 ms 1.101 ms 2 lw-dc2-core4-po2.rtr.liquidweb.com (209.59.157.131) 1.275 ms 1.308 ms 1.385 ms 3 lw-dc1-core1-ge3-5.rtr.liquidweb.com (209.59.157.93) 1.849 ms 1.921 ms 1.980 ms 4 lw-dc1-dist1-ge1.rtr.liquidweb.com (209.59.157.2) 92.082 ms 92.155 ms 92.347 ms 5 * * * 6 * * * 7 * * * 8 * * * [truncated]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:
- A network outage
- High amounts of traffic causing network congestion
- A firewall dropping traffic from your IP address
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.
Note: If you see these asterisks once you are inside Liquid Web’s network, there may be no need to worry. VPS customers frequently are not able to trace to their instance on the parent server.
If you believe you are experiencing network issues, having the output of traceroute handy and providing it, along with your public IPV4 address (which you can obtain from
http://ip.liquidweb.com) when contacting
Heroic Support® is an excellent way to help us begin investigating the issue as quickly as possible.
Fig.01: apachectl in action on macOS
