MTR: Advanced Network Diagnostics
MTR (My Traceroute) combines ping and traceroute in a single interactive tool. It's the standard for diagnosing network problems between two hosts: packet loss, high latency, asymmetric routing.
Installation
# Debian / Ubuntu
apt install mtr -y
# CentOS / AlmaLinux / Rocky
yum install mtr -y
# or
dnf install mtr -y
# Windows
# Download WinMTR from: https://sourceforge.net/projects/winmtr/
Basic Usage
# Interactive MTR to a host
mtr google.com
# MTR to an IP
mtr 8.8.8.8
# Non-interactive report (useful for pasting in tickets)
mtr --report google.com
mtr -r google.com
# Report with 100 packets (more accurate)
mtr --report --report-cycles 100 google.com
# Show IP only (without DNS reverse lookup: faster)
mtr --report --no-dns google.com
# Force IPv4 or IPv6
mtr -4 google.com
mtr -6 google.com
Interpreting the Output
My traceroute [v0.95]
Host Loss% Snt Last Avg Best Wrst StDev
| Column | Meaning |
|---|---|
| Loss% | Percentage of packets lost on that node |
| Snt | Packets sent |
| Last | Latency of the last packet (ms) |
| Avg | Average latency (ms): the most important |
| Best | Minimum latency recorded |
| Wrst | Maximum latency recorded |
| StDev | Standard deviation: indicates instability |
- router.deluxhost.net 0.0% 100 0.3 0.3 0.2 0.5 0.1
- 10.10.1.1 0.0% 100 1.2 1.1 0.9 2.1 0.2
- 185.1.2.3 0.0% 100 3.4 3.5 3.1 4.2 0.2
- ae1.cr1.fra1.example.net 0.0% 100 12.1 12.3 11.9 13.1 0.3
- ??? 100% 100 0.0 0.0 0.0 0.0 0.0
- 142.250.x.x 0.0% 100 22.4 22.6 22.1 24.0 0.4
- google.com 0.0% 100 23.1 23.2 22.8 24.5 0.4
How to Read the Results
Normal Packet Loss (Ignore It)
Many transit routers block ICMP (the protocol used by MTR) for security policy. If the next node shows 0% loss, there's no problem: the router simply doesn't respond to pings.
Always look at the node after the one with loss. If the next one is 0%, the loss on the previous node is artificial (ICMP rate limiting). If loss propagates to the destination, the problem is real.
Real Packet Loss
Loss starts at node 4 and propagates: the problem is on the link between node 3 and node 4. Report to your provider.
High Latency on a Single Node
Node 4 responds with 450ms but node 5 is back to 22ms: node 4 has only ICMP rate limiting, there's no real problem. The effective latency is that of the destination.
Real High Latency Problem
High latency propagates to the destination: real problem starting at node 4.
- ??? 100% 100 0.0 0.0 0.0 0.0 0.0
- ae1.cr1.fra1.example.net 15.0% 100 45.2 44.8 12.1 90.1 18.3
- 142.250.x.x 15.0% 100 46.1 45.0 12.3 91.0 18.1
- google.com 15.0% 100 46.5 45.2 12.5 92.0 18.4
- ae1.example.net 0.0% 100 450.2 448.1 440.0 460.0 4.2
- 142.250.x.x 0.0% 100 22.4 22.6 22.1 24.0 0.4
- ae1.example.net 0.0% 100 450.2 448.1 440.0 460.0 4.2
- 142.250.x.x 0.0% 100 460.1 459.3 449.0 470.0 4.1
- google.com 0.0% 100 461.5 460.2 450.0 471.0 4.3
Bidirectional MTR (For Support Tickets)
Network problems are often asymmetric: outbound works but inbound doesn't (or vice versa). For complete diagnosis, you need two MTR runs: one from your PC to the server, and one from the server to your IP.
# From the server to your IP (example)
mtr --report --report-cycles 100 --no-dns YOUR_PUBLIC_IP
To find your public IP:
curl ifconfig.me
Common Usage Examples
Diagnose to DeluxHost Gateway
# Replace with your VPS IP
mtr --report --report-cycles 50 --no-dns YOUR_VPS_IP
Verify Routing to a Specific Datacenter
# Check the path to an IP in a specific DC
mtr --report --tcp --port 80 --no-dns DESTINATION_IP
MTR with TCP Instead of ICMP
Useful if ICMP is blocked (e.g., to a web server):
mtr --tcp --port 443 google.com
mtr --tcp --port 80 tuodominio.com
When to Attach MTR to a Support Ticket
Always attach MTR output when reporting:
Always provide both directions (from your PC to server AND from server to your PC) to allow complete diagnosis.
- High lag/latency on the server
- Packet loss during connections
- Intermittent disconnections
- Anomalous routing to certain regions
Related articles
