~/ linuxnetwork.net

Traceroute: Print the Route Packets Trace to Network Host

In the vast and complex world of computer networks, understanding how data travels from one point to another is crucial. Traceroute is a powerful network diagnostic tool that allows users to trace the route that packets take from their source to a specified destination on the network. By revealing the path packets follow and the time taken to reach each hop along the way, traceroute provides valuable insights into network performance, latency, and potential bottlenecks. In this blog post, we will delve into the details of traceroute, exploring its functionality, common practices, best practices, and providing example usage.

Table of Contents#

  1. How Traceroute Works
  2. Common Traceroute Commands
  3. Understanding Traceroute Output
  4. Interpreting Asterisks and Timeouts
  5. Related Tools: MTR, tracepath, and PathPing
  6. Common Practices
  7. Best Practices
  8. Example Usage
  9. Limitations of Traceroute
  10. Conclusion
  11. References

How Traceroute Works#

Traceroute operates on the principle of the Internet Control Message Protocol (ICMP) and the Time to Live (TTL) field in the IP header. When a user initiates a traceroute to a destination IP address, the tool sends a series of packets with incrementally increasing TTL values.

The TTL field is a counter that limits the lifespan of a packet in the network. Each router that processes a packet decrements the TTL value by one. When the TTL value reaches zero, the router discards the packet and sends an ICMP Time Exceeded message (Type 11) back to the source. Traceroute uses these Time Exceeded messages to identify each hop along the route to the destination.

As the TTL values are incrementally increased, traceroute is able to map out the entire path from the source to the destination, recording the IP address and the round-trip time (RTT) for each hop.

Protocol Differences by Platform#

The default protocol used by traceroute varies by operating system:

  • Linux and macOS: The traceroute command sends UDP packets by default, targeting destination ports in the range 33434–33534. You can switch to ICMP Echo Request packets with the -I flag or TCP SYN packets with the -T flag.
  • Windows: The tracert command sends ICMP Echo Request packets by default, rather than UDP.
  • Cisco IOS: Uses UDP datagrams to an invalid port (default UDP 33434), similar to the Unix implementation.

When the destination receives the final probe packet, it responds with an ICMP Destination Unreachable message (for UDP probes) or an ICMP Echo Reply (for ICMP probes), signaling that the trace is complete.

Common Traceroute Commands#

Linux and macOS#

  • traceroute <destination>: This is the basic traceroute command in Linux and macOS. Replace <destination> with the IP address or domain name of the target host.
  • traceroute -I <destination>: Use ICMP ECHO packets instead of UDP datagrams. This can be useful if UDP packets are being blocked by firewalls.
  • traceroute -T <destination>: Use TCP SYN packets instead of UDP datagrams. This is helpful when UDP and ICMP are blocked, but TCP traffic is allowed. Requires root privileges.
  • traceroute -n <destination>: Skip DNS resolution for faster results.
  • traceroute -m <max_hops> <destination>: Set the maximum number of hops to trace.
  • traceroute -w <seconds> <destination>: Set the timeout to wait for a response from each hop (default is 5 seconds).
  • traceroute -q <nqueries> <destination>: Set the number of probe packets per hop (default is 3).

Windows#

  • tracert <destination>: The Windows equivalent of the traceroute command. It uses ICMP Echo Request messages to trace the route.
  • tracert -d <destination>: Do not resolve IP addresses to hostnames. This can speed up the traceroute process, especially when dealing with hosts that have slow DNS resolution.
  • tracert -h <max_hops> <destination>: Set the maximum number of hops to trace.
  • tracert -w <milliseconds> <destination>: Set the timeout in milliseconds to wait for each reply.

Understanding Traceroute Output#

The output of a traceroute command typically consists of several lines, each representing a hop along the route to the destination. Here is an example of traceroute output:

traceroute to google.com (142.251.42.174), 30 hops max, 60 byte packets
 1  router.example.com (192.168.1.1)  1.234 ms  1.567 ms  1.890 ms
 2  isp-router.example.net (203.0.113.1)  5.678 ms  6.789 ms  7.890 ms
 3  core-router.example.net (203.0.113.2)  10.123 ms  11.234 ms  12.345 ms
 ...
10  google-gateway.example.net (142.251.42.174)  20.234 ms  21.345 ms  22.456 ms
  • Hop Number: The first column indicates the hop number, starting from 1. This represents the order in which the routers are encountered along the path.
  • Hostname and IP Address: The second column shows the hostname (if available) and IP address of the router at each hop. If the hostname cannot be resolved, only the IP address will be displayed.
  • Round-Trip Time (RTT): The remaining columns show the round-trip time in milliseconds for each packet sent to the router at that hop. Multiple RTT values are usually displayed (three by default) to account for variations in network latency.

Interpreting Asterisks and Timeouts#

A common question when reading traceroute output is what the asterisk (*) characters mean. An asterisk indicates that no response was received from a router within the timeout period (default 5 seconds). There are several reasons why this can happen:

  • ICMP rate limiting: Many routers are configured to limit the rate at which they generate ICMP error messages. This is known as Control Plane Policing. The router is still forwarding traffic normally, but it suppresses the Time Exceeded replies. If subsequent hops respond fine, the asterisks are usually not a cause for concern.
  • Firewall filtering: A firewall at that hop may be blocking ICMP messages or UDP packets, preventing the router from sending a reply.
  • Actual packet loss: If you see sustained packet loss (all three probes show *) at a hop and at every subsequent hop, it may indicate a real connectivity problem.
  • Asymmetric routing: The probe packets may reach the router, but the response takes a different path back and never arrives.

