How to Use Traceroute and MTR to Diagnose Network Issues

Learning how to use traceroute and MTR to diagnose network issues is a practical step when you need to see which routers sit between your machine and a remote host, whether latency spikes on one hop, and whether loss is real or an artifact of how probes are handled. Traceroute gives a single snapshot of the forward path. MTR combines traceroute-style discovery with repeated probes so you can build loss and round-trip time statistics per hop.

This tutorial walks through how TTL-based tracing works, how to install and run traceroute and mtr on common operating systems, how to read annotated output, when paths differ in each direction, and a short triage workflow you can use before you attach logs to a support ticket. For background on interfaces and protocols, see An Introduction to Networking Terminology, Interfaces, and Protocols.

• Traceroute discovers the forward path by sending packets with increasing TTL values and recording ICMP “time exceeded” replies from each hop; MTR repeats that idea and adds live statistics (loss, min, avg, max, standard deviation).
• Asterisks in traceroute output often mean a router did not answer the probe, not necessarily that user traffic is dropped. Always compare with MTR toward the final hop and with application-level symptoms.
• Paths can be asymmetric: run mtr from your laptop to the server and from the server back toward your public IP (or another stable endpoint) when both sides are reachable.
• Rough RTT guides for interpretation: same metro often under about 5 ms per hop; cross-country segments in a large country often tens of milliseconds; transoceanic segments often roughly 80 ms to 150 ms. Sustained values above about 150 ms to 200 ms on a hop warrant a closer look in context.
• When routing tools are not enough, capture packets with tools such as tcpdump or Wireshark, inspect sockets with ss, and review local firewall rules. On Ubuntu, see How To Set Up a Firewall with UFW.

• A Linux or macOS shell, or Windows with tracert (and optionally a third-party MTR build) for the platform-specific sections.
• Network egress to the host you are testing. If you are testing a Droplet, you can SSH in and run commands on the instance. Follow How to Connect to Your Droplet with SSH if you need a refresher.
• sudo or administrator rights if your OS requires elevated privileges for certain probe types (common with ICMP or raw sockets).

What a network hop is

A hop is one router or layer-3 device along the path. Your packets cross many hops between a home or office network and a cloud instance.

Your PC -- hop 1 (edge router) -- hop 2 (ISP) -- hop 3 (backbone) -- ... -- target

Each hop decrements the IP TTL. When TTL reaches zero, the device is supposed to return an ICMP time exceeded message, which is what classic traceroute uses to discover that hop.

Traceroute answers: “Which routers did my packets visit on the way to this destination, and what round-trip time did I see to each?” On many Linux systems the default traceroute from iputils sends UDP probes to high ports and listens for ICMP responses. On macOS, the system traceroute also uses UDP by default. You can often request ICMP echo probes with a flag such as -I on Linux (where supported) when you want behavior closer to ping.

TTL-based probing

The sender starts with a small TTL. The first router drops the packet, returns time exceeded, and reveals its identity. The sender increases TTL step by step until the packet reaches the destination (or the hop limit is hit).

ICMP, UDP, and TCP-style traces

• ICMP: Resembles ping; some networks treat ICMP differently than TCP or UDP application traffic.
• UDP: Common default for many traceroute implementations.
• TCP: Tools such as tcptraceroute or mtr -T can help when ICMP or UDP is filtered but a TCP port is open.

Limitations of traceroute

• Firewalls and rate limits: Operators may filter or rate-limit ICMP or odd UDP ports, which produces * in output even when HTTP or SSH works fine.
• Asymmetric routing: Return paths for ICMP messages may differ from the path your application traffic takes.
• Load balancers and anycast: You might see different hops between runs if the destination is anycast or load balanced.

For a deeper read on interpreting traces, see the APNIC article How to properly interpret a traceroute or MTR.

Ubuntu and Debian

Most Ubuntu images include traceroute. If it is missing:

sudo apt update
sudo apt install traceroute

Install MTR (CLI; includes mtr and an optional TUI). For a smaller CLI-only package you can use mtr-tiny:

sudo apt install mtr

Rocky Linux, CentOS Stream, Fedora, and RHEL-family

Use dnf on current releases (older systems may still use yum):

sudo dnf install traceroute mtr

macOS

traceroute is preinstalled. Install MTR with Homebrew:

brew install mtr

Homebrew may install mtr as mtr or advise a path; run mtr --version after install to confirm.

Windows

tracert is built in. Open Command Prompt or PowerShell:

tracert example.com

pathping combines a route trace with sustained loss sampling:

pathping example.com

Native MTR is not bundled with Windows; many administrators use maintained third-party builds if they need MTR semantics on Windows clients.

Basic syntax

traceroute example.com

Replace example.com with a hostname or IP you are allowed to test.

Example output (annotated)

Your addresses and hostnames will differ. This sample shows the usual fields:

traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets
 1  gateway.lan (192.0.2.1)    2.1 ms   2.0 ms   2.2 ms   # your edge
 2  isp-core.example.net       10.4 ms  10.1 ms  10.3 ms  # provider backhaul
 3  * * *                                                # no reply this round
 4  core.backbone.example     18.2 ms  17.9 ms  18.0 ms  # still progressing
 ...

Reading each column

• Hop number: Distance in steps from your host.
• Hostname or IP: From reverse DNS, or the numeric address if PTR is missing.
• Three round-trip times: Three probes by default; they can vary with congestion or multipath.

Useful flags

Increase the maximum hop count (default is often 30; max is 255 on many builds):

traceroute -m 64 example.com

Change probe count per hop:

traceroute -q 1 example.com

Skip reverse DNS to run faster:

traceroute -n example.com

On many Linux systems you can change the packet size (payload length) with a length argument after the host:

traceroute example.com 70

What asterisks mean

An asterisk means that probe did not get a usable reply before the timeout. That often indicates an intermediate router that does not respond to traceroute probes, ICMP rate limiting, or a firewall policy. If later hops still appear, user traffic may still work. Treat * as a signal to corroborate with MTR, application tests, and possibly captures.

Identifying a problem hop

Look for the first hop where latency jumps sharply compared with the previous stable hop, or where loss appears and the last hop also shows loss or the application fails. If only middle hops show loss but the destination is clean in MTR, the middle loss may be control-plane deprioritization rather than a broken forwarding path.

MTR (Matt’s traceroute, often packaged as mtr) sends repeated probes and updates statistics per hop. That makes it far better for intermittent loss and jitter than a one-off traceroute.

MTR column meanings

In report mode you typically see:

• Loss%: Percentage of replies lost for that hop in the sample window.
• Snt: Packets sent.
• Last, Avg, Best, Wrst: Round-trip times in milliseconds.
• StDev: Spread of latency samples (useful jitter signal).

When to prefer MTR

Use MTR when the problem is sporadic, when you need evidence for a provider, or when you want to see whether “bad” middle hops still lead to a healthy final hop.

Interactive mode

mtr example.com

The TUI refreshes until you quit (often q).

Non-interactive report

Send 10 cycles by default (exact flags depend on version; --report is widely available):

mtr --report example.com

Increase cycles for a steadier sample:

mtr --report --report-cycles 50 example.com

Example report (values are illustrative):

HOST: myserver                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- gateway.lan               0.0%    50    0.4   0.5   0.3   1.1   0.2
  2.|-- isp-pe.example.net       0.0%    50    9.2  10.1   8.4  15.2   1.8
  3.|-- core1.backbone.example   0.0%    50   18.0  18.4  17.1  22.0   1.1
  4.|-- core2.backbone.example   0.0%    50   88.5  90.2  85.1 120.4  10.3
  5.|-- target.example.com        0.0%    50   91.0  92.0  89.0 125.0  11.0

In this pattern, latency rises at hop 4 and stays high through the destination, which points to that segment of the path (subject to asymmetric caveats below).

Packet loss at intermediate hops versus the destination

If an intermediate hop shows loss but the final hop shows about 0% loss and the service works, the intermediate loss may be because that router deprioritizes or limits probe traffic. If the final hop shows sustained loss that matches application errors, treat it as end-to-end loss.

Private addresses and MPLS

You may see RFC 1918 addresses or terse labels on provider backbones. That is common with MPLS or carrier networks. Focus on where latency or loss changes relative to neighboring hops, not on whether a label is “pretty.”

High latency at one hop

A sharp jump at a single hop suggests congestion, a long geographic segment, or a questionable peering point. Compare across time with MTR and from another network (for example tethered phone versus office Wi-Fi) to see if the jump is stable.

Packet loss patterns

• End-to-end loss on the last hop that matches user-visible failures usually deserves escalation with MTR reports and timestamps.
• Only mid-hop loss with a clean last hop often needs interpretation, not an emergency routing change.

Complete timeouts

