How Traceroute Works: A Visual, Interactive Guide

You type traceroute google.com and get a list of IP addresses with millisecond timings. Each line represents a router between you and your destination. But what’s actually happening under the hood?

Traceroute exploits a clever trick with packet lifetimes to map the invisible infrastructure of the internet. Most explanations stop at “it sends packets with increasing TTL.” They don’t cover why traceroute sometimes gives you wrong answers, how modern variants fix those flaws, or how to actually read the output for real troubleshooting.

This guide walks through the complete mechanics with interactive diagrams you can step through. We’ll cover the TTL trick that makes it all work, decode real output line by line, and build a troubleshooting framework for actual network problems. Whether you’re debugging a slow API call or just curious about what sits between you and a server, you’ll leave with a working mental model.

TL;DR: Traceroute maps network paths by sending packets with incrementing TTL values. Each router decrements TTL; when it hits zero, the router returns an ICMP message revealing its identity. Classic traceroute has limitations with load balancers and firewalls, but modern variants like Paris traceroute and mtr address these gaps. The network monitoring market reaches $9.52 billion by 2034 (Fortune Business Insights).

What Is Traceroute and Why Does It Matter?

Traceroute is a diagnostic command that maps the exact path packets take from your machine to any destination on the internet. Van Jacobson wrote the original in 1987-88, based on a suggestion from Steve Deering (Wikipedia). The idea was simple: instead of just knowing whether a destination is reachable (that’s what ping does), engineers needed to know where things break along the route.

Why does that matter today? Because IT downtime costs an average of $14,056 per minute, and up to $23,750 per minute for large enterprises (BigPanda 2024). When your API calls are timing out, traceroute tells you whether the problem is your local network, your ISP, a transit provider, or the destination itself. That’s the difference between filing a ticket with the right provider and spending hours blaming the wrong one.

The global network monitoring market is valued at $4.13 billion in 2025 and projected to reach $9.52 billion by 2034 at a 9.5% CAGR (Fortune Business Insights). Traceroute is one of the foundational tools driving that market.

Think of it like mailing a letter with a rule: each post office stamps a “handled by” receipt and subtracts one from a counter. When the counter hits zero, that post office sends the receipt back to you. Send enough letters with different starting counters, and you’ve mapped every post office on the route.

Traceroute was written by Van Jacobson in 1987 and remains the primary tool for mapping network paths between hosts (Wikipedia). With IT downtime costing $14,056 per minute on average (BigPanda 2024), identifying the exact hop where packets are delayed or dropped directly reduces mean time to resolution.

How Does TTL Actually Work?

RFC 791 defined Time-to-Live as an 8-bit field in every IP packet header back in 1981, and it remains unchanged today (IETF). TTL caps how many routers a packet can pass through. Each router decrements it by one before forwarding. When TTL reaches zero, the router drops the packet and sends back an ICMP Time Exceeded message (Type 11, Code 0). That response is exactly how traceroute discovers each hop.

TTL exists to prevent routing loops. Without it, a misconfigured route could send packets bouncing between two routers forever, consuming bandwidth until the network collapses. The default TTL varies by operating system: Linux uses 64, Windows uses 128, and some network equipment uses 255.

The TTL Trick: How Traceroute Exploits It

Here’s traceroute’s core insight. Send a packet with TTL=1. The first router decrements it to zero and sends back an ICMP response. Now you know the first router’s IP address and how long the round trip took. Send another with TTL=2. The first router decrements to 1 and forwards it. The second router decrements to zero and responds. Repeat until you reach the destination.

The destination itself responds differently. On Linux, traceroute sends UDP packets to high-numbered ports (33434+). When the packet actually reaches the destination, it responds with ICMP Port Unreachable (since nothing is listening on that port). Windows tracert uses ICMP Echo Requests instead, so the destination responds with an ICMP Echo Reply. Either way, traceroute knows the trace is complete.

By default, traceroute sends three probes per TTL value and caps the trace at 30 hops. That means a typical trace sends 90 packets to map a route. Step through the interactive demo below to see this process in action.

$ traceroute 142.250.80.46
traceroute to 142.250.80.46, 30 hops max, 60 byte packets

