Why does my traceroute hit '* * *' for some hops?

The router exists but didn't reply to the probe. Common reasons: ICMP rate limiting, firewall policy that drops TTL-exceeded replies, or operator decision to make the router invisible. The packets are still passing through; you just can't see those hops.

Does traceroute work through a VPN?

Yes, but the trace starts from the VPN exit, not from your real location. The first few hops you'd normally see (your home router, your ISP) are replaced by the single hop into the VPN tunnel. The trace becomes a view of the VPN provider's network and its onward path.

Why does traceroute show different paths each time I run it?

Many large networks load-balance traffic across multiple equal-cost paths, and the load-balancing key includes packet fields. Different probes hash to different paths and you see the union. Tools like Paris-traceroute keep the load-balancing key constant to produce stable output.

What does a sudden spike in latency at one hop mean?

Could be a congested link, a slow control plane on that specific router (most likely), or asymmetric return path. Look at the subsequent hops — if their RTT is similar, the spike is real congestion; if their RTT drops back, the spike was the router's control plane being slow to reply.

Is there a tool that combines traceroute and continuous ping?

MTR (mtr on Unix, WinMTR on Windows). It pings every hop in a loop and shows running statistics — average RTT, packet loss percentage, standard deviation. Far more useful than vanilla traceroute for intermittent problems.

Traceroute Explained: How to See Every Hop a Packet Takes

Traceroute is the diagnostic tool that exposes the Internet's hidden geography. Type one command, get back a list of every router your packets traverse on the way to a destination. It works because of an obscure feature of the IP protocol — the Time To Live field — and it's been finding network problems for thirty years.

Traceroute reveals the sequence of hops between you and a destination. Each line in the output is one router; the round-trip time tells you the latency to that router. When something on the Internet is slow or broken, traceroute is usually the first tool out of the box.

How it works: the TTL trick

Every IP packet has a Time To Live (TTL) field, originally meant to prevent packets from circulating forever in routing loops. Each router decrements the TTL by one. When TTL reaches zero, the router drops the packet and sends back an ICMP "Time Exceeded" message to the source.

Traceroute weaponizes this:

Send a packet to the destination with TTL=1. The first router decrements it to 0, drops it, replies with "Time Exceeded" — revealing itself as hop 1.
Send TTL=2. The first router decrements to 1 and forwards; the second router decrements to 0, drops, replies — revealing hop 2.
Continue incrementing until you reach the destination, which replies with something else (a port-unreachable or an actual application response).

The destination's reply is how traceroute knows to stop. Three probes per hop is the default, which is why you see three RTT measurements per line.

The three probe types

Different traceroute implementations send different kinds of probes:

UDP traceroute (classic Unix): sends UDP packets to high port numbers. The destination replies with "port unreachable." Default on Linux/macOS.
ICMP traceroute (Windows tracert): sends ICMP Echo Request packets. The destination replies with Echo Reply. Better behaved through some firewalls.
TCP traceroute: sends TCP SYN to a specific port (commonly 80 or 443). Useful when a destination drops UDP and ICMP but accepts TCP on a known port.

The right tool depends on what the path's firewalls drop. tcptraceroute often succeeds where traceroute fails.

Reading the output

A typical line:

 5  ae1.cr1.fra4.de.example.net (172.16.50.1)  18.234 ms  18.012 ms  17.998 ms

The hop number, the router's name and IP, then three RTT measurements. Asterisks * * * mean the router didn't respond — either it dropped the probe, rate-limited ICMP replies, or has been configured not to identify itself. Asterisks are normal and don't necessarily mean a problem; many backbone routers deliberately don't respond to traceroute.

What the hops tell you

The DNS names of routers are loaded with meaning. ae1.cr1.fra4.de tells you: aggregation Ethernet bundle 1, core router 1, Frankfurt site 4, Germany. Network engineers can read these names like license plates and tell you which carrier owns the path, which city the packet is in, and even which equipment vendor (Cisco vs Juniper vs Arista) the operator uses.

An unexpected geographic detour — packets to a Frankfurt destination going through Singapore — usually means a BGP policy decision rather than a physical fiber cut. Suboptimal routing happens constantly and isn't necessarily a problem.

The asymmetric path problem

Traceroute only shows the outbound path. The return path can be — and often is — completely different, because each AS chooses its own outbound routing. A high RTT on a hop could mean a slow link there, or it could mean the slow link is on the return path from that hop. Without traceroute from the destination back to you, you can't tell.

This is why "traceroute looks fine but my latency is terrible" is a common situation. The probe is exploring the path one direction at a time.

Modern alternatives: MTR and mtr-style tools

MTR (My Traceroute) is a continuous traceroute — it pings every hop in a loop and shows running statistics: average RTT, loss percentage, jitter. Much more useful for diagnosing intermittent problems than a one-shot traceroute. WinMTR on Windows, mtr on Unix, PathPing as the built-in Windows alternative.

For diagnosing a path you don't own, RIPE Atlas and looking-glass servers operated by major networks let you run traceroute from a remote vantage point — invaluable for understanding asymmetric routes.

Limitations and quirks

MPLS-aware routers can hide hops by not decrementing TTL across an MPLS cloud. Load-balanced networks can show different paths on consecutive probes, making the output look chaotic. ICMP rate limiting on busy routers can produce false "slow hop" readings that don't reflect actual data-plane performance. The intermediate routers' RTT measures the time to that router's control plane, which is often slower than the data plane through the same router. Use traceroute as a hint, not a metric.

Frequently asked questions

Why does my traceroute hit '* * *' for some hops?: The router exists but didn't reply to the probe. Common reasons: ICMP rate limiting, firewall policy that drops TTL-exceeded replies, or operator decision to make the router invisible. The packets are still passing through; you just can't see those hops.
Does traceroute work through a VPN?: Yes, but the trace starts from the VPN exit, not from your real location. The first few hops you'd normally see (your home router, your ISP) are replaced by the single hop into the VPN tunnel. The trace becomes a view of the VPN provider's network and its onward path.
Why does traceroute show different paths each time I run it?: Many large networks load-balance traffic across multiple equal-cost paths, and the load-balancing key includes packet fields. Different probes hash to different paths and you see the union. Tools like Paris-traceroute keep the load-balancing key constant to produce stable output.
What does a sudden spike in latency at one hop mean?: Could be a congested link, a slow control plane on that specific router (most likely), or asymmetric return path. Look at the subsequent hops — if their RTT is similar, the spike is real congestion; if their RTT drops back, the spike was the router's control plane being slow to reply.
Is there a tool that combines traceroute and continuous ping?: MTR (mtr on Unix, WinMTR on Windows). It pings every hop in a loop and shows running statistics — average RTT, packet loss percentage, standard deviation. Far more useful than vanilla traceroute for intermittent problems.