How Traceroute Works

Traceroute maps the path that packets take from your device to a destination. It reveals every router hop along the way, showing you the actual infrastructure your traffic traverses. This is one of the most valuable diagnostic tools in networking - and it works by exploiting a quirk of how routers handle the TTL field.

The Core Concept

Every IP packet has a TTL (Time to Live) field. Despite the name, TTL is not measured in time but in hops. Each router that forwards the packet decrements the TTL by one. When TTL reaches zero, the router drops the packet and sends an ICMP Time Exceeded (Type 11, Code 0) message back to the original sender.

Traceroute exploits this by sending a series of packets with carefully chosen TTL values. The first packet has TTL=1, so the first router drops it and responds. The second packet has TTL=2, so it passes the first router and dies at the second. This continues until a packet reaches the destination.

Each ICMP Time Exceeded response comes from a different router, and the source IP of that response identifies the router. By collecting all responses in order, traceroute builds a hop-by-hop map of the path.

The TTL Trick

The process works step by step:

1. Send a packet with TTL=1. The first router decrements it to 0, drops the packet, and sends back ICMP Time Exceeded. Record the router's IP and the round-trip time.
2. Send a packet with TTL=2. The first router decrements to 1 and forwards it. The second router decrements to 0, drops it, and sends ICMP Time Exceeded. Record the second router's IP and RTT.
3. Continue incrementing TTL until the packet actually reaches the destination. The destination responds differently (depending on the traceroute variant) to signal that the path is complete.

Most implementations send three probes per TTL value. This is why traceroute output typically shows three RTT values per hop - they represent three independent measurements that help identify inconsistency or packet loss at that hop.

sequenceDiagram
    participant S as Source
    participant R1 as Router 1 - 10.0.0.1
    participant R2 as Router 2 - 172.16.0.1
    participant R3 as Router 3 - 192.0.2.1
    participant D as Destination - 104.21.48.1
    S->>R1: Probe TTL=1
    R1->>S: ICMP Time Exceeded - from 10.0.0.1
    Note over S: Hop 1 - 10.0.0.1 - 2ms
    S->>R1: Probe TTL=2
    R1->>R2: Forward TTL=1
    R2->>S: ICMP Time Exceeded - from 172.16.0.1
    Note over S: Hop 2 - 172.16.0.1 - 8ms
    S->>R1: Probe TTL=3
    R1->>R2: Forward TTL=2
    R2->>R3: Forward TTL=1
    R3->>S: ICMP Time Exceeded - from 192.0.2.1
    Note over S: Hop 3 - 192.0.2.1 - 15ms
    S->>R1: Probe TTL=4
    R1->>R2: Forward TTL=3
    R2->>R3: Forward TTL=2
    R3->>D: Forward TTL=1
    D->>S: Response - destination reached
    Note over S: Hop 4 - 104.21.48.1 - 18ms - DONE

Figure 1 - Traceroute incrementing TTL to discover each router hop along the path

UDP, ICMP, and TCP Variants

Different traceroute implementations use different probe packet types, which affects what the destination sends back:

UDP traceroute (Linux default). Sends UDP packets to high-numbered ports (starting at 33434, incrementing per probe). When the packet reaches the destination, nothing is listening on that port, so the destination responds with ICMP Destination Unreachable, Port Unreachable (Type 3, Code 3). Traceroute recognizes this as the end of the path.

ICMP traceroute (Windows default, Linux -I flag). Sends ICMP Echo Request packets. When the packet reaches the destination, it responds with ICMP Echo Reply instead of Time Exceeded. Traceroute recognizes the Echo Reply as the end.

TCP traceroute (tcptraceroute, Linux -T flag). Sends TCP SYN packets, typically to port 80 or 443. The destination responds with SYN-ACK (port open) or RST (port closed). This variant is valuable because many firewalls allow TCP traffic to web ports while blocking UDP and ICMP probes.

Each variant may produce different results on the same path because firewalls treat different protocols differently. A hop that appears as * * * with UDP probes might respond normally with TCP probes.

Reading Traceroute Output

A typical traceroute output looks like this:

traceroute to infishark.com (104.21.48.1), 30 hops max
 1  gateway (192.168.1.1)  1.234 ms  0.987 ms  1.102 ms
 2  10.0.0.1  8.456 ms  8.221 ms  8.334 ms
 3  172.16.50.1  12.678 ms  12.444 ms  12.891 ms
 4  * * *
 5  198.51.100.1  18.123 ms  17.998 ms  18.456 ms
 6  104.21.48.1  19.234 ms  19.001 ms  19.345 ms

Each line shows:

• The hop number
• The router's hostname (if reverse DNS resolves) and IP address
• Three RTT measurements from three probes

RTT at each hop represents the round trip from the source to that router, not the latency between consecutive routers. A jump from 12ms at hop 3 to 18ms at hop 5 does not mean hop 5 added 6ms - the path asymmetry and processing time at each hop affect the measurement.

Why Hops Go Missing

The * * * at hop 4 in the example means no response was received for any of the three probes. Common reasons:

ICMP rate limiting. Many routers limit the rate at which they generate ICMP messages to conserve CPU. If your probe arrives during a rate-limited period, the Time Exceeded message is silently suppressed.

Firewall rules. Some routers are configured to never send ICMP Time Exceeded messages. They still forward packets normally - they just do not respond when the TTL expires.

MPLS tunnels. Multiprotocol Label Switching (MPLS) can create tunnels through the network where packets are forwarded based on labels rather than IP headers. Routers inside the tunnel may not decrement TTL or generate ICMP responses.

A missing hop does not indicate a problem. The packet still passed through that router successfully - the router just declined to announce itself. If subsequent hops respond normally, the path is working fine.

graph TD
    subgraph "Why Hops Show as * * *"
        A[Probe arrives at router] --> B{Does router generate ICMP?}
        B -->|Yes| C{ICMP rate limit exceeded?}
        C -->|No| D[Time Exceeded sent - hop visible]
        C -->|Yes| E[Message suppressed - shows * * *]
        B -->|No - firewall blocks| F[No response - shows * * *]
        A --> G{MPLS tunnel?}
        G -->|Yes| H[TTL not decremented - hop hidden]
        G -->|No| B
    end
    subgraph "Not an Error"
        I[Packet still forwarded normally] --> J[Next hop may respond fine]
        J --> K[Path is working despite * * *]
    end

Figure 2 - Reasons a traceroute hop may appear as asterisks and why it is usually not a problem

Asymmetric Routing

Traceroute shows the forward path - the routers your probe packets traverse on the way to the destination. But the ICMP responses take a return path that may be completely different. This is called asymmetric routing, and it is common on the internet.

The RTT measurements include both the forward and return paths. If the forward path to hop 5 takes 10ms but the return ICMP message takes 25ms via a different route, traceroute shows 35ms at hop 5. This can create misleading latency jumps that do not correspond to actual problems on the forward path.

Asymmetric routing also means traceroute cannot show you the return path. Tools like reverse traceroute exist but require cooperation from the destination network, which is rarely available.

Paris Traceroute

Classic traceroute has a subtle flaw: it varies the source port (or ICMP identifier) across probes. Many routers use ECMP (Equal-Cost Multi-Path) routing, which distributes traffic across multiple parallel links based on a hash of the packet's flow identifier (source IP, destination IP, source port, destination port, protocol).

Because classic traceroute uses different flow identifiers for different probes, each probe may take a different ECMP path. The result is a traceroute that shows routers from multiple paths stitched together - a path that no single packet actually traverses.

Paris traceroute solves this by keeping the flow identifier constant across all probes. It manipulates other header fields (like the UDP checksum or ICMP identifier) to vary the probes while maintaining the same ECMP hash. This ensures all probes follow the same path, producing an accurate single-path trace.

What Traceroute Reveals and What It Does Not

Traceroute shows you:

• The routers along the forward path to a destination
• The approximate latency to each hop (including return path)
• Where packet loss occurs (if probes consistently fail at a specific hop)
• The network topology between you and the destination
• Which ISPs and transit providers carry your traffic

Traceroute does not show you:

• The return path (which may differ entirely)
• The actual per-link latency (only cumulative RTT to each hop)
• Whether a non-responding hop is actually a problem
• Bandwidth capacity of any link
• What happens inside MPLS tunnels

For network security work, traceroute helps you understand the infrastructure your traffic crosses. When combined with the BLEShark Nano's local network visibility, you get a complete picture from Layer 2 (ARP, MAC addresses) through the routing topology to the final destination.