What does traceroute do?

Traceroute maps the path your IP packets take from your machine to a remote destination, listing each router (hop) along the way and the latency to each. It is the standard first tool when something is slow or unreachable — it shows where the path breaks or where the latency suddenly jumps, narrowing the problem to a specific link.

Why do I see stars (* * *) in some hops?

Stars mean the probe got no reply within the timeout. The most common cause is the router rate-limiting ICMP error messages (most backbone routers cap "Time Exceeded" generation to a few per second). Other causes include firewalls that drop probe packets, asymmetric routing where the reply takes a different path home, or anycast networks where successive probes hit different physical replicas.

Is high latency on a middle hop bad?

Not necessarily. The latency you see on a router is round-trip time for the probe to reach that router and elicit an ICMP response. Routers prioritize forwarding actual traffic over generating control-plane replies, so a router that takes 200 ms to reply to a probe may still be forwarding your real traffic in under 5 ms. The number that matters is the end-to-end latency to the destination, not the per-hop reply time of intermediate routers.

What is MTR and when should I use it instead of traceroute?

MTR (My Traceroute) is traceroute that runs continuously, building a stable per-hop loss and latency picture over many probes. It is the right tool whenever you need to answer 'is this packet loss real or transient' or 'which hop is the actual bottleneck.' A single traceroute is a snapshot; MTR is a time-lapse. For ongoing diagnosis MTR is almost always better.

How traceroute works — and how to actually read the output

The trick: how a 40-year-old IP feature became a diagnostic tool

Traceroute, invented by Van Jacobson in 1987, isn't a special protocol — it's a clever re-use of a field that's existed in every IP packet since IPv4 was standardized in 1981. That field is the Time-To-Live, or TTL (in IPv6 it's renamed Hop Limit but works identically). See the TTL glossary entry for the deeper background.

Every IP packet leaves your machine with a TTL of typically 64 (Linux/macOS) or 128 (Windows). Each router along the path decrements the TTL by one before forwarding. If a router decrements TTL to zero, it drops the packet and — by RFC 792 — sends back an ICMP "Time Exceeded" message to the original source, identifying itself.

The TTL field was originally a loop-prevention mechanism: a packet that got stuck in a routing loop would eventually expire instead of circulating forever. Traceroute turns this safety feature into a probe by setting TTL artificially low on purpose.

The traceroute algorithm, step by step

Send a probe packet to the destination with TTL = 1. The very first router on your path decrements TTL to zero, drops the packet, and replies with ICMP Time Exceeded. The reply's source IP is the router's IP. You just learned hop 1.
Send another probe with TTL = 2. Router 1 decrements to 1 and forwards; router 2 decrements to 0, drops, and replies. You just learned hop 2.
Continue incrementing TTL until you reach a TTL where the packet actually arrives at the destination. The destination doesn't generate Time Exceeded; instead it replies normally (or replies with ICMP Port Unreachable, depending on what kind of probe you sent). That tells you the final hop count.

Most traceroute implementations send three probes at each TTL by default, which is why you see three latency columns in the output. The latencies are usually similar — small jitter is normal. Wild variation suggests congestion or that the three probes took different paths (which happens often with load-balanced routers).

The three flavors: ICMP, UDP, TCP

The protocol used for the probes themselves differs by implementation, and the choice matters because firewalls and rate-limiters treat them differently.

Classic UNIX traceroute (UDP). Sends UDP packets to a high random port (33434+). The destination is unlikely to have anything listening there, so it replies with ICMP Port Unreachable, ending the trace. The intermediate hops respond with ICMP Time Exceeded as expected. UDP is great until a firewall along the path drops random high-numbered ports — then you see stars where the path used to be.
Windows tracert (ICMP). Uses ICMP Echo Request as the probe (the same packet ping uses). Most consumer networks let ICMP through, so tracert "just works" in environments where UDP traceroute fails. The downside is that some sophisticated rate-limiters target ICMP harder than UDP.
TCP traceroute (tcptraceroute on Linux, tcp-traceroute or third-party tools elsewhere). Sends TCP SYN packets to a specific port — usually 80 or 443. The intermediate hops still reply ICMP Time Exceeded; the destination replies with SYN+ACK (port open) or RST (port closed). This is the right variant when you need to traceroute through a firewall that only allows web traffic — and it can also reveal middleboxes that intercept TCP differently from ICMP.
MTR (My Traceroute). Runs traceroute on a loop and updates a live table per-hop showing packet loss percentage, average latency, jitter, and best/worst times. Far more informative than a single traceroute when you need to answer "is this packet loss real or transient." Available as mtr on Linux/macOS (via Homebrew) and as WinMTR on Windows.

