BLOG POSTS

MangoHost Blog / How to Use traceroute and mtr to Diagnose Network Issues

How to Use traceroute and mtr to Diagnose Network Issues

Network troubleshooting is one of those skills that separates junior admins from seasoned professionals, and two tools stand at the heart of effective network diagnostics: traceroute and mtr. While ping tells you if a destination is reachable, these tools reveal the complete path your packets take across the internet, showing you exactly where things go wrong when connectivity issues arise. Whether you’re dealing with intermittent timeouts, routing loops, or performance degradation, mastering these utilities will help you pinpoint problems faster and communicate more effectively with ISPs and hosting providers when escalating issues.

How Network Path Tracing Works

Both traceroute and mtr exploit the Time To Live (TTL) field in IP packets to map network paths. Every router decrements the TTL value by one, and when it reaches zero, the router sends back an ICMP “Time Exceeded” message to the source. By systematically sending packets with incrementing TTL values (starting from 1), these tools can identify each hop along the path to your destination.

The key difference lies in their approach: traceroute performs a single pass and exits, while mtr continuously monitors the path, providing real-time statistics about packet loss and latency at each hop. This makes traceroute ideal for quick diagnostics, while mtr excels at identifying intermittent issues that might not show up in a single snapshot.

Basic Traceroute Implementation

Most Unix-like systems come with traceroute pre-installed, though the specific implementation varies. Linux typically uses the traceroute command, while BSD systems (including macOS) use traceroute with slightly different default behavior.

# Basic traceroute to Google's DNS
traceroute 8.8.8.8

# Traceroute with specific options
traceroute -I -n 8.8.8.8

# IPv6 traceroute
traceroute6 2001:4860:4860::8888

# UDP traceroute to specific port
traceroute -p 53 8.8.8.8

The -I flag uses ICMP instead of UDP probes (useful when firewalls block UDP), while -n skips DNS resolution for faster results. Understanding these options is crucial because different networks may respond differently to various probe types.

Option	Purpose	Use Case
`-I`	Use ICMP probes	UDP blocked by firewalls
`-T`	Use TCP probes	Both UDP and ICMP filtered
`-n`	No DNS resolution	Faster execution, DNS issues
`-m`	Maximum hops	Limit trace depth
`-w`	Wait timeout	Adjust for slow networks

MTR: The Superior Alternative

MTR (originally “Matt’s traceroute”) combines traceroute and ping functionality into a single, more powerful tool. It provides continuous monitoring with statistical analysis, making it invaluable for diagnosing intermittent network issues.

# Install mtr on various systems
# Ubuntu/Debian
sudo apt-get install mtr

# CentOS/RHEL
sudo yum install mtr

# macOS with Homebrew
brew install mtr

# Basic mtr usage
sudo mtr google.com

# Report mode (non-interactive)
sudo mtr -r -c 10 8.8.8.8

# Extended report with additional statistics
sudo mtr -r -c 100 --report-wide 8.8.8.8

The real power of mtr becomes apparent when diagnosing intermittent issues. Unlike traceroute’s single snapshot, mtr’s continuous probing reveals patterns that would otherwise be invisible.

Real-World Troubleshooting Scenarios

Let’s examine some common scenarios where these tools prove invaluable:

Scenario 1: Intermittent Packet Loss

A web application experiences random timeouts. A quick traceroute shows nothing obvious, but running mtr for several minutes reveals the issue:

sudo mtr -r -c 300 problematic-server.com

HOST: server1                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- gateway                    0.0%   300    1.2   1.3   0.8   4.2   0.4
  2.|-- isp-router-1               0.0%   300    8.9   9.1   7.8  15.3   1.2
  3.|-- isp-router-2               0.0%   300   12.4  12.8  11.2  18.9   1.8
  4.|-- peer-exchange              2.3%   300   28.7  29.1  27.2  45.6   3.4
  5.|-- destination               2.3%   300   32.1  32.8  30.9  48.2   3.9

The 2.3% packet loss starting at hop 4 indicates an issue at the peering point, not with your server or application code.

Scenario 2: Routing Loops

Sometimes packets get stuck in routing loops, consuming bandwidth and causing timeouts:

traceroute problematic-destination.com

 1  gateway (192.168.1.1)  1.234 ms  1.123 ms  1.045 ms
 2  isp-router-1.example.com (10.1.1.1)  8.567 ms  8.234 ms  8.123 ms
 3  isp-router-2.example.com (10.1.2.1)  12.345 ms  12.234 ms  12.123 ms
 4  isp-router-3.example.com (10.1.3.1)  16.567 ms  16.234 ms  16.123 ms
 5  isp-router-2.example.com (10.1.2.1)  20.345 ms  20.234 ms  20.123 ms
 6  isp-router-3.example.com (10.1.3.1)  24.567 ms  24.234 ms  24.123 ms

The alternating pattern between routers 2 and 3 indicates a routing loop that needs ISP intervention.

Advanced Techniques and Best Practices

For serious network diagnostics, consider these advanced approaches:

Multiple probe types: Test with UDP, ICMP, and TCP probes to identify filtering behavior
Bidirectional testing: Run traces from both source and destination to identify asymmetric routing
Extended monitoring: Use mtr with large packet counts during problem periods
Geographic correlation: Cross-reference hop IP addresses with geographic databases to identify routing inefficiencies

# Comprehensive diagnostic script
#!/bin/bash
TARGET=$1
echo "=== UDP Traceroute ==="
traceroute -U $TARGET
echo "=== ICMP Traceroute ==="
traceroute -I $TARGET
echo "=== TCP Traceroute ==="
traceroute -T -p 80 $TARGET
echo "=== MTR Report ==="
mtr -r -c 50 $TARGET

Comparing Traceroute vs MTR

Feature	Traceroute	MTR
Execution Speed	Fast (single pass)	Slower (continuous)
Intermittent Issue Detection	Poor	Excellent
Statistical Analysis	None	Comprehensive
Memory Usage	Minimal	Moderate
Scripting Integration	Excellent	Good
Real-time Monitoring	No	Yes

Common Pitfalls and Troubleshooting

Network path tracing isn’t always straightforward. Here are common issues you’ll encounter:

ICMP filtering: Many routers deprioritize or block ICMP, causing false timeouts. Try different probe types.
Load balancers: Can cause inconsistent paths between packets, making traces appear chaotic.
Rate limiting: Some routers rate-limit ICMP responses, causing artificially high latencies in traces.
Firewall interference: Corporate firewalls often break traceroute functionality.

# Dealing with problematic traces
# Increase wait time for slow networks
traceroute -w 5 slow-destination.com

# Use smaller packet sizes for MTU issues
traceroute -s 1024 destination.com

# Force specific interface for multi-homed systems
traceroute -i eth0 destination.com

When working with hosting providers or ISPs, always include complete mtr reports rather than single traceroute outputs. The statistical data from extended mtr runs provides much more actionable information for network engineers.

Integration with Monitoring Systems

Both tools integrate well with monitoring infrastructure. Consider automating network path monitoring for critical services:

# Simple monitoring script for cron
#!/bin/bash
TARGETS=("8.8.8.8" "1.1.1.1" "your-critical-server.com")
REPORT_FILE="/var/log/network-monitoring/$(date +%Y%m%d_%H%M%S).report"

for target in "${TARGETS[@]}"; do
    echo "=== Testing $target ===" >> $REPORT_FILE
    mtr -r -c 20 $target >> $REPORT_FILE
    echo "" >> $REPORT_FILE
done

For deeper integration, tools like Nagios, Zabbix, and Prometheus can parse mtr output to generate alerts on packet loss or latency thresholds. The official mtr documentation provides additional details on output formats and advanced usage.

Understanding network paths becomes crucial when troubleshooting distributed systems, CDN performance, or multi-region deployments. These tools provide the visibility needed to distinguish between application issues and network problems, ultimately leading to faster resolution times and better service reliability.

This article incorporates information and material from various online sources. We acknowledge and appreciate the work of all original authors, publishers, and websites. While every effort has been made to appropriately credit the source material, any unintentional oversight or omission does not constitute a copyright infringement. All trademarks, logos, and images mentioned are the property of their respective owners. If you believe that any content used in this article infringes upon your copyright, please contact us immediately for review and prompt action.

This article is intended for informational and educational purposes only and does not infringe on the rights of the copyright owners. If any copyrighted material has been used without proper credit or in violation of copyright laws, it is unintentional and we will rectify it promptly upon notification. Please note that the republishing, redistribution, or reproduction of part or all of the contents in any form is prohibited without express written permission from the author and website owner. For permissions or further inquiries, please contact us.