What is Traceroute
Traceroute is conceptually similar to the ping command, so if you haven’t watched our ping video yet or are unfamiliar with it, I recommend checking it out first. Like ping, traceroute uses the ICMP protocol to establish communication with a remote host. It’s available on all major operating systems, as well as on networking equipment like switches, routers, and firewalls, making it widely supported.
What sets traceroute apart is that, instead of merely indicating whether a host can be reached or not, it provides a detailed list of every hop the data packets take to reach the destination. But what exactly is a “hop”?
A “hop” in the context of computer networks refers to a Layer 3 device, typically a router, that your data packets need to traverse on their journey to the destination. Knowing the hops can be incredibly valuable for understanding the path your traffic is taking.
Traceroute accomplishes this by utilizing a concept called “Time to Live” or TTL. TTL is a mechanism for limiting the lifespan of IP packets. It’s essentially a counter that decreases with each hop a data packet traverses on its way to the destination. This is the magic behind how traceroute works.
Let’s illustrate this with an example. Suppose we want to reach the Google DNS server at 8.8.8.8. When we initiate a traceroute, our computer sends an ICMP request to 8.8.8.8 but with a TTL value of 1. As soon as this request reaches the first router, the TTL value decreases to 0, causing the request to be dropped. The router then responds to our host with a message saying “Time to Live Exceeded.”
Now, here’s the clever part. Our computer takes note of the IP address of the router that just responded. It then sends the same request again but with a TTL value of 2. This time, the request reaches the first router, the TTL value decreases to 1, and then it passes to the next router. The process continues, decrementing the TTL value with each hop, until it either reaches the destination host or until traceroute reaches its maximum hop count, typically 30.
Now, let’s switch over to my computer, and I’ll show you how this works in action.
Before we proceed, I’ll start Wireshark, a tool that allows us to monitor all the traffic sent and received by our computer. We’ll use it to review the results after running the traceroute command.
Next, we’ll open a command prompt or PowerShell. On Windows, we use the command tracert followed by the IP address or domain we want to trace. For example, I’ll use Google’s DNS, which is 8.8.8.8.
Now, if you’re using Linux or macOS, the command is simply traceroute 8.8.8.8.
[Linux/macOS Command Entry]
After pressing Enter, you’ll start seeing the hops between your computer and the destination. Keep in mind that traceroute takes longer to run than the ping command, especially if it’s resolving IP addresses to hostnames. You can disable hostname resolution with the -d option, but it still takes some time.
[Traceroute Progress]
Now that the traceroute has finished, we can see the list of hops between my computer and Google’s DNS server. The first entry is my default gateway, followed by every public router in between. This provides us with the exact path the traffic takes, along with round-trip time information for each hop.
- Hop Number: Indicates the order of hops.
- Round Trip Times: Displays the time taken to reach each hop and return to our computer, helping measure latency.
- IP Address or Domain Name: Shows the IP address or domain name for each hop.
Now, let’s examine our packet capture to see what happened behind the scenes.
[Wireshark Analysis]
We’ve filtered the capture to show only ICMP traffic. The first message reveals our computer sending a ping request to Google’s DNS server (8.8.8.8) with a TTL value of 1. The next message is a reply from our default gateway indicating “Time to Live Exceeded.” Our computer notes this IP address as the first hop.
The process continues as our computer increments the TTL value and sends the request again. The second message shows a TTL value of 2, and the reply comes from a different router. Our computer notes this IP address as the second hop. This process repeats until it reaches the destination or the maximum hop count.
Now that we understand how traceroute works, let’s explore how we can use it for troubleshooting.
Using Traceroute for Troubleshooting
Imagine you’re trying to reach a remote host, and your ping request fails with “Request Timed Out.” There might be several hops between you and the destination. Traceroute can help pinpoint where the issue might be.
Instead of a ping, which only tells you that the host can’t be reached, you can use traceroute to narrow down the problem. For instance:
tracert 192.168.50.1Traceroute will attempt to collect all the hops between your computer and the remote host. If the responses stop after a certain hop, it suggests that the issue likely occurs on or after that hop. In this example, you’d start investigating from the last responding hop, such as 10.0.2.2, checking for routing problems, firewalls, or access lists.
Another scenario where traceroute proves valuable is when you’re experiencing latency issues. By using traceroute, you can identify which hop might be causing the problem. If one hop has a significantly larger round-trip time than the others, it could be a bottleneck.
For instance:
tracert www.serpros.comThis command lists all the hops between your computer and the serpros.com server, along with their round-trip times. If you notice a hop with exceptionally high latency, it could be the source of the problem.