mtr: traceroute + ping in one tool

Why mtr instead of traceroute

A standard traceroute sends 3 probes per hop and prints one result. If packet loss is 50%, traceroute may miss it entirely.

mtr probes all hops continuously (once per second), accumulates statistics, and shows them in real time:

• loss% at each hop
• last RTT, average, best, worst, jitter
• number of probes sent

This is the first tool to reach for when users report lag or packet loss.

Basic usage

mtr example.com

Interactive mode: rows update every second. Press q to quit.

Typical output:

HOST: myhost                Loss%   Snt   Last   Avg  Best  Wrst

 1. _gateway                 0.0%    20    0.5   0.6   0.4   1.2

 2. 10.0.0.1                 0.0%    20    1.1   1.3   1.0   2.5

 3. provider-router          0.0%    20    5.2   5.4   5.1   8.0

 4. ???                     100.0%   20    0.0   0.0   0.0   0.0

 5. core1.isp.net            5.0%    20   12.1  12.5  11.8  15.0

 6. example.com             5.0%    20   25.3  25.5  24.9  28.0

Hop 4 shows no ICMP response (filtered), but traffic flows through it. The 5% loss on hops 5 and 6 is real. Hop 4 does not count.

How to read loss

• Loss increases gradually starting at one hop. That hop (or its uplink) is dropping packets.
• Loss appears and stays the same from a hop onward. The problem is at the first hop where loss appeared.
• Loss is 100% on a hop, but 0% on all subsequent hops. That is ICMP rate-limiting, not a real problem.

Options

-n - skip DNS resolution

mtr -n 8.8.8.8

Skips [[dns-resolution|reverse DNS]] for each hop. Faster output, less noise when DNS is slow.

-r - report mode (non-interactive)

mtr -r -c 100 example.com > report.txt

Sends 100 probes, prints the result once, and exits. Useful in scripts or when filing a bug report.

-c N - number of probes

Default is unlimited in interactive mode. With -c 10, mtr runs 10 rounds and stops.

-T - TCP instead of ICMP

mtr -T -P 443 example.com

Many firewalls block ICMP but allow TCP. -T -P 443 sends TCP SYN packets to port 443, giving a realistic picture for web traffic.

-u - UDP

mtr -u -P 53 example.com

Classic traceroute used UDP. Running mtr with -u does the same.

-i N - interval

mtr -i 0.5 example.com

Probes every 0.5 seconds for faster statistics accumulation.

-s N - packet size

mtr -s 1500 example.com

Sends 1500-byte packets (or larger) to test for MTU issues and fragmentation.

JSON output

mtr -j -r -c 10 example.com > mtr.json

Structured output. Useful for automated monitoring.

What mtr does not show

• The return path (asymmetric routing). mtr only sees the forward path. Loss may be on the return leg. Run mtr from the target host back to the source to check.
• L7 problems. If an application hangs during a TCP handshake rather than on pure latency, mtr will not show it.
• QoS or shaping. A provider may prioritize ICMP differently from TCP. In that case, mtr -T -P 443 will show a different picture.

Troubleshooting scenarios

• Loss from the first hop. The problem is on your machine or its uplink.
• Loss starting inside the ISP. File a complaint with the ISP network team. You cannot fix this yourself.
• Loss only on the return path. Run mtr -T to the target, then run mtr from the target host back to your machine.
• Loss 100% on hop X, but everything works. ICMP is filtered at that hop. Not a real packet loss.
• mtr does not start. Raw sockets require root. Either use setuid or run setcap cap_net_raw+ep $(which mtr).

Alternatives

• traceroute - the classic tool, no real-time stats
• pathping - the Windows equivalent of mtr
• tcptraceroute - traceroute via TCP SYN
• nexttrace - modern, fast, JSON output
• WhatsMyMTR - an online service when you have no console access