Network packet loss? How to use mtr to find the issue

What is mtr and why it outperforms traditional ping

When a corporate application starts experiencing slowness or intermittent drops, the first instinct of many network administrators is to open the terminal and fire a simple ping command at the destination server. In practice, traditional ping only confirms whether the remote host is responding and what the average delay is, but it remains completely blind to what happens along the way. This is precisely where mtr comes in, a time-tested tool that combines the features of traceroute — which maps the path taken by data — with ping — which measures response time and stability at each stop.

In simple terms, every packet of data you send across the internet needs to hop through several intermediate routers until reaching its final destination, much like toll booths on an interstate highway. If one of those toll booths starts experiencing mechanical failures, the entire traffic suffers, but a superficial test can mask the real origin of the bottleneck. mtr sends a continuous stream of packets to the destination, dynamically adjusting each packet's time-to-live to force every router along the path to identify itself, displaying a real-time table with valuable statistics for each hop.

To better understand the impact of bottlenecks on infrastructure, it is worth correlating this scenario with detailed traffic analyses, such as those we perform when investigating WAN connection failures with traceroute in edge environments. While traditional traceroute takes only a static snapshot of the journey at a given moment, mtr records a continuous film, updating packet loss rates and statistical delay second by second. This continuous view is the great differentiator for separating a momentary issue from a persistent structural failure in a telecommunications operator's equipment.

How to install and run mtr on your operating system

Using mtr is quite straightforward on Unix-based systems like Linux and macOS, being available in the vast majority of official package managers for modern distributions. Before starting any deep diagnosis on your corporate network, it is advisable to ensure the system has its packages and network cache properly updated, fundamental practices we also cover when clearing the APT cache on Ubuntu via terminal to avoid operational noise caused by corrupted packages. To install mtr on Debian or Ubuntu-based distributions, simply run the standard package manager with administrative privileges.

The basic command to launch the tool consists of invoking the utility followed by the destination IP address or domain you want to test, whether it is a cloud server or the company's headquarters. However, by default, mtr uses ICMP packets to perform tests, which can cause some corporate routers along the path to prioritize regular traffic and ignore or limit diagnostic responses, generating false impressions of packet loss. To bypass this behavior and simulate real web traffic, you can trigger TCP mode using port 80 or 443.

To run mtr using TCP packets directed at the standard web port, open your terminal and use the following command:

sudo mtr --tcp -P 443 marciocunha.net

This command instructs the system to send packets formatted specifically for secure connections, forcing intermediate routers to treat the test with the same priority given to legitimate browsing traffic. If you need to stop data collection and generate a static textual report after collecting a safe amount of samples, simply append the report parameter to the initial terminal command.

Interpreting mtr columns and metrics in practice

As soon as mtr runs, an interactive interface loads on the terminal screen, displaying columns full of numbers that may look intimidatingly complex at first glance. In practice, each row represents a physical or logical hop in the network, starting at your own local router and advancing hop by hop until the final destination. The column identified as Loss% (percentage loss) is the most critical metric for diagnosis, as it reveals exactly how many packets sent at that specific hop failed to return.

Another vital indicator is the Sstdev or Jitter column, which measures the variation in packet delay time, revealing whether the connection is stable or suffering from abrupt millisecond fluctuations. An essential concept every network analyst must master is that not every packet loss shown in the middle of the route implies a real problem. If an intermediate hop shows a high percentage of loss, but the next hop and all subsequent ones show zero loss to the destination, it simply means that specific router is configured to prioritize client data forwarding and discards diagnostic replies to save its own internal processing.

On the other hand, if packet loss starts appearing at a certain hop and persists across all subsequent hops until the end of the line, you have found the exact culprit for the performance issue. This surgical clarity saves days of unproductive discussions with technical support teams and telecom operators, allowing you to point with irrefutable evidence to the exact equipment where traffic is being lost or corrupted.

Common pitfalls and best practices in corporate diagnostics

Diagnosing corporate networks requires patience and a deep understanding of how internet protocols handle security policies and load balancing. A classic trap when using mtr occurs when the load balancer halfway through dynamically alters packet routing between different hops, causing the report to display ghost hops or artificial latency oscillations. To mitigate this effect and obtain a realistic overview, it is recommended to let mtr run for at least five to ten minutes, accumulating hundreds of statistical samples before drawing any definitive conclusion.

Additionally, remember that modern networks often operate with asymmetric paths, meaning data leaving your company travels through a completely different route than the one used by response packets sent by the remote server. This asymmetry can confuse route-based diagnostic tools if the operator is not paying attention to the particularities of BGP routing used by major global transit providers. Maintaining regular logs and comparing reports obtained during peak hours with off-peak hours is key to separating genuine bandwidth congestion from hardware failures.

In environments where packet loss directly interferes with the experience of critical services, combining mtr with other deep packet inspection tools ensures a holistic view of the infrastructure. Mastering these techniques elevates the IT team's operational level, turning vague assumptions into precise diagnoses backed by solid statistical data and ready for definitive network incident resolution.

Final thoughts on mtr efficiency

The consistent use of mtr represents a natural evolution in how system administrators and network engineers handle daily connectivity incidents. By eliminating guesswork and providing a clear, statistical visualization of each network hop, the tool drastically reduces the mean time to resolution in complex corporate environments. Mastering this technique ensures not only the stability of essential services but also the peace of mind of operating a transparent, resilient infrastructure fully under technical control.

Investing time in the correct interpretation of route reports and understanding the nuances of protocols like ICMP and TCP strengthens the organization's operational resilience against unexpected bottlenecks. Whether validating traffic delivery in remote data centers or troubleshooting instabilities in local connections, mtr remains one of the most reliable pillars in any serious technology professional's arsenal.