Reading MTR Output: A Network Engineer's Guide
MTR (My Traceroute) is the network diagnostic tool that combines ping and traceroute into a single continuous probe. Engineers reach for it when "the network feels slow" needs to become "here's exactly which hop is dropping packets." This post is the guide to reading MTR output — what each column means, the patterns worth recognizing, and how to tell ISP rate-limiting from a real network problem.
When a connection feels slow, the question is usually "where on the network is the problem?" — and MTR (My Traceroute) is the right tool to answer it. MTR continuously probes every router between you and a destination, reporting per-hop latency, packet loss, and jitter in a single live-updating table. It combines ping and traceroute into one continuous test, and unlike a single run of either, MTR's continuous probing surfaces intermittent failures that point queries would miss. The mtr-packet binary handles the raw probe sending; the mtr command is the user-facing interface that aggregates the results.
What MTR is and what it tells you
MTR is a hybrid of two tools:
- Traceroute sends probes with increasing TTL (time-to-live) values, causing each router along the path to send back an "ICMP time exceeded" reply. The replies reveal the router addresses, building a list of hops between source and destination.
- Ping continuously sends echo requests and tracks round-trip time and loss to a single target.
MTR does both at once. It sends probes to every hop along the path repeatedly, accumulating statistics for each one. After a few minutes of running, the output shows per-hop packet loss and latency — exactly what you need to identify which router is the problem, not just that there is one.
How to install MTR
On most Linux distributions:
# Debian / Ubuntu
sudo apt install mtr
# RHEL / Fedora / Rocky / Alma
sudo dnf install mtr
# Arch
sudo pacman -S mtr
On macOS, via Homebrew:
brew install mtr
On Windows, the closest equivalent is WinMTR (a third-party port) or PingPlotter (a commercial GUI). Microsoft's built-in pathping covers some of the same job but with a less convenient output format.
Running MTR
The basic invocation:
mtr files.com
That opens MTR in interactive curses mode and probes continuously. A few useful flags:
mtr -r files.com # report mode — runs for 10 probes then exits
mtr -r -c 100 files.com # report mode, 100 probes per hop
mtr -r -c 100 -w files.com # wide output (full hostnames not truncated)
mtr -r -c 100 -n files.com # numeric — don't resolve IPs to hostnames
mtr -r -c 100 --tcp -P 443 files.com # use TCP probes to port 443 instead of ICMP
mtr -r -c 100 --json files.com # JSON output for piping into other tools
For a real diagnostic run, mtr -r -c 100 -w files.com is the canonical invocation — 100 probes is enough to surface intermittent issues, wide mode keeps the hostnames readable.
Reading the columns
A typical MTR report looks like this:
Start: 2026-05-24T14:32:01-0700
HOST: laptop Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 100 1.2 1.5 0.9 8.3 1.1
2.|-- 10.0.0.1 0.0% 100 8.4 9.2 8.0 15.1 1.8
3.|-- isp-router.example.net 0.0% 100 12.1 13.4 11.5 22.3 2.1
4.|-- backbone-1.example.net 0.0% 100 18.9 19.7 18.5 28.4 1.9
5.|-- backbone-2.example.net 2.0% 100 20.1 21.3 19.8 35.2 2.5
6.|-- peering.cdn.example.net 0.0% 100 24.5 25.8 23.9 41.0 2.8
7.|-- files.com 0.0% 100 28.3 29.1 27.5 44.6 2.9
The columns:
- HOST — the IP or hostname of the router at that hop.
- Loss% — percentage of probes that didn't get a reply. The single most important column.
- Snt — total probes sent to this hop.
- Last — round-trip time of the most recent probe (milliseconds).
- Avg — average round-trip time across all probes.
- Best — fastest round-trip seen.
- Wrst — slowest round-trip seen.
- StDev — standard deviation of round-trip times. High StDev means jitter — the connection is inconsistent.
The two columns that matter most: Loss% tells you whether packets are getting dropped, and Avg tells you how long the round-trip is. Everything else is context for interpreting those two.
The six patterns worth recognizing
1. Clean run — no packet loss
1.|-- gateway 0.0% 100 1.2 1.5 0.9 8.3 1.1
2.|-- isp-router 0.0% 100 8.4 9.2 8.0 15.1 1.8
...
7.|-- destination 0.0% 100 28.3 29.1 27.5 44.6 2.9
Zero packet loss across every hop and reasonable latency at the destination. The network is fine.
2. Single-hop loss that doesn't continue
6.|-- backbone-3 89.3% 100 20.1 21.3 19.8 35.2 2.5
7.|-- destination 0.0% 100 28.3 29.1 27.5 44.6 2.9
Loss at hop 6, but the destination at hop 7 has zero loss. This is not a problem. Almost certainly the hop-6 router is rate-limiting ICMP responses to itself while forwarding traffic normally. As long as subsequent hops show zero loss, ignore the intermediate-hop loss.
3. ISP rate-limiting
4.|-- isp-router 1.5% 100 12.1 13.4 11.5 22.3 2.1
5.|-- backbone-1 0.0% 100 18.9 19.7 18.5 28.4 1.9
Small (under 5%) loss at one hop, zero loss at later hops. The ISP is throttling ICMP — typical for transit providers that don't want to spend resources answering traceroute probes. Cosmetic, not a real problem.
4. Significant loss continuing to the destination
7.|-- backbone-3 34.2% 100 20.1 21.3 19.8 35.2 2.5
8.|-- backbone-4 34.5% 100 24.5 25.8 23.9 41.0 2.8
9.|-- destination 34.1% 100 28.3 29.1 27.5 44.6 2.9
Loss starting at hop 7 and continuing to the destination. This is a real problem. A router between hop 6 and hop 7 is dropping a third of all traffic — and that's affecting the actual destination, not just the probe responses. Contact your ISP with the MTR results.
5. Latency spike at one hop
4.|-- isp-router 0.0% 100 12.1 13.4 11.5 22.3 2.1
5.|-- backbone-1 0.0% 100 185.2 192.4 181.0 220.5 12.8
6.|-- backbone-2 0.0% 100 18.9 19.7 18.5 28.4 1.9
Single hop with massively higher latency than the hops before and after. Almost always cosmetic — the router on that hop is deprioritizing its CPU for handling ICMP responses, while forwarding actual traffic at line rate. If subsequent hops have normal latency, the destination is reachable at normal speed.
6. Sustained high latency from a midpoint
4.|-- isp-router 0.0% 100 12.1 13.4 11.5 22.3 2.1
5.|-- backbone-1 0.0% 100 185.2 192.4 181.0 220.5 12.8
6.|-- backbone-2 0.0% 100 188.9 195.7 184.5 225.4 13.9
7.|-- destination 0.0% 100 192.3 198.1 186.0 230.5 14.2
Latency jumps at hop 5 and stays elevated through the destination. This is a real problem. A network segment between hop 4 and hop 5 has high latency (likely a saturated link or a long geographic path), and it's affecting your actual traffic. Either route around it (BGP peering changes, VPN through a different region) or accept the increased latency.
What MTR can't tell you
MTR uses ICMP probes by default, which is convenient but has limits:
- Asymmetric routing — traffic going from your laptop to the destination may take a different path than traffic coming back. MTR shows you the outbound path; if the problem is on the return path, MTR misses it.
- TCP-specific issues — some routers prioritize TCP traffic over ICMP. If your application is TCP-based (HTTP, SSH, SFTP) and you're seeing ICMP loss, the application might be unaffected. Use
mtr --tcp -P <port>to send probes as TCP SYNs to a specific port — closer to what your application actually does. - Application-layer problems — MTR tests the network layer. A failing TLS handshake, a misconfigured firewall blocking a specific port, an authentication issue — none of those show up in MTR.
- ICMP rate-limiting at the destination — some servers (and most cloud load balancers) rate-limit ICMP responses to themselves. The final hop showing partial loss might be the destination being polite to probe traffic, not a real network issue.
When MTR is clean but your application is still slow, the problem is application-layer, not network. Pull packet captures, check application logs, look at TLS handshake times — MTR has done its job by ruling out the network.
When to reach for MTR
The good cases:
- "My file transfer to the SFTP server keeps stalling." Run MTR to the SFTP server's hostname. Is there packet loss on the path? If yes, that's why.
- "Latency to the cloud provider is terrible this afternoon." Run MTR; see if the latency jumped at a specific hop. If a backbone provider is having a bad day, you'll see it in the per-hop numbers.
- "VPN connection feels slow." MTR to the VPN endpoint, then MTR from inside the VPN to the destination. Compare. The hop where latency jumps is the bottleneck.
- "Customer support claims our service is unreachable from their network." Have them run MTR to your service from their location and send the output. Per-hop data tells you exactly where the path is failing.
The bad cases:
- "DNS resolution is slow." MTR doesn't test DNS. Use
digornslookupinstead. - "TLS handshakes are failing." MTR runs at the IP layer; TLS is way above that. Use
openssl s_client -connect <host>:<port>instead. - "HTTP requests are returning 503." That's application-layer. MTR has nothing to say.
FAQ
What does MTR stand for?
My Traceroute. The tool was originally a project named "Matt's Traceroute" (after author Matt Kimball, 1997) and got renamed when Roger Wolff took over maintenance and rebranded it as MTR, sometimes back-formed as "My Traceroute" in the documentation.
What's the difference between MTR and traceroute?
Traceroute sends a single round of probes to identify each hop on the path and exits. MTR continuously sends probes and updates per-hop statistics in real time — making it much better at catching intermittent issues that a single traceroute would miss.
What's mtr-packet?
mtr-packet is the privileged binary that actually sends the raw network probes (it needs raw-socket access, which requires root or CAP_NET_RAW). The user-facing mtr command spawns mtr-packet to do the actual work. On most installs, mtr-packet is installed with setuid or capability bits so regular users can run mtr without sudo.
Should I use ICMP or TCP probes?
ICMP by default — it's faster, works without requiring an open application port, and gives you a clean view of the network path.
TCP when you want to probe how a specific application's traffic is treated. mtr --tcp -P 22 server.example.com sends TCP SYNs to port 22, which is closer to what your SSH client actually does. Useful when you suspect ICMP is being rate-limited and TCP isn't.
How long should I run MTR for?
For a quick check, 30 seconds is enough to spot persistent issues. For a real diagnostic, 10–15 minutes (or 100+ probes in report mode). Intermittent issues — a peering link that flakes once a minute — don't show up in 30-second runs.
Why is the loss at one hop high but the destination is fine?
Almost always ICMP rate-limiting at the intermediate router. Many routers deprioritize replying to traceroute probes while forwarding actual traffic at line rate. As long as the destination shows zero loss, the intermediate-hop loss is cosmetic. The pattern to worry about is loss that starts at a hop and continues to the destination — that's a real problem.
Can MTR diagnose problems behind a NAT or firewall?
Partially. MTR can probe the path from your machine to the destination across the public internet. It can't probe inside a corporate network from outside, and it can't probe through a firewall that blocks the probe protocol (ICMP or TCP, depending on --tcp). For inside-the-firewall diagnostics, run MTR from a machine on the inside network.