Every Packet Leaves Footprints
When you analyze unsolicited traffic or chronic latency, packets do not move instantly from source to destination. They traverse routers that decrement TTL and may emit ICMP errors back toward the sender. The traceroute family of tools—and the continuous monitor mtr—use that behavior to map the forward path, turning opaque addresses into an ordered hop list with timing samples.
Network and security teams use traceroute early in triage because it answers more than “who owns this IP?” It shows how probes or flows reached you across provider boundaries, where latency accumulates, and whether responses disappear behind ICMP-filtering gear.
How Traceroute Works: The TTL Mechanism
Every IP packet carries a field called TTL (Time to Live)—an integer that starts at a value set by the sender (typically 64, 128, or 255) and is decremented by 1 at every router the packet passes through. When TTL reaches zero, the router discards the packet and sends back an ICMP Time Exceeded message to the original sender. That ICMP reply includes the router's own IP address in its source field.
Traceroute exploits this by sending a series of probe packets with deliberately low TTLs:
- First probe: TTL = 1. The very first router decrements to 0 and replies with ICMP Time Exceeded. You learn the first hop's IP address and round-trip time.
- Second probe: TTL = 2. The first router decrements to 1 and passes it on. The second router decrements to 0 and replies. You learn the second hop.
- This continues until the probe reaches the destination, which replies with ICMP Port Unreachable (or TCP RST, depending on the tool variant) indicating the destination has been reached.
The result is an ordered list of every router between you and the target, along with latency measurements for each hop. On Unix/Linux/macOS, the command is traceroute [target]. On Windows, it is tracert [target]. By default, both send three probes per TTL value and report the round-trip times for each.
Reading a Traceroute Output
A typical traceroute output looks like this (simplified):
- Hop 1: 192.168.1.1 — your router
- Hop 2: 10.x.x.x — your ISP's first router (private/CGNAT range)
- Hop 3: 100.x.x.x — ISP aggregation layer
- Hop 4–5: Public IP addresses belonging to your ISP's backbone
- Hop 6–8: Upstream transit provider routers (identified via reverse DNS or ASN lookup)
- Hop 9+: Destination network's edge and internal routers
Stars (* * *) in the output indicate a router that either dropped the ICMP probe (firewalled) or did not respond within the timeout window. A firewall returning stars does not mean the router is offline—it means it was configured to silently drop ICMP Time Exceeded responses. Subsequent hops may still respond normally.
Large latency jumps between hops often indicate a geographic boundary—a transatlantic submarine cable, a satellite link, or a long-haul terrestrial fiber run. A sudden 100ms increase followed by stable latency on subsequent hops suggests the traffic crossed an ocean at that point.
Traceroute in security triage
When responders need context for an unfamiliar source address, traceroute from your own network edge—or from a second vantage point you control—can show:
Hosting and proxy hops: Traffic may traverse VPS providers, VPN concentrators, Tor exits, or other relay infrastructure. Each hop can appear as a separate address and ASN. A sequence that moves from a well-known cloud ASN to a consumer ISP prefix is a common pattern for VPN exit or nested tunnels, but similar shapes appear with legitimate remote access and split-tunnel designs. Treat ASN transitions as evidence about path, not as standalone proof of identity.
ISP escalation paths: Knowing which ISP owns each hop along the observed path supports structured abuse mail. An abuse complaint to AS1234 is far more effective than a complaint to a generic registry. Traceroute combined with whois lookups yields ASN, abuse contact email, and organizational details for each responding interface.
CDN and WAF fingerprinting: A traceroute to a well-defended target often terminates at a CDN edge node (Cloudflare, Akamai, Fastly) several hops before reaching the actual origin server. The origin never appears in the traceroute at all. This is intentional—CDN providers create an IP anonymization layer for origin servers. Understanding this helps engineers and testers recognize when they are hitting a proxy versus the actual server, and helps defenders confirm their CDN is properly obscuring the origin.
BGP routing anomaly detection: In BGP hijacking incidents, traffic to a destination suddenly takes an unexpected path—often through a new ASN that was not in the route before. Automated traceroute monitoring from multiple vantage points can detect these routing changes in near-real-time. Services like RIPE Atlas run continuous path monitoring for exactly this purpose.
Advanced Tools: mtr and tcptraceroute
mtr (My Traceroute): Available on Linux and macOS, mtr runs a continuous traceroute and updates the display in real-time, showing packet loss statistics per hop. This is invaluable for diagnosing intermittent problems that only appear under sustained traffic. A hop with 30% packet loss while subsequent hops show 0% loss indicates rate-limiting of ICMP on that router rather than a real problem. A hop with 5% loss followed by 5% loss at all subsequent hops indicates real packet loss at that hop propagating forward.
tcptraceroute: Standard traceroute uses UDP or ICMP probes. Many firewalls drop ICMP but pass TCP. tcptraceroute sends TCP SYN packets to a specified port (e.g., port 443), making the probe look like a legitimate connection attempt and passing through many firewalls that would otherwise produce * * * results. This gives you visibility into hops that are invisible to standard traceroute.
Paris traceroute: Traditional traceroute varies the source port between probes to work around per-flow load balancers, but this can cause path inconsistency—different probes take different paths, making the output appear to show phantom branching. Paris traceroute keeps the 5-tuple (source IP, source port, dest IP, dest port, protocol) constant across all probes to a given TTL, ensuring all packets to the same TTL follow the same ECMP (Equal-Cost Multi-Path) route. This produces a more accurate view of the actual path.
Standards and enterprise collection
IPv4 traceroute depends on routers generating ICMP Time Exceeded (RFC 792) when TTL expires. IPv6 uses ICMPv6 Time Exceeded (RFC 4443). Because probes are synthetic, SOC playbooks often pair traceroute with NetFlow or IPFIX from routers, SPAN or TAP captures on choke points, and SIEM tickets that record vantage point, timestamp, and probe type. Document whether probes used UDP, ICMP, or TCP so analysts can explain silent hops caused by policy rather than loss.
Traceroute vs. other techniques
| Technique | What it reveals | What it misses |
|---|---|---|
| IP lookup / whois | Owner, ASN, country, abuse contact of a single IP | How traffic got there; routing path; intermediate infrastructure |
| Traceroute | Forward hops, ASN transitions, latency clues, relay segments | Silent hops behind filters (***); return path asymmetry |
| mtr (continuous) | Per-hop loss and jitter over time; route churn during observation | Return path; root cause of loss without packet capture |
| tcptraceroute | Hops when ICMP is filtered but TCP to an open port is allowed | Requires a known open TCP port at the destination |
| BGP looking glass | AS paths and prefix advertisements as control plane sees them | Host-level forwarding; data-plane specifics |
| RIPE Atlas traces | Paths from many geographic probes in parallel | Coverage limits; credits and scheduling constraints |
Common Misconceptions
Misconception 1: Stars in Traceroute Mean the Network Is Down
Stars (* * *) at a hop simply mean that hop did not send an ICMP Time Exceeded response within the timeout period. Most commonly this means the router's ICMP rate-limiting or firewall rules prevent it from responding to probe packets. The router is still forwarding traffic normally—it is just not talking back. If subsequent hops respond normally, the network path is intact and the intermediate router is simply quiet.
Misconception 2: Traceroute Shows the Exact Physical Route
Traceroute reveals the logical routing path as experienced by probe packets at the moment of execution. It does not show the return path (which may be completely different due to asymmetric routing). It does not show what path real application traffic takes if load balancers or ECMP routing spread flows across multiple paths. And it represents a snapshot in time—routes can change between one traceroute run and the next due to BGP updates.
Misconception 3: Traceroute pinpoints a person or street address
Traceroute lists router interfaces and the apparent source; geolocation databases map those to coarse regions. VPN exits, Tor, carrier-grade NAT, and cloud egress all decouple the observed hop from an individual endpoint. Use traces to scope abuse reports and routing anomalies, then corroborate with other evidence.
Misconception 4: Traceroute Requires Root or Administrator Privileges
On Linux, the default traceroute uses UDP and requires elevated privileges to send raw packets. However, many modern implementations (including traceroute with the -I flag for ICMP, and mtr) work without root when the system is configured accordingly. On macOS, traceroute works as a standard user. On Windows, tracert runs without administrator privileges. The privilege requirement depends on the probe type and OS configuration.
Pro Tips
- Run traceroute from multiple vantage points, not just your workstation. The path from your network to a remote IP is affected by your upstream routing. Running traceroute from a VPS in a different geographic region or from a public RIPE Atlas probe gives a more complete picture of how traffic reaches the target globally.
- Correlate traceroute hops with ASN data in real time. For each hop IP, run
whois [IP]or use a tool like Team Cymru's IP to ASN mapping to identify the organization behind each router. The transition points between ASNs are where traffic crosses organization boundaries—the most forensically interesting hops. - Use mtr for sustained monitoring during an active incident. A single traceroute is a snapshot. During a live performance or security event, mtr's continuous output shows whether the routing path is stable, whether packet loss is fluctuating, and whether the route changes mid-incident.
- Combine traceroute with netflow or PCAP data. Traceroute shows the path; netflow shows the volume and timing; PCAP shows the payload. Together, these three data sources provide a complete forensic picture that each alone cannot deliver.
- Document all traceroute evidence with timestamps. In a legal or regulatory context, routing evidence must include the timestamp of collection, the source vantage point, and the full command used. A screenshot alone is insufficient. Save raw terminal output with date/time context using a command like
traceroute -n [target] 2>&1 | tee traceroute_$(date +%F_%T).txt. - Understand that Tor and VPN traffic will produce uninformative traces. Traffic from a Tor exit node or VPN endpoint will show the traceroute terminating at the exit infrastructure with no visibility into what is behind it. This is the expected, designed behavior. In that case, the forensic value comes from identifying which exit infrastructure is being used, not from tracing further.
Traceroute remains a fast, low-cost way to visualize the forward path. Combined with ASN context, multi-vantage runs, and continuous mtr during incidents, it supports structured triage without replacing flow records or packet evidence. Review port and path discovery basics with Nmap, and confirm your own egress address when comparing traces.