I still remember the first time a user complained that “the internet was slow.” Fresh out of college, armed with my shiny new CS degree, I confidently ran ping and saw… perfectly fine response times. The problem? I was only checking if the destination was reachable, not where along the path things were breaking down. That’s when my mentor introduced me to traceroute, and honestly, it changed how I troubleshoot network issues forever.
If you’ve ever wondered why your connection is sluggish or where packets are getting lost between your server and the rest of the internet, traceroute is the diagnostic tool you need in your arsenal. Let me show you how it works and how I use it daily.
What is Traceroute and Why Should You Care?
Traceroute is a network diagnostic utility that maps the path your data takes from your computer to any destination on the internet. Think of it like tracking a package through the postal system—instead of just knowing it arrived (or didn’t), you can see every sorting facility it passed through and how long it spent at each stop.
Every time you connect to a website or server, your data doesn’t travel directly there. It hops through multiple routers—sometimes dozens of them—across different networks and ISPs. When something goes wrong, traceroute tells you exactly where the problem is happening.
Here’s what makes traceroute invaluable for troubleshooting:
- Identifies the specific router or network segment causing latency
- Reveals packet loss at individual hops along the route
- Shows you whether the problem is on your end, your ISP’s network, or the destination
- Helps diagnose routing issues and network misconfigurations
I use traceroute alongside ping for basic connectivity checks, but traceroute gives me the granular detail I need when ping alone isn’t enough.
How Traceroute Actually Works (The Technical Side)
Understanding how traceroute works under the hood makes you a better troubleshooter. The mechanism is clever: it exploits the Time-To-Live (TTL) field in IP packets.
Every IP packet has a TTL value—basically a countdown timer that prevents packets from circulating forever if routing loops occur. Each router that handles your packet decrements the TTL by one. When TTL hits zero, the router drops the packet and sends back an ICMP Time Exceeded message to the source.
Traceroute leverages this behavior brilliantly:
- First probe: Sends packets with TTL=1. The first router decrements it to 0, drops the packet, and replies with “Time Exceeded.” Now we know the first hop.
- Second probe: Sends packets with TTL=2. The first router forwards it, the second router drops it and replies. Now we know the second hop.
- Incremental discovery: This continues, incrementing TTL each round, until packets reach the destination.
For each hop, traceroute sends three probe packets, which is why you see three timing measurements per line in the output. This redundancy helps identify intermittent issues.
UDP vs ICMP: Protocol Differences
Here’s something that trips up a lot of people: traceroute on Linux uses UDP packets by default, while Windows’ tracert uses ICMP Echo Request packets (the same protocol ping uses).
Why does this matter? Some firewalls and routers treat UDP and ICMP differently. I’ve seen situations where traceroute fails but traceroute -I (forcing ICMP mode) works perfectly—or vice versa. When you’re troubleshooting, knowing you can switch protocols with the -I flag is a lifesaver.
Installing Traceroute on Linux
Most Linux distributions come with traceroute preinstalled, but if you get a “command not found” error, installation is straightforward.
On Debian/Ubuntu:
sudo apt update sudo apt install traceroute
On RHEL/CentOS/Fedora:
sudo dnf install traceroute
On Arch Linux:
sudo pacman -S traceroute
Verify the installation by checking the version:
traceroute --version
Basic Traceroute Usage with Examples
The simplest way to use traceroute is just pointing it at a destination—either a domain name or IP address:
traceroute google.com
You’ll see output that looks something like this:
traceroute to google.com (142.250.185.46), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 1.234 ms 1.189 ms 1.156 ms 2 10.0.0.1 (10.0.0.1) 8.567 ms 8.534 ms 8.501 ms 3 96.120.88.125 (96.120.88.125) 12.234 ms 12.201 ms 12.168 ms 4 68.85.221.73 (68.85.221.73) 15.432 ms 15.399 ms 15.366 ms
Understanding the Output
Let me break down what you’re seeing:
- First column: The hop number (1, 2, 3…)
- Second column: The hostname and IP address of the router at that hop
- Three timing values: Round-trip time in milliseconds for each of the three probe packets
When I’m analyzing traceroute output, I look for several red flags. Consistently high latency values at a specific hop indicate a bottleneck. If you see asterisks (* * *) instead of timing values, it means that router didn’t respond—which could indicate packet loss, firewall rules blocking ICMP/UDP, or a router configured not to respond to traceroute probes.
According to Catchpoint’s network admin guide, the key is looking for patterns. A single hop with packet loss isn’t necessarily a problem if subsequent hops are fine—many routers deprioritize ICMP responses. But if you see packet loss that continues through subsequent hops, that’s your smoking gun.
Useful Traceroute Options and Flags
The default traceroute behavior works fine for basic troubleshooting, but I’ve learned to use specific flags for different scenarios.
-I (Use ICMP Instead of UDP)
traceroute -I google.com
Forces traceroute to use ICMP Echo Request packets instead of UDP. This is helpful when UDP packets are being filtered by firewalls. I use this flag frequently when troubleshooting connections through corporate networks or restrictive firewall configurations.
-n (No DNS Resolution)
traceroute -n 8.8.8.8
Skips DNS lookups for each hop, showing only IP addresses. This makes traceroute run much faster and is my go-to when I need quick results or when DNS itself is part of the problem I’m diagnosing.
-m (Set Maximum Hops)
traceroute -m 15 example.com
Sets the maximum number of hops to probe. The default is 30, but sometimes I set it lower (like 15) when I know the destination should be close, or higher when troubleshooting international routes that might legitimately have more hops.
-q (Set Number of Queries per Hop)
traceroute -q 1 example.com
Changes how many probe packets are sent per hop. The default is 3, but using -q 1 speeds things up when you’re in a hurry. Conversely, -q 5 gives you more data points for detecting intermittent issues.
-w (Set Timeout)
traceroute -w 2 example.com
Sets the timeout (in seconds) to wait for a response. The default is 5 seconds, which can feel like forever when you’re staring at the terminal. I often use -w 2 to speed things up, though be aware you might miss slow-responding routers.
Real-World Troubleshooting Scenarios
Let me share a few situations where traceroute has saved my bacon.
Scenario 1: Diagnosing ISP Issues
A client complained their site was unreachable from certain locations. Ping showed packet loss, but where was it happening? I ran traceroute and immediately saw the problem: massive latency spikes at hop 4, which resolved to their ISP’s router. The three subsequent hops showed continued high latency.
This gave me concrete evidence to take to the ISP. Instead of “your internet is slow,” I could say “your router at 96.120.88.125 is showing 200ms+ latency and 40% packet loss.” That gets fixed a lot faster.
Scenario 2: Identifying Routing Loops
I once saw a traceroute output where the same router appeared multiple times in sequence—packets were literally going in circles. This routing misconfiguration was causing intermittent connectivity failures. Without traceroute, I’d have been chasing ghosts.
Scenario 3: Geolocation and CDN Debugging
When setting up a CDN, I used traceroute to verify that requests from different geographic locations were actually hitting the intended edge servers. Seeing the physical path your packets take through different cities and providers is genuinely fascinating—and incredibly useful for optimizing content delivery.
Traceroute vs Tracepath vs MTR: Which Tool When?
Traceroute isn’t the only path-tracing tool available, and understanding when to use alternatives makes you more effective.
Tracepath: No Root Required
Tracepath is similar to traceroute but doesn’t require root privileges on most systems. It also detects Maximum Transmission Unit (MTU) sizes along the path, which is helpful for diagnosing packet fragmentation issues.
The trade-off? It’s less feature-rich and can only use UDP. When I’m on a system where I don’t have sudo access, tracepath is my fallback. According to TechTarget’s comparison, tracepath is sufficient for most everyday troubleshooting scenarios.
MTR: Continuous Monitoring
MTR (My Traceroute) combines traceroute and ping into a single, continuously updating display. Instead of a one-time snapshot, MTR shows you real-time statistics: packet loss percentages, average latency, and worst-case latency for each hop.
I use MTR when I’m dealing with intermittent network problems—the kind that come and go and are maddeningly hard to pin down. Running MTR for several minutes gives you statistical data that a single traceroute run would miss entirely.
mtr google.com
The interactive display updates every second, building a comprehensive picture of network performance over time. It’s become my preferred tool for serious network diagnostics.
Common Traceroute Issues and How to Fix Them
Problem: Asterisks Instead of Response Times
When you see * * * in the output, it doesn’t always mean something’s wrong. Many routers are configured to deprioritize or completely ignore traceroute probes as a security measure or to conserve resources.
Solution: Look at the hops after the asterisks. If subsequent routers respond normally, the non-responsive router is likely just filtering ICMP/UDP. If everything after shows asterisks, you’ve found where connectivity is actually failing.
Problem: “Operation Not Permitted” Error
If you get a permission error, it’s because the default UDP method requires elevated privileges on some systems.
Solution: Either run with sudo (sudo traceroute example.com) or use the ICMP method which sometimes requires fewer privileges: traceroute -I example.com.
Problem: Traceroute Takes Forever
Default settings wait 5 seconds per probe and attempt 3 probes per hop across 30 hops. That’s potentially a long time.
Solution: Use traceroute -n -w 2 -q 1 -m 15 example.com to skip DNS lookups, reduce timeout to 2 seconds, use 1 query per hop, and limit maximum hops to 15. This runs much faster.
Integrating Traceroute Into Your Workflow
I don’t run traceroute in isolation. It’s part of a broader troubleshooting toolkit.
My typical network diagnostic workflow looks like this:
- Start with ping: Use ping to verify basic connectivity and measure round-trip time
- Check local network: Verify network interfaces are up and configured correctly
- Run traceroute: Identify where along the path issues occur
- Check logs: Review system logs with journalctl for related errors
- Investigate services: Check if relevant services are running properly
For ongoing monitoring, I sometimes incorporate traceroute into scripts that run periodically and alert me when specific thresholds are exceeded. Pairing this with MTR for continuous monitoring gives you a robust early warning system for network degradation.
Advanced Tips from a Decade of Troubleshooting
Here are a few things I’ve learned over 10+ years of running traceroute in production environments:
Save Traceroute Output for Comparison
When things are working normally, save a traceroute to your critical destinations:
traceroute -n important-server.com > baseline-traceroute.txt
When problems occur, you can compare the current output against your baseline to spot routing changes or new problem hops immediately.
Use Multiple Vantage Points
Running traceroute from just your location tells you about your path, but not necessarily what users in other regions experience. I use online traceroute services or spin up cloud instances in different geographic regions to get multiple perspectives on network paths.
Understand Rate Limiting
Some routers implement rate limiting on ICMP responses. According to research from Obkio’s network monitoring guide, if you see packet loss at 1 packet per second but not at higher rates, you’re likely hitting rate-limiting rules rather than genuine network issues. This is where adjusting the query rate with -q helps differentiate between rate limiting and actual problems.
Combine with Other Tools
Traceroute shows you the path, but tools like tcpdump can show you what’s actually in the packets. When I’m debugging complex issues, I’ll run tcpdump on both ends while running traceroute to see exactly what’s happening at the packet level.
When Traceroute Won’t Help
It’s worth mentioning that traceroute isn’t a silver bullet. It won’t help you with:
- Application-layer issues: If the problem is with how an application processes data, traceroute won’t reveal it
- Encrypted traffic analysis: Traceroute sees the path but not the content—you need other tools for analyzing encrypted connections
- Firewall-blocked environments: Some networks block all ICMP and high-port UDP, making traceroute completely useless
In these cases, you’ll need application-specific logging, protocol analyzers, or alternative diagnostic approaches.
Final Thoughts: Make Traceroute Part of Your Muscle Memory
When I started out, I’d fumble through man pages every time I needed to troubleshoot network issues. Now, running traceroute -n -I is as automatic as checking my coffee level before diving into a complex problem (which is to say: absolutely essential).
The beauty of traceroute is its simplicity combined with its power. You’re not just seeing “the internet is broken”—you’re seeing exactly where, and often why. That visibility transforms vague complaints into concrete, actionable problems you can actually fix.
Start using it regularly, even when things are working fine. Build up that baseline knowledge of what normal looks like for your infrastructure. When 3 AM rolls around and someone’s paging you about network issues, you’ll be glad you did.
And remember: the path your packets take is rarely a straight line. Understanding that journey—hop by hop, router by router—is what separates reactive troubleshooting from proactive system administration.
