VMware ESXi and vSphere Cluster Management

Linux traceroute Command: Trace Network Paths and Diagnose Connectivity

Learn how to use Linux traceroute to inspect network hops, understand TTL and ICMP responses, interpret timing and timeouts, and troubleshoot connectivity problems.

traceroute is a network diagnostic utility that reveals the sequence of hops between your Linux host and a destination. A hop is a router or other network transit point that forwards a packet.

Unlike ping, which mainly tests whether a destination responds and measures latency, traceroute helps show where a path travels and where a problem may begin. It can help narrow down routing failures, packet loss, filtering, or increased delay, but its results require careful interpretation.

What traceroute is used for

• Discovering the hop-by-hop path from a source host to a destination.
• Identifying the first point where responses stop appearing.
• Finding where measured round-trip times change significantly.
• Comparing paths to different destinations or from different networks.
• Investigating possible routing problems, filtering, congestion, or packet loss.

Traceroute is a path-discovery and diagnostic tool, not a complete reachability test. A destination can respond to ping while a router along the path ignores traceroute probes. Conversely, a router can answer traceroute probes slowly while forwarding ordinary traffic normally.

How traceroute works

TTL limits packet lifetime

TTL, or Time To Live, is a field in an IP packet header. Each routed hop decreases the TTL by one. If the value reaches zero, the router discards the packet instead of forwarding it indefinitely.

Traceroute takes advantage of this behavior by sending groups of probes with progressively larger TTL values:

1. Probes with TTL 1 expire at the first router.
2. Probes with TTL 2 pass through the first router and expire at the second router.
3. Probes with TTL 3 reach the third router before expiring.
4. The process continues until the destination responds or the trace reaches its hop limit.

ICMP responses identify intermediate routers

When a router discards a packet because its TTL has expired, it commonly sends an ICMP Time Exceeded message back to the source. ICMP, the Internet Control Message Protocol, carries diagnostic and error messages rather than ordinary application data. The source uses the address of this response to identify the router at that hop.

Traceroute normally sends multiple probes for each TTL value. For every response, it measures the round-trip time (RTT): the time from sending a probe until the response returns. Multiple measurements show whether a hop responds consistently or whether its timing varies.

How the destination ends the trace

On a UDP-based Linux trace, the destination commonly receives a probe sent to a high, unlikely-to-be-used UDP destination port. Because no application is listening there, the destination often returns ICMP Port Unreachable. That response indicates that the probe reached the destination, so traceroute can end the trace.

In ICMP mode, enabled with -I, traceroute sends ICMP Echo Request probes, similar to those used by ping. A permitted destination commonly responds with an ICMP Echo Reply.

Basic traceroute command usage

The general syntax is:

traceroute <destination>

The destination can be a hostname or an IP address:

traceroute www.google.com
traceroute 8.8.8.8

A typical command sends several probes for each hop and may display output similar to:

 1  router.home (192.168.1.1)   1.123 ms  1.087 ms  1.102 ms
 2  203.0.113.1                 8.421 ms  8.377 ms  8.509 ms
 3  * * *
 4  198.51.100.10              22.314 ms 22.190 ms 22.401 ms

Reading each output line

Under common defaults, three timing values appear for each hop because three probes are sent. A trace normally ends when a response from the target is received. It may instead stop or show timeouts when the target, an intermediate firewall, or network policy filters the selected probes or diagnostic replies.

Useful traceroute options

Numeric output with -n

traceroute -n 8.8.8.8

Without -n, traceroute may perform a reverse DNS lookup, which resolves an IP address back to a hostname. Name lookups can make output slower and can obscure whether the network trace itself is slow. Numeric output is useful during time-sensitive troubleshooting.

Changing probe count with -q

traceroute -q 1 www.google.com

The -q option controls how many probes are sent at each hop. A smaller value produces output more quickly, but gives you less information about timing variation, intermittent replies, or load balancing. More probes provide better sampling at the cost of additional packets and waiting time.

Using ICMP probes with -I

traceroute -I www.google.com

ICMP mode is useful when a network treats UDP and ICMP differently. It can also make results easier to compare with ping. However, ICMP may be filtered too, and a different probe method can produce a different apparent path.

