How Traceroute is actually work ? Traceroute Lies? Why You Shouldn’t Trust It Blindly During Troubleshooting
You run a traceroute to figure out where your packet is getting stuck.
You expect it to be your secret weapon — a perfect path map.
But instead, it shows missing hops, timeouts, and inconsistent results.
And you think:
“Wait… is this thing lying to me?”
Yes. Sort of.
Traceroute is incredibly useful — but it has limits. And if you don’t understand how it works, it can mislead you.
So in this blog, let’s break down how traceroute really works, when it lies (or just omits the truth), and how you can interpret it the right way.
Let’s keep it simple.
Traceroute:
- Sends a series of packets to the destination
- Starts with TTL (Time To Live) = 1, then 2, 3, 4… up to 30
- Each router along the way decrements the TTL by 1
- When a router gets a packet with TTL = 0, it replies with an ICMP “Time Exceeded” message
That’s how you learn the IP (and sometimes hostname) of each hop.
It’s a clever hack — not a direct map.
Let’s walk through the most common situations where traceroute gives misleading results.
- Routers That Don’t Send ICMP Time Exceeded
Some routers silently drop TTL-expired packets.
That means traceroute gets no reply — and shows * * *.
Does that mean the router is down? NO.
It’s just not responding to traceroute — but it could still be forwarding traffic perfectly.
This is common on:
-
-
- Firewalls
- Internet backbone routers
- Security-hardened WAN devices
-
What You See:
1 192.168.1.1 1 ms
2 * * *
3 10.0.0.1 30 ms
You might assume hop 2 is dead. But it’s likely just not sending ICMP.
- Load-Balanced Paths Show Inconsistent Hops
Traceroute sends multiple packets per hop (usually 3). But in load-balanced environments, each packet may take a different path.
That leads to:
-
-
- Hops appearing out of order
- IPs from different networks on the same hop
- Different latency results per line
-
Traceroute doesn’t detect load balancing — it just shows what it gets back.
What It Looks Like:
5 10.1.1.1 25 ms
6 10.2.2.2 40 ms
6 10.1.2.1 38 ms
6 10.1.3.1 42 ms
Three replies for “hop 6” — because each probe took a different path.
- NAT or Firewall Masking
Traceroute hits a firewall or NAT device and gets back:
-
-
- A public IP instead of private
- A completely unrelated IP
- Or no reply at all
-
Why?
Because:
-
-
- The NAT device may respond with its outside IP
- A firewall might respond with its own interface IP
- ICMP replies could be spoofed or anonymized
-
Traceroute doesn’t expose private topology behind NAT or firewalls.
Scenario:
You run traceroute google.com and get:
6 203.0.113.1 50 ms
7 203.0.113.1 51 ms
8 203.0.113.1 49 ms
Looks like a loop, right?
Nope — that’s just a firewall replying on behalf of multiple hops.
- Traceroute Might Show Success Even When App Traffic Fails
Just like ping, traceroute uses ICMP by default (or UDP/TCP depending on system or flags). If ICMP is allowed, but TCP/UDP is blocked, traceroute may show a complete path…
…but your real application (e.g., HTTP, FTP, RDP) still won’t connect.
This creates false confidence that the path is healthy.
Use TCP Traceroute (if needed):
traceroute -T -p 80 google.com ← On Linux/macOS
tracert -d <ip> ← On Windows
- Devices That Don’t Reply at All (But Forward Traffic)
Yes, some routers — especially core backbone devices or MPLS routers — are configured to not reply to TTL-expired probes.
You’ll see:
5 * * *
6 * * *
7 8.8.8.8 45 ms
Looks scary, right?
But again — traceroute lies.
The traffic is passing through — but you’re not allowed to “see” the middle.
Ask yourself:
- Do multiple consecutive hops show * * * — then suddenly it resumes?
→ Likely ICMP block, not a failure. - Do hop IPs repeat or seem unrelated?
→ NAT/firewall interference. - Do some replies come from different ASNs or networks?
→ Load balancing in play. - Does traceroute complete but your app still fails?
→ Port/protocol-specific block (ICMP vs TCP/UDP).
Traceroute is great for:
- Checking approximate path to destination
- Verifying where latency jumps
- Spotting routing loops (same IP repeating)
Testing if TTL expiration behaves normally
Traceroute is NOT good for:
- Confirming application path
- Verifying port-specific or protocol-specific connectivity
- Seeing real behavior behind NAT/firewalls
Replacing proper monitoring/logging
|
Tool |
Purpose |
|
ping |
Basic reachability check |
|
tcping / hping3 |
Ping with specific port/protocol |
|
Wireshark |
Deep packet inspection |
|
MTR (My Traceroute) |
Real-time traceroute + loss tracking |
|
PathPing (Windows) |
Combines ping + traceroute with stats |
User Complaint:
“My app is slow when accessing the cloud server.”
You run traceroute and it shows:
8 * * *
9 * * *
10 35.186.238.101 90 ms
Looks like packet loss?
But wait — ping is clean. The app uses TCP port 443.
You run:
traceroute -T -p 443 35.186.238.101
Now you see different hops — the actual TCP path.
Lesson: Standard traceroute (ICMP) didn’t show you the real picture.
|
Misleading Symptom |
Real Cause |
|
* * * in hops |
ICMP blocked, not real packet loss |
|
Repeated IPs or mismatches |
NAT, firewall, or load balancer |
|
Traceroute works, app fails |
Protocol/port-specific block |
|
Random hop reordering |
Load balancing in effect |
Traceroute is a smart, creative tool — but it only shows you what it’s allowed to see.
And sometimes, that’s not the truth.
📞 Contact Us
Have a question, feedback, or want to work with us?
We’d love to hear from you!
📍 Address:
Maharashtra, India
📧 Email:
mynetworkingtrends@gmail.com
©2025, mynetworking-trends. All Rights Reserved