Traceroute Command on Linux with Examples

In the world of network diagnostics and troubleshooting, few tools are as fundamental and powerful as the traceroute command. Whether you’re a system administrator investigating network latency issues, a security professional analyzing potential routing problems, or simply a curious Linux user wanting to understand your connection’s path across the internet, mastering traceroute is essential. This comprehensive guide will walk you through everything you need to know about the traceroute command in Linux, from basic usage to advanced techniques and real-world troubleshooting examples.

Table of Contents

What is Traceroute?

Traceroute is a network diagnostic tool designed to track the path that data packets take from your computer to a target destination across an IP network. Originally developed for Unix systems, traceroute has become an essential utility available on virtually every operating system, including Linux, where it often comes pre-installed on most distributions.

At its core, traceroute allows you to visualize the journey your data takes across the internet, showing each “hop” (router or intermediate device) along the way. This visibility makes it invaluable for:

Identifying network bottlenecks causing slow connections
Detecting routing problems or network failures
Verifying network paths for security analysis
Understanding the topology of complex networks
Diagnosing connection issues between systems

Unlike simple ping tests that only confirm if a destination is reachable, traceroute provides a comprehensive map of the entire route, complete with timing information for each hop. This detailed view makes it possible to pinpoint exactly where network problems might be occurring.

How Traceroute Works

Understanding how traceroute functions is crucial to interpreting its results correctly. The mechanism behind traceroute is quite clever and relies on a fundamental aspect of IP networking: the Time To Live (TTL) field.

Traceroute works by sending packets with gradually increasing TTL values. The TTL value in an IP packet determines how many network hops the packet can traverse before it’s discarded. Each router that handles the packet decrements the TTL by one. When a packet’s TTL reaches zero, the router discards it and sends back an ICMP “Time Exceeded” message to the source.

Here’s the step-by-step process:

Traceroute sends a packet with TTL set to 1
The first router in the path decrements the TTL to 0, discards the packet, and returns an ICMP Time Exceeded message
Traceroute records the time it took to receive this response and the IP address of the router
Next, traceroute sends a packet with TTL set to 2, which will reach the second router before being discarded
This process continues, incrementing the TTL value with each new set of packets, until either the destination is reached or the maximum hop count is exceeded

By default, traceroute sends UDP packets, though it can also use ICMP or TCP packets depending on the options selected. This versatility is particularly useful when certain protocols might be blocked by firewalls along the route.

Installing Traceroute on Linux

While traceroute comes pre-installed on most Linux distributions, there might be cases where you need to install it manually. The installation process is straightforward and varies slightly depending on your distribution.

Checking if Traceroute is Already Installed

First, verify if traceroute is already installed on your system:

which traceroute

If you see a path like /usr/bin/traceroute, then the tool is already installed. If not, you’ll need to install it.

Installation on Different Linux Distributions

For Ubuntu/Debian-based systems:

sudo apt-get update
sudo apt-get install traceroute

For Red Hat/CentOS/Fedora systems:

sudo yum install traceroute

For Arch Linux:

sudo pacman -S traceroute

Once installed, you can verify the installation by checking the version:

traceroute --version

If you’re working in a minimal environment or container where traceroute isn’t available, remember that many distributions also include tracepath, a similar tool with fewer options but no requirement for root privileges.

Basic Traceroute Command Syntax

The basic syntax of the traceroute command is pleasantly simple:

traceroute [options] destination

Where destination can be either a hostname or an IP address. For example:

traceroute www.google.com

This command traces the route from your computer to Google’s servers, displaying each hop along the way.

The output typically shows:

Hop number (starting from 1)
Hostname and/or IP address of each router/device in the path
Round-trip time (RTT) for each of the probes (usually three) sent to each hop

A typical output might look like this:

traceroute to google.com (172.217.169.78), 30 hops max, 60 byte packets
 1  _gateway (192.168.1.1)  3.171 ms  4.086 ms  4.947 ms
 2  192.168.100.1 (192.168.100.1)  10.183 ms  10.702 ms  11.880 ms
 3  72.14.215.116 (72.14.215.116)  23.141 ms  24.834 ms  24.954 ms
 ...