Probe method comparison

Interpreting timeouts and latency

What asterisks mean

An asterisk means that a particular probe did not produce a response before the command's timeout. Possible causes include:

• The router does not send TTL-expired responses.
• A firewall filters the probe or the ICMP response.
• The router applies ICMP response rate limiting.
• The response was delayed beyond the wait period.
• The path uses behavior that does not expose the router to this probe type.

A row containing * * * does not by itself prove that traffic stops there. If later hops and the final destination respond, the trace demonstrates that packets or responses continued beyond that nonresponsive hop.

Finding a possible problem point

1. Run the trace more than once and look for a repeatable pattern.
2. Identify the first hop where responses consistently stop or RTT increases substantially.
3. Check whether the increased delay continues at later hops.
4. Compare the result with another destination.
5. Use a different probe method when filtering is suspected.

If one intermediate hop reports a high RTT but later hops return to their previous range, the router may simply be deprioritizing diagnostic replies. The value can also reflect the return path, temporary congestion, or control-plane behavior. It is not necessarily evidence that the router is delaying forwarded traffic.

Common troubleshooting scenarios

One or more hops show only asterisks

First check whether later hops or the destination respond. If they do, the nonresponsive router is probably filtering or rate-limiting diagnostic replies rather than blocking forwarding. Repeat the trace, compare it with another target, and try:

traceroute -I example.net

An intermediate hop has unusually high RTT

Check whether the high value continues through subsequent hops. If later values return to normal, do not treat the intermediate value alone as proof of a forwarding problem. If the increase persists, investigate congestion, routing changes, or a path segment that may genuinely be adding delay.

The trace never reaches the destination

Possible explanations include a down target, an unavailable or misconfigured route, or filtering of the selected probe type. Use permitted tests such as:

ping example.net
traceroute -I example.net
host example.net

ping checks basic reachability and latency when ICMP is allowed. host resolves a hostname and helps verify that the name maps to the expected address. Compare results from another destination or network before concluding that the route is broken.

The command is slow

Slow output can result from reverse DNS lookups, multiple probes per hop, or unanswered probes waiting for timeouts. Use numeric output or fewer probes:

traceroute -n example.net
traceroute -n -q 1 example.net

The second command is faster but samples each hop only once, so it provides less timing detail.

Why traceroute results can be misleading

• Asymmetric routing: the forward path and response path may differ, so RTT does not describe only the outbound route.
• ICMP rate limiting: routers may limit control-message generation while continuing to forward normal traffic.
• Packet filtering: firewalls or policies may block UDP, ICMP, high ports, or diagnostic replies.
• Load balancing: different probes may take different paths, producing different responding addresses or timings.
• Congestion: temporary queueing can change RTT and packet loss.
• Router control-plane behavior: handling a TTL-expired packet may receive lower priority than forwarding traffic.

Platform availability

Traceroute-style utilities are available on Linux, Unix-like systems, macOS, and Windows, but the command name and flags can differ. Linux commonly uses traceroute; other platforms may provide a similarly named utility with different options. Check the local command's manual page before transferring flags between systems.

Related utilities

• ping <destination> checks basic reachability and measures response latency when the target permits the probe.
• host <hostname> resolves a hostname and can help investigate DNS results.
• mtr combines repeated path discovery and latency/loss observations for longer-running diagnosis.

For a focused route investigation, start with the traceroute command, then compare its output with reachability and DNS checks rather than relying on one trace alone.

Exam-relevant summary

• Traceroute discovers hops by sending probes with progressively increasing TTL values.
• Each router decrements TTL; when TTL reaches zero, the router commonly returns ICMP Time Exceeded.
• Linux commonly uses UDP probes by default and detects the destination through ICMP Port Unreachable.
• -I selects ICMP Echo Request probes.
• -n disables reverse DNS lookups, and -q changes the number of probes per hop.
• An asterisk means no response was received in time; it does not automatically prove a route failure.
• A high RTT at one intermediate hop matters most when the increase continues at later hops.
• Filtering, rate limiting, asymmetric routing, load balancing, congestion, and router control-plane behavior can make output incomplete or misleading.