How to find route bottlenecks and high latency using MTR

Why your network fails and simple ping isn't enough

When an application suffers from slowness or intermittent drops, any operator's first instinct is to open the terminal and ping the destination server. In practice, traditional ping only shows whether the destination responds and what the average response time is, completely hiding what happens along the way. If your connection suffers from intermittent bottlenecks, often caused by physical interference or issues similar to what we discuss in how to diagnose packet loss and high latency, a simple test is simply not enough. To uncover what occurs during every step of the data journey, we need tools that peer directly into the routing infrastructure.

In network engineering, each intermediate router your packet traverses is called a hop. When a link suffers from congestion, packets begin competing for space in memory queues which, once capacity is exhausted, simply drop excess traffic. This drop generates dreaded packet loss, while fluctuations in queue wait times create jitter, which is the variance in delivery speed. If you have ever investigated deep issues like how to find disk and IOPS bottlenecks in Linux, you know a slow system often suffers from resource starvation; in networks, the principle is identical, but the starved resource is bandwidth or router control-plane processing capacity.

How to use MTR to map packet loss and jitter hop by hop

MTR (My Traceroute) is the ultimate tool for advanced diagnostics because it unites traceroute's path discovery with ping's continuous packet measurement. Instead of sending just three packets and freezing a snapshot of the moment, MTR sends probes continuously, letting you observe how network behavior changes over seconds. To start a practical investigation in your Linux or macOS terminal, run the command below replacing the address with your target:

mtr -r -c 100 8.8.8.8

In the output generated by this command, you will see a table divided into essential columns. The packet loss column (Loss %) reveals precisely which router is dropping traffic. If you notice that hop four shows 15% loss, but hop five and all subsequent hops show zero, it usually means that specific router merely prioritizes local traffic and drops low-priority ICMP test packets without affecting real traffic. However, if the loss persists and increases in final hops, the problem is real and lies within the route. To deepen this analysis for complex scenarios, it is worth understanding how to map packet loss and jitter in routes.

Interpreting extreme jitter and its impact on applications

Jitter is the silent poison of real-time applications like video calls, VoIP, and online gaming, degrading user experience even when packet loss rates appear low. When jitter reaches tens or hundreds of milliseconds, application playback buffers overflow, resulting in choppy audio or frozen video frames. In practice, this happens because packets arrive out of order or with irregular delays, forcing the receiver to discard data that arrived too late. To mitigate this type of anomaly in dedicated links, check the recommendations in how to fix packet loss and jitter.

To isolate whether jitter is generated by bandwidth bottlenecks or router hardware issues, we must examine the 'StDev' (standard deviation) column in MTR. High standard deviation means response times vary enormously between packets. If one packet responds in 10 milliseconds and the next in 120 milliseconds, the deviation will be massive, laying bare a saturated router queue or a network interface struggling with physical instability. In mission-critical environments, identifying this fluctuation prevents false software fault diagnoses when the real problem lies in the transport infrastructure.

Investigating TCP flags and packets with Wireshark

When MTR shows that the network layer is healthy but users still complain of slowness, we must drop down to the transport layer and analyze TCP headers via a Wireshark packet capture. The TCP protocol uses control flags to manage connections, and anomalous behaviors within them expose hidden problems. For example, a flood of packets with the RST (Reset) flag indicates that connections are being abruptly terminated by firewalls, NAT timeouts, or remote application faults. Similarly, frequent TCP segment retransmissions point out that sent data never received an acknowledgment (ACK) within the expected timeframe.

To capture and filter this traffic efficiently in the terminal before opening Wireshark's graphical interface, you can use tcpdump with a filter focused on retransmissions or handshake issues. Check out the practical command to isolate problematic packets on a network interface:

tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-rst|tcp-fin) != 0'

This command filters in real-time any packet containing termination or reset flags, letting you map the exact moment network sessions start dropping. Crossing this packet data with the previously obtained route analysis gives you a complete view of traffic, isolating whether the issue lies in an ISP router, a restrictive corporate firewall rule, or a systemic bottleneck on the destination server.

Final Thoughts

Advanced network diagnostics cease to be a mystery when we combine MTR's macroscopic view with Wireshark's microscopic inspection and correct interpretation of TCP flags. Understanding the difference between packet loss on intermediate routers and the real application impact of jitter ensures engineering time is spent fixing root causes rather than chasing empty assumptions. Mastering these tools turns any professional into a highly effective troubleshooter when faced with complex instability scenarios.

Maintaining a proactive monitoring routine and documenting baseline behavior for your infrastructure's critical routes drastically accelerates future incident resolution. By aligning route testing with detailed transport traffic analysis, your organization gains operational resilience and delivers a much more stable experience for end users and distributed systems.