Core idea
traceroute (Linux/BSD/macOS) maps the sequence of routers toward a destination by sending probe packets whose TTL (IPv4) or hop limit (IPv6) starts at 1 and increases each round. When a transit router decrements TTL to zero, it normally returns an ICMP Time Exceeded message naming itself (or an interface address). The tool records RTT samples for that hop. The final hop typically responds with a port unreachable (UDP mode), ICMP echo reply (some ICMP modes), or TCP RST/response depending on implementation and flags.
Why implementations differ
| Variant | Typical probes | Firewall reality |
|---|---|---|
| Linux default | UDP to high destination ports | Some edges block UDP but allow TCP 443 |
traceroute -I | ICMP echo like ping | Closer to Windows tracert behavior |
traceroute -T -p 443 | TCP SYN toward a port | Often needs privileges; simulates app-like paths |
Windows tracert | ICMP echo with rising TTL | Middle boxes may treat ICMP differently from your TCP app |
Reading the output
Asterisks mean no reply before the timeout—often rate limiting, ACLs, or asymmetric paths—not proof the hop is offline. A single inflated RTT on a middle router may reflect slow-path ICMP generation, not application latency—validate with end-to-end TCP or HTTP timings.
Related tools
mtr combines traceroute with continuous loss/latency sampling. pathping on Windows performs a similar multi-phase idea. For DNS-specific failures, still run dig/nslookup alongside path tools.
Related: ping vs traceroute vs mtr, Windows tracert explained, traceroute forensics, DNS troubleshooting commands.