RFC 791 (1981) defines TTL as an 8-bit integer decremented by each router that forwards a packet (IETF). When TTL reaches zero, the router returns an ICMP Time Exceeded message. Traceroute exploits this behavior by sending sequential probes with TTL values of 1, 2, 3, and so on, building a hop-by-hop map of the route to any destination.

What Do the Three Columns in Traceroute Output Mean?

Traceroute’s default configuration sends 3 probes per hop across a maximum of 30 hops, generating up to 90 packets for a single trace (traceroute(8) man page). The three round-trip time (RTT) measurements in each row help distinguish consistent latency from transient spikes. If two values are 12ms and one is 45ms, that’s a one-off fluctuation, not a persistent problem.

Here’s a real-world traceroute output. Hover over any element to see what it means (tap on mobile):

$ traceroute google.com
traceroute to google.com (142.250.80.46), 30 hops max
 1  gateway (192.168.1.1)  1.234 ms  1.120 ms  1.089 ms
 2  ae-1.r01.sttlwa01.us.bb.gin.ntt.net (129.250.2.11)  11.234 ms  12.891 ms  11.445 ms
 3  * * *
 4  108.170.245.65 (108.170.245.65)  18.432 ms  17.891 ms  18.112 ms
 5  lax17s55-in-f14.1e100.net (142.250.80.46)  24.112 ms  23.987 ms  24.234 ms

Each row tells a story. The hop number shows position in the route. The hostname (when available) often encodes geographic location. Look for airport codes like sttlwa (Seattle), lax (Los Angeles), or fra (Frankfurt). The three RTT values give you statistical confidence that a measurement is real rather than a fluke.

What about those asterisks on hop 3? They don’t mean the route is broken. Traffic clearly flows through that hop because hops 4 and 5 respond normally. The router is simply configured to silently drop traceroute probes. This is one of the most common misreadings in traceroute output.

Traceroute sends three probes per hop by default, capped at 30 hops maximum (traceroute(8) man page). Comparing the three RTT values reveals whether latency is consistent or intermittent. Asterisks indicate a non-responding hop, usually a deliberate firewall policy, and should only concern you if all subsequent hops also fail to respond.

How Do You Run Traceroute on Different Operating Systems?

Windows tracert sends ICMP Echo Requests by default, while Linux and macOS traceroute sends UDP datagrams to ports 33434 and above (Microsoft Learn). This protocol difference matters: firewalls that block UDP may allow ICMP, or vice versa. Running the same trace on Windows and Linux can produce genuinely different results for the same destination.

# Linux / macOS (UDP probes by default)
traceroute google.com

# Windows (ICMP probes by default)
tracert google.com

# Force ICMP on Linux (requires root)
sudo traceroute -I google.com

# Force TCP on Linux (bypasses many firewalls)
sudo traceroute -T -p 443 google.com

Common Flags Reference

The -n flag is worth memorizing. DNS lookups on every hop can add seconds to each line of output. When you’re troubleshooting an urgent issue, traceroute -n gives you raw IPs instantly. You can resolve hostnames later.

When standard traceroute gives you nothing but asterisks, try TCP mode. traceroute -T -p 443 sends TCP SYN packets to port 443 (HTTPS). Most firewalls allow this because blocking it would break web traffic. It’s the single most useful flag for getting through restrictive networks.

Windows tracert defaults to ICMP Echo Requests while Linux traceroute defaults to UDP on ports 33434+ (Microsoft Learn). When standard UDP or ICMP traceroute returns only asterisks, TCP traceroute to port 443 bypasses most firewalls because blocking it would break HTTPS traffic.

Why Does Traceroute Sometimes Lie to You?

Network operators routinely rate-limit ICMP responses to as low as 1 packet per second on high-throughput routers (APNIC). That means a single hop showing high latency doesn’t necessarily indicate a problem. Routers deprioritize ICMP generation compared to forwarding traffic, so the response time reflects control plane load, not forwarding performance. If hop 5 shows 150ms but hop 6 shows 25ms, hop 5 isn’t slow. It’s just busy generating ICMP responses.

This is one of the most common misinterpretations, and it trips up experienced engineers too. Here are the scenarios where traceroute output doesn’t mean what you think it means.

