Tracing Network Paths with traceroute and mtr on Linux
When a packet leaves a workstation in Melbourne and heads toward a server in Frankfurt, every router along the way either helps the deliverer or throws the packet away. Australian networks push traffic across vast undersea cables before reaching the rest of the internet, so latency and loss along the path are common headaches for local sysadmins. A dropped route on the Sydney-to-Singapore segment can make an otherwise healthy service feel broken to users in Brisbane or Perth.
Two of the most useful tools for diagnosing where a path is failing are traceroute and mtr, short for My Traceroute. Both reveal the sequence of hops a packet takes, but they work in different ways and suit different purposes. Knowing when to reach for each one saves hours of guessing when an NBN service or corporate WAN starts misbehaving.
This guide walks through installation on RHEL, CentOS, Fedora, and AlmaLinux, explains how to read each command's output, and offers practical examples for everyday troubleshooting, with notes tailored to Australian ISPs and long-haul routing realities.
Installing the tools on RHEL-based systems
On modern RHEL 9 or Rocky Linux 9 hosts, both utilities are usually in the base repos. Begin with a quick check:
dnf list installed traceroute mtr
If nothing shows up, install them with dnf install traceroute mtr -y. On older CentOS 7 boxes, yum install traceroute mtr -y is the equivalent. Fedora users can run the same dnf command without enabling EPEL first. After installation, verify each binary is on the $PATH and that the setuid bit is set on /usr/sbin/traceroute, since raw sockets are required for default UDP probing.
| Feature | traceroute | mtr |
|---|---|---|
| Output style | Static snapshot per run | Live, refreshes every second |
| Default protocol | UDP on port 33434 | ICMP echo |
| Loss view per hop | Summary only | Per-hop column, easy to scan |
| Automation friendly | One run per snapshot | --report writes CSV-like output |
| Best use case | Quick checks, scripting | Intermittent faults, longer samples |
Reading traceroute output
The default invocation traceroute example.com produces a numbered list of hops. Each line shows round-trip time in milliseconds from three probes, the router's hostname if reverse DNS resolves, and its IP address. Asterisks indicate a probe that did not return within the timeout, often because the router de-prioritised the TTL-exceeded message or rate-limited the response.
A common Australian quirk is high delays on hops inside the Optus or TPG backbone before traffic even reaches the cable landing station at Glebe in Sydney. This is normal for transit peering, but worth noting when comparing paths from a Perth office versus a Sydney office. ICMP mode (traceroute -I) is sometimes blocked by firewalls, so the UDP variant often reaches more hops.
Common mtr flags worth memorising:
-rfor report mode without a live display-c Nto set the cycle count-nto skip reverse DNS lookups--report-cycles=N --logfile=pathfor unattended logging
Running mtr for continuous monitoring
mtr combines traceroute and ping into a single display that updates in real time. A typical session starts with mtr -r -c 100 example.com. The -r flag puts mtr into report mode, and -c 100 sends 100 cycles before exiting. The result shows average loss, average, worst, and standard deviation of round-trip times per hop.
When diagnosing intermittent dropouts on a TPG or iiNet fibre line, mtr excels because the loss column often reveals which upstream carrier is dropping packets. Operators can pipe output to a log file with --no-dns --report-cycles=200, which makes post-mortem analysis easier after an outage.
If the on-screen display is preferred, running mtr example.com without flags opens an interactive view. Press p to pause, d to toggle DNS lookups, and q to quit. For remote servers without X11 forwarding, report mode is the practical choice.
Spotting bottlenecks and black holes
A black hole hop stops responding entirely. If traceroute shows asterisks from a particular hop onwards and never reaches the destination, that router is probably filtering ICMP TTL-exceeded messages. mtr will show 100% loss on that hop but may still report lower loss on later hops, a strong indicator of rate-limited responses rather than true failure.
Latency jumps between adjacent hops are the other red flag. A sudden increase of 100 ms when traffic moves from an Australian carrier to an international hop, such as Sydney to Los Angeles, can be normal because of undersea cable distance. A jump from 20 ms to 250 ms between two domestic hops usually points to congestion or a faulty router.
Local Wi-Fi issues can masquerade as routing problems. If the first hop shows wild latency, the issue is rarely upstream. Some setups benefit from integrating an Edimax extender with a mesh Wi-Fi system to cover dead spots in sheds and outdoor offices common across regional properties.
Symptoms worth checking during an outage:
- 100% loss at hop 3 or 4 often points to the home router or NBN connection
- 20-40% loss on a single hop is usually that carrier's fault
- Sudden latency doubling at a transit exchange suggests peering congestion
- Loss appearing only on the last hop points to a server-side problem
Combining traceroute with other diagnostic commands
traceroute and mtr rarely work alone. Pairing them with ping -R for record-route, tcpdump -i eth0 icmp to see the actual probes, and ss -tulnp to confirm local sockets are open gives a fuller picture. tracepath is a related tool that does not require root, useful when only a regular user shell exists.
For DNS-related slowdowns, run mtr -r -c 50 8.8.8.8 and mtr -c 50 1.1.1.1 in turn. Australian users sometimes see differences between Google and Cloudflare paths because of peering arrangements, and this comparison quickly reveals which provider has the cleaner route. Nmap's --traceroute option combines host discovery with path tracing, handy during a remote migration.
Automating diagnostics on a schedule
Persistent issues call for scheduled samples written to disk. A simple cron job runs mtr every five minutes:
*/5 * * * * /usr/sbin/mtr -r -c 60 -n example.com >> /var/log/network-mtr.log
The -n flag skips DNS lookups, which speeds things up on DNS-heavy networks. Parsing the log with a small Python or awk script and feeding it into Grafana or Prometheus gives a visual timeline of when loss spiked. When NBN congestion strikes in the arvo peak hours and users complain, centralised data is invaluable.
For a quick look at a connectivity complaint, run mtr -r -c 30 against the destination and read the loss column from the bottom up. Loss at only the destination means the server is the culprit, while loss beginning at a specific hop points to that router or link. Reach for traceroute when a single snapshot is enough, such as after a BGP update. Use mtr for intermittent issues that need a longer sample. Both tools are tiny, fast, and in every standard repo, so there is little reason not to install them on every Linux host that touches the public internet. This article is published under the site copyright policy.