Linux online course

Linux traceroute Command: Trace Network Paths and Diagnose Connectivity

Learn how to use Linux traceroute to inspect network hops, understand TTL and ICMP responses, read RTT output, and troubleshoot latency, packet loss, and connectivity.

traceroute is a Linux network diagnostic utility that maps the responding hops between your computer and a destination. It can help you discover where latency, packet loss, filtering, or a routing failure may occur.

This lesson assumes basic Linux command-line usage, hostnames, IP addresses, and a general understanding of ping and routers.

What traceroute Does

A hop is an intermediate routing device or network transition encountered by a packet. traceroute sends diagnostic probes toward a target and reports the hops that respond along the path.

This differs from ping:

• ping primarily tests whether an endpoint responds and measures round-trip latency to that endpoint.
• traceroute displays intermediate routers and measures the response time associated with each hop.

For example, if the destination responds but latency becomes high after a particular group of routers, traceroute provides a starting point for investigation. It can also show whether a trace stops at a local gateway, an upstream provider, or near the destination.

Installing traceroute

The package may not be installed by default. If the shell reports that the command cannot be found, install it using the package manager for your distribution:

sudo apt install traceroute
sudo dnf install traceroute
sudo pacman -S traceroute

The first command is commonly used on Debian- and Ubuntu-based systems, the second on Fedora- and RHEL-family systems where available, and the third on Arch-based systems. Confirm that the executable is available with:

command -v traceroute

Basic traceroute Syntax

The basic form is:

traceroute destination

The destination can be a hostname or an IP address:

traceroute example.com
traceroute 1.1.1.1

The hostname form may perform DNS lookups for the destination and for responding router addresses. The IP-address form avoids resolving the destination name, but router hostnames may still be looked up unless you use -n.

How traceroute Works

TTL is a hop limit

TTL, or Time To Live, is an IP header field used as a hop limit. Each router that forwards a packet decrements the TTL by one. When the value expires, the router discards the packet instead of forwarding it indefinitely.

Probes discover one hop at a time

1. traceroute sends probes with TTL 1.
2. The first router decrements the TTL to zero and discards the probe.
3. That router normally sends an ICMP Time Exceeded response back to the source.
4. traceroute records the responding router's address and the round-trip time.
5. It repeats the process with TTL 2, TTL 3, and progressively larger values.

This sequence reveals the addresses of intermediate routers. Tracing ends when the destination responds or when the configured maximum hop limit is reached.

ICMP, the Internet Control Message Protocol, is used for diagnostics and error reporting. ICMP Time Exceeded responses are part of TTL-based path discovery; they are not the same as the probe protocol that traceroute sends.

Traditional Linux probe behavior

Traditional Linux traceroute commonly sends UDP probes by default. UDP is the User Datagram Protocol. The probes typically use high destination ports beginning around 33434, with ports changing for successive probes.

When a UDP probe reaches the destination, it commonly targets an unused port. The destination then returns an ICMP Port Unreachable error. That response tells traceroute that the probe reached the target, so the trace can finish.

Defaults vary between traceroute implementations and Linux distributions. Consult the local manual page when exact probe behavior matters:

man traceroute

Reading traceroute Output

A typical result may look similar to this:

traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets
 1  router.home (192.168.1.1)  1.123 ms  1.087 ms  1.102 ms
 2  198.51.100.1          8.441 ms  8.512 ms  8.477 ms
 3  * * *
 4  203.0.113.9           21.004 ms  20.882 ms  21.191 ms

Round-trip time (RTT) is the time between sending a probe and receiving its response. Values are usually displayed in milliseconds, abbreviated as ms.

Three probe results per hop are commonly displayed by default. A single asterisk means one probe did not receive a response. A line containing * * * means none of the probes for that hop received a response within the timeout.

Using ICMP Probe Mode

Use the uppercase -I option to send ICMP Echo Request probes instead of the default UDP probes:

traceroute -I example.com

An ICMP Echo Request is the probe type commonly used by ping. If the destination permits it, the corresponding response is an ICMP Echo Reply. ICMP mode can be useful when a network filters UDP traceroute probes or when you want to compare traceroute behavior with ping.

The -I option changes the probes sent by traceroute. It does not change the ICMP Time Exceeded messages that routers may send when intermediate TTL values expire.

Controlling Speed and Output

Skip reverse DNS with -n

