mtr Command Guide: Diagnosing Packet Loss and Latency

When a network path misbehaves - intermittent packet loss, latency spikes, or throughput that never matches the circuit - a single traceroute is often not enough: it sends a few probes per hop and exits, so it misses intermittent problems entirely. mtr (My Traceroute) combines traceroute and ping: it discovers the path and then keeps probing every hop continuously, accumulating hundreds of samples per hop. This guide explains how to run mtr, how to read its columns, and how to avoid the classic false alarm of mistaking ICMP rate-limiting for real loss.

How mtr Works

Like traceroute, mtr manipulates the TTL of probe packets so each router along the path sends back an ICMP Time Exceeded message; the difference is that mtr keeps sending probes to every hop simultaneously and updates live statistics. Most implementations default to ICMP probes, but TCP and UDP modes are available when ICMP is filtered.

$ mtr 8.8.8.8
$ mtr -n 8.8.8.8        # numeric, no DNS lookups
$ mtr --report 8.8.8.8  # send 10 rounds, print one report, exit
$ mtr --tcp -P 443 example.com
$ mtr --udp -P 53 1.1.1.1

Reading the Output Columns

Interactive mtr output shows one row per hop with the following columns:

• Loss%: percentage of probes that received no reply at this hop.
• Snt: probes sent to this hop so far - the more samples, the more trustworthy the loss figure.
• Last: round-trip time of the most recent probe.
• Avg: average RTT - the primary latency indicator per hop.
• Best / Wrst: fastest and slowest RTT seen; a large gap means jitter or congestion events.
• StDev: RTT standard deviation; a high value signals an unstable, jittery hop.

The One Rule That Prevents False Alarms

If loss appears at an intermediate hop (say 30-70% at hop 4) but every subsequent hop - including the final destination - shows 0% loss, that router is almost certainly rate-limiting or refusing the ICMP probes mtr uses, while still forwarding your real traffic normally. Many routers cap ICMP Time Exceeded replies to protect their control plane. The rule: loss at an intermediate hop only matters if the loss carries through to the final destination. Conversely, loss that begins at one hop and continues on every hop after it indicates a real problem at or beyond that point.

Patterns and What They Mean

• Loss starts at hop 1 (your gateway) and continues: the problem is inside your own site - Wi-Fi, cable, or your router. Test from a wired connection.
• Hops 1-2 clean, loss starts at hop 3-4 and continues to the end: the issue sits at your ISP's edge - exactly the report your provider needs.
• Avg latency jumps sharply at one hop and stays high afterward: that hop is congested or is a long-distance link; the added delay carries downstream.
• High StDev or a wide Best-Wrst gap at one hop: jitter or congestion events on that segment.

Caveats: ECMP and Asymmetry

Internet paths frequently use Equal Cost Multi-Path (ECMP) routing: different probes can take different parallel paths to the same destination, so the per-hop statistics mix multiple routes. Repeat the test several times and, if possible, run the test in the reverse direction - a lossy path in one direction is not necessarily lossy in the other.

Validating the Result

Because mtr manipulates TTLs, it can produce false positives. Validate an end-to-end finding with plain tools: ping for continuous end-to-end loss/latency, and hping3 to test the same TCP or ICMP type and port you used in the mtr run:

$ ping -i 0.2 -c 100 8.8.8.8
$ hping3 -S -p 443 -c 100 example.com

If mtr shows end-to-end loss but a long ping run is clean, re-check the mtr parameters (ICMP vs TCP) before escalating.

Related reading: tcpdump filters for troubleshooting and Linux network troubleshooting with ss, netstat and tcpdump.

Original article: AWS re:Post: Diagnosing packet loss and latency with MTR