MTR Network Diagnostics
MTR: Network Path Diagnostics
MTR combines the functionality of ping and traceroute into a single tool that monitors every hop along a network path continuously, producing statistical output that identifies where latency and packet loss actually occur. When basic connectivity tools confirm a problem exists but don’t locate it, MTR provides the data needed to isolate it.
Installation
sudo apt install mtr
MTR is available in the Debian main repository and requires no additional sources. It is maintained across all current Debian releases and installs without external dependencies. The package name is mtr, which includes both the command-line interface and mtr-packet, the helper binary responsible for sending and receiving network packets.
Basic Usage
MTR operates in two modes: interactive, which displays a live updating view of the network path, and report mode, which runs a fixed number of cycles and prints a summary.
- Interactive mode
mtr example.com
- Report mode — 50 cycles, no DNS resolution
mtr --report --report-cycles 50 --no-dns example.com
- TCP mode — useful when ICMP is filtered
sudo mtr --tcp --port 443 example.com
- Save report to file
mtr --report --report-cycles 100 --no-dns example.com > mtr-report.txt
| Host | hostname | Loss% | Snt | Last | Ave | Best | Wrst | StDEV |
|---|---|---|---|---|---|---|---|---|
| 1. | 192.168.1.1 | 0.0% | 50 | 1.2 | 1.5 | 1.0 | 2.3 | 0.4 |
| 2. | 10.0.0.1 | 0.0% | 50 | 8.5 | 9.2 | 7.8 | 12.1 | 1.3 |
| 3. | isp-gateway.net | 0.0% | 50 | 15.3 | 16.1 | 14.2 | 19.8 | 1.8 |
| 4. | ??? | 100.0% | 50 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| 5. | destination.com | 0.0% | 50 | 25.4 | 26.8 | 24.1 | 32.5 | 2.4 |
Each row represents one hop. The columns report packet loss percentage, packets sent, and latency values in milliseconds — last, average, best, worst, and standard deviation. Standard deviation measures consistency: a low value indicates stable latency, a high value indicates jitter.
Interpreting Results
Packet loss at an intermediate hop that does not persist to subsequent hops is typically not a network problem. Many routers deprioritise or rate-limit ICMP responses while forwarding traffic normally. If hop 4 shows 100% loss but hop 5 responds cleanly, traffic is flowing through hop 4 — it simply isn’t generating diagnostic replies.
Packet loss that begins at a hop and continues through to the destination indicates a genuine problem at or beyond that hop.
A sudden increase in latency at a specific hop that persists to all subsequent hops points to a congested or slow link at that point in the path.
High standard deviation indicates unstable latency, which affects real-time applications such as VoIP and video conferencing even when average latency appears acceptable.
A large latency increase with stable standard deviation and no packet loss reflects geographic distance or a slower interconnect, not a fault.
Problems confined to the first hop — your local router — and absent from all subsequent hops point to a local network issue: wireless interference, a misconfigured interface, or a problem with the router itself.
Practical Scenarios
Isolating a problem for an ISP or hosting provider
Run an extended report against a known external address and save the output:
mtr --report-cycles 100 --no-dns 8.8.8.8 > isp-report.txt
The report shows exactly where in the path packet loss or latency appears, which hop belongs to which network, and whether the problem is within the provider’s infrastructure or beyond it.
Testing when ICMP is filtered
Some paths block ICMP but pass TCP traffic. Testing with TCP against a specific port confirms whether a service is reachable end-to-end:
sudo mtr --tcp --port 22 --report-cycles 50 remote-server.com
sudo mtr --tcp --port 443 --report-cycles 50 remote-server.com
Diagnosing jitter for real-time applications
Run a longer test and focus on the StDev column:
mtr --report-cycles 200 game-server.com
Values above 5ms in the StDev column at any hop that persists to the destination will affect latency-sensitive applications.
Catching intermittent problems
Intermittent issues require longer observation windows than a standard report provides:
mtr --report-cycles 500 --interval 1 target.com > long-test.txt
Protocol Selection
MTR supports ICMP (default), UDP, and TCP. When one protocol appears to show loss or filtering, testing with another confirms whether the issue is protocol-specific or affects all traffic:
Icmp
mtr example.com
UDP
mtr --udp example.com
TCP on port 80
sudo mtr --tcp --port 80 example.com
Output Formats
MTR can produce machine-readable output for logging or automated analysis:
mtr --report --csv example.com
mtr --report --json example.com
mtr --report --xml example.com
Additional Options
- Show both hostname and IP address
mtr --show-ips example.com
- Display Autonomous System numbers
mtr --aslookup example.com
- Limit maximum hops
mtr --max-ttl 20 example.com
- Specify source address on systems with multiple interfaces
mtr --address 192.168.1.100 example.com
- Force IPv4 or IPv6
mtr -4 example.com
mtr -6 example.com
Interactive Mode Key Bindings
In interactive mode, the following keys are available:
| Key | Action |
|---|---|
| d | Toggle display mode |
| n | Toggle between hostnames and IP addresses |
| r | Reset statistics |
| p | Pause and resume |
| u | Cycle between ICMP, UDP, and TCP |
| y | Toggle between IPv4 and IPv6 |
| q | Quit |
Useful Aliases
These aliases cover the most common diagnostic tasks. Add them to ~/.bashrc and reload with source ~/.bashrc:
- Standard report — 50 cycles, no DNS
alias mtrreport='mtr --report --report-cycles 50 --no-dns'
- Extended report — 100 cycles
alias mtrlong='mtr --report --report-cycles 100 --no-dns'
- HTTPS path test
alias mtrhttps='sudo mtr --tcp --port 443 --report-cycles 50'
Permission Note
TCP mode on privileged ports requires either sudo or the cap_net_raw capability set on the mtr-packet binary:
sudo setcap cap_net_raw+ep /usr/bin/mtr-packet
After setting the capability, TCP tests run without sudo.
Remember: If in doubt, search for the specific error message along with "Debian" and the version number. e.g. Debian 13 or point release if needed, Debian 13,1
This work was contributed by distro-nix on Debian User Forums on 2025-10-27 23:38:22
Further resources are available at https://www.debianfirstaid.org index.php?title=Category:HowTo index.php?title=Category:Networking index.php?title=Category:Full Paper