15  216.239.43.111 (216.239.43.111)  25.097 ms 216.239.47.167 (216.239.47.167)  24.882 ms 216.239.43.111 (216.239.43.111)  24.328 ms
16  172.217.169.78 (172.217.169.78)  23.392 ms  24.174 ms  24.168 ms

This output tells you that it took 16 hops to reach Google’s server, with the round-trip time at each hop displayed in milliseconds.

Common Traceroute Options in Linux

While the basic traceroute command is useful, the real power comes from its various options that allow you to customize how it functions. Here are some of the most commonly used options:

-n (No DNS Resolution)

By default, traceroute attempts to resolve IP addresses to hostnames, which can slow down the trace. Using the -n option disables this DNS lookup, displaying only IP addresses:

traceroute -n www.google.com

This option is particularly useful when you’re troubleshooting DNS issues or when you need faster results.

-w (Wait Time)

The -w option allows you to specify how long (in seconds) traceroute should wait for a response before moving on:

traceroute -w 2 www.google.com

This sets the timeout to 2 seconds, which can be helpful when tracing routes over slow or congested networks.

-m (Maximum Hops)

By default, traceroute will try up to 30 hops before giving up. You can modify this limit with the -m option:

traceroute -m 15 www.google.com

This limits the trace to a maximum of 15 hops, which is useful when you’re only interested in the beginning portion of a route.

-q (Number of Queries)

The -q option specifies how many probes to send for each hop (default is 3):

traceroute -q 5 www.google.com

This sends 5 probes per hop instead of the default 3, providing more data points for each router in the path.

-I (ICMP Mode)

By default, traceroute uses UDP packets. The -I option switches it to use ICMP Echo requests instead:

traceroute -I www.google.com

This is particularly useful when UDP traffic is blocked by firewalls but ICMP is allowed.

-T (TCP Mode)

Similar to the -I option, -T switches traceroute to use TCP SYN packets:

traceroute -T www.google.com

This can be beneficial when both UDP and ICMP traffic is filtered but TCP is permitted.

-p (Port Specification)

The -p option allows you to specify which port to connect to:

traceroute -p 80 www.google.com

This traces the route to Google’s web server using port 80 (HTTP), which can be useful for testing connectivity to specific services.

Reading and Interpreting Traceroute Results

Properly interpreting traceroute results is a crucial skill for effective network diagnostics. Here’s how to make sense of what you’re seeing:

Understanding the Output Format

Each line in the traceroute output represents a hop in the path and typically contains:

Hop number: The sequence number of the router in the path
Hostname/IP address: The router’s hostname (if available) and IP address
Round-trip time (RTT): The time (in milliseconds) it took for the packet to reach that hop and return, shown for each probe sent

Interpreting Response Times

The three time values shown for each hop represent the round-trip times for each of the three probes sent by default. These times can tell you a lot about network performance:

Consistent times: Indicate a stable connection to that router
Varying times: May suggest congestion or route changes
Increasing times between hops: Normal, as packets travel further
Large jumps in time: Often indicate bottlenecks or congestion points

Understanding Timeouts and Asterisks

Sometimes you’ll see asterisks (*) in place of timing information:

5  * * *

This indicates that the probe timed out—the router didn’t respond within the timeout period. This could be because:

The router is configured not to respond to traceroute packets
A firewall is blocking the traceroute probes
The network is experiencing severe congestion or packet loss
The router might be down or unreachable

It’s important to note that timeouts don’t necessarily mean the trace failed—subsequent hops may still respond, indicating that packets are still getting through despite the silent router.

Recognizing Common Patterns

Certain patterns in traceroute output can help identify specific issues:

Multiple consecutive timeouts followed by responses: Often indicates a firewall blocking the specific protocol you’re using for traceroute
Timeouts starting at a specific hop and continuing to the destination: May indicate a network failure at that point
Drastically increasing latency at a specific hop: Often points to congestion or bandwidth limitations at that router
Different paths in repeated traces: Suggests load balancing or route changes in the network

