What is MTR? Network testing explained
Author: Domeny.ForSale editorial team Published
In brief: MTR, short for My Traceroute, is a network diagnostic tool that combines packet route tracing with repeated measurements of latency and missing responses. On Linux, it helps determine whether a connection problem starts in the local network or further along the route to the server. The key rule when interpreting results: a single router failing to respond does not necessarily mean it is dropping traffic bound for the destination.
How MTR works and how it differs from ping
ping checks whether a specified host responds and measures how long it takes to receive a reply. traceroute shows the successive nodes along the route to the destination. MTR combines these functions: it discovers the route and repeatedly sends probes, updating the results for each node.
A node, also called a hop, is usually a router that forwards packets. MTR detects these devices by gradually increasing TTL, the packet’s hop limit. When that limit is reached, the router may send back a message that identifies its address.
The measurement shows the round-trip time for a probe and its reply, not just the delay between two adjacent routers. The return route may differ from the route to the destination, so the report does not always pinpoint where a fault occurs.
Installation and your first test on Linux
On Debian and Ubuntu, you can usually install the text-based version of the tool with these commands:
sudo apt update
sudo apt install mtr-tiny
Other distributions may use a different package name, often mtr. Check the distribution’s documentation or your package manager’s package search to confirm it.
To start an interactive test, supply an IP address or hostname:
mtr 1.1.1.1
The results will keep updating until you end the test, for example by pressing q. The address 1.1.1.1 is used here to check connectivity to a public destination; when diagnosing a particular service, focus on testing that service’s host.
A report with a set number of cycles is more convenient for saving and sharing results:
mtr -r -w -c 100 -n 1.1.1.1
The -r option enables report mode, -w uses a wider report format, -c 100 sets 100 measurement cycles, and -n disables conversion of IP addresses to hostnames. If the program reports that it lacks permission to send probes, check the package configuration; depending on the installation, you may need to run it with sudo.
How to read the report columns
Each row describes a detected node. The most useful columns are:
| Column | Meaning |
|---|---|
Loss% | Percentage of probes that received no response |
Snt | Number of probes sent |
Last | Response time of the most recent reply |
Avg | Average response time |
Best / Wrst | Shortest and longest response times |
StDev | A measure of variation in response times |
Times are usually given in milliseconds. A high Wrst value alongside a low average may indicate a single latency spike. A high StDev indicates inconsistent measurements, but does not by itself identify the cause.
Do not judge a connection based on just a few probes. Collect, for example, 100 cycles while the problem is occurring, then compare them with a measurement taken when the service is working properly.
When missing responses indicate a problem
Routers may limit diagnostic responses or give them a lower priority than forwarding traffic. As a result, Loss% for an intermediate node is not automatically a measure of user packet loss.
For example, the fourth node shows 70% response loss, but all subsequent nodes, including the destination, show 0%. This usually indicates that the fourth router is limiting its responses rather than dropping forwarded traffic. After all, the packets are reaching the devices further along the route.
It is more concerning when response loss starts at a particular point and also appears at subsequent nodes and the destination. This warrants further investigation, but does not prove that a particular router is at fault: different routes, filtering and the way probes are handled can affect the results.
Interpret latency in the same way. If one router responds slowly but subsequent routers respond quickly, its high response time does not prove that the entire connection is slow. Missing responses marked with ??? do not necessarily mean the route is broken either.
What to check when a website has problems
MTR’s default probes use ICMP, a protocol used for diagnostic messages, among other purposes. A network may handle them differently from website traffic. For problems with HTTPS, a TCP test on port 443 can be helpful:
mtr -r -w -c 100 -n --tcp -P 443 example.com
Replace example.com with the host of the service you are testing. This test still does not measure page loading, TLS negotiation or application performance. A normal MTR report therefore does not rule out problems with DNS, the web server or the database.
If the host has both IPv4 and IPv6 addresses, you can compare tests using the -4 and -6 options. When reporting a problem to an administrator, include the report, the measurement time and time zone, the destination tested, and a description of the symptoms. Before publishing the report, remove any addresses or names that reveal private infrastructure.
See also: What is ping?
Read also
