Throughout your days as an internet user, you’ve likely run into a snafu or two when it comes to problematic sites. Maybe they won’t load, maybe an error displays on the page, or maybe your browser simply won’t connect. That’s where traceroute comes in. If that’s a foreign term to you, not to worry — we’re here to cover how traceroute works and why it’s important.
You might not think about it, but being a piece of data is a very hard job.
You're always being told what to do, where to go, and you're never forgiven for being late. Data doesn’t fly as the crow does — instead, it takes an indirect and often confusing path to reach its goal. Think about something as simple as a request to check your Gmail address. Your computer tells your modem, “Hey, pull up Google.com.” Your modem then sends that request to your local grid, which directs the request to your Internet Service Provider’s (ISP’s) closest server bank. Then it bounces around via a series of nodes, routers, servers and the occasional satellite until it finds the server that hosts gmail.com.
It’s less like shooting an arrow at a still target and more like a crazed game of ping pong at the speed of light.
With so much going on and so many different entities involved, it’s natural for things to occasionally go awry. But with so many connections, how would you ever know where the problem resides? Fortunately, our computers’ built-in traceroute function helps diagnose potential network issues.
How traceroute works
Traceroute is a function that quite literally traces the route a piece of data takes to get from one place to another. It shows how quickly the data took to get there, and if a server or node drops the request, it shows where it was dropped.
Traceroute is extremely helpful for determining what issue needs fixing.
If you can’t access a certain website, running a trace to that site will tell you if the issue is with your modem, your ISP or with the site's host.
Steps for running traceroute
So how do you run traceroute? The steps are slightly different between Windows and Apple computers.
For a Windows computer, open up the program called Command Prompt and type the following words into the prompt: "tracert examplewebsite.com" (where examplewebsite.com is the site in which you are trying to reach) and then hit Enter.
For an Apple, open up the program called Terminal and type this into the prompt instead: "traceroute examplewbsite.com" before hitting Enter.
Note: Do NOT include the “www” at the beginning of the URL when running a trace.
After that, traceroute will make and track a connection with the destination site and spit out the play-by-play for your viewing pleasure.
Let's take a look at a sample traceroute now to Google.com:
Looks like a whole bunch of gibberish, right? The good news is, understanding how traceroute works is simpler than it looks. Let's break it down to find out. First, take note of the number of lines on the far left. This is the number of different "hops" the data had to take between servers to reach its destination. In this case, it took nine total "hops" to go from my desktop computer to Google's home page server.
The next thing to notice are the small numbers in the middle of the trace. This is the speed it took for the request to reach each node or server on its way to your destination in milliseconds (that's what the "ms" is). While that number can change significantly due to a variety of factors, anything less than 300 ms is typically considered to be OK. Numbers above 300 ms are considered latency and might cause issues with your data request.
After the milliseconds, we see the destination for each line. In this case, the first line shows my computer. The second line represents the data going from my computer to my cable modem, and it shows the IP of the modem (which I've redacted) and so on. You can tell that my ISP is Cox Communications because my request reaches their nameservers on lines four and five, then goes out to reach Google's server on line six.
But what happens when a trace doesn’t go according to plan? You might notice a reading that states, “Request timed out.” Just as it sounds, this isn’t a good thing:
You see those lines with nothing but asterisks where the milliseconds should be? That indicates that the node or server was not able to process the request.
Timeouts early in the trace can lead to timeouts later, so we want to identify the first timeout in the sequence for troubleshooting.
You can see in the above example that the last server to successfully hit my request was a Cox Communications server. While we can’t say for sure that the timed-out node belongs to Cox, they would be my first point of contact about my connection issue since the last known “hopw” was in their system.
Pro tip: Sometimes, you might encounter timeouts in a trace, but it continues the request to completion anyway. When that happens, you might be pinging a security firewall that blocks traceroute from seeing the IP of that node.
Check the speed of the requests before and after the timeout for latency to judge if it’s a firewall or a messed-up node.
And there you have it! We've just taken a trip through the world of fiber optic and wifi and emerged on the other end with some valuable insight. Data leads a harder life than it looks! If you’re experiencing issues connecting to the internet, run traceroute to see what you can do to help your data along.