Advanced Traceroute Techniques

Once you’re comfortable with basic traceroute usage, several advanced techniques can provide even more insight into network issues.

Using Different Protocols

As mentioned earlier, traceroute can use different protocols (UDP, ICMP, or TCP). When troubleshooting connectivity issues, it’s often useful to try all three to see if one succeeds where others fail:

# UDP traceroute (default)
traceroute www.example.com

# ICMP traceroute
traceroute -I www.example.com

# TCP traceroute
traceroute -T www.example.com

This approach helps identify protocol-specific filtering in the network path.

Detecting Load Balancing

Modern networks often employ load balancers that distribute traffic across multiple paths. To detect load balancing, you can increase the number of probes sent to each hop:

traceroute -q 10 www.example.com

If you see different IP addresses for the same hop number, it likely indicates load balancing in the path.

Source Routing Options

Traceroute allows you to specify the interface or source IP address to use for outgoing packets, which is particularly useful on multi-homed systems:

traceroute -s 192.168.1.100 www.example.com

This forces traceroute to use the specified source address (192.168.1.100) when sending packets, which can help troubleshoot routing issues from specific interfaces.

MTU Path Discovery

You can use traceroute to help identify Maximum Transmission Unit (MTU) issues in the path:

traceroute -F www.example.com

The -F option sets the “Don’t Fragment” bit in outgoing packets, which can help detect path MTU issues that might cause performance problems with large packets.

Practical Traceroute Examples with Analysis

Let’s examine some real-world scenarios where traceroute can help diagnose network issues.

Example 1: Identifying Local Network Issues

Suppose users complain about slow internet access. A traceroute to a popular website might reveal:

traceroute to google.com (172.217.12.14), 30 hops max, 60 byte packets
 1  router.local (192.168.1.1)  150.171 ms  160.086 ms  164.947 ms
 2  isp-gateway.net (203.0.113.1)  15.183 ms  10.702 ms  11.880 ms
 3  isp-core1.net (203.0.113.18)  13.141 ms  14.834 ms  14.954 ms
 ...

The abnormally high latency at the first hop (local router) immediately identifies the problem as being within the local network, not with the ISP or internet backbone.

Example 2: Detecting ISP Routing Issues

In another scenario, a traceroute to a business partner’s server might show:

traceroute to partner.com (198.51.100.50), 30 hops max, 60 byte packets
 1  router.local (192.168.1.1)  3.171 ms  4.086 ms  3.947 ms
 2  isp-gateway.net (203.0.113.1)  10.183 ms  9.702 ms  10.880 ms
 3  isp-core1.net (203.0.113.18)  13.141 ms  14.834 ms  14.954 ms
 4  * * *
 5  * * *
 6  * * *
 7  backbone1.net (198.51.100.5)  87.141 ms  84.834 ms  90.954 ms
 ...

The consecutive timeouts at hops 4-6 followed by responses with much higher latency might indicate routing issues within the ISP’s network or at peering points between networks.

Example 3: Identifying International Routing Inefficiencies

When communicating with international servers, traceroute can reveal inefficient routing paths:

traceroute to international-site.jp (192.0.2.100), 30 hops max, 60 byte packets
 1  router.local (192.168.1.1)  3.171 ms  4.086 ms  3.947 ms
 ...
 8  us-west-core.net (192.0.2.20)  50.141 ms  53.834 ms  51.954 ms
 9  us-east-core.net (192.0.2.25)  90.141 ms  92.834 ms  91.954 ms
10  europe-gateway.net (192.0.2.30)  150.141 ms  153.834 ms  151.954 ms
11  asia-gateway.net (192.0.2.35)  220.141 ms  223.834 ms  221.954 ms
...

This trace shows packets traveling from the US West Coast to the East Coast, then to Europe before finally reaching Asia—a clearly inefficient path that explains high latency when accessing the Japanese site.

Troubleshooting Network Issues with Traceroute

