Traceroute Explained: How to Diagnose Network Problems Like a Pro

What Is Traceroute and How Does It Work?

Traceroute is a network diagnostic utility that maps the path that packets take from your computer to a specified destination, revealing every intermediate router (or "hop") along the way and measuring the round-trip latency at each point. It is one of the most fundamental and widely-used tools in network troubleshooting, providing visibility into the otherwise opaque journey that data takes across the internet. Whether you are diagnosing slow connectivity, investigating routing anomalies, or mapping network infrastructure, traceroute gives you the ability to see exactly where packets travel and where problems occur.

The underlying mechanism of traceroute is both elegant and simple, relying on the Time to Live (TTL) field in the IP packet header. The TTL field is a counter that is decremented by one at each router the packet passes through. When a router decrements the TTL to zero, it discards the packet and sends an ICMP "Time Exceeded" message back to the source. Traceroute exploits this behavior by sending a sequence of packets with incrementing TTL values, starting at 1 and increasing by one for each probe. The first packet (TTL=1) triggers a Time Exceeded response from the first router, the second packet (TTL=2) triggers a response from the second router, and so on until the destination is reached.

When the destination host receives a packet — either an ICMP Echo Request or a UDP packet to a high-numbered port, depending on the implementation — it responds with either an ICMP Echo Reply (for ICMP-based traceroute) or an ICMP Port Unreachable message (for UDP-based traceroute). This response signals to traceroute that the destination has been reached, and the utility stops sending further probes. The result is a sequential list of every router along the path, along with the round-trip time (RTT) for each hop, typically measured three times per hop for statistical reliability.

Understanding Asymmetric Routing

It is important to understand that traceroute reveals the forward path from source to destination, but the return path taken by the ICMP Time Exceeded messages may be different. This is known as asymmetric routing, and it is common on the internet, particularly when traffic crosses multiple autonomous systems (ASes). Each AS may have its own routing policies that favor different paths for inbound and outbound traffic. As a result, the latency measurements shown by traceroute represent the round-trip time for each probe, not the one-way latency in either direction. This asymmetry can sometimes make traceroute output appear inconsistent, with later hops showing lower latency than earlier ones, because the return path from a later hop may be more direct.

Another important caveat is that traceroute may not reveal the true network path in the presence of load balancing. Many networks use Equal-Cost Multi-Path (ECMP) routing, which distributes traffic across multiple paths based on a hash of the packet headers. Since traceroute probes typically have varying source ports or other header variations, consecutive probes may take different paths through the network, causing the traceroute output to show an inconsistent or inaccurate route. Advanced traceroute implementations like Paris Traceroute address this issue by keeping the hashing fields consistent across probes, ensuring that all packets follow the same path.

Traceroute vs Tracert vs MTR

While the concept of tracing network paths is universal, the specific implementations vary across operating systems and tools. Understanding these differences is essential for interpreting results correctly and choosing the right tool for your troubleshooting scenario. The three most common tools are traceroute (Linux/macOS), tracert (Windows), and MTR (cross-platform), each with distinct behaviors and capabilities.

The most significant difference between traceroute on Linux/macOS and tracert on Windows is the default protocol used for probes. Linux traceroute sends UDP packets to high-numbered destination ports (starting at 33434 and incrementing), while Windows tracert sends ICMP Echo Request packets. This distinction matters because many firewalls and network devices handle UDP and ICMP traffic differently. ICMP-based traceroute (Windows tracert) is more likely to succeed through firewalls that allow ping traffic, while UDP-based traceroute (Linux/macOS) may be blocked by firewalls that drop UDP traffic to unknown ports. If you find that traceroute fails on Linux, try using the -I flag to switch to ICMP mode: traceroute -I example.com.

MTR (My Traceroute) combines the functionality of traceroute and ping into a single, continuously-updating tool. Unlike traceroute, which sends a fixed number of probes and displays a snapshot, MTR continuously sends probes to each hop and accumulates statistics over time. This makes MTR far more effective for detecting intermittent issues such as periodic packet loss, jitter, and transient latency spikes that might not appear in a single traceroute run. MTR is the preferred tool for ongoing network monitoring and for diagnosing issues that require sustained observation. Install it with sudo apt install mtr-tiny (Debian/Ubuntu) or brew install mtr (macOS), and run it with mtr example.com for interactive mode or mtr --report example.com for a text summary.

How to Read Traceroute Output

Annotated Output Example

Interpreting traceroute output correctly requires understanding what each column represents and how to identify patterns that indicate network problems. Below is a detailed annotated example of traceroute output, followed by guidance on interpreting common patterns.