Why some hops show stars

A row of * * * means: no reply within the timeout. There are several common reasons, in rough order of frequency:

The router rate-limits ICMP. Generating Time Exceeded responses is considered a control-plane task; most backbone routers cap the rate at single-digit messages per second per source. Your probe was throttled. The traffic still flows through that hop normally — you just can't probe it. Run the trace twice; usually you see a different stars pattern each time, confirming the limit is per-probe-stream.
A firewall drops the probe. Some networks let traffic through but specifically discard the kinds of packets traceroute uses to map them. Switch variants: UDP traceroute might fail where TCP traceroute on port 443 works fine.
Asymmetric routing. The path from you to the router and the path from the router back to you may not be the same. The ICMP reply takes a different route and arrives too late to match the timeout, or takes a route that the firewall drops on the reverse direction. This is the rule, not the exception, on the public internet — routes are picked independently in each direction.
Anycast networks. CDNs and DNS providers (Cloudflare's 1.1.1.1, Google's 8.8.8.8, the DNS root servers, every modern CDN edge) advertise the same IP from hundreds of physical locations using BGP anycast. Different probes can hit different replicas; the resulting "path" is a confusing mix of three different networks that happen to share an IP at the end.

Reading the latency column like an engineer

The latency at hop N is the round-trip time from you to that router. The number is mostly useful for comparing one hop to the next, not in absolute terms.

A typical residential-to-cloud trace might look like this:

1  192.168.1.1     0.4 ms
2  10.10.10.1      8 ms     ← cable headend / ISP CMTS
3  ge-0-2-0.ny.    12 ms    ← ISP regional aggregation
4  ae-3.r01.lhr.   85 ms    ← undersea cable to London
5  ae-2.r05.lhr.   86 ms    ← peering exchange
6  104.16.x.x     86 ms    ← destination

The big jump at hop 4 (12 ms → 85 ms) is the transatlantic cable. Every subsequent hop inherits that 85 ms baseline. The destination's own latency is what matters — 86 ms, 1 ms slower than the cable's RTT, which makes sense for a London POP after the cable lands.

A common misreading: panicking at high latency on an intermediate hop where the router is deprioritizing your probe replies. The router might take 200 ms to respond but forward your real packets in 5 ms. Look at where the end-to-end latency settles, not at any single middle hop.

What hostnames in traceroute tell you

Routers in the middle of the internet usually have descriptive reverse DNS names — and you can read a surprising amount of information from them. Common patterns:

City codes. nyc, lhr, nrt, fra, sjc — three-letter IATA airport codes name the city the router lives in.
Interface names. ge-0-2-0 = Gigabit Ethernet card 0 port 2; te1-0-1 = TenGig; ae3 = aggregate (LAG) interface 3. These tell you the router's hardware and which port your traffic is on.
ASN labels. cogent, ntt, he.net, level3 — operator name embedded in the FQDN. Useful to know which network you're transiting (see the ASN glossary for context).

For any IP that catches your eye, the WHOIS / RDAP tool will give you the registrant, ASN, and abuse contact in one query.

Online traceroute vs. running it yourself

Most "online traceroute" tools run from a single datacenter and show you the path from their location, not yours. That's useful for confirming a destination is reachable from somewhere, but it tells you nothing about your local network path — which is usually where the actual problem lives.

For broader perspective, use a looking glass at a major Tier-1 ISP: Cogent, NTT, Hurricane Electric, and Telia all run public looking glasses that let you traceroute from their networks. For a problem you're actually experiencing, your own terminal running mtr from where you sit is always the better diagnostic.

How traceroute works