A single asterisk among otherwise normal responses (e.g., 1.2 ms * 1.5 ms) is typically harmless and usually due to transient congestion or rate limiting. Focus on patterns of loss rather than individual dropped probes.

Traceroute is not the only tool available for path discovery. Several related utilities offer complementary features.

MTR (My Traceroute)#

MTR combines the functionality of traceroute and ping into a single tool. Instead of a single snapshot, MTR continuously sends probes and aggregates statistics over time, showing packet loss percentages and average latency for each hop. This makes it particularly useful for identifying intermittent network issues.

mtr google.com

MTR is available on Linux, macOS, and Windows. Like traceroute, it can use either ICMP or UDP for its probes.

tracepath#

tracepath is a Linux utility similar to traceroute, but it does not require root privileges. It uses UDP by default and relies on the sockets API rather than raw packet manipulation. It also reports the Path MTU (Maximum Transmission Unit) for each hop, which can help identify MTU-related issues.

tracepath google.com

For basic network tracing where advanced protocol options are not needed, tracepath is a convenient alternative.

PathPing#

PathPing is a Windows utility that combines the functionality of ping and tracert. It sends packets to each router along the path and computes packet loss and latency statistics over a longer period than a single tracert run.

pathping google.com

Common Practices#

  • Diagnosing Network Issues: Traceroute is commonly used to diagnose network connectivity problems. If a traceroute fails to reach the destination or experiences high latency at a particular hop, it can indicate a problem with the router or the network link at that point.
  • Monitoring Network Performance: By regularly running traceroutes to critical hosts, network administrators can monitor the performance of their network and detect any changes or anomalies in the route or latency.
  • Testing Firewall Rules: Traceroute can be used to test the effectiveness of firewall rules. If a traceroute fails to reach a particular host or hop, it may indicate that the firewall is blocking traffic.
  • Comparing Network Paths: If multiple routes or mirrors are available to reach a destination, traceroute can help determine which path has fewer hops or lower latency.

Best Practices#

  • Use Appropriate Permissions: In some cases, running traceroute may require administrative privileges. On Linux, using -I (ICMP) or -T (TCP) flags requires root. Make sure you have the necessary permissions to execute the command.
  • Limit the Number of Hops: By default, traceroute may attempt to reach up to 30 hops. If you are only interested in the local network, you can limit the number of hops using the -m option in Linux and macOS or the -h option in Windows.
  • Use DNS Resolution Sparingly: Resolving IP addresses to hostnames can slow down the traceroute process, especially when dealing with slow DNS servers. Use the -n option to disable DNS resolution if speed is a concern.
  • Run Multiple Traces: Network paths can change due to routing decisions. Running traceroute multiple times can confirm whether a path is consistent or if there is instability.
  • Trace in Both Directions: When diagnosing connectivity issues, try to obtain traceroutes from both ends of the connection. Forward and return paths are often asymmetric, and a problem may exist only in one direction.

Example Usage#

Linux#

To trace the route to Google's website using the default UDP packets:

traceroute google.com

To trace the route using ICMP packets:

traceroute -I google.com

To trace the route using TCP SYN packets (useful when UDP and ICMP are blocked):

sudo traceroute -T google.com

To trace with no DNS resolution and a maximum of 15 hops:

traceroute -n -m 15 google.com

Windows#

To trace the route to Google's website without resolving IP addresses to hostnames:

tracert -d google.com

To trace with a maximum of 20 hops and a 3-second timeout:

tracert -h 20 -w 3000 google.com

Limitations of Traceroute#

While traceroute is a valuable diagnostic tool, it has several limitations to be aware of:

  • Path variability: IP does not guarantee that packets follow the same route. The path shown by traceroute may not represent the exact route that application traffic takes, especially in networks with load balancing.
  • Interface-level, not router-level: Traceroute discovers the IP address of each interface along the path, not the router itself. A single router with multiple interfaces may appear as multiple hops.
  • Rate limiting and filtering: Many routers suppress ICMP error messages, causing hops to appear as asterisks even when traffic is flowing normally.
  • Asymmetric routing: The forward and return paths may differ, so traceroute only reveals the forward path from the source.
  • No guarantee of application connectivity: A successful traceroute does not guarantee that applications can communicate, since firewalls may permit ICMP but block TCP or UDP traffic on application ports.

For more advanced path analysis, tools like Paris-traceroute maintain flow identifiers to work correctly in the presence of load balancing.

Conclusion#

Traceroute is a versatile and powerful network diagnostic tool that provides valuable insights into the path packets take on the network. By understanding how traceroute works, interpreting its output—including asterisks and timeouts—and following common and best practices, users can effectively diagnose network issues, monitor performance, and test firewall rules. Whether you are a network administrator, a developer, or just a curious user, traceroute is an essential tool in your network troubleshooting toolkit.

References#

Please note that the above references are provided for further reading and research. The information in this blog post is based on general knowledge and common practices in the field of network diagnostics.

2026-04