traceroute to ippulsepro.com (104.21.35.186), 30 hops max, 60 byte packets
 │── Destination hostname, resolved IP, max hops, packet size

 1  _gateway (192.168.1.1)  0.421 ms  0.389 ms  0.356 ms
 │  │       │                 │         │         │
 │  │       │                 └─── Three RTT measurements (ms)
 │  │       └── Router IP address (often shows hostname)
 │  └── Hop number (1st router from source)

 2  10.0.0.1 (10.0.0.1)  1.893 ms  1.754 ms  2.012 ms
 │── Internal ISP router; private IP suggests carrier-grade NAT

 3  isp-edge-router.provider.net (72.14.2.1)  8.312 ms  8.156 ms  8.487 ms
 │── First public IP hop; this is your ISP's edge router

 4  core-r1.provider.net (142.250.68.1)  12.423 ms  12.189 ms  12.567 ms
 │── ISP core network; latency jump from hop 3 to 4 is normal

 5  exchange-point.ix.net (195.66.224.1)  14.891 ms  14.654 ms  14.923 ms
 │── Internet exchange point where traffic crosses between networks

 6  * * *
 │── No response from this hop (ICMP rate-limited or filtered)
 │   This is common and does NOT necessarily indicate a problem

 7  cdn-pop.cloudflare.net (104.21.35.186)  15.234 ms  14.987 ms  15.112 ms
 │── Destination reached; these are the final latency values
 │   The destination's IP matches the resolved address

Interpreting Common Output Patterns

Each line in the traceroute output represents one hop along the path. The hop number indicates the position in the route, starting from 1 (your local gateway). The hostname (if resolvable) and IP address identify the router at that hop. The three RTT values represent the round-trip time for each of the three probes sent to that hop, measured in milliseconds. A well-performing network will show smoothly increasing latency as packets traverse greater distances, with no dramatic jumps between consecutive hops.

Several patterns in traceroute output deserve special attention. Asterisks (* * *) indicate that a probe went unanswered within the timeout period (typically 5 seconds). This is extremely common and usually indicates that the router at that hop is configured to rate-limit or ignore ICMP Time Exceeded messages, not that there is a connectivity problem. As long as subsequent hops respond normally, asterisks at intermediate hops are benign. However, if asterisks appear at the final hop (the destination), it suggests the destination is unreachable or is blocking the traceroute probes entirely.

Sudden latency spikes — where one hop shows dramatically higher RTT than the previous hop — are the most important indicator to watch for. A jump from 5ms to 200ms between consecutive hops suggests a bottleneck, congestion, or a problematic link at that point in the path. However, be cautious about attributing the problem to the specific hop showing the spike, because the ICMP Time Exceeded message is generated with low priority on most routers. The actual data-forwarding latency may be much lower than the ICMP response latency. A more reliable indicator of a problem is when all hops after a certain point show consistently elevated latency — this pinpoints the problematic link between those two hops.

Inconsistent RTT values across the three probes for a single hop (e.g., "5ms 50ms 200ms") indicate jitter — variability in latency that can cause problems for real-time applications like VoIP and video conferencing. Jitter is often caused by network congestion, where packets are queued for varying lengths of time at a congested router. MTR is a better tool for measuring jitter because it provides sustained monitoring and statistical analysis over time.

Common Traceroute Patterns

Healthy vs Problematic Traces

Experienced network engineers learn to recognize common patterns in traceroute output that point to specific types of problems. Understanding these patterns accelerates troubleshooting and prevents misdiagnosis. Here are the most important patterns to recognize:

Normal, healthy traceroute: Latency increases smoothly and gradually as packets travel farther from the source. Each hop is slightly slower than the previous one, reflecting the additional distance and processing. RTT values are consistent across the three probes (low jitter), and all hops respond. This pattern indicates a well-functioning network path with no congestion, routing issues, or equipment problems.

ICMP rate limiting (asterisks at intermediate hops): One or more intermediate hops show * * * while hops before and after respond normally. This is the most common "abnormal" pattern and is almost always benign. Routers, especially core internet routers operated by large ISPs, often prioritize forwarding traffic over generating ICMP responses. When the router is busy forwarding packets, it may drop or delay ICMP Time Exceeded messages. As long as subsequent hops respond, the path is functioning correctly. Do not waste time investigating non-responsive intermediate hops when later hops are healthy.

Critical Problem Indicators

