Find Where Latency or Packet Loss Begins with mtr

Something is slow between you and a server, and mtr shows you exactly where the trail goes cold. This guide builds one short, repeatable mtr report and shows you how to read it without jumping to conclusions. The examples use the installed mtr-tiny package, version 0.95-1.1ubuntu0.1, and take about ten minutes if you already have a destination to test.

Network probes here are ordinary user commands, not privileged ones. They still send real traffic, so do not run large or repeated tests against a third party without a reason.

1. Confirm the installed command

Check the binary and version before you trust anyone's copy-pasted flags, including your own from six months ago. A different build can support different options.

$ command -v mtr
/usr/bin/mtr
$ dpkg-query -W -f='${Package} ${Version}\n' mtr-tiny
mtr-tiny 0.95-1.1ubuntu0.1
$ mtr --version
mtr 0.95

The local manual is the authority for this installation. Upstream keeps developing mtr, so check the installed version before reusing newer examples or assuming output fields match another host.

Checkpoint: You have confirmed which executable will send the probes and which package supplied it.

2. Run one controlled report

Use report mode when you want a result that exits instead of an interactive display that never stops scrolling. Set the cycle count explicitly, disable DNS while diagnosing, and use a destination you are authorised to test. The loopback address is a safe syntax check; swap in HOSTNAME for a real path.

$ mtr --report --report-cycles 5 --no-dns HOSTNAME

The report lists hops and statistics: loss percentage, sent packets, last response, average response, best response, worst response and standard deviation. A successful local test looks like this, though the hostname and timings will vary:

Start: 2026-09-25T04:11:32+0100
HOST: workstation.example       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.0.2.1                 0.0%     5    0.8   0.9   0.7   1.2   0.2

Five cycles are enough for a quick look, not a durable performance claim. The default probe interval is one second. Every running instance creates network traffic, and the manual warns that many instances at once can affect network performance.

Checkpoint: The command exits after the requested number of cycles and you have kept the complete report, including its start time.

3. Make names and addresses tell the same story

$ mtr --report --report-wide --report-cycles 10 --show-ips HOSTNAME

Do not treat an address as a device identity just because it appears on one run. Routes change, some hops hide their addresses, and several routers can share a name. A ??? marker or a missing response means that hop did not answer this kind of probe: it does not by itself prove forwarding traffic was lost there.

The project documentation makes the same distinction operationally: intermediate routers may suppress or rate-limit the ICMP replies mtr relies on. Look for loss that continues at later hops and at the destination itself. Loss at one intermediate hop followed by clean later hops is usually a response-policy quirk, not a confirmed fault at that hop.

4. Compare the route with IPv4 and IPv6

When a name has both address families, test them separately. -4 forces IPv4 and -6 forces IPv6. IPv6 mode may still use IPv4 for the DNS lookup itself, so keep --no-dns in to keep the displayed path unambiguous.

$ mtr --report --report-wide --report-cycles 10 --no-dns -4 HOSTNAME
$ mtr --report --report-wide --report-cycles 10 --no-dns -6 HOSTNAME

Compare like with like: same cycle count, similar time of day, same destination address family. A difference between the two reports is evidence about the paths, not proof that one provider or router is at fault. If the IPv6 command cannot reach the destination at all, first confirm the host has working IPv6 connectivity before you blame the route.

5. Choose a probe type that matches the failure

Normal mtr probes use ICMP Echo. A firewall or router can treat ICMP very differently from application traffic, so a second probe type earns its keep. --tcp sends TCP SYN probes and needs a target port; --udp sends UDP datagrams and also needs one. These stay diagnostic packets, not a way to bypass access controls.

$ mtr --report --report-cycles 5 --no-dns --tcp --port 443 HOSTNAME
$ mtr --report --report-cycles 5 --no-dns --udp --port 53 HOSTNAME

Use a port the destination is expected to provide and that you are allowed to test. A closed or filtered port can make the result look bad even when the network path is perfectly healthy. Do not infer service health from mtr alone; test the service with its own client as a separate check.

The packet size option counts the IP and ICMP headers for ICMP probes. Leave it at the default until a smaller-path or fragmentation investigation gives you a specific reason to change it. Large timeout values combined with a short interval can consume many file descriptors.

6. Save machine-readable evidence

For scripts, use one of the documented output formats rather than parsing the aligned terminal table. JSON requires the Jansson library to have been available when mtr was built. CSV, despite its name, is described by the local manual as semicolon-separated. Check the actual output before wiring it into an importer.

$ mtr --report --report-cycles 5 --no-dns --json HOSTNAME > mtr-report.json
$ test -s mtr-report.json && echo 'report written'
report written

Redirection creates or truncates the destination before mtr even runs. If the existing file matters, write to a new name first and replace it only after validation:

$ mtr --report --report-cycles 5 --no-dns --json HOSTNAME > mtr-report.json.new
$ test -s mtr-report.json.new && mv mtr-report.json.new mtr-report.json

If the command fails, remove the incomplete mtr-report.json.new after checking the error; the previous report stays untouched. There is no service configuration to undo here, and mtr never alters the route or destination.

7. Interpret a suspicious hop carefully

Start at the first hop where loss or latency rises, then inspect every hop after it. If later hops and the destination show the same loss, the problem may genuinely begin near that point. If later hops recover, the intermediate router is probably just deprioritising diagnostic replies. High average latency at one hop is weak evidence on its own when later hops look normal. Congestion, asymmetric return paths and ICMP rate limiting can all distort the picture.

Repeat the report from another host or network before escalating. Keep the command, version, destination, address family, probe type, cycle count and timestamp together with the report. Never publish internal addresses or hostnames in a ticket or paste service without checking for sensitive information first.

Done means