Traceroute & MTR | Essential Tools for Network Troubleshooting π


Traceroute is a widely used and trusted troubleshooting tool that provides visibility into the path that packets take across a network. Whether you're a beginner or an experienced network engineer, traceroute is an invaluable tool that can help diagnose connectivity issues, measure latency, and validate network routing. π
Supported by all major operating systems, including Linux and Windows, traceroute does not require a high-cost observability platform or complex software integrations. It is a lightweight yet powerful method for visualizing how data flows through the network. π―
Understanding the Basics of Traceroute π οΈππ
When you issue a ping, you learn only a few things:
Whether the destination is reachable.
The end-to-end latency.
If the target device is online.
However, ping does not provide insights into intermediate hops, routing behavior, or network congestion points. Traceroute, on the other hand, shows each hop along the way, revealing:
IP addresses and hostnames of intermediary devices.
Latency measurements between hops.
Possible packet loss or filtering at specific points in the network.
High latency on intermediate hops does not always mean congestionβmany networks prioritize transit traffic over ICMP responses. Firewalls, MPLS hops, or load balancing can also affect results. Traceroute remains useful for detecting routing changes, path validation, and analyzing geographical routing. π
Advanced Tracing with MTR πππ‘
MTR (My Traceroute) extends traceroute by continuously measuring the network path, providing real-time updates and statistical insights. Unlike a one-time traceroute snapshot, MTR allows you to:
Track routing changes dynamically.
Observe loss percentages over time.
Detect intermittent issues such as routing flaps or degraded paths.
A typical command for running MTR in Linux is:
mtr -r -c 100 fusionsdwan.co.za
This runs a report mode MTR with 100 packets, giving a statistical view of network performance over time. π
Why Bidirectional Testing Matters πππ‘
Network issues are not always symmetricβtraffic might take one path to the destination and a different path on the return. Relying on a single-direction traceroute can lead to incomplete conclusions. π¦
Key reasons why testing both directions is crucial:
Different ISPs may route traffic asymmetrically.
Firewalls or NAT policies could be impacting only one direction.
Load balancing may send outbound traffic over a different link than inbound.
Return path issues could be affecting application performance while outbound traffic appears normal.
To accurately diagnose performance problems, run traceroute from both ends of the communicationβfrom your location to the remote server and from the remote server back to you. π
Practical Use Cases for Traceroute & MTR πΌπ₯οΈπ
Traceroute and MTR are useful in various real-world scenarios, including:
1. Verifying ISP Routing Paths
If you've purchased a Direct Internet Access (DIA) circuit or multi-homed your network, you can use traceroute to ensure that traffic follows the expected route. ποΈ
2. Detecting Load Balancing Issues
Intermittent packet loss or increased latency? Running MTR can reveal inconsistent routes caused by link balancing issues, allowing you to isolate problematic links. βοΈ
3. Testing New SD-WAN Deployments
When deploying SD-WAN solutions, traceroute can validate that traffic is exiting through the correct gateways, following expected policies, and routing efficiently. π
4. Confirming Geographical Routing
Traceroute can help determine whether a circuit is routing through the intended Point of Presence (PoP) or if traffic is taking an unintended long-haul route. π
5. Diagnosing Application Performance Issues
If users report slowness, traceroute and MTR can confirm whether the issue is due to network latency, routing problems, or congestion at a specific provider. β‘
Best Practices for Interpreting Traceroute & MTR ππ―π οΈ
Always run tests multiple times to rule out transient issues.
Use MTR for longer-term monitoring instead of relying on a single traceroute snapshot.
Compare results from different ISPs or locations to get a broader view.
Be cautious with high-latency hopsβonly end-to-end latency should be used for performance assessment.
If traceroute results show gaps or missing hops, check for firewalls or routers that block ICMP responses.
Troubleshooting Checklist β ππ οΈ
Destination unreachable? Check for firewall rules blocking ICMP.
High latency at a specific hop? Consider whether that router prioritizes transit traffic over ICMP.
Packet loss detected? Verify if it persists across multiple runs and use MTR to confirm consistency.
Asymmetric routing suspected? Run tests in both directions and compare results.
Unexpected routing paths? Check ISP peering agreements and route announcements.
Limitations and Considerations π§β οΈπ
While traceroute and MTR are powerful tools, they should be used alongside other troubleshooting methods. Some key considerations:
ICMP filters: Some routers and firewalls do not respond to ICMP probes, leading to gaps in the traceroute output.
Load-balanced paths: Traceroute might not reveal all available paths if Equal-Cost Multipath (ECMP) routing is in use.
False positives: High latency on intermediate hops does not always indicate a problemβlook at end-to-end latency trends instead. π
Wrap π―ππ
Traceroute and MTR remain indispensable for network troubleshooting and performance validation. While they should not be solely relied upon for SLA verification, they provide critical insights into network behavior. By using these tools in combination with SD-WAN solutions, network engineers can validate routing paths, optimize performance, and ensure seamless connectivity. π
Whether you're troubleshooting an ISP issue, validating a network deployment, or just exploring the fascinating world of Internet routing, traceroute and MTR are your go-to tools! π
Subscribe to my newsletter
Read articles from Ronald Bartels directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by

Ronald Bartels
Ronald Bartels
Driving SD-WAN Adoption in South Africa