Latency spike followed by sustained high latency: If latency jumps significantly at hop N and remains elevated for all subsequent hops, the problematic link is between hop N-1 and hop N. This could indicate congestion on that link, a bandwidth limitation, or a routing issue that is sending traffic through a suboptimal path. For example, if hops 1-5 show 10ms latency and hops 6-10 show 150ms latency, the bottleneck is between hops 5 and 6 — possibly a transatlantic link, a congested peering point, or a routing detour.

Routing loop: If the same IP address appears at multiple non-consecutive hops (e.g., hop 5 and hop 8), this indicates a routing loop where packets are cycling between routers instead of progressing toward the destination. Routing loops are caused by misconfigured routing tables and will result in packets eventually being dropped when the TTL reaches zero. This is a serious problem that requires intervention by the network operators responsible for the affected routers.

Asymmetric path: Sometimes traceroute shows latency decreasing at later hops, which seems counterintuitive. This occurs when the return path from a later hop is shorter or less congested than the return path from an earlier hop, due to asymmetric routing. Since traceroute measures round-trip time (forward path + return path), a more efficient return path from a later hop can result in a lower overall RTT. This is not necessarily a problem, but it can make traceroute output confusing to interpret.

Destination unreachable: If traceroute ends with a "Destination Net Unreachable," "Destination Host Unreachable," or "Destination Port Unreachable" message, it means the packets cannot reach the target. The specific ICMP error message identifies the type of failure. "Net Unreachable" indicates a routing problem — no route to the destination network exists. "Host Unreachable" means the network was reached but the specific host is down. "Port Unreachable" (for UDP traceroute) actually means the destination was reached, which is the normal termination for UDP-based traceroute.

Diagnosing High Latency

Systematic Latency Diagnosis Workflow

High latency is one of the most common network complaints, and traceroute is the primary tool for identifying where in the network path the latency originates. A systematic approach to latency diagnosis involves using traceroute and MTR to isolate the problematic segment, then investigating the specific cause. The following workflow outlines the recommended process for diagnosing latency issues from initial detection to resolution.

Isolating Local vs External Latency

