How to diagnose packet loss with mtr tool
Learn how to use mtr to combine traceroute and ping, pinpointing the exact router or hop causing instability in corporate links.
Summary
- The mtr tool merges traceroute path tracking with continuous ping latency and loss metrics into a single interactive interface.
- Isolating failures at intermediate hops requires separating transient drops from actual network traffic congestion.
- Configuring sending intervals and disabling reverse DNS lookups dramatically speeds up troubleshooting in critical environments.
- Route monitoring complements deep traffic analysis utilities, such as inspecting packets with tcpdump .
- MTU adjustments and fragmented packets in tunnels often create similar symptoms that also require validation via WireGuard packet loss and MTU troubleshooting .
What is mtr and why it outperforms standard ping
When a corporate application suffers from slowness or intermittent drops, the initial reaction is usually to open a terminal and fire a basic ping command toward the remote server. Although ping confirms if the destination replies, it provides a myose perspective: it only tells whether the packet reached the end of the line, completely hiding what happens along the way. This is where mtr (My TraceRoute) comes in as an indispensable tool merging the route mapping of classic traceroute with the continuous statistical tests of ping.
In practice, mtr sends successive packets to each intermediate router (known as hops) between your origin and the final destination. Instead of measuring the path only once, it updates data in real time on the screen, calculating packet loss percentage, average latency, standard deviation, and worst response time for every stop on the route. This turns a technical guess into indisputable mathematical evidence when dealing with telecom carriers.
How to interpret mtr columns and metrics
When running mtr for the first time, you encounter a table full of numbers that might look confusing to anyone unaccustomed to networking. The first column displays the hop number and the IP address or router name your packet is traversing. Right beside it lies the packet loss metric (Loss %), revealing precisely where the data flow suffers degradation or drop due to congestion.
Subsequent columns show latency in milliseconds: SNT (packets sent), Last (last packet time), Avg (average), Best (best time), Wrst (worst time), and StDev (standard deviation). In practice, an intermediate hop showing high packet loss does not always indicate a real problem if subsequent hops show zero loss. This happens because many routers prioritize core traffic and throttle ICMP responses destined for diagnostic tools, which is completely normal internet infrastructure behavior.
How to install and run mtr in daily operations
Installing mtr is straightforward across virtually any Linux distribution or Unix-like system. In Debian or Ubuntu-based environments, for instance, the utility can be fetched directly from the standard operating system package manager using a single terminal command.
sudo apt update && sudo apt install mtr -yWith the tool installed, the most common execution to diagnose a sluggish corporate link involves supplying the destination address or domain experiencing performance issues. To prevent DNS name resolution delays from cluttering immediate data visualization, it is highly recommended to add the parameter that forces numeric IP display only.
mtr -n 8.8.8.8Isolating routing failures in corporate links
In mission-critical corporate links, discovering whether instability occurs at the local carrier's last mile or the international transit provider requires patience and an analytical method. While watching mtr run for a few minutes, pay special attention to the moment packet loss begins to appear and persists across all subsequent hops up to the destination. If hop number four lost 15% of its packets and that exact rate repeats from hop five onward, you have found the exact bottleneck.
Another common scenario involves intermittent drops caused by bandwidth saturation or physical port failures on carrier edge routers. When the issue is sporadic, letting mtr generate a text-mode report over an extended period helps gather thousands of statistical samples. To save this information into a file and attach it to a technical support ticket, simply run the command specifying your desired number of test cycles. To complement this implementation in production environments, see our related technical analyses on How to test Schottky diodes on a board with a multimeter and How to diagnose Wi-Fi network slowness with iperf3.
mtr --report --report-cycles 100 200.221.29.0 > network_report.txtFinal considerations on continuous network diagnostics
Mastering mtr transforms how engineers and system administrators handle complex network tickets and slowness complaints. Instead of accepting vague carrier support answers regarding internet fluctuations, you present consolidated data on latency and packet loss per hop. Combined with solid monitoring practices and deep inspection tools, mtr guarantees total visibility over your data link health.