Skip to content

mtr

traceroute takes one sample of the path and prints it. That's fine when the path is broken — a route that dies at hop 4 dies at hop 4 every time. It's close to useless for the far more common complaint, which is that the connection mostly works and occasionally doesn't. Three probes per hop, taken once, cannot distinguish a link that drops 2% of packets from one that drops none.

mtr fixes that by never stopping. It runs traceroute's hop discovery in a loop and keeps running statistics per hop, so after a minute you're looking at hundreds of samples instead of three.

sudo apt install mtr-tiny

The mtr-tiny package is the terminal-only build, which is the one you want on a server. The full mtr package pulls in GTK for a graphical window nobody uses over SSH.

Reading the live display

mtr 1.1.1.1

                             My traceroute  [v0.95]
lab-01 (192.168.1.10) -> 1.1.1.1                      2026-08-03T10:12:04+0000
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway                          0.0%    47    0.4   0.5   0.3   1.9   0.2
 2. 10.20.0.1                         0.0%    47    8.1   9.3   7.4  31.2   3.6
 3. ???                              100.0%    47    0.0   0.0   0.0   0.0   0.0
 4. 172.68.140.2                      0.0%    47   12.4  13.1  11.8  28.7   2.1
 5. one.one.one.one                   0.0%    47   12.6  13.4  12.0  30.1   2.4

The display refreshes in place; q quits. Hop addresses and timings will differ everywhere.

Column by column: Snt is how many probes have been sent to that hop so far, Loss% is the fraction that went unanswered, and Last/Avg/Best/Wrst are round-trip times in milliseconds. StDev is the standard deviation of those times — a number worth watching, because a hop with a good average and a large standard deviation is a hop with intermittent queuing, and that's exactly what users describe as "the site is sometimes slow."

The trap that makes people file the wrong ticket

Hop 3 in that output shows 100% loss. Hop 4 and hop 5, which are further away, show none.

That router is not dropping your traffic. If it were, nothing beyond it could answer — the packets have to pass through hop 3 to reach hop 4. What's actually happening is that hop 3's control plane declines to generate the ICMP Time Exceeded message that mtr counts as a reply. Many routers rate-limit or entirely disable ICMP generation, because producing those messages costs CPU on a device optimised for forwarding, and it's traffic that serves nobody but people running traceroute.

Loss at a middle hop that doesn't continue to the final hop is a reporting artefact, not packet loss. Only loss that persists through to the destination is real.

That single rule is the reason mtr output gets misread so often, and it's a standard interview question in any role that touches network support. The corollary is just as useful: loss that starts at hop 4 and appears at every hop after it, including the last, means hop 4 is genuinely dropping traffic.

Making the measurement match the real traffic

By default mtr probes with ICMP, and a network's treatment of ICMP frequently has nothing to do with its treatment of your application's TCP. A path can deprioritise ICMP under load while forwarding TCP perfectly, or the reverse. When you're investigating why HTTPS is slow, measure HTTPS:

sudo mtr --tcp --port 443 --report --report-cycles 100 api.example.com

Start: 2026-08-03T10:20:41+0000
HOST: lab-01                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- _gateway                   0.0%   100    0.4   0.5   0.3   2.1   0.2
  2.|-- 10.20.0.1                  0.0%   100    8.2   9.1   7.4  28.6   2.9
  3.|-- ???                       100.0%   100    0.0   0.0   0.0   0.0   0.0
  4.|-- 203.0.113.9                4.0%   100   41.2  46.8  38.9 214.3  22.7
  5.|-- api.example.com            4.0%   100   41.5  47.1  39.1 219.8  23.1
  • --tcp --port 443 sends TCP SYN probes to port 443 instead of ICMP echoes, so the packets travel the same class of path your application's traffic does. This needs root, because crafting those packets requires a raw socket.
  • --report runs a fixed number of cycles and prints a static summary instead of a live screen — the form to paste into a ticket.
  • --report-cycles 100 sets that number. A hundred probes per hop is enough to make a 2% loss rate visible; ten is not.

Now read it. Hop 3 is the same rate-limiting artefact as before, safely ignorable. Hop 4 shows 4% loss and a worst-case RTT of 214 ms against a best of 39 ms — and hop 5, the destination, shows the same 4%. The loss persists to the end, so it's real, and it starts at hop 4. That's a defensible finding to send to whoever operates 203.0.113.9, with the output attached.

Always capture mtr in both directions

A path from A to B and the path from B back to A can be completely different, and network problems are frequently one-way. An mtr run from your side alone shows the forward path plus the return path of the ICMP replies, blended together, with no way to separate them.

When you have shell access on both ends, run --report from each towards the other and compare. "Loss appears only on the return path" is a much stronger diagnosis than "there's loss somewhere," and it's the difference between a ticket that gets fixed and one that gets closed as unreproducible.

Where mtr fits next to the tools around it

Question Reach for
Is the destination up at all? ping
What is the path, right now, once? traceroute
Is the path losing packets or jittering over time, and where? mtr
Can I open a connection to this specific port? netcat

mtr is the tool for a complaint with the word "sometimes" in it. It is not the tool for "the site is down" — that's ping and netcat, and they answer in two seconds. Running a hundred cycles of mtr on a host that isn't answering anything wastes two minutes to tell you what a single ping already said.

Practice

  1. Run mtr --report --report-cycles 50 to a well-known public address. Identify every hop showing loss, and for each, decide from the output alone whether it's real loss or ICMP rate limiting. Justify each answer in one sentence.
  2. Run the same target twice: once with the default ICMP mode and once with --tcp --port 443. If the hop lists differ, explain what that tells you about how the path treats the two kinds of traffic.
  3. Find the hop on your own route with the highest StDev and correlate it with Wrst. Then run the test again while saturating your own uplink (a large upload works) and see whether that hop's numbers change — and reason about whether the congestion is yours or the network's.

Exercise 3 has a specific lesson buried in it. If the jitter appears only while your own upload is running, the congested link is the one leaving your building, and no amount of complaining to an upstream provider will help. Distinguishing "the network is slow" from "I am the reason the network is slow" is most of network performance work.

Reachability and path are one category of question, and ping, traceroute, and mtr between them cover it. The tools that follow shift to a different one entirely — not what's out there on the network, but what this machine believes about itself: its interfaces, its addresses, and which DNS servers it was told to use. That question gets answered differently on every operating system, starting with the one most people meet first.

Sources