What is Traceroute and MTR?

Every packet crossing the Internet passes through routers. Traceroute and MTR reveal this chain. They map the route from your computer to a remote host and measure each step. Engineers use them to find slowdowns, loops, and packet loss.

What Are Traceroute and MTR?

Available on virtually all operating systems (it's tracert on Windows), Traceroute sends test packets to a target and records each intermediate router, or hop, plus round-trip time. It maps the path packets take from your device to a destination. The result is a static snapshot.

MTR, short for My Traceroute, combines traceroute's path discovery with continuous monitoring similar to ping. Once it discovers the path, it keeps sending probes to every hop continuously. It is maintained in an open-source repository, and its behavior is fully documented in the system manual page. While traceroute gives a snapshot, MTR provides a live dashboard of latency, packet loss, and jitter across the entire route.

Both tools rely on core concepts. A hop is any router that forwards traffic. A probe is the test packet. TTL, or Time to Live, is an IP header field that counts down. Each router decrements TTL by one. When it hits zero, the router drops the packet and usually returns an ICMP "Time Exceeded" message. That reply reveals the router.

How Traceroute and MTR Work

The mechanics are simple. Traceroute sets the initial TTL to 1. The first router decrements it to 0 and returns an error. Traceroute records that address and timing. It then sends probes with TTL 2, exposing the second hop. The process repeats, incrementing by one each round, until the probes reach the destination or a maximum.

After MTR maps the path with the same TTL method, it switches to parallel mode. It sends probes to all hops at once and updates statistics in real time. Most implementations default to ICMP, though either tool can use UDP or TCP. This matters because many firewalls block ICMP but allow TCP on common ports.

Not every probe gets a reply. When a hop doesn't respond within the timeout, the output shows an asterisk. That can mean the router is down, it's filtering ICMP, or it's too busy. Reading these gaps correctly is essential.

Traceroute vs. MTR

Because traceroute runs once and exits, it captures only a single moment. MTR stays open, collecting dozens or hundreds of samples. That persistence catches intermittent issues a single traceroute would miss entirely.

While traceroute shows isolated probe times, MTR aggregates data across many probes. It calculates loss percentage, average latency, best and worst cases, and standard deviation. This depth makes it easier to spot a noisy link or an overloaded peering router.

Beyond statistics, MTR probes every hop simultaneously once the path is known, whereas traceroute often waits for each TTL round. Results therefore appear faster, this parallelism makes MTR considerably faster for full results. There's a subtle routing caveat too. Because MTR uses consistent ICMP probes, it tends to stay on one path even on networks using equal-cost multipath. Traceroute with varying UDP ports can expose multiple parallel paths.

Reading the Output

From a Linux terminal, a basic traceroute invocation requires only the target:

traceroute -n example.com

Typical output looks like this:

traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets
 1  192.168.1.1  1.2 ms  1.1 ms  1.3 ms
 2  10.10.0.1  5.4 ms  5.2 ms  5.5 ms
 3  * * *
 4  93.184.216.34  15.1 ms  14.9 ms  15.2 ms

Using the -n flag skips DNS lookups, which makes the test faster and the output cleaner.

When you need a continuous view, MTR in report mode generates a parseable summary after a set number of cycles:

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

Some platforms, including the Dig Trace online traceroute tool and MTR Tool render continuous results in a compressed table.

Host                                                                 Loss% Drop Rcv  Avg  StDev  Javg 
 1. AS36352 _gateway (23.94.20.53)                                    0.0%    0  10  1.7    0.8   0.6

Columns like Loss%, Avg, and StDev summarize hop health at a glance. The AS number prefix identifies the network that owns the router.

Common Pitfalls

One common mistake is assuming loss on an intermediate hop means the network is broken. In reality, routers often rate-limit ICMP responses. If MTR shows 10% loss at hop 3 but 0% at the destination, packets are likely getting through fine. The missing replies are control-plane artifacts, not data-plane failures.

Results can also be skewed by asymmetric routing. These tools measure the forward path, but the reply may take a different route back. A delay might exist on the return journey. For a fuller picture, engineers often run tests from both ends or supplement with tcpdump and iperf.

Other factors complicate output too. Firewalls, load balancers, and anycast addresses affect behavior. Some hops will never respond no matter how many probes you send. That's normal. The goal is to identify consistent patterns, not to eliminate every asterisk.

When to Use Each Tool

During initial troubleshooting, a quick traceroute is usually enough. It answers "which path are my packets taking right now?" in seconds. If you're confirming a new route or verifying that a specific upstream carrier is in use, the snapshot is exactly what you need.

Switch to MTR when the problem is intermittent. If users report sporadic latency or occasional drops, a single traceroute will likely look clean. MTR's continuous sampling reveals transient packet loss and jitter that appear only under load or during peak hours.

In operational environments, MTR report mode fits neatly into monitoring scripts, recommended for integrating these reports into logging pipelines. You can schedule periodic tests, log the output, and alert when loss or latency crosses a threshold. Combining these results with an understanding of how DNS resolves names to addresses gives you a solid foundation for end-to-end connectivity troubleshooting.

Neither tool fixes a network on its own. They're windows into the routing layer. Used correctly, they narrow a problem from "the Internet is slow" to "hop 7 on AS6453 shows 30% loss between 14:00 and 14:15 UTC." That specificity saves time, whether you're debugging a home connection or a transcontinental backbone.