Intro
When diagnosing latency or packet loss, many engineers turn to MTR (My Traceroute) — a hybrid of ping and traceroute that provides real-time visibility into network paths.
However, MTR can be misleading if its output is not interpreted correctly. High “loss” on intermediate hops doesn’t always mean there’s a problem — and often, it’s just
control-plane rate limiting, not real data loss.
This post explains how MTR works, what those scary “Loss%” numbers really mean, and how to distinguish between ICMP control-plane behavior and actual data-plane issues.
How MTR Works
By default, MTR sends ICMP Echo Request packets with incrementally increasing TTL (Time To Live) values.
Each router that decrements the TTL to zero replies with an ICMP Type 11 (Time Exceeded) message.
MTR records these replies to map the path, round-trip time, and variability to each hop.
- Each hop represents a router that handled your packet.
- “Loss%” shows how many of your ICMP probes that hop replied to.
- It does not directly measure loss of user/application traffic.
Control Plane vs. Data Plane
Routers have two logical planes:
- Data Plane — forwards packets at wire speed (your application traffic).
- Control Plane — handles routing protocols, management traffic, and ICMP.
MTR traffic (ICMP) is control-plane traffic. Many providers use Control Plane Policing (CoPP) to rate-limit ICMP and protect CPU resources.
Intermediate routers may silently drop or de-prioritize ICMP TTL-expired packets, creating the appearance of loss while data-plane traffic passes normally.
Real-World Example
Intermediate hops show high loss; the destination does not — this is classic ICMP rate limiting.
HOST: myrouter Loss% Snt Last Avg Best Wrst StDev 4.|-- 2001:978:2:42::e:1 50.0% 10 129.2 129.6 129.2 130.5 0.6 5.|-- be2846.ccr42.fra03.atlas.cogentco.com 80.0% 10 151.9 139.5 127.1 151.9 17.6 ... 21.|-- 2400:cb00:36:1008::a29e:40e2 0.0% 9 302.9 302.9 302.8 303.2 0.1
If there were real loss, it would typically persist to the final hop.
Since the destination shows 0% loss, the end-to-end path is healthy; the mid-path “loss” is control-plane rate limiting of ICMP.
MTR Transport Modes
Running MTR with Protocol Modes and Logging
You can combine MTR’s reporting flags (-bwrc) with TCP, UDP, or IPv6 testing modes to create repeatable, automatable diagnostics.
Below are examples showing how to use different protocols, save results to files, and even schedule continuous monitoring.
Base Command Recap
mtr -bwrc 250 example.com
This runs 250 ICMP probes per hop, displays both hostnames and IPs, formats the output in a wide layout, and exits with a summarized report.
Protocol Modes & Examples
| Purpose | Protocol / Mode | Example Command | Description |
|---|---|---|---|
| Default (ICMP) | ICMP Echo |
mtr -bwrc 250 8.8.8.8 |
Standard reachability test — behaves like a combined ping and traceroute. |
| TCP Mode (firewall/NAT testing) | TCP SYN |
mtr -T -p 443 -bwrc 250 zscaler.net |
Uses TCP SYN packets on port 443 (HTTPS). Ideal when ICMP is deprioritized or filtered. |
| UDP Mode (traceroute-style testing) | UDP Datagram |
mtr --udp -p 53 -bwrc 250 1.1.1.1 |
Sends UDP packets (default ports 33434–33534, or specify your own). Useful for DNS or VoIP path checks. |
| IPv6 Testing | IPv6 + TCP |
mtr -6 -T -p 443 -bwrc 250 google.com |
Forces IPv6 testing. Useful for validating IPv6 routing, tunnels, or dual-stack reachability. |
| MTU Path Testing | MTU Discovery |
mtr --mtu -bwrc 50 example.com |
Performs Path MTU Discovery to identify where fragmentation or PMTUD failures occur. |
Logging MTR Output
Using report mode (-r), you can redirect MTR output to a log file for later analysis or ticket documentation.
Example 1 – Save to a text file:
mtr -T -p 443 -bwrc 250 zscaler.net > mtr_zscaler_tcp443.txt
Example 2 – Append timestamped results:
mtr -T -p 443 -bwrc 250 zscaler.net >> /var/log/mtr_$(date +%Y%m%d_%H%M).log
Example 3 – Combine IPv6 and UDP mode:
mtr -6 --udp -p 53 -bwrc 250 dns.google > mtr_ipv6_udp_dns.log
Continuous Monitoring (Looped MTR Test)
For ongoing visibility, you can run MTR in a loop with timestamps to detect intermittent loss or latency changes:
while true; do echo "=== $(date) ===" >> /var/log/mtr_monitor.log mtr -T -p 443 -bwrc 250 zscaler.net >> /var/log/mtr_monitor.log sleep 300 done
This configuration:
- Adds a timestamp before each run.
- Appends results every 5 minutes.
- Helps track intermittent or time-based network issues.
Summary
-b– Show both hostnames and IPs.-w– Wide output for readability.-r– Report mode (run once and exit).-c 250– Send 250 probes per hop for statistical accuracy.- Add
-Tor--udpto emulate real application traffic. - Redirect output (
>or>>) for logging and automation.
Combining these options gives you a flexible, scriptable tool for end-to-end path analysis, regardless of protocol or filtering conditions.
Why MTR Isn’t “100% Correct” (Across the Public Internet)
Traversing multiple networks/ISPs means you encounter varied ICMP policies, filtering, and load balancing:
- Intermediate ICMP “loss” ≠ data-plane loss.
- Some routers never reply to ICMP.
- ECMP/load balancing can make hop stats inconsistent.
- Asymmetric routing can skew per-hop readings.
Treat MTR as a diagnostic indicator, not a source of absolute truth. Always validate with the destination and with flow-relevant probes.
How to Validate Real Packet Loss
- Continuous ping to the destination (look for consistent loss/jitter):
ping -c 300 {destination} - Test with TCP or UDP to mimic real traffic paths:
mtr -T -p 443 -bwrc 300 {destination} mtr --udp -bwrc 300 {destination} - Correlate with application metrics/logs (timeouts, retransmits, HTTP 5xx/504s).
- Check device telemetry (SNMP/Streaming Telemetry/NetFlow/IPFIX) on relevant interfaces for drops, errors, or congestion.
Genuine data-plane loss typically shows up in multiple tools and persists to the final hop, not just mid-path ICMP responses.
Key Takeaways
- MTR is powerful but ICMP-focused and therefore not bulletproof.
- Mid-path “Loss%” often reflects Control Plane Policing, not actual packet loss.
- Final hop health is the most important indicator for end-to-end reachability.
- Use TCP/UDP modes and application-layer checks to confirm real issues.