Master Network Troubleshooting with MTR: Installation, Commands, and Result Analysis

What Is MTR?

MTR (My Traceroute) combines the functions of ping and traceroute into a single program, providing a more convenient way to assess network connectivity and path characteristics. Unlike traditional traceroute, which defaults to UDP packets, MTR uses ICMP packets, which may be deprioritized on some routers, potentially yielding slightly lower performance measurements.

Installation

Windows : Download the BestTrace executable from https://cdn.ipip.net/17mon/besttrace.exe or obtain the portable WinMTR tool from the GitHub releases page https://github.com/oott123/WinMTR/releases.

Linux : apt install mtr for Debian/Ubuntu, or yum install mtr for RedHat/CentOS.

macOS : Search for “Best NetTools” in the App Store and install the client.

Android : Install TracePing from Google Play, or download it directly from https://dwz.cn/KCdNPH4c when Play Store access is unavailable.

Basic Usage

Running MTR against a target host displays the route and latency information in real time. For example, to trace the path to qq.com:

mtr qq.com

Key Parameters

-r

or --report: Generates a static report after sending a default of 10 ICMP packets. Without this flag, MTR runs continuously. -c: Specifies the number of packets to send (e.g., mtr -c 100 qq.com). -s or --packetsize: Sets the size of each ping packet (e.g., mtr -s 100 qq.com). -n: Disables hostname resolution, showing only IP addresses.

Understanding the Output Columns

IP : Destination IP address of the hop.

Loss : Packet loss percentage.

Snt : Number of packets sent.

Last : Latency of the most recent packet.

Avg : Average latency.

Best : Minimum latency observed.

Wrst : Maximum latency observed.

StDev : Standard deviation, indicating latency stability.

Result Analysis

When reviewing an MTR report, focus on two primary metrics: packet loss and latency.

Packet Loss

If any hop shows a non‑zero loss percentage, that hop may be problematic. However, many ISPs deliberately throttle ICMP traffic, causing apparent loss that disappears on subsequent hops. In such cases, the loss is likely due to rate limiting rather than a genuine network fault.

Conversely, if loss persists across multiple consecutive hops, the issue is probably a real network problem at that segment.

Latency

The Last, Avg, Best, and Wrst columns report round‑trip times in milliseconds. A sudden spike—e.g., a jump from 20 ms to 250 ms between two hops—often indicates a long‑distance link, misconfigured router, or congestion. High standard deviation ( StDev) suggests unstable latency, which can mask the true average delay.

Because the forward and return paths may differ, a bidirectional MTR test (running the command from both ends) is recommended for a complete picture.

Note: ICMP rate limiting can also increase apparent latency; checking the final hop’s timing helps differentiate this effect.

Practical Troubleshooting Steps

Run mtr -r target to obtain a concise report.

Inspect the Loss column; if loss appears only on a single hop and disappears afterward, consider ICMP throttling.

Examine Avg and StDev; high values indicate latency problems or instability.

Identify the responsible network segment (local ISP, intermediate carrier, or remote ISP) based on hop positions.

When necessary, provide the report to the relevant ISP for further investigation.

When Issues Are Temporary

Most routing anomalies resolve within a few hours as network operators address them. If you encounter persistent problems, contact your ISP with the MTR report and any relevant timestamps. In many cases, high latency is simply due to long physical distances (e.g., trans‑oceanic links) or peak‑hour congestion, not a fault in the routing equipment.

By mastering MTR installation, command options, and report interpretation, you can quickly pinpoint where packet loss or latency originates and take appropriate action—whether that means adjusting your own network configuration or escalating the issue to the service provider.