When you encounter high latency, the first step is to determine whether the problem is in your local network or in the external network (your ISP or beyond). Run traceroute to the affected destination and examine the first few hops. If latency is already high at hop 2 or 3 (your ISP's local router), the problem is likely local — check your router, WiFi signal strength, network cables, and whether other devices on your network are consuming bandwidth. If latency is normal through your ISP's local network but spikes at a later hop, the problem is external and may require contacting your ISP or the affected network operator.

Once you have identified the approximate location of the latency, run MTR for at least 100 packets (mtr --report -c 100 target.com) to gather statistical data. MTR will show you the minimum, average, and maximum latency at each hop, along with the standard deviation and packet loss percentage. This data helps distinguish between consistent latency (all probes are slow) and intermittent latency (some probes are fast while others are slow). Consistent latency suggests a bandwidth limitation or routing issue, while intermittent latency suggests congestion that occurs during peak periods.

For latency that appears to be at an internet exchange point or between autonomous systems, you can use looking glass servers to perform traceroute from other locations on the internet toward your destination. This helps determine whether the problem is specific to your path or is affecting traffic from multiple origins. Looking glass servers are publicly accessible diagnostic tools operated by ISPs and network operators — you can find them at lg.he.net (Hurricane Electric), lg.cloudflare.com (Cloudflare), and many others. If traceroute from multiple origins shows the same latency spike, the problem is likely at the destination's network edge or hosting provider. If the problem is only visible from your location, it is specific to the path between you and the destination, and you should contact your ISP with the traceroute output as evidence.

Using Traceroute for Security

Network Infrastructure Mapping

While traceroute is primarily known as a network diagnostic tool, it has significant applications in cybersecurity as well. Security professionals use traceroute to map network infrastructure, identify unauthorized services, detect network manipulation, and gather intelligence about target networks during authorized penetration tests. Understanding these security applications adds another dimension to traceroute's value as a tool in your arsenal.

Network infrastructure mapping is the most fundamental security application of traceroute. By running traceroute to multiple destinations within a target network, you can build a map of the network's topology, identifying boundary routers, internal segments, and the relationships between different parts of the infrastructure. This information is useful both for defenders (understanding their own network architecture) and for attackers (reconnaissance during a penetration test). Traceroute reveals the IP addresses of intermediate routers, which can then be probed for open management ports, default credentials, or known vulnerabilities. Many organizations are unaware of how much infrastructure information they expose through router responses to traceroute probes.

Firewall Detection and Manipulation Discovery

Firewall and filter detection is another important security use case. By comparing traceroute results using different protocols (ICMP, UDP, TCP on various ports), you can determine which types of traffic are allowed or blocked by firewalls along the path. For example, if a standard UDP traceroute shows hops up to a certain point and then stops, but a TCP traceroute on port 443 reaches the destination, this indicates that a firewall is blocking UDP and ICMP traffic but allowing HTTPS. This technique, known as firewalking, helps map firewall rule sets and identify potential bypass vectors. Tools like firewalk and nmap --traceroute automate this process.

DNS-based traceroute manipulation detection uses traceroute to identify networks that are performing DNS hijacking or transparent proxying. If traceroute to a domain resolves to a different IP address than expected, or if the path shows traffic being routed through an unusual intermediate network, this may indicate that a network operator is intercepting and redirecting DNS queries. This technique has been used to detect ISP-level content filtering, government censorship, and malicious DNS hijacking attacks. Comparing traceroute results from multiple locations can reveal inconsistent routing that suggests manipulation.

Geopolitical routing analysis leverages traceroute to examine how internet traffic flows between countries and through different jurisdictions. Traceroute can reveal when traffic between two points in one country is routed through a foreign country's infrastructure, which has implications for data sovereignty, surveillance, and national security. Researchers have used traceroute to document how traffic between South American countries sometimes routes through the United States, how traffic between Middle Eastern countries routes through Europe, and how traffic in Africa often routes through London or Marseille. These routing anomalies can expose communications to surveillance by intelligence agencies in the transit countries and increase latency for users. Organizations with data sovereignty requirements should regularly audit their traffic paths using traceroute from multiple vantage points.

Visual Traceroute and Geolocation

How Visual Traceroute Works

Visual traceroute tools combine the network path information from traceroute with geolocation data to create a graphical map showing the physical route that packets take across the internet. This visualization transforms the abstract sequence of IP addresses and latency numbers into an intuitive, geographic representation that makes it easy to understand routing patterns, identify inefficient paths, and detect traffic that is being routed through unexpected countries or regions.

The geolocation data used by visual traceroute tools comes from IP geolocation databases, which map IP addresses to approximate physical locations. These databases use a combination of WHOIS data, Regional Internet Registry allocations, BGP routing data, and crowdsourced measurements to determine the location of each IP address. The accuracy varies — major internet exchange points and data centers are typically located with high precision, while residential and mobile IP addresses may only be accurate to the city level. Despite this variability, visual traceroute provides a valuable high-level view of how traffic flows across the globe.

Running Traceroute on Different Operating Systems

Knowing how to run traceroute on your specific operating system is the first step toward effective network diagnostics. While the underlying concept is the same across platforms, the commands and options differ significantly between Windows, macOS, and Linux. Below is a step-by-step guide for each major operating system.

Getting the Most from Visual Traceroute

IP Pulse Pro's visual traceroute tool provides an interactive map that traces the path from multiple global vantage points to any destination. This is particularly useful for understanding how your website or service appears to users in different parts of the world. Running a visual traceroute from multiple locations can reveal routing asymmetries, CDN performance differences, and geographic bottlenecks that affect user experience in specific regions. For example, you might discover that users in Asia experience high latency because their traffic is routed through the United States before reaching your European server, indicating that you should consider adding a CDN edge location or server in the Asia-Pacific region.

Beyond simple path visualization, advanced visual traceroute tools also integrate AS (Autonomous System) information, showing which network operators handle your traffic at each hop. This is valuable for understanding your network dependencies — which ISPs, transit providers, and exchange points your traffic depends on. If a particular transit provider experiences an outage, you can quickly assess whether your services are affected by checking whether your traceroute paths traverse that provider's AS. AS path analysis also helps with vendor selection, peering decisions, and understanding the resilience of your network connectivity. If all of your traceroute paths to a critical service traverse the same transit provider, you have a single point of failure that should be addressed by diversifying your connectivity.

To get the most out of visual traceroute, run traces from multiple origins and at different times of day. Internet routing is dynamic, and paths can change based on congestion, outages, and BGP policy updates. A visual traceroute run at 2 AM may show a different path than one run at 2 PM during peak traffic hours. By collecting multiple traces over time, you can identify patterns, establish baselines, and detect anomalies that indicate routing problems or deliberate manipulation. The IP Pulse Pro traceroute tool supports automated periodic tracing and can alert you when paths change or latency exceeds configured thresholds, providing continuous visibility into the health and behavior of your network paths.