Load Balancers Create False Paths

Classic traceroute varies the UDP destination port for each probe. Load balancers (ECMP, Equal-Cost Multi-Path) use that port as part of their flow hash. Different probes for the same TTL value can take different physical paths. The result? Traceroute output shows hops that appear to zigzag between routers that aren’t actually on the same path. You’re seeing a composite of multiple routes stitched together, not a single real path.

This is exactly why Paris traceroute was created in 2007 to keep the flow identifier constant so all probes follow the same load-balanced path (Paris Traceroute Project).

Firewalls and ICMP Rate Limiting

Some routers block ICMP entirely. Others rate-limit it to prevent ICMP-based attacks. Both produce asterisks in your output. A row of * * * between two healthy hops means “this router won’t talk to me,” not “this router is down.”

From experience: In cloud environments, we routinely see 2-3 silent hops in every trace. AWS and GCP’s internal routers almost never respond to traceroute probes. Treat silent hops as normal in cloud-heavy routes unless every hop after them also fails.

Test Your Reading Skills

Can you tell real problems from false alarms? Try these scenarios:

 1  192.168.1.1      2.1 ms   1.8 ms   2.3 ms
 2  10.0.0.1        12.4 ms  11.8 ms  12.1 ms
 3  *                *        *
 4  72.14.215.85    19.2 ms  18.7 ms  19.5 ms
 5  142.250.80.46   24.1 ms  23.8 ms  24.3 ms

 1  192.168.1.1      1.2 ms   1.1 ms   1.3 ms
 2  10.0.0.1        11.4 ms  12.1 ms  11.8 ms
 3  68.85.105.201  148.3 ms 147.9 ms 149.1 ms
 4  72.14.215.85    19.5 ms  18.8 ms  19.2 ms
 5  142.250.80.46   24.3 ms  23.7 ms  24.1 ms

 1  192.168.1.1      1.2 ms   1.1 ms   1.3 ms
 2  10.0.0.1        11.4 ms  12.1 ms  11.8 ms
 3  68.85.105.201   89.3 ms  92.1 ms  88.7 ms
 4  72.14.215.85    94.5 ms  91.8 ms  95.2 ms
 5  142.250.80.46  102.3 ms  98.7 ms 101.1 ms

MITRE classifies traceroute route enumeration as attack pattern CAPEC-293, related to CWE-200 (Exposure of Sensitive Information) (MITRE CAPEC). This is why many organizations block ICMP and UDP traceroute probes at their network perimeter. The same tool that helps you diagnose problems also reveals internal network topology to potential attackers.

What Are Paris Traceroute, mtr, and Other Modern Variants?

Paris traceroute was introduced in 2007 at an IEEE workshop to fix classic traceroute’s biggest flaw: inaccurate paths through load-balanced networks (Kentik). By keeping the flow identifier (source port, destination port, protocol) constant across all probes for a given TTL, Paris traceroute ensures every probe follows the same path through ECMP load balancers.

Why does this matter? Because nearly every ISP and cloud provider uses ECMP. Classic traceroute can show you hops from path A mixed with hops from path B, creating a route that doesn’t actually exist. Paris traceroute shows the real path your traffic takes.

mtr: Traceroute Meets Ping

mtr (My Traceroute) combines traceroute with continuous ping in a single real-time display. Instead of three probes per hop, mtr sends probes continuously and shows running statistics: packet loss percentage, average latency, jitter, best and worst times. It’s the tool you reach for when a problem is intermittent. A standard traceroute might catch a good moment and show everything is fine. mtr running for 60 seconds will catch the drops that happen every 10 seconds.

TCP Traceroute: The Firewall Bypass

tcptraceroute (or traceroute -T on Linux) sends TCP SYN packets instead of UDP or ICMP. Since most firewalls must allow TCP to ports like 80 and 443 for web traffic, TCP traceroute often gets through when classic traceroute shows nothing but asterisks.

Trippy: The Modern All-in-One

