mtr vs traceroute

Traceroute and mtr are both command-line tools for diagnosing network path issues. Traceroute gives you a one-time snapshot of the route your packets take. mtr does the same thing but keeps probing, building up statistics on packet loss, latency and jitter over time. This post covers how each tool works, how to read the output, and when to use which.

How traceroute works

Traceroute uses the Time-to-Live (TTL) field in IP packet headers. It sends a packet with TTL set to 1. The first router decrements the TTL to zero, drops the packet, and sends back an ICMP "Time Exceeded" message. Traceroute records the router's IP and the round-trip time, then sends another packet with TTL set to 2, and so on until the packet reaches the destination or hits the maximum hop limit (30 by default, adjustable with -m).

By default, traceroute sends three probes per hop, giving you three latency readings. The protocols differ by OS:

• Windows: The tracert command sends ICMP Echo Requests.
• Linux/macOS: The traceroute command sends UDP datagrams (ports 33434-33534). Use -I for ICMP or -T for TCP if UDP is blocked.

Adding the -n flag skips reverse DNS lookups, which speeds things up noticeably on paths with many hops.

How mtr works

mtr (My Traceroute) uses the same TTL-based path discovery as traceroute, but it keeps sending probes, typically one per second. Instead of three data points per hop, you get running statistics: packet loss percentage, average latency, best and worst response times, and standard deviation (jitter).

mtr supports ICMP (default), UDP, and TCP SYN probes. TCP mode is useful when firewalls block ICMP, or when you want to test a specific application port:

mtr --tcp --port 443 example.com

For a non-interactive report you can share with a support team, use report mode:

mtr --report --report-cycles 100 example.com

This runs 100 probes and prints a summary. You can also set custom packet sizes with --psize to test for MTU or fragmentation issues.

mtr runs natively on Linux and macOS. Windows users can use WinMTR for a GUI equivalent.

Key differences

The practical difference comes down to intermittent problems. A single traceroute can easily miss a router that drops 2% of packets or a hop with 15ms of jitter. mtr catches these because it keeps measuring.

Reading the output

The most common mistake when reading traceroute or mtr output is assuming that a problematic-looking intermediate hop means there's a real problem. It usually doesn't.

Asterisks (*) in traceroute mean the router didn't respond to the probe. Many routers are configured to ignore or rate-limit ICMP. If the hops after it respond normally, the path is fine.

Packet loss at a single hop in mtr follows the same logic. If hop 5 shows 20% loss but the final destination shows 0%, that router is just deprioritising probe responses. Real packet loss shows up as a pattern: loss appears at one hop and persists through every subsequent hop to the destination.

Latency jumps between hops are normal and expected. A jump from 10ms to 80ms usually means the packet crossed an ocean or a long land route. Only worry about latency if it's unusually high for the distance (under 5ms within a metro area, tens of milliseconds cross-country, 80-150ms transoceanic) or if the final destination latency is unacceptable.

StDev (jitter) in mtr is worth paying attention to. Values above 10ms at any hop can cause problems for VoIP, video calls, and gaming. If you see high jitter, run at least 100 cycles to confirm it's a sustained pattern and not a brief spike.

When to use each tool

Use traceroute when you need a quick answer: is the destination reachable, and if not, where does the path break? It's the right starting point for outages and for verifying basic routing.

Use mtr when the problem is intermittent or performance-related. Users reporting occasional disconnections, VoIP quality issues, or latency spikes need mtr's continuous data. Run at least 50-100 cycles for reliable statistics.

For thorough diagnosis, run mtr in both directions: from your machine to the server, and from the server back to your IP. Internet routing is asymmetric, so the return path can have completely different characteristics. If you only test one direction, you might miss where the problem actually is.

If you're running into issues with your dedicated server or VPS, FDC Servers support teams accept mtr reports as standard diagnostic evidence for network escalations.