MTR (My Traceroute)

You run traceroute, see the path to your server, and assume you understand your network. But networks lie. Routes shift. Congestion comes and goes. Problems appear for thirty seconds and vanish before you can catch them.

A one-time traceroute is like checking your pulse once and declaring yourself healthy.

MTR (originally "Matt's Traceroute," now "My Traceroute") keeps watching. It runs traceroute continuously, building up statistics over time until patterns emerge that single measurements would miss entirely.

What MTR Actually Does

MTR sends packets to every hop along the path, over and over. Instead of one snapshot, you get a statistical picture: average latency, worst-case latency, packet loss percentage, consistency. Run it for five minutes while your connection feels sluggish, and the problem hop will reveal itself through accumulated evidence.

The simplest invocation:

mtr example.com

This opens a continuously updating display. Press 'q' when you've seen enough.

With root privileges, MTR can use multiple probe types:

sudo mtr example.com

Reading MTR Output

A typical display:

                             My traceroute  [v0.95]
hostname (192.168.1.100)                    2024-01-15T10:30:45-0500
                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. router.local                      0.0%    50    1.2   1.3   1.0   2.5   0.3
 2. 10.20.30.1                        0.0%    50    8.4   8.5   8.1   9.8   0.4
 3. ae-1.core1.nyc.example.net        0.0%    50   12.5  12.6  12.2  14.1   0.5
 4. ae-2.core2.nyc.example.net        0.0%    50   13.2  13.4  13.0  15.2   0.6
 5. ???                              100.0%   50    0.0   0.0   0.0   0.0   0.0
 6. example.com                        0.0%    50   22.3  22.5  22.1  24.8   0.7

Loss% is the metric that matters most. But here's the crucial insight:

Packet loss only indicates a real problem if it continues to the destination.

Look at hop 5—100% loss. Looks catastrophic. But hop 6 shows 0% loss. What's happening?

Hop 5 is a router that's too busy to answer MTR's questions but perfectly capable of forwarding your actual traffic. It's deprioritizing diagnostic packets, not dropping real data. This is common. Routers have better things to do than respond to every ICMP probe.

Now imagine hop 5 shows 50% loss, and hop 6 also shows 50% loss, and the destination shows 50% loss. That's real. Something at hop 5 is genuinely dropping half your packets.

StDev (standard deviation) reveals consistency. A hop with Avg=20ms and StDev=2ms is rock solid. A hop with Avg=20ms and StDev=50ms is wildly unpredictable—sometimes fast, sometimes crawling. Users feel that variability even if the average looks fine.

Wrst catches spikes. If a hop shows Best=13ms but Wrst=450ms, something caused a major delay at some point—congestion, route flapping, or processing hiccups.

The Commands That Matter

Generate a report (instead of interactive mode):

mtr -r -c 100 example.com

This sends 100 probes and outputs a final summary—perfect for pasting into support tickets or logging.

Show IP addresses only (skip DNS lookups):

mtr -n example.com

Faster, and sometimes DNS itself is the problem.

Show both hostnames and IPs:

mtr -b example.com

Use TCP instead of ICMP (when ICMP is blocked or filtered):

sudo mtr -T -P 443 example.com

This sends TCP SYN packets to port 443. The path TCP takes might differ from ICMP, and some networks filter ICMP entirely.

Faster probing:

mtr -i 0.5 example.com

Probe every half-second instead of every second.

Machine-readable output:

mtr --json -c 100 example.com > results.json

Real Troubleshooting Scenarios

Intermittent problems: Let MTR run during the times you experience issues. Five minutes of data reveals patterns that no single test could catch.

ISP support tickets: Generate a report while experiencing the problem:

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

"I'm seeing 15% packet loss starting at your edge router ae-2.core1" is harder to dismiss than "my Internet is slow."

Comparing IPv4 vs. IPv6:

mtr -4 example.com  # IPv4
mtr -6 example.com  # IPv6

Sometimes one protocol takes a completely different—and problematic—path.

Testing specific application paths:

sudo mtr -T -P 22 server.example.com   # SSH
sudo mtr -T -P 443 api.example.com     # HTTPS

The path to port 443 might differ from the path ICMP takes.

What MTR Can't Tell You

MTR shows the path your probes take. It doesn't show the return path, which might be completely different. Asymmetric routing is common—your packets go one way, responses come back another.

MTR also can't diagnose application-layer problems. If your web app is slow because of database queries, MTR will show a perfectly healthy network path.

And if the destination blocks all probe types, MTR has nothing to measure.

The Mental Model

Think of MTR as a stethoscope for network paths. Ping tells you whether the patient has a heartbeat. Traceroute shows you the circulatory system once. MTR listens continuously, building up a picture of how blood actually flows—where it moves freely, where it meets resistance, where it occasionally gets stuck.

The network reveals itself over time. MTR has the patience to wait.