Trippy is a Rust-based network diagnostic tool that combines traceroute, ping, and live visualization in a single TUI. It supports ICMP, UDP, and TCP probes, handles load-balanced paths (Dublin traceroute-style flow detection), and runs continuously like mtr. Where mtr gives you a table of statistics, Trippy gives you a real-time visual map with per-hop latency charts, AS number lookups, and GeoIP data. It runs on Linux, macOS, and Windows.

Which Variant Should You Use?

It depends on what you’re diagnosing. Quick reference:

Paris traceroute was introduced at an IEEE workshop in 2007 to fix false path detection through ECMP load balancers (Paris Traceroute Project). By maintaining a constant flow identifier across all probes, it ensures each TTL value’s probes follow the same physical path, producing accurate route maps through modern load-balanced networks.

If you’re running containerized workloads, network path visibility becomes even more critical. See our guide on building highly available systems with Kubernetes for how orchestration handles service routing.

How Do You Troubleshoot Real Network Problems with Traceroute?

With IT downtime costing up to $23,750 per minute at large enterprises (BigPanda 2024), fast and accurate network diagnosis is worth real money. Effective traceroute troubleshooting follows a pattern: run the trace, find where latency or loss begins, determine whether it’s real or an artifact, then decide who to contact. Traceroute shows where a problem occurs, not what the problem is. You need additional context for root cause.

Step-by-Step Troubleshooting

1. Run a baseline trace to the destination: traceroute -n <host>. Use -n to skip DNS for speed.
2. Find the transition point: Look for the first hop where latency increases and stays elevated through all subsequent hops.
3. Rule out ICMP artifacts: If latency spikes at one hop but drops back on the next, it’s ICMP rate limiting. Ignore it.
4. Run mtr for confirmation: mtr -n -c 100 <host> sends 100 probes and shows packet loss per hop. A single traceroute can catch a good moment. mtr running for 60 seconds catches the drops.
5. Compare paths: Run traces from different source networks if possible. If the problem appears only from one source, it’s in the early hops (your network or ISP).

Decision Tree

Here’s a quick reference for the most common output patterns:

• All asterisks from hop 1 → Your firewall blocks outbound traceroute probes. Try sudo traceroute -T -p 443 or sudo traceroute -I.
• Asterisks at one hop, trace continues → Firewall on that router. Not a problem. Ignore it.
• Latency spike at hop N, recovers at N+1 → ICMP rate limiting. Not real congestion. Ignore it.
• Latency jumps at hop N, stays high through destination → Real congestion at or before hop N. Identify the ISP responsible for that hop and contact them.
• Hops loop (same IPs repeating) → Routing loop. Usually transient. If it persists beyond 5 minutes, the upstream ISP has a misconfiguration.
• Trace completes normally, but application is slow → The problem isn’t routing. Check DNS resolution time, TLS handshake, or server-side processing. Use curl -w for timing breakdown.

With enterprise downtime reaching $23,750 per minute (BigPanda 2024), quickly distinguishing real network problems from ICMP artifacts is critical. The key rule: a latency spike matters only if all subsequent hops also show elevated latency. A single high hop followed by normal hops indicates ICMP rate limiting, not congestion.

How Does Traceroute Work in Cloud Environments?

The global cloud infrastructure market exceeded $330 billion in 2024 (Synergy Research Group), meaning most production traffic now traverses cloud networks where traceroute behaves differently. In AWS VPCs, traceroute typically shows only 1-2 hops regardless of the actual physical path, because the underlying software-defined network (SDN) fabric doesn’t decrement TTL the way traditional routers do. GCP and Azure behave similarly. Their virtual network overlays abstract away the physical topology.

This isn’t a limitation you can work around. It’s by design. Cloud providers don’t want you (or attackers) mapping their internal infrastructure. What you’ll see in a cloud trace:

• Within a VPC: 1-2 hops, even if traffic crosses multiple physical switches
• Between VPCs/regions: You’ll see the entry/exit points of each VPC but nothing in between
• Through a CDN: Traceroute terminates at the nearest PoP (Point of Presence), not the origin server
• In Kubernetes: Pod-to-pod traces may show overlay network hops from CNI plugins like Calico or Cilium, depending on the networking mode

