Test Connectivity With mtr Instead of ping+traceroute

Diagnosing network connectivity issues often begins with fundamental tools like ping and traceroute . While invaluable, their separate outputs and…

Diagnosing network connectivity issues often begins with fundamental tools like ping and traceroute. While invaluable, their separate outputs and stateless nature can complicate the identification of transient problems or differentiate between actual packet loss and ICMP rate-limiting. This article explores mtr (My Traceroute), a powerful network diagnostic tool that combines the functionality of ping and traceroute into a single, interactive, and comprehensive utility, providing real-time insights into network path performance and stability.

mtr works by sending ICMP ECHO requests (or TCP/UDP packets, depending on configuration) to a specified host and then displaying information about the route taken, round-trip times, and packet loss percentages at each hop along the path. This continuous stream of data makes it superior for pinpointing exactly where performance degradation or outages are occurring over time.

Understanding mtr Output

The core power of mtr lies in its consolidated output. When you run mtr in its default interactive mode, it continuously updates a display showing detailed statistics for each hop. Let's break down the typical columns:

• Host: The IP address and hostname (if resolvable) of the router at that hop.
• Loss%: The percentage of packets lost at this specific hop. This is a critical metric for identifying bottlenecks or overloaded routers.
• Snt: The number of packets sent to this hop.
• Last: The RTT (Round Trip Time) of the last packet sent to this hop, in milliseconds.
• Avg: The average RTT to this hop.
• Best: The shortest RTT observed to this hop.
• Wrst: The longest RTT observed to this hop.
• StDev: The standard deviation of RTTs to this hop, indicating the consistency of latency. High standard deviation suggests jitter or inconsistent network performance.

A common misconception when interpreting mtr output is that packet loss at an intermediate hop (e.g., Loss% > 0) necessarily indicates a problem with that specific router. Often, this is due to ICMP rate-limiting implemented by network devices to protect their control plane from DoS attacks. If packet loss is observed at an intermediate hop but does not persist at subsequent hops, and the final destination shows 0% loss, the intermediate loss is typically benign. The real signal for a problem is consistent packet loss that extends to the final destination or a significant increase in latency.

Basic Usage and Command-Line Flags

To start mtr in its interactive mode, simply provide the destination hostname or IP address:

mtr google.com

This will open a live updating window. You can press q to quit, d to toggle display modes (e.g., show/hide DNS resolution), or p to pause updates.

For automated diagnostics or post-mortem analysis, mtr offers a powerful report mode. The snippet from the prompt, mtr -rwbz example.com -c 100, is an excellent starting point:

• -r or --report: Activates report mode, where mtr runs for a specified number of cycles and then prints a summary report before exiting.
• -w or --wide: Displays full hostnames and IP addresses, preventing truncation in the output.
• -b or --no-dns: Disables DNS resolution. This can speed up the report generation, especially for many hops or unreliable DNS.
• -z or --aslookup: Displays AS (Autonomous System) numbers alongside hostnames/IPs. Useful for understanding network topology and peering relationships.
• -c 100 or --report-cycles 100: Specifies the number of packets (cycles) to send before generating the report. More cycles provide a statistically more reliable sample.

Here's an example of running a report with these flags:

mtr -rwbz -c 200 example.com > mtr_report_example.txt

This command will run 200 cycles, collect data, and save the detailed report to mtr_report_example.txt. Always allow a sufficient number of cycles (e.g., 100-200) to get meaningful statistics, especially for detecting intermittent issues.

Advanced Options and Protocols

mtr isn't limited to ICMP. It can use TCP or UDP for probes, which is crucial when ICMP is filtered on the network, a common practice for security reasons. For these scenarios, tcptraceroute is a separate utility, but mtr also supports TCP and UDP modes with the --tcp or --udp flags (requires root privileges on some systems or capabilities):

• --tcp or -T: Uses TCP SYN packets for probes instead of ICMP ECHO requests. By default, it targets port 80.
• --udp or -U: Uses UDP packets for probes. By default, it targets port 65535.
• -P <port> or --port <port>: Specifies the destination port for TCP or UDP probes. This is particularly useful for testing connectivity to specific services.

# Test TCP connectivity to port 443 (HTTPS)
sudo mtr -T -P 443 -c 100 --report example.com

# Test UDP connectivity to port 53 (DNS)
sudo mtr -U -P 53 -c 100 --report example.com

When encountering situations where ICMP is filtered, and you're diagnosing application-layer connectivity, using TCP probes to the service's specific port provides a more accurate representation of the application's path and potential issues. For instance, if you suspect a firewall blocking traffic to a web server, testing with mtr -T -P 80 or -P 443 is more relevant than ICMP.

Interpreting Loss and Latency

Accurately interpreting mtr output requires a nuanced understanding of packet loss and latency:

• End-to-End Loss: If the "Loss%" column shows a non-zero value for the final destination, this is a clear indication of a problem. It could be congestion, a misconfigured firewall, or a downed host.
• Intermediate Hop Loss (Benign): As mentioned, loss at an intermediate hop that doesn't propagate to the final destination is usually due to ICMP rate-limiting or deprioritization on the router's control plane. Focus on the final hop's statistics.
• Intermediate Hop Loss (Problematic): If an intermediate hop shows significant loss, and subsequent hops (including the destination) also show similar or increasing loss, then the issue likely lies with that intermediate hop or the link immediately after it.
• High Latency: A sudden, sustained jump in "Avg" or "Last" RTT at a particular hop, which then persists for all subsequent hops, indicates a bottleneck or congestion point at or immediately after that hop. High "StDev" (standard deviation) suggests inconsistent latency, often referred to as "jitter," which can severely impact real-time applications like VoIP or video conferencing.

Comparing mtr to ping and traceroute

Let's briefly summarize why mtr is often preferred:

Common Pitfalls and Troubleshooting

• Firewall Blocking mtr: If mtr (especially with ICMP) doesn't show any hops or times out completely, a firewall along the path or on the destination host might be blocking the probe packets. Try using TCP probes (-T -P <port>) to a common open port like 80, 443, or 22 to bypass ICMP-specific blocks.
• Misinterpreting Intermediate Loss: The most common mistake is assuming packet loss at an intermediate hop is always a network problem. Always check if the loss propagates to the final destination. If not, it's likely ICMP rate-limiting.
• Insufficient Cycles: Running mtr in report mode with too few cycles (e.g., -c 10) can give misleading statistics, especially for intermittent issues. Aim for at least 100-200 cycles for a robust report.
• No Reverse DNS: If hostnames aren't resolving (e.g., showing only IPs), this can be due to slow or non-existent reverse DNS entries. Use the -b flag to disable DNS lookup if it's slowing down your output or if you only need IP addresses.
• Permissions Issues: On Linux, running mtr with TCP or UDP probes (-T or -U) typically requires root privileges (sudo mtr ...) because it needs to craft raw sockets.
• VPN Interference: When connected to a VPN, mtr will show the path from your machine to the VPN endpoint, and then from the VPN endpoint to the target. Remember that the VPN tunnel itself adds an extra layer of encapsulation and potentially latency. Test both with and without the VPN if you suspect issues originating before the VPN gateway.