How to inspect network routes with the mtr command on Linux

What is the mtr command and why it outperforms classic ping

When an application suffers from unexpected slowness or sudden connection drops, the initial instinct of any technology professional is to run a basic Wi-Fi packet loss diagnostic or use the traditional ping utility. However, ping only tells you whether the final destination is responding and what the average round-trip time, known as latency, is. If there is an intermediate bottleneck at some router along the way, traditional ping remains completely blind. This is precisely where the mtr command comes in, short for My TraceRoute, acting as an intelligent fusion between traceroute and traditional ping.

In practice, this means that instead of firing a single static burst or an isolated packet, mtr sends packets continuously to each of the nodes or intermediate routers forming the path to the final destination. It updates statistics second by second in an interactive terminal table, showing loss percentage and delay at every network hop crystal clear. For anyone needing to troubleshoot infrastructure issues quickly, this real-time visibility replaces hours of guesswork with concrete, actionable data.

How to install and run mtr on your machine

Before diving into charts and packet loss percentages, we must ensure the tool is available on the operating system. On Debian and Ubuntu-based distributions, installation is straightforward and fast via the standard package manager, much like what we do when we need to clear the Apt cache to free disk space. To check if the package is already installed or add it to your working environment, simply use the terminal with administrative privileges.

Basic execution of the utility requires only that you provide the IP address or domain name of the target server you wish to inspect. Below are the fundamental commands to prepare and run the tool in your daily support or engineering routine:

sudo apt update && sudo apt install mtr-tiny
mtr google.com
mtr -r -c 100 8.8.8.8

In the command block above, the first line installs the lean version of mtr, ideal for remote servers without a graphical interface. The second line starts interactive real-time monitoring against Google's domain. The third line uses the -r flag (report mode) and -c 100 (to collect exactly one hundred packet cycles before displaying the consolidated result and exiting), which is excellent for generating logs and quick documentation reports.

Interpreting columns and packet loss metrics

When the interactive mtr interface opens in the terminal, you are greeted with a table full of columns whose names might look enigmatic at first glance. Each row represents a hop—meaning a physical router your data packet must pass through to reach the destination. Understanding each metric is vital to avoid jumping to conclusions about where the true connectivity bottleneck lies along the route.

The first column displays the hop number and the corresponding IP address or DNS name. The Loss% column shows the percentage of packets lost at that specific point, while SNT indicates how many packets have been sent so far. The Last, Avg, Best, and Worst columns reveal respectively the latency of the last sent packet, the historical average, the lowest recorded time, and the worst response time, measured in milliseconds.

Distinguishing real packet loss from ICMP rate limiting

One of the most common pitfalls when analyzing mtr output is the false alarm of packet loss on intermediate routers. Many companies and telecom operators configure their edge equipment to prioritize forwarding core customer traffic and heavily limit responses to diagnostic packets, such as ICMP or UDP protocols used by default in route tracing.

In practice, if you notice an intermediate hop showing a 100% loss rate while subsequent hops and the final destination show zero loss, it means that specific router merely ignored probe requests due to security policies or CPU load, without impacting real traffic. A genuine network problem only exists when packet loss manifests at one hop and persists across all subsequent hops until the end of the monitored route.

Advanced adjustments and useful complementary commands

Although mtr's default mode sends ICMP packets, situations arise where corporate firewalls completely block this type of traffic, preventing diagnosis. To bypass this barrier and test specific ports or use alternative protocols simulating legitimate web traffic, we can rely on advanced command-line parameters.

Using the TCP protocol or targeting common browsing ports often reveals true network behavior without interference from provider edge security rules. The following table summarizes the main customization flags that make mtr a Swiss Army knife for system administrators: To explore these architectural concepts further in production, see our related technical analysis on How to test electromechanical relays with a multimeter.

Final thoughts on continuous network diagnostics

Mastering tools like mtr radically transforms how we approach connectivity incidents, replacing the frustration of blind testing with surgical, second-by-second data-driven investigation. Knowing how to read hops, understanding the difference between ICMP false positives and actual packet losses, and leveraging alternative protocols ensures you can pinpoint exactly where infrastructure failed during a service outage.

Maintaining the habit of recording these reports and correlating metrics with bandwidth tools and hardware testing builds a robust network engineering foundation. Whether validating a dedicated link adjustment or speeding up technical support with your ISP, conscious and continuous use of mtr elevates any tech team's operational tier.