For cloud-native applications, traditional traceroute gives you limited visibility into the cloud provider’s network. Tools like AWS VPC Reachability Analyzer, GCP Network Intelligence Center, or third-party solutions (ThousandEyes, Kentik) provide the internal visibility that traceroute can’t.

Where traceroute still shines in cloud environments is the path between your users and the cloud edge. If customers in Europe report latency to your US-East deployment, traceroute from their location reveals whether traffic is taking an efficient path to the nearest PoP or being routed through an extra continent. The problem is rarely inside the cloud. It’s almost always in the transit between user and cloud edge.

A-Line Cloud runs on Talos Linux, an immutable OS with no SSH access by design. Traditional debugging tools like traceroute aren’t available on the nodes themselves, which makes understanding network fundamentals even more important when diagnosing connectivity between your services and the outside world.

Cloud infrastructure spending exceeded $330 billion in 2024 (Synergy Research Group), yet traceroute provides minimal visibility into cloud provider networks by design. For diagnosing latency to cloud-hosted services, traceroute remains most valuable for the path between end users and the cloud edge, not within the cloud itself.

Running Kubernetes in production adds another layer of networking complexity. Container networking (CNI plugins, service meshes) sits on top of the physical network that traceroute maps.

Frequently Asked Questions

What is the difference between ping and traceroute?

Ping tests whether a host is reachable and measures round-trip time to that single destination. Traceroute maps every intermediate hop along the route, showing where delays occur. Use ping to confirm a host is up. Use traceroute when ping shows high latency and you need to identify which network segment is causing it. mtr combines both into a single continuous display.

What do asterisks (*) mean in traceroute output?

Asterisks mean a hop didn’t respond within the timeout period. The most common cause is a firewall configured to drop traceroute probes silently. If hops before and after the asterisks show normal latency, traffic is flowing through that hop, but it won’t identify itself. Asterisks only indicate a real problem when all subsequent hops also show asterisks or packet loss.

Are tracert and traceroute the same thing?

They serve the same purpose but differ in default protocol. Windows tracert sends ICMP Echo Requests. Linux and macOS traceroute sends UDP packets to ports 33434 and above. This protocol difference produces different results when firewalls treat ICMP and UDP differently. Both tools accept flags to override the default protocol.

What is mtr and how is it different from traceroute?

mtr (My Traceroute) combines traceroute with continuous ping, updating results in real time. While standard traceroute sends three probes per hop and exits, mtr runs indefinitely, reporting packet loss percentages, average latency, and jitter per hop. It’s better for diagnosing intermittent issues that a single traceroute snapshot might miss. Install it with apt install mtr on Ubuntu or brew install mtr on macOS.

Can traceroute be used for network reconnaissance?

Yes. MITRE classifies traceroute route enumeration as attack pattern CAPEC-293, related to CWE-200 (Exposure of Sensitive Information) (MITRE CAPEC). Attackers use traceroute during the reconnaissance phase to map internal network topology, identify firewall boundaries, and discover routing paths. This is why security-conscious organizations block ICMP Time Exceeded responses and UDP traceroute probes at their perimeter firewalls.

Conclusion

Traceroute maps network paths by exploiting a simple mechanism: TTL decrement and ICMP feedback. Every router between you and a destination becomes visible, one hop at a time. The tool is 39 years old and still indispensable.

The key takeaways:

• TTL decrement is the core mechanism. Each router decrements TTL by one and responds when it hits zero.
• Three probes per hop give you statistical confidence, not just a single measurement.
• Asterisks usually aren’t problems. They’re firewalls being deliberately silent.
• Latency spikes only matter if downstream hops also spike. Isolated spikes are ICMP rate limiting.
• Modern variants exist for a reason. Use Paris traceroute for load-balanced paths, mtr for intermittent issues, TCP traceroute for firewall-heavy networks.

Try the interactive TTL demo above with the step controls. Then open a terminal and run mtr google.com to see every concept from this guide in a live, continuously updating display. There’s no better way to internalize how traceroute works than watching it happen in real time.

A-Line Cloud runs on Talos Linux, an immutable OS with no SSH access by design. Traditional debugging tools like traceroute aren’t available on the nodes themselves, which makes understanding network fundamentals even more important when diagnosing connectivity between your services and the outside world. Join the waitlist to get early access.