~/ linuxnetwork.net

mtr – A Comprehensive Guide to the Network Diagnostic Tool

mtr (My Traceroute) is a powerful open-source network diagnostic tool that combines the functionality of ping (continuous latency/availability checks) and traceroute (path discovery) to provide real-time insights into network path quality. Unlike traditional tools, mtr continuously sends packets to each hop along a route, measuring metrics like packet loss, latency, and jitter. This makes it ideal for troubleshooting intermittent connectivity, high latency, or packet loss across complex network paths.

Table of Contents#

  1. What is mtr?
  2. Installation
  3. Basic Usage
  4. Understanding mtr Output
  5. Advanced Features and Options
  6. Common Use Cases
  7. Best Practices
  8. Limitations and Caveats
  9. References

1. What is mtr?#

mtr is a network diagnostic tool that traces the path to a target (e.g., a website, server, or IP) and continuously pings each intermediate hop (router, switch, etc.) along the way. It merges:

  • traceroute: Discovers the network path (via Time-to-Live (TTL) expiration).
  • ping: Continuously measures latency, packet loss, and jitter for each hop.

How It Works#

mtr sends ICMP (or TCP/UDP) echo requests to each hop in the route. For each hop, it tracks:

  • Packet loss (percentage of packets not returned).
  • Round-Trip Time (RTT) metrics (minimum, average, maximum, and standard deviation).

2. Installation#

Linux#

  • Debian/Ubuntu: sudo apt-get install mtr-tiny (lightweight) or mtr (full curses UI).
  • RHEL/CentOS: sudo yum install mtr (or sudo dnf install mtr for newer versions).
  • Arch Linux: sudo pacman -S mtr.

macOS#

  • Homebrew: brew install mtr (run with sudo mtr or configure permissions).
  • Source: Compile from the official mtr repository.

Windows#

mtr is not natively available, but WinMTR (a GUI port) provides similar functionality.

3. Basic Usage#

Command Syntax#

mtr [options] <target>

Example Commands#

  1. Basic Trace to a Domain (interactive mode):

    mtr google.com

    This runs mtr in real-time, updating hop metrics continuously.

  2. Limit Packets per Hop (collect more data):

    mtr -c 100 google.com  # Send 100 packets to each hop

  3. IPv4/IPv6 Testing (force protocol):

    • IPv4: mtr -4 google.com
    • IPv6: mtr -6 google.com (if the target supports IPv6).

  4. Quiet (Report) Mode (non-interactive, save output):

    mtr -r -c 100 google.com > mtr_report.txt

4. Understanding mtr Output#

In interactive mode, mtr displays a table with columns:

ColumnDescription
HostIP/hostname of the hop (router, switch, or destination).
Loss%Percentage of packets lost to this hop (0% = all packets returned).
SntNumber of packets sent to this hop.
LastRTT (ms) of the last packet sent.
AvgAverage RTT (ms) for all packets.
BestLowest (best) RTT (ms) observed.
WrstHighest (worst) RTT (ms) observed.
StDevStandard deviation of RTT (measures latency consistency).

Example Output (Simplified)#

Host                     Loss%   Snt   Last   Avg  Best  Wrst StDev
192.168.1.1               0.0%   100    1.2   1.5   0.9   3.2   0.5  # Local router
10.0.0.1                  0.0%   100    5.3   6.1   4.8   9.7   1.2  # ISP hop
203.0.113.1               2.0%   100   12.4  15.7  10.1  25.3   3.1  # Transit hop (2% loss)
74.125.142.100            0.0%   100   18.9  20.5  17.3  28.1   2.9  # Destination (Google)

5. Advanced Features and Options#

Key Flags#

  • -n (Numeric Mode): Disable DNS resolution (show IPs only):

    mtr -n google.com

  • -s <size> (Packet Size): Test with custom packet sizes (e.g., for MTU issues):

    mtr -s 1472 google.com  # 1472-byte packets (leaves 28 bytes for headers)

  • -P <port> (Port) + Protocol: Use TCP/UDP instead of ICMP (useful if ICMP is blocked):

    • TCP: mtr --tcp -P 80 google.com (send TCP SYN to port 80).
    • UDP: mtr --udp -P 53 google.com (send UDP to port 53, e.g., DNS).

6. Common Use Cases#

Troubleshooting Latency#

If an app (e.g., video conferencing, SSH) is slow, run mtr to the server. Look for hops with:

  • High Avg/Wrst latency.
  • High StDev (variable latency).

Identifying Packet Loss#

For intermittent connectivity, check Loss% across hops:

  • Loss at the first few hops? → Local network issue (e.g., Wi-Fi, faulty switch).
  • Loss at intermediate hops? → ISP/transit provider issue.

ISP/DC Diagnostics#

Share mtr reports with your ISP to prove network issues (e.g., loss at their hop).

Gaming/Real-Time Apps#

Run mtr to the game server:

  • High Loss% or Wrst latency at a hop near the server → Explains lag.

7. Best Practices#

When to Use mtr#

Use mtr when:

  • ping shows loss/latency, but traceroute (single path check) doesn’t reveal the issue.
  • Issues are intermittent (e.g., random disconnects).

Testing Duration#

For transient issues, run mtr for at least 100–1000 packets (-c 1000). Short tests (e.g., 10 packets) may miss problems.

Interpreting Loss Rates#

  • Loss at local hops (first 1–2 hops) → Home/office network problem (e.g., Wi-Fi).
  • Loss at intermediate hops (ISP, transit) → Provider-side issue.

8. Limitations and Caveats#

  • ICMP Blocking: Many routers/firewalls drop ICMP. A hop with 100% loss may just be blocking ICMP (not “down”). Use TCP/UDP mode to verify.
  • Protocol Differences: ICMP (default) behaves differently from TCP/UDP. A server may block TCP SYN (e.g., port 80) but accept ICMP.

9. References#

By mastering mtr, you can diagnose complex network issues that traditional tools miss. Share your mtr reports with support teams to accelerate troubleshooting!

2026-03