How to diagnose packet loss and routing issues with mtr

What is the mtr command and why it beats traditional ping

When a corporate application begins suffering from intermittent slowness or connection drops, the first tool we usually open in the Linux terminal is good old ping. However, traditional ping only shows whether the final destination is responding and what the average round-trip time, known as latency, is. It is blind to what happens along the way—namely, which intermediate routers the data passes through before reaching the destination. This is precisely where mtr comes in, combining the best of both worlds by running continuous tests while tracking every single hop along the route.

In practice, mtr executes constant diagnostics and updates the on-screen statistics every second, allowing you to observe network behavior over time. While investigating infrastructure problems or checking operational bottlenecks, it is very common to cross-reference connectivity data with physical hardware health, a process similar to how we diagnose CPU and temperature bottlenecks on Linux via SSH. Understanding this end-to-end dynamic prevents you from blaming the wrong server for issues that actually lie somewhere along the path.

How to install and run basic mtr readings in the terminal

Before applying any advanced parameters, we need to ensure the tool is installed on the operating system. On Debian and Ubuntu-based distributions, installation is quickly done via the default package manager with administrative privileges. The basic command simply requires you to provide the IP address or domain name you wish to test, immediately starting real-time packet capture in your terminal window.

sudo apt update && sudo apt install mtr -y
mtr google.com

Executing this line displays an interactive table filling up line by line. Each line represents a router or hop that the data packet traversed. The columns display vital information such as packet loss percentage, number of packets sent, current response time, and the average and worst recorded times. If you notice local traffic anomalies before it even leaves the interface, it is worth checking out how to monitor Linux network traffic in real time with bpfTOP to isolate whether the issue is internal or external.

How to differentiate real packet loss from false positives at hops

One of the most common mistakes made by beginner system administrators is panicking when seeing a high packet loss rate at an intermediate hop during mtr execution. Most of the time, this is a harmless false positive. Modern internet routers are designed to prioritize fast data forwarding and often limit the processing of diagnostic packets, such as the ICMP protocol, which serves to send control and error messages across the network.

In practice, if an intermediate hop shows 100% packet loss but the subsequent hop and final destination show zero loss, it simply means that specific router refused to answer our test requests while continuing to forward regular packets normally. To be absolutely sure a failure is real, you must check whether packet loss persists across all subsequent hops up to the final destination. If the loss starts at one point and continues to the end, you have a real bottleneck requiring urgent intervention.

How to use TCP packets to bypass firewall blocks

Many modern corporate networks and internet service providers apply strict firewall rules that block or severely limit ICMP traffic, which is the standard protocol used by mtr and traditional traceroute. When this happens, reports remain incomplete or filled with asterisks, making route analysis extremely difficult. To solve this problem, we can instruct mtr to use the TCP or UDP protocol instead of standard ICMP, forcing the traffic to look like regular web access.

The command below demonstrates how to perform this variation using port 443, which is the default port for encrypted HTTPS web traffic and is rarely blocked by corporate security policies. Much like analyzing complex data flows when we monitor HTTP/3 and QUIC traffic in Linux terminal, forcing mtr to use specific ports reveals how your actual application traffic behaves along the route.

sudo mtr --tcp --port 443 8.8.8.8

This approach is extremely useful for simulating real client connections accessing APIs or cloud servers. If the route fails only when using the TCP protocol on specific ports, we know there is a security device midway filtering packets based on deep packet inspection rules or rate-limiting policies.

How to export reports and automate route monitoring

The interactive mtr interface is excellent for quick, ad-hoc diagnostics, but in production environments, we often need to record network behavior over several hours to present reports to telecom operators. To meet this need, mtr features a report mode that disables visual interactivity, sends a fixed number of packets, and generates a clean text summary ready to be saved into log files.

sudo mtr --report --report-cycles 100 1.1.1.1 > network_report.txt

With this command, the system sends exactly one hundred test cycles to the specified IP address and directs the output to a text file. This allows you to document intermittent performance drops and hold carriers accountable to service level agreements using irrefutable technical evidence. Mastering these techniques drastically boosts the engineering team's responsiveness during critical connectivity incidents.

Final considerations on advanced network diagnostics

Mastering the mtr command transforms how engineers and administrators handle connectivity incidents, replacing guesswork with clear, objective data. Knowing how to separate false positives from real packet losses saves precious troubleshooting hours and prevents unnecessary friction with service providers.

Integrating this testing routine into your daily arsenal, combining it with deep traffic analysis and hardware monitoring, ensures a much more resilient, stable network infrastructure ready to support modern corporate system demands without unpleasant surprises.