If traces stop entirely, check local egress, VPNs, corporate proxies, and security groups or cloud firewalls. On Linux hosts, also confirm that local iptables or nftables rules are not blocking probes. For open listeners and connectivity checks beyond routing, you may use How To Use Netcat to Establish and Test TCP and UDP Connections and How To Use Nmap to Scan for Open Ports on Your VPS.

Paths from A to B and B to A can differ. A forward trace that looks clean can coexist with a poor return path for some flows.

When you have shell access on both ends (for example your laptop and a Droplet):

1. Run mtr --report <target> from the client to the server public IP or hostname.
2. From the server, run mtr --report toward the client’s public IP.

If the client sits behind carrier-grade NAT and has no stable inbound IP, use a known reflector both sides can reach, or test from a small cloud VM you control with a public address on one leg of the path.

Compare both reports side by side and note where latency or loss diverges.

Use this sequence when users report “the server feels slow” or “SSH drops.”

1. Confirm DNS and L4 reachability: Resolve the name, ping or connect to the service port when policy allows.
2. Traceroute snapshot: traceroute -n <host> for a quick map.
3. MTR report: mtr --report --report-cycles 50 <host> (adjust cycles).
4. Directionality: Repeat from the remote host back toward the client or a stable public endpoint.
5. Local policy: Verify UFW or cloud firewalls are not blocking needed traffic. For port concepts, read Opening a Port on Linux.
6. Escalation bundle: Attach MTR reports with timestamps, source and destination IPs, and whether the issue correlates with a specific ISP or VPN.

When traceroute and MTR are not enough

• Packet capture: tcpdump on an interface, or Wireshark on a laptop, to see retransmissions, resets, and DNS oddities.
• Socket state: ss -tunap (modern replacement for much of netstat) to see what is listening and connected.
• Kubernetes: For workloads on DigitalOcean Kubernetes, also review service routing and CNI behavior with How To Inspect Kubernetes Networking.
• Advanced kernel introspection: eBPF-based tools (for example bpftrace with the right probes) help in complex production environments but require separate expertise and safe rollout practices.

Submitting an MTR report to a provider

Plain text is easy to paste into tickets:

mtr --report --report-cycles 100 example.com > mtr-client-to-server.txt

Run the matching reverse test when possible and label files with direction, time zone, and source IP.

Historical note

The classic traceroute idea is associated with Van Jacobson’s work on Unix network tooling in the late 1980s. MTR appeared later to merge repeated measurements with path discovery, which matches how network operators actually isolate flaky paths. Both tools remain everyday utilities on Linux and BSD servers, including cloud hosts you manage yourself.

1. How do I use traceroute to identify network problems?

Run traceroute <destination> (or tracert on Windows) and look for the first hop where latency jumps compared with earlier hops, or where asterisks cluster and your application also fails. Combine that with mtr --report so you are not fooled by a single lucky snapshot.

2. How do I diagnose network connectivity issues using these tools?

Start with basic reachability (ping or a TCP connection test when ICMP is blocked). Then run mtr --report toward the service IP. If the service is bidirectional, run MTR from both ends or toward a stable public endpoint on each side to account for asymmetric routing.

3. How do I use MTR to troubleshoot?

Use interactive mode for live monitoring during an incident. For tickets, use report mode with enough cycles, for example mtr --report --report-cycles 50 <host>. If UDP or ICMP is filtered, explore TCP mode with -T toward an open port when your build supports it.

4. Is MTR the same as traceroute?

No. Traceroute discovers hops once per run (unless you script repeats). MTR repeatedly probes and summarizes loss and round-trip statistics per hop, which is closer to what you need for intermittent issues.

5. What do asterisks in traceroute output mean?

They mean that probe did not receive a reply before the timeout. Common causes include ICMP filtering, rate limits, or a router that does not prioritize traceroute traffic. If the trace continues past the stars and MTR shows a healthy final hop, the path may still be fine for real application traffic.

You can use traceroute and MTR to diagnose network issues by mapping hops, comparing round-trip times, and reading loss on the final hop versus middle hops. Add bidirectional tests when asymmetry is likely, then move to captures and socket inspection if routing looks healthy but applications still fail.

Next steps and related resources

• An Introduction to Networking Terminology, Interfaces, and Protocols
• How to Set Up a Firewall with UFW on Ubuntu
• How to Inspect Kubernetes Networking

Spin up a Linux VM

Spin up a DigitalOcean Droplets and practice forward and reverse mtr between your home connection and the instance.