A reverse DNS lookup resolves an IP address to a hostname. These lookups can delay output when DNS is slow, unavailable, or ambiguous. Use -n to display numeric addresses only:

traceroute -n 1.1.1.1

This often makes a trace appear faster and removes hostname-resolution noise from the investigation.

Change the probe count with -q

Use -q to set how many probes are sent per hop:

traceroute -q 1 example.com

One probe per hop produces a quicker, less detailed trace. It provides less information about latency variation and intermittent loss. More probes take longer but give a better sample of conditions at each hop.

A practical compromise is two numeric probes per hop:

traceroute -n -q 2 example.com

A Practical Troubleshooting Workflow

1. Choose a known destination and record the time, network, and command options used.
2. Run a normal trace, then repeat it later or from another network when possible.
3. Use -n if hostname lookups make the command pause.
4. Look for the first consistently unresponsive hop or the point where latency changes sharply.
5. Check whether later hops and the destination show the same delay or loss.
6. Compare default UDP probing with -I ICMP probing if filtering is suspected.
7. Use other tests to confirm the observation: ping, DNS lookup tools such as dig or host, routing information from ip route, and an application-level test against the actual service.

Traceroute should be one part of an investigation. A path can look normal while an application is failing because the service port, protocol, authentication, or application itself is unavailable.

Interpreting Common Symptoms

Limitations and Interpretation Cautions

• Return paths may differ: traceroute observes responses returning to your host. It does not guarantee that the reverse path is identical to the forward path taken by the probes.
• Load balancing can change results: equal-cost multipath routing or other load-balancing systems may send different probes through different routers at the same hop.
• Filtering creates incomplete traces: firewalls, access control lists, NAT devices, and ICMP filtering can hide hops or prevent the destination from replying.
• Routers can rate-limit diagnostics: a router may delay or suppress control-plane responses even while forwarding packets normally.
• Destination reachability is limited evidence: reaching a host does not prove that a particular TCP or UDP port, application protocol, or service is available.

Common Problems

The command is not found

The traceroute package may not be installed, or its executable may not be in your PATH. Install the package for your distribution and confirm it with:

command -v traceroute

The trace pauses while displaying hostnames

Slow reverse DNS lookups are a common cause. Run:

traceroute -n destination

Investigate DNS separately if you need router hostnames.

An intermediate hop shows asterisks, but later hops respond

This commonly means that the router does not answer diagnostic probes, or that its ICMP responses are filtered or rate-limited. Since later hops respond, do not treat that line alone as proof of a path failure.

The trace stops before reaching the target

Possible causes include a firewall or ACL blocking probes, a routing problem beyond the last responding hop, or a destination network that suppresses traceroute responses. Compare:

traceroute destination
traceroute -I destination
ping destination

Use ping only when permitted, and test the actual application port separately because traceroute does not verify service access.

One middle hop has high delay, but later hops are fast

The router may be rate-limiting or deprioritizing diagnostic responses rather than forwarding traffic slowly. Judge the destination and subsequent hops, repeat the test, and confirm with application measurements before reporting a performance problem.

Different runs show different routers at one hop

This can result from equal-cost multipath routing or another load-balancing system. Run several traces and treat alternate paths as normal unless they correlate with a persistent failure or performance change.

Exam-Relevant Notes

• TTL is decremented by each router and limits how many hops a packet can cross.
• A router whose TTL processing expires normally returns ICMP Time Exceeded.
• Traditional Linux traceroute commonly uses UDP probes with high destination ports beginning around 33434.
• A destination may return ICMP Port Unreachable when a UDP probe reaches an unused port.
• -I selects ICMP Echo Request probes; it is not the same thing as the ICMP Time Exceeded responses used for intermediate-hop discovery.
• -n disables reverse DNS lookups, and -q number changes the number of probes per hop.
• An asterisk means that one probe did not receive a response within the wait time; it does not automatically mean packet forwarding failed.

Quick Reference

# Standard trace to a hostname
traceroute example.com

# Trace an IP address without reverse DNS lookups
traceroute -n 1.1.1.1

# Use ICMP Echo Request probes
traceroute -I example.com

# Send one probe per hop
traceroute -q 1 example.com

# Numeric output with two probes per hop
traceroute -n -q 2 example.com

Use traceroute to form a hypothesis about where a network problem begins, then verify that hypothesis with repeated tests, endpoint checks, DNS and routing information, and the application-level protocol that is actually failing.