mtr

Network path diagnostics — combines traceroute and ping for continuous path analysis.

Basic Usage

Interactive mode — live-updating traceroute+ping hybrid (Ctrl+C to exit)
mtr 8.8.8.8
Non-interactive report — send 100 probes, print summary, exit
mtr --report 8.8.8.8
Report with wide hostnames — prevents truncation of long DNS names
mtr --report-wide 8.8.8.8
Specify probe count — fewer for quick checks, more for statistical significance
mtr --report -c 50 8.8.8.8

Output Control

No DNS resolution — faster output, avoids DNS-induced delays in the display
mtr -n 8.8.8.8
Wide report with no DNS — the fastest, cleanest output for troubleshooting
mtr -wnc 100 8.8.8.8
Show both IP addresses and hostnames
mtr -b 8.8.8.8
CSV output — pipe to awk or import into a spreadsheet
mtr --report --csv 8.8.8.8
JSON output — parseable by jq
mtr --report --json 8.8.8.8 | jq '.report.hubs[]'
Set the interval between probes — 0.5 seconds (requires root for < 1s)
sudo mtr --report -i 0.5 8.8.8.8

Protocol Modes

ICMP mode (default) — standard ping-based probes
mtr 8.8.8.8
TCP mode — bypasses firewalls that block ICMP, defaults to port 80
mtr --tcp 8.8.8.8
TCP mode on a specific port — test path to a specific service
mtr --tcp -P 443 8.8.8.8
UDP mode — useful when testing DNS or VPN paths
mtr --udp 8.8.8.8
UDP on a specific port — match the actual service being tested
mtr --udp -P 51820 vpn.example.com
Set packet size — test MTU path issues (1500 = standard Ethernet frame)
mtr --report -s 1472 8.8.8.8

Source Interface & Routing

Bind to a specific source IP — useful on multi-homed hosts
mtr --address 10.50.1.100 8.8.8.8
Force IPv4 only
mtr -4 8.8.8.8
Force IPv6 only
mtr -6 2001:4860:4860::8888
Set initial TTL — skip known near-side hops
mtr --first-ttl 5 8.8.8.8
Set max TTL — stop probing after N hops
mtr --max-ttl 15 8.8.8.8

Interpreting Results

Understanding the mtr output columns
Host           IP or hostname of each hop
Loss%          Packet loss at this hop (see interpretation below)
Snt            Probes sent
Last           Last RTT in ms
Avg            Average RTT in ms
Best           Minimum RTT in ms
Wrst           Worst RTT in ms
StDev          Standard deviation — high = inconsistent path
Interpreting Loss% — the most misunderstood column
Loss at an intermediate hop but NOT at the destination:
  → Likely ICMP rate limiting, NOT real loss. Routers deprioritize
    ICMP responses. This is normal and expected.

Loss at the FINAL hop:
  → Real packet loss. This is the number that matters.

Loss at an intermediate hop AND all subsequent hops:
  → Real loss. The problem is at that hop or just before it.

Consistent 100% loss at one hop, 0% everywhere else:
  → That router simply doesn't respond to TTL-expired probes.
    Not a problem.
Interpreting latency jumps
Sudden increase that persists at all subsequent hops:
  → Real latency increase. Likely a long geographic link
    or congested segment.

Spike at one hop, returns to normal at the next:
  → That router is slow to generate ICMP replies (CPU-bound).
    Not a forwarding problem.
Detecting asymmetric routing — different paths in and out
Symptoms: mtr in one direction shows different intermediate hops
than mtr from the remote end. Latency asymmetry between hops.

Test: Run mtr from BOTH ends simultaneously and compare.
If hop lists differ, routing is asymmetric. This is normal on
the internet but can mask the source of loss or latency.

mtr vs traceroute

When to use each tool
mtr:         Continuous probing, statistical analysis, detects
             intermittent loss. Use for diagnosing quality issues.

traceroute:  Single-shot path discovery. Use when you just need
             to know the route, not measure its quality.

Key difference: traceroute sends 3 probes per hop and exits.
mtr sends continuous probes and builds statistics. A 2% packet
loss at hop 7 is invisible to traceroute but clear in mtr.
Quick comparison run — save both outputs side by side
paste <(traceroute -n 8.8.8.8 2>&1) <(mtr -wnc 100 8.8.8.8 2>&1)

See Also