How to Diagnose Packet Loss with mtr

When a site feels slow or connections drop, ping can tell you that packets are being lost, but not where. mtr sends probes to every router on the path and keeps statistics for each hop, so you can see whether the problem is your own network, somewhere in between, or the server itself. It is also the report most hosting support teams ask for. Reading it correctly is the important part, because the most eye-catching numbers in an mtr report are often harmless.

Install mtr

Ubuntu 24.04 includes the text version of mtr as the mtr-tiny package. If mtr --version does not work, install it:

$ sudo apt-get update
$ sudo apt-get install -y mtr-tiny
$ mtr --version

The output is mtr 0.95. You can run it as a normal user; the package grants the probe helper the network permission it needs.

Run a report

Run mtr from the machine that sees the problem, towards the server or site it cannot reach well:

$ mtr -rwbz -c 100 example.com

The options give a report suitable for reading and sharing:

• -r prints a report after the probes finish, instead of the live screen.
• -w shows full host names.
• -b shows both host names and IP addresses.
• -z adds the network (AS) number, which tells you which provider runs each hop.
• -c 100 sends 100 probes per hop. Fewer probes make the percentages unreliable.

If the report is slow to start because name lookups hang, replace -b with -n to show IP addresses only.

The report takes about 100 seconds. Each row is one hop, with these columns:

Column	Meaning
Loss%	Share of probes to this hop that got no reply
Snt	Probes sent
Last, Avg, Best, Wrst	Round-trip time in milliseconds
StDev	How much the round-trip time varies

Interpret intermediate-hop loss cautiously

A router can forward traffic while limiting or ignoring probes addressed to itself. If an intermediate hop reports missing replies but subsequent hops and the destination answer normally, that pattern alone does not establish forwarding loss at that router. Different probe types, load balancing and return paths can affect the comparison.

Start with the destination and the application symptom, then compare repeated reports. A clean destination sample is useful evidence for that measurement period, not proof that the path never loses traffic.

Look for persistent patterns

Loss that continues through later hops to the destination is worth investigating, particularly when it coincides with failed application requests. Compare repeated measurements from the affected source and, where possible, the reverse direction.

A first-hop pattern can suggest a local link or router issue; a later sustained change can help a provider narrow its investigation. Neither identifies a confirmed faulty router by itself. Probe rate limits, asymmetric routes, changing paths and destination policy can produce similar output.

Likewise, persistent latency changes can reflect distance, queuing or congestion. Correlate them with the affected service rather than diagnosing the cause from one high number.

Confirm with a TCP test

Some servers and firewalls limit or block the ICMP probes that mtr uses by default. TCP mode probes a real service port instead:

$ mtr -rwbz -T -P 443 -c 100 example.com

Use a port the destination actually serves, such as 443 for a website or 22 for SSH. Compare the final hop in both reports:

• ICMP loss but normal TCP probes: this can be consistent with different filtering or reply limits. It does not prove that every application packet is unaffected.
• High TCP worst time or variation: inspect congestion, queuing, retransmission behavior and endpoint load. Timing alone does not establish a loss percentage or root cause; implementation and probe type also matter.

Test both directions

The route back from a server can differ from the route to it, and a problem may exist in only one direction. When you contact support, run mtr from your computer to the server and from the server to your computer’s public IP address. You can look that address up from your computer with curl -4 ifconfig.me.

Send both reports, the time you ran them, and a short description of the symptom. Run them while the problem is happening; a clean report taken an hour later does not help.

If the report looks wrong

• The final hop does not answer but the site works: probe filtering or reply policy may differ from application traffic. Compare a TCP probe to a port the service actually uses and a real application request during the same period.
• Probe-helper permission errors: inspect the installed package, helper path and file capabilities. Distribution packaging and container restrictions differ. Restore the package’s intended permissions through your normal administration process rather than granting capabilities to an unverified executable.
• Numbers jump around between runs: use at least 100 probes, and run the report a few times during the problem.

Make the report useful to support

Read the destination row first, then work backward to see whether a pattern persists. Keep the complete report rather than sending only the row with the largest percentage. A middle hop’s alarming figure loses much of its meaning when the destination and later hops answer normally.

Compare measurements made during the actual symptom. Include the affected service port, probe mode, source network, destination and time zone alongside the time of the report. A TCP run against SSH and an ICMP run towards a website are not identical observations, even when they share a destination address.

Avoid naming a router as the confirmed cause based on one run. Probe responses take a return path too, and that path may not match the forward route displayed in the report. Give the provider the measurements and the application symptom so they can correlate them with their own link and routing data.

A clean mtr report narrows the investigation; it does not test TLS negotiation, HTTP responses, database queries or every packet sent by the application. Use it to distinguish likely network-path problems from questions that need service-specific diagnostics.

Send the complete report and the application symptom to support. Intermediate-hop statistics provide context; they are not independent proof of a broken link or an all-clear.

Reference: mtr upstream documentation. Check the documentation for your installed version before applying changes.