mtr Network Diagnostics

mtr cheatsheet — diagnose network latency and packet loss. mtr google.com, mtr --report --report-cycles 10, mtr --tcp. Combines ping and traceroute in one tool.

6 min read

What it is

mtr (My Traceroute) is a network diagnostic tool that combines the functionality of traceroute and ping to help diagnose network latency and packet loss issues by showing the network hops between your machine and a target host.

Installation

Linux (Debian/Ubuntu)

sudo apt update
sudo apt install mtr

Linux (Fedora/CentOS/RHEL)

sudo dnf install mtr
# or
sudo yum install mtr

macOS

brew install mtr

Windows

Windows does not have a native mtr installation. You can use the Windows Subsystem for Linux (WSL) to install and run mtr, or look for third-party ports if available.

Core Concepts

Hops: Each router or network device between your machine and the target host is considered a hop. mtr displays information for each hop.
Latency: The time it takes for a packet to travel from your machine to a specific hop and back. mtr shows average, best, and worst latency for each hop.
Packet Loss: The percentage of packets that are lost in transit between your machine and a specific hop. mtr displays this as Loss%.
Resets: When mtr loses contact with a hop, it displays ?? or ***. This can indicate packet loss or that the hop is configured not to respond to mtr’s probes.
AS Number (ASN): The Autonomous System Number identifies a network or group of networks. mtr can display the ASN for each hop, which is useful for understanding network routing.

Commands / Usage

Basic Usage

Diagnose latency to a website:
```
mtr google.com
```
Continuously diagnoses network connectivity to google.com, displaying hops, latency, and packet loss.
Diagnose latency to an IP address:
```
mtr 8.8.8.8
```
Continuously diagnoses network connectivity to the IP address 8.8.8.8.

Controlling Probes and Display

Set the number of probes per hop:
```
mtr --report-loops 10 google.com
```
Sends 10 probes to each hop before moving to the next. Useful for more detailed analysis.
Set the interval between probes:
```
mtr --interval 0.5 google.com
```
Sends probes every 0.5 seconds. Default is 1 second.
Display only IP addresses (no hostnames):
```
mtr --no-dns google.com
```
Skips DNS lookups for hop hostnames, showing only IP addresses. Faster and useful if DNS is slow.
Display AS numbers for hops:
```
mtr --show-as google.com
```
Includes the Autonomous System Number (ASN) for each hop in the output.
Limit the number of hops displayed:
```
mtr --max-ttl 15 google.com
```
Limits the trace to a maximum of 15 hops.
Turn off color output:
```
mtr --no-color google.com
```
Disables color formatting in the output, useful for plain text logs.

Reporting and Exiting

Generate a single report and exit:
```
mtr --report google.com
```
Runs mtr once, collects statistics, and prints a single report before exiting.
Generate an HTML report and exit:
```
mtr --html --report google.com > mtr-report.html
```
Generates an HTML report of the network diagnostics and saves it to mtr-report.html.
Generate a CSV report and exit:
```
mtr --csv --report google.com > mtr-report.csv
```
Generates a CSV report of the network diagnostics and saves it to mtr-report.csv.
Specify a filename for the report:
```
mtr --reportfile /tmp/network_test.txt --report google.com
```
Saves the report to /tmp/network_test.txt instead of standard output.
Set a timeout for probes:
```
mtr --timeout 5 google.com
```
Waits a maximum of 5 seconds for a response from each hop. Default is 10 seconds.
Set the number of initial round-trip time (RTT) probes:
```
mtr --mpls google.com
```
This flag is for MPLS (Multi-Protocol Label Switching) networks and is less commonly used for general diagnostics.

Advanced Options

Specify the network interface to use:
```
mtr --interface eth0 google.com
```
Forces mtr to use the eth0 network interface for sending probes.
Specify the port for TCP probes (if using TCP):
```
mtr --tcp --port 80 google.com
```
Uses TCP probes to port 80 instead of the default UDP. Useful for testing connectivity to specific services.
Specify the port for UDP probes:
```
mtr --udp --port 53 google.com
```
Explicitly uses UDP probes to port 53.

Common Patterns

Running a quick test and exiting:
```
mtr --report google.com
```
This is the most common way to get a snapshot of network performance without the continuous update.
Saving a report for later analysis:
```
mtr --report google.com > $(date +%Y-%m-%d_%H-%M-%S)_google_mtr.log
```
Runs mtr, saves the report to a timestamped file in the current directory.
Comparing latency to two different hosts:
```
# Open two terminals
# Terminal 1
mtr google.com

# Terminal 2
mtr cloudflare.com
```
Allows side-by-side comparison of network paths and performance to different destinations.
Checking for packet loss at a specific hop: If you see high packet loss (Loss%) at a particular hop, it indicates a potential problem in that part of the network. The goal is to see minimal packet loss and consistent latency across all hops.
Using mtr with grep to find issues:
```
mtr --report google.com | grep 'Loss%'
```
Filters the report to show only lines containing packet loss statistics.
Checking connectivity to a specific port using TCP:
```
mtr --tcp --port 443 example.com
```
Useful for diagnosing issues with HTTPS connections.

Gotchas

Firewalls: Some network devices or hosts might be configured to drop mtr’s UDP or ICMP probes, or not respond to them. This can manifest as ?? or *** even if the connection is otherwise working. Using the --tcp flag can sometimes bypass these issues if the target port is open.
DNS Resolution: By default, mtr attempts to resolve IP addresses of hops to hostnames. If DNS is slow or failing, this can make mtr appear slow or unresponsive. Use --no-dns if you suspect DNS issues or want faster output.
Dynamic Routing: The path packets take can change over time, especially on the internet. Running mtr multiple times might show slightly different routes or performance metrics.
mtr vs. traceroute: While similar, mtr provides continuous updates and statistics for each hop, whereas traceroute typically shows a single pass. mtr is generally preferred for interactive troubleshooting due to its real-time nature.
Interpreting ?? or ***: These symbols indicate that no response was received from a hop within the timeout period. It could mean the hop is down, heavily congested, or deliberately not responding. It doesn’t always mean the entire path is broken, but it’s a strong indicator of a problem at or beyond that hop.
Loss% at the last hop: If the final hop (your destination) shows packet loss, it means packets are being lost on their way to the destination or on their way back from the destination. If intermediate hops show loss but the final hop does not, it might suggest the intermediate hops are not responding to probes but the connection is still functional.