Traceroute is a diagnostic tool that discovers the sequence of routers (hops) a packet crosses on its way to a destination and measures the round-trip time to each hop. In network monitoring, it is one of the first tools used to locate where along a path latency rises, packets are lost or traffic takes an unexpected route. On Windows the same function is provided by the command tracert.
Traceroute does not use a dedicated protocol. It exploits a side effect of the IP header field Time to Live (TTL), called Hop Limit in IPv6, and the ICMP error messages routers send when that field runs out.
How traceroute discovers each hop
Traceroute sends probes with a deliberately small TTL and increases it step by step. Every router decrements the TTL by one; when it reaches zero, the router discards the packet and returns an ICMP Time Exceeded message. The source address of that message reveals the router, and the time between sending the probe and receiving the reply gives the round-trip time to that hop.
The first probe uses TTL 1 and reveals the first router, the next uses TTL 2, and so on until the destination itself answers. By default most implementations send three probes per hop and stop after 30 hops. The destination is recognized by a different reply: an ICMP Port Unreachable for UDP probes, an ICMP Echo Reply for ICMP probes, or a TCP SYN-ACK or reset for TCP probes.
Each line of output therefore shows a hop number, the responding address or its reverse DNS name and three timing values in milliseconds. An asterisk means that no reply arrived within the timeout, typically a few seconds per probe.
Traceroute probe methods and implementations
Implementations differ mainly in the type of probe they send, and that choice decides whether firewalls along the path let the probes through. The table summarizes the common methods.
| Probe type | Default in | Destination reply | Practical note |
|---|---|---|---|
| UDP to high ports | Unix and Linux traceroute | ICMP Port Unreachable | Often blocked by firewalls at the destination |
| ICMP Echo Request | Windows tracert, traceroute -I | ICMP Echo Reply | Works where ping is allowed |
| TCP SYN | tcptraceroute, traceroute -T | SYN-ACK or reset | Passes firewalls that allow port 443 or 80 |
| Paris-style fixed flow | Paris traceroute, MTR options | Depends on probe type | Keeps one path across load balancers |
Load balancing complicates the picture. Routers using ECMP hash packet header fields to choose a path, and classic traceroute changes the port numbers for each probe, so successive hops may come from different parallel paths. Paris traceroute keeps the flow identifiers constant to produce a consistent path, and its multipath mode enumerates all of them.
Reading traceroute output correctly
Traceroute output is easy to misread, because routers treat probes that expire on them differently from traffic they simply forward. Generating ICMP replies is handled by the router’s control plane, which often rate-limits or deprioritizes them. A slow or silent hop is therefore not proof of a problem.
| Pattern | Likely meaning | Problem on the path |
|---|---|---|
| Asterisks at one hop, later hops fine | Router does not answer or rate-limits ICMP | No |
| High RTT at one hop only | Slow control-plane response on that router | No |
| RTT rises at one hop and stays high | Real delay introduced at or after that link | Likely |
| Asterisks from one hop to the end | Filtering or a break in the path | Possibly, verify with TCP probes |
| Large jump between distant cities | Long physical distance or undersea cable | Usually expected |
| Same addresses repeating | Routing loop | Yes |
The rule of thumb is that only latency or loss that persists to the final hop affects the traffic. Light in fiber covers roughly 200 km per millisecond, so a jump of about 70 to 80 ms across the Atlantic is physics rather than congestion.
Traceroute compared with related monitoring tools
Traceroute gives a snapshot of one path at one moment. Related tools add repetition, statistics or bandwidth measurement, and they are often used together during troubleshooting.
| Tool | What it measures | Best used for |
|---|---|---|
| Ping | Reachability and RTT to one host | Quick check whether a host answers |
| Traceroute | Path and RTT per hop, one pass | Locating where a path changes or breaks |
| MTR | Continuous traceroute with loss and jitter per hop | Intermittent loss and latency problems |
| iPerf | Achievable throughput between two endpoints | Bandwidth and capacity testing |
| Packet capture | Every packet on an interface | Protocol-level analysis |
For ongoing monitoring, platforms run scheduled traceroutes or MTR tests from several probes and alert when the path or latency profile deviates from the network baseline.
Limitations of traceroute
Traceroute shows only the forward path, from the source toward the destination. Internet routing is often asymmetric, so the return traffic may take a completely different route that the output does not reveal. A complete diagnosis therefore needs a traceroute from both ends.
- MPLS tunnels may hide internal hops entirely unless the provider propagates TTL.
- Reverse DNS names can be outdated and give misleading locations.
- ICMP replies may come from a different interface than the one the probe arrived on.
- Firewalls and NAT devices may drop probes or answer on behalf of hidden hosts.
Used with these limits in mind, traceroute remains a fast and reliable first step for answering where a path goes and roughly where trouble begins.
In everyday language
Traceroute shows the stops a piece of data makes on its way across a network and how long each stop takes to answer. It works a bit like sending a series of letters, each one told to come back after one more post office than the last.
By collecting the replies, you get a list of every post office on the route. If the delay jumps and stays high after a certain stop, that is where to start looking for the problem.
Seen in the real world
Remote employees of a design studio complain that a cloud storage service has become slow every evening. The network administrator runs MTR and traceroute from the office and from an employee’s home connection to the service’s address.
Both paths look normal up to the home provider’s border router, where round-trip time jumps from about 12 ms to roughly 95 ms and stays high on every following hop, with a few percent of loss. Earlier hops with occasional asterisks are ignored because later hops respond normally. The administrator sends the traceroute output with timestamps to the provider, which confirms a saturated peering link and adds capacity within the week.