How does traffic from my computer actually get to a web server somewhere on the Internet?
What routers does it pass through along the way?
And perhaps more importantly when troubleshooting: where does a network problem appear to begin?
One of the oldest and most useful tools for answering these questions is traceroute.
Traceroute has been around for decades, but it remains one of those networking tools that every technician and network engineer should understand. The command is simple. Correctly interpreting the results takes a little more knowledge.
Let’s take a look.
What Does Traceroute Do?
When you communicate with a system somewhere on the Internet, your packets normally pass through a series of routers before reaching the destination.
Each router along that path represents a hop.
Traceroute attempts to identify those hops and measures the round-trip time (RTT) associated with probes sent toward each one.
On Windows, the command is called tracert:
tracert www.cellstream.comOn Linux and macOS, it is normally:
traceroute www.cellstream.comBe patient, it takes time to complete this discovery of the path to CellStream.com. Your output will differ from mine because you are asking your machine to trace the path to the cellstream.com server from your location. Let’s look at what my output says:
Again, your results will almost certainly be different from mine. That is part of what makes traceroute interesting.
The path depends on where you are, your ISP, the destination, routing policies, IPv4 versus IPv6, load balancing, and what is happening in the Internet at that particular moment.
Reading the Output
A typical traceroute might look something like this:
1 2 ms 1 ms 1 ms 192.168.1.1
2 10 ms 9 ms 11 ms 100.64.0.1
3 14 ms 13 ms 14 ms 203.0.113.1
4 22 ms 21 ms 23 ms 198.51.100.6
5 31 ms 30 ms 31 ms 192.0.2.25The number at the far left is the hop number.
The IP address on the right identifies the address from which the response was received. If DNS name resolution is enabled, you may also see a hostname.
The three time measurements are three separate round-trip-time measurements for probes sent toward that hop.
That last point is important.
These numbers are not minimum, average, and maximum times, and you should not add the latency values from all the hops together. Each measurement represents the round-trip time from your computer to that point in the path and back.
For example, if hop 8 reports 35 ms and the final destination reports 42 ms, your end-to-end RTT is roughly represented by the measurements to the destination—not 35 + 42 plus all the previous hops.
How Does Traceroute Actually Work?
This is where traceroute gets clever.
Every IPv4 packet contains an 8-bit field called Time To Live, or TTL. IPv6 has an equivalent field called the Hop Limit.
Despite the name, the IPv4 TTL is effectively a hop counter in normal operation.
Every router forwarding the packet decrements this value by one. If the value reaches zero, the router discards the packet.
Why?
Imagine a routing loop:
Router A → Router B → Router C → Router A → Router B...Without some mechanism to stop it, that packet could theoretically circulate forever.
TTL/Hop Limit prevents that.
Traceroute takes advantage of this behavior.
It sends its first probes with a TTL or Hop Limit of 1.
The first router receives the packet, decrements the value to zero, drops the packet, and normally sends an ICMP Time Exceeded message back to the sender.
Now we know the address of the first router.
Traceroute then sends another set of probes with the value set to 2.
The first router decrements it to 1 and forwards it. The second router decrements it to zero, drops it, and normally sends an ICMP Time Exceeded response.
Now we have discovered hop 2.
Then traceroute tries 3, 4, 5, and so on until the probes reach the destination or the configured maximum number of hops is reached.
It is a remarkably simple idea and I have tried to illustrate it here:
Not Every Traceroute Uses the Same Type of Probe
This is an important detail that is often overlooked.
Windows tracert normally uses ICMP Echo Request probes.
Traditional implementations of traceroute on Unix-like systems commonly use UDP probes directed toward high-numbered destination ports. Other implementations and command options can use ICMP or TCP instead.
Regardless of the probe type, the basic TTL/Hop Limit trick is the same.
This difference can also explain why traceroute results from two different operating systems—or two different traceroute tools—may not be identical.
Firewalls, routers, and security policies may treat ICMP, UDP, and TCP differently.
Why Do I See Asterisks?
You will frequently encounter something like this:
7 24 ms 25 ms 24 ms 203.0.113.9
8 * * *
9 31 ms 30 ms 32 ms 198.51.100.14Does that mean hop 8 is broken?
No.
It means traceroute did not receive a response to those probes within the allotted time.
The router might be configured not to generate the expected ICMP response. A firewall might filter it. ICMP responses might be rate-limited. The router’s control plane may simply give traceroute traffic a very low priority.
Meanwhile, the router can still be forwarding your actual traffic perfectly well.
This is one of the most important rules when reading traceroute:
An asterisk does not automatically indicate packet loss or a network failure.
If a router does not respond but every router after it does, packets obviously made it through that portion of the network.
Be Careful Interpreting Latency at Intermediate Hops
Here’s another common traceroute trap.
Suppose you see:
5 20 ms 19 ms 21 ms
6 145 ms 160 ms 151 ms
7 24 ms 23 ms 25 ms
8 27 ms 28 ms 27 msIt is tempting to declare:
“Hop 6 has a latency problem!”
Probably not.
If hop 6 were actually delaying the traffic it forwards by more than 100 ms, you would normally expect that delay to continue into subsequent hops.
Instead, hop 7 is back to approximately 24 ms.
That tells us something useful: hop 6 may simply be slow to respond to traceroute probes, while continuing to forward transit traffic normally.
Routers are built to route packets. Generating ICMP diagnostic responses is generally a control-plane function and may receive much lower priority.
This distinction between forwarding traffic and responding to traceroute is critical when troubleshooting.
What Does a Real Problem Look Like?
Traceroute becomes much more interesting when a change persists.
For example:
5 18 ms 19 ms 18 ms
6 21 ms 20 ms 21 ms
7 85 ms 88 ms 86 ms
8 87 ms 90 ms 88 ms
9 91 ms 89 ms 90 ms10 92 ms 93 ms 91 ms
Now we have something worth investigating.
Latency increased significantly around hop 7 and remained elevated at subsequent hops.
That still does not prove that router 7 itself caused the delay. The problematic link could be between hops 6 and 7, there could be congestion, the route could have entered a geographically longer path, or something else could have changed.
Traceroute gives us evidence. It does not automatically give us the root cause.
The Forward Path and Return Path May Be Different
Another important Internet routing concept is asymmetric routing.
Traceroute is showing us evidence about the path taken by our probes toward the destination and the responses returning to us.
The return path does not have to be the reverse of the forward path.
On the Internet, BGP routing policies and other routing decisions can cause traffic in each direction to follow completely different routes.
This means an RTT measurement represents both directions of the journey. You cannot automatically assign all of that latency to the forward hop shown on the screen.
Will Traceroute Always Show the Same Path?
No.
The Internet is dynamic.
Routing protocols continuously determine how traffic should be forwarded. ISPs can change routing policies. Links can fail. Traffic engineering can move traffic. BGP decisions can change. Equal-Cost Multi-Path (ECMP) routing can distribute traffic across multiple paths.
There is also an interesting complication with traditional traceroute.
Because traceroute sends multiple probes, differences between those packets can cause ECMP devices to hash them onto different paths. This can produce a traceroute that appears to show a path that no single flow actually followed.
Tools such as Paris Traceroute were developed specifically to deal with this problem.
So think of traceroute as a measurement of the path observed during that test—not a permanent map of the Internet.
What About MPLS Networks?
Traceroute becomes even more interesting when your packets encounter an MPLS network.
An MPLS provider network may expose some of its internal Label Switched Routers in traceroute, or those routers may be largely invisible. The result depends on the provider’s MPLS configuration, TTL propagation, tunneling behavior, and ICMP handling.
You may therefore see a path apparently jump across part of a provider’s network.
What you should not do is assume that a group of asterisks means, “I just entered an MPLS tunnel.”
It might.
But there are many other reasons why a router does not respond to traceroute.
Traceroute tells us what responded. It does not necessarily tell us everything that forwarded the packet.
IPv4 Versus IPv6
Traceroute works with IPv6 as well.
Instead of decrementing the IPv4 TTL, routers decrement the IPv6 Hop Limit.
The underlying discovery technique is essentially the same: deliberately send packets with progressively larger Hop Limit values and observe the ICMPv6 responses.
Depending on the operating system and installed tools, you may also encounter commands such as:
traceroute6 www.cellstream.comor options that explicitly force IPv4 or IPv6:
traceroute -4 www.cellstream.com
traceroute -6 www.cellstream.comThis can be extremely useful when troubleshooting a dual-stack network. Try both.
The IPv4 and IPv6 paths to the same destination can be quite different.
Watching Traceroute with Wireshark
Naturally, one of my favorite ways to understand traceroute is to capture it with Wireshark.
Start a capture and then run traceroute.
On Windows, where tracert normally uses ICMP Echo Requests, you can start with a simple display filter:
icmp || icmpv6Then examine the IP TTL or IPv6 Hop Limit.
You should see the probes begin with 1, followed by probes with 2, then 3, and so forth.
More importantly, look at the responses. Here is an example:
If you wanted to try this yourself, and want to use a more advanced filter, use the following display filter in Wireshark to display the traceroute traffic:
(icmp || icmpv6) && (icmp.type ==128 ||icmpv6.type == 128) || (icmp.type==129 || icmpv6.type ==129)For IPv4, the intermediate routers normally return ICMP Time Exceeded messages. With IPv6, look for the corresponding ICMPv6 Time Exceeded messages.
If you capture a traditional UDP-based traceroute from Linux or macOS, you will also need to examine the UDP probes themselves.
This is a great packet-analysis exercise because traceroute lets you watch an IP header field being deliberately manipulated to discover the Layer 3 path. In the example above, I am using my IPv6 Profile, and I encourage my users to use profiles to uplevel Wireshark’s GUI for what they are working on. You will find profiles here.
Traceroute Is Not a Performance Test
This distinction is important.
Traceroute can provide performance clues, but it is primarily a path-discovery and diagnostic tool.
A single traceroute is only a snapshot.
If you want to observe a route repeatedly and collect statistics over time, a tool such as MTR (My Traceroute) is much better suited to the job. MTR combines concepts from ping and traceroute and repeatedly measures the path.
Even then, be careful when interpreting apparent packet loss at intermediate routers. If a hop reports 40% loss but every subsequent hop—including the destination—shows no loss, the intermediate router probably isn’t dropping 40% of your forwarded traffic. It is more likely limiting or deprioritizing its diagnostic responses.
The destination results and persistent behavior across subsequent hops matter much more.
A Few Useful Experiments
If you want to become comfortable with traceroute, don’t just run it once.
Try tracing to several different destinations:
tracert www.cellstream.com
tracert 8.8.8.8
tracert 1.1.1.1Then try the same tests at different times of day. If you have IPv4 and IPv6 connectivity, compare the IPv4 and IPv6 paths. Try the same destination from your home network, office, a VPN connection, or a mobile hotspot.
Capture a few of those tests with Wireshark.
The differences are where traceroute starts becoming a real networking lesson instead of just another command.
What Traceroute Can—and Cannot—Tell You
I use traceroute as a clue generator.
It can tell me:
- How many visible Layer 3 hops appear between me and a destination.
- Which routers responded to the probes.
- Approximate RTT measurements to those responding devices.
- Where a persistent latency increase appears along a path.
- Whether the observed route has changed.
- Whether IPv4 and IPv6 appear to be taking different paths.
But traceroute cannot prove that every device shown is causing the behavior we observe, and it cannot show routers that do not generate visible responses.
That is the key to using traceroute correctly. Don’t look at one slow response or one row of asterisks and immediately declare that you found the problem.
Look at what happens after that hop.
Look for patterns.
Run the test again.
Compare paths.
Capture the packets.
Then use the evidence to decide what to investigate next.
Traceroute is simple enough that anyone can run it. Learning to interpret what it is actually telling you is where the networking skill begins.
Will the Traceroute path always be the same?
Great question – I get this one a lot.
It may not. The reason is that there are usually multiple paths in the Internet. Your traffic will 100% of the time follow the “least cost” path.
But there may be equal cost paths. You can read more on this in this post.
Here is another great question along this train of thought. Can I gather statistics to measure network performance with Traceroute?
The answer is yes, but frankly, you are better off using Linux. In Linux there is a great tool called My Traceroute. You can read more on this tool here and you can end up with some cool testing. Here is an example where MTR has run multiple cycles on the traceroute process monitoring the performance, in this case 37 times!
A more practical use case would be to discern which DNS is faster for you? Is 8.8.8.8 (Google) or 1.1.1.1 (Cloudfare) better for me?
Here is Google (11 hops – sum up the Avg column = 119 ms):
Here is Cloudfare (12 hops – sum up the Avg column = 134 ms):
Conclusion from these tests: for me, using the Google DNS is going to be faster.
I hope this has helped you learn yet another great networking tool called traceroute!
If you would like to help support the continued development of independent networking, broadband, Wi-Fi, VoIP, and packet analysis content, please consider joining our Patreon community where you will gain access to exclusive technical resources, downloadable labs and PCAPs, bonus course content, troubleshooting guides, and additional member-only material. Comments and technical discussion are always welcomed at our Patreon community or on our Discord server. You can also support our work by simply buying us a coffee — every contribution helps us continue creating practical, real-world network science education for professionals and enthusiasts alike.
The one thing I should have added was what happens when your traffic enters into an MPLS tunnel? In most public networks, even though your packets are in a Label Switched Path – or an MPLS Tunnel – passing from router to router along that path, those routers are a) not doing Layer 3 processing of the MPLS encapsulated packets, and b) they probably do not carry the TTL field from the original IP packet that enters the tunnel to the TTL of the MPLS label. So therefore, they will not trigger the ICMP error message and therefore we don’t actually get to see those hops.
I have played with this a lot over the years, and while it is not definitive, I have always suspected that the asterisk hops are likely indicators you have entered into an MPLS LSP. Again not 100% by any means. In fact, many times you silently enter into the LSP with no idea it even exists.