traceroute

The ICMP article on traceroute covers the mechanism in full — TTL decremented to zero at each hop, an ICMP Time Exceeded revealing that hop's address, and how the destination is finally recognized once a probe survives the whole path. What that article doesn't cover is that "traceroute" isn't even one command. Depending on your OS, it's a genuinely different tool sending a genuinely different kind of probe, and knowing which one you're looking at changes how you read a stalled trace.

Windows' tracert uses ICMP for every probe

Linux's traceroute defaults to UDP probes to an unused high port, relying on the destination's Destination Unreachable response to signal arrival — that's covered in the ICMP article. Windows' tracert is built differently from the ground up: it sends ICMP Echo Requests at every single hop, including the final one, and the destination confirms arrival with an ordinary Echo Reply rather than a Destination Unreachable.

tracert example.com

Tracing route to example.com [93.184.216.34]
over a maximum of 30 hops:

  1     1 ms     1 ms    <1 ms  192.168.1.1
  2     6 ms     5 ms     6 ms  10.20.0.1
  3    10 ms     9 ms    10 ms  203.0.113.5
  4     *        *        *     Request timed out.
  5    12 ms    12 ms    12 ms  93.184.216.34

Trace complete.

The shape of the output looks almost identical to Linux's, but the underlying probes aren't the same protocol at all. That difference matters in exactly one common situation: a firewall that blocks the UDP port range Linux's traceroute uses, while permitting ICMP Echo, can make a Linux trace stall permanently at the last hop while a Windows trace against the very same destination completes without issue — not because the path is actually different, but because the two tools are testing with different traffic entirely. tracert's default hop limit is also 30, matching Linux, set with /h instead of -m.

mtr: ping and traceroute combined, continuously

Both tools above give you a single snapshot. mtr (My Traceroute) runs the same TTL-incrementing probe technique but repeats it continuously, aggregating results per hop into live statistics — effectively ping, run against every hop simultaneously, refreshed in real time:

mtr -rw -c 20 example.com

Start: 2026-07-27T09:14:03+0000
HOST: web01                       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 192.168.1.1                   0.0%    20    0.4   0.4   0.3   0.6   0.1
  2. 10.20.0.1                     0.0%    20    4.1   4.3   3.9   5.2   0.3
  3. 203.0.113.5                   5.0%    20    9.6   9.8   9.1  11.4   0.5
  4. 93.184.216.34                 0.0%    20   12.1  12.3  11.9  12.9   0.2

-r produces this single report instead of mtr's default live-updating terminal display, and -w prints it in wide format with full hostnames. The Loss% column is the detail a single traceroute run can't give you at all: hop 3 here shows 5% loss across the 20 probes sent (Snt), while hop 4 — the actual destination, one hop further along the same path — shows none. A single lossy-looking hop in the middle of an otherwise clean path, with zero loss at every hop after it, is usually a router deprioritizing its own ICMP generation under load rather than a real forwarding problem; loss that's present at one hop and every hop after it is the pattern that indicates a genuine problem starting at that point.

A clean trace doesn't mean the service itself works

A trace to a partner API's IP completes cleanly, every hop responding, no loss anywhere — and yet the actual API call still times out. This is a common point of confusion: traceroute and mtr only confirm that ICMP or UDP probes reach the destination host. They say nothing about whether the destination's firewall permits the actual protocol and port the API uses, since a host can answer ICMP or the UDP probes traceroute happens to use while still dropping everything aimed at, say, TCP port 8443.

mtr -rw -c 10 partner-api.example

HOST: web01                       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 192.168.1.1                   0.0%    10    0.4   0.4   0.3   0.5   0.1
  2. 10.20.0.1                     0.0%    10    4.0   4.2   3.8   4.9   0.3
  3. partner-api.example           0.0%    10   18.2  18.4  17.9  19.1  0.3

A perfectly clean trace, followed by curl -v --connect-timeout 5 https://partner-api.example:8443 hanging until it times out, points squarely at a firewall rule on the destination that's specific to port 8443 — reachable, responsive host; unreachable service on that particular port. Confirming the path is fine narrows the problem down to that one port, rather than leaving "is it even the network?" as an open question.

Practice exercises

1. If you have access to both a Linux and a Windows machine on the same network, run a trace to the same destination from each and compare whether the last hop before the destination differs — and if it does, consider whether a UDP-specific block could explain it.
2. Run mtr -rw -c 20 against two destinations — one nearby, one far away — and identify whether any hop shows loss on every subsequent hop too, versus loss at just one hop that clears up immediately after.
3. Using the scenario above as a model, describe the single next command you'd run to confirm whether a "trace succeeds but the service times out" report is a destination-side firewall rule rather than a routing problem.

One traceroute is a single photograph of the path. It's enough when the path is broken outright, and close to useless for the complaint that arrives far more often — that the connection works most of the time and occasionally doesn't. Three probes per hop, taken once, can't tell a link losing two percent of packets from one losing none, and the next article is about the tool that can.

Sources

• Linux man-pages, traceroute(8)
• Microsoft Learn, tracert | Windows Commands
• Debian Manpages, mtr(8) — a network diagnostic tool