Traceroute is particularly valuable for diagnosing specific network problems. Here’s how to approach common issues:

Identifying Network Latency Issues

If users complain about slow network performance, use traceroute to identify where delays are occurring:

Run traceroute to the destination experiencing slowness
Look for significant jumps in round-trip times between consecutive hops
Note any hops with consistently high or fluctuating response times

For example, if response times suddenly jump from 20ms to 200ms between hops 6 and 7, the issue is likely at hop 7 or the link leading to it.

Detecting Routing Problems

Routing problems often manifest as unexpected paths or loops in traceroute output:

Run multiple traceroutes to the same destination over time
Compare the paths to identify inconsistencies
Look for routes that seem unnecessarily complex or that loop back through the same networks

Routing loops are particularly problematic and can be identified when you see the same IP address appearing multiple times in the path.

Locating Connection Failures

When connections fail completely, traceroute can help locate where the failure occurs:

Run traceroute to the unreachable destination
Identify the last hop that responds successfully
Note where the timeouts begin—the problem likely lies just after the last responding hop

This information is invaluable for determining whether the issue is within your network, your ISP’s network, or somewhere in the internet backbone.

Recognizing Firewall Blocks

Firewalls often silently drop traceroute packets. You can identify potential firewall blocks by:

Running traceroute with different protocols (-I for ICMP, -T for TCP)
Comparing the results to see if one protocol succeeds where others fail
Looking for patterns of consistent timeouts that start at a specific hop

If ICMP traceroute fails but TCP traceroute to port 80 succeeds, you’ve likely encountered a firewall that blocks ICMP but allows HTTP traffic.

Comparing Traceroute Between Operating Systems

While this article focuses on Linux’s traceroute implementation, it’s worth noting the differences between traceroute across operating systems, especially if you work in mixed environments.

Linux vs. Windows (tracert)

Windows includes a similar tool called tracert with some notable differences:

Windows tracert uses ICMP Echo requests by default, while Linux traceroute uses UDP
The command syntax and options differ slightly
Output formatting is different, though it contains similar information
Linux traceroute offers more protocol options and customization

When troubleshooting in mixed environments, be aware that these differences can lead to different results even when tracing the same target.

Linux vs. macOS

macOS includes a traceroute implementation that is more similar to Linux’s version:

Both use UDP by default
Command syntax is largely compatible
macOS offers fewer advanced options than Linux
Output formatting is very similar

Despite these similarities, subtle implementation differences can sometimes cause variations in the results.

MTR – A Cross-Platform Alternative

For cross-platform consistency, consider using mtr (My Traceroute), which combines the functionality of traceroute and ping into a single, real-time network diagnostic tool available on Linux, macOS, and Windows (via packages like Cygwin or WSL).

Best Practices and Tips

To get the most out of traceroute for network diagnostics, follow these best practices:

When to Use Traceroute Effectively

Use traceroute proactively: Don’t wait for network problems to become severe—regular tracing can help identify issues before they impact users
Establish baselines: Run traceroute during normal operations to establish baseline performance metrics for comparison during troubleshooting
Combine with other tools: Use traceroute alongside tools like ping, mtr, and tcpdump for comprehensive network analysis

Common Mistakes to Avoid

Misinterpreting asterisks: Remember that timeouts (*) don’t always indicate failures—some routers are configured not to respond to traceroute
Using only one protocol: Always try different protocols (UDP, ICMP, TCP) when troubleshooting, as different networks filter different types of traffic
Focusing only on latency: While high latency is important, also look for patterns, asymmetries, and unexpected paths

Security Considerations

Be aware of information disclosure: Traceroute reveals network topology information that could potentially be used by attackers
Use traceroute judiciously: Some organizations consider traceroute probes as potential security scans
Consider source address spoofing protection: Some networks implement ingress filtering that may affect traceroute results

VPS Manage Service Offer

If you don’t have time to do all of this stuff, or if this is not your area of expertise, we offer a service to do “VPS Manage Service Offer”, starting from $10 (Paypal payment). Please contact us to get the best deal!