Traceroute is not a list of “good routers” and “bad routers”
Traceroute reveals how packets with increasing TTL or Hop Limit values cause routers along a path to generate diagnostic responses. Those responses are useful, but they are not the same thing as the routers’ normal forwarding behavior. A router can forward traffic correctly while delaying, rate-limiting, filtering, or ignoring traceroute probes addressed to its control plane.
TTL expiration creates the hop-by-hop map
This mechanism explains a crucial limitation: traceroute measures the willingness and timing of devices to answer diagnostic probes. It does not directly measure every forwarding decision made by every router.
Each hop line is a set of probe observations, not a direct cable measurement
This tells you that probes with the relevant TTL received responses associated with that hop and that the round-trip times for those responses were roughly 18–21 ms. It does not prove that the physical link immediately before that router has 18–21 ms of one-way latency.
One silent hop with healthy downstream responses
Best conclusion: hop 3 did not return the traceroute probes, but it clearly forwarded traffic onward because later hops answered.
What this proves: diagnostic visibility at hop 3 is missing.
What this does not prove: transit failure, packet loss through hop 3, or that the router is down.
A latency increase that persists is stronger evidence
The RTT jump begins near hop 3 and remains high downstream. That makes the change more meaningful than an isolated slow response. Possible explanations include geographic distance, a new transit segment, congestion, queuing, or a route change.
One high-latency hop followed by normal latency
Best interpretation: hop 3 answered its own diagnostic probes slowly, but the delay does not persist. Transit traffic continued downstream with normal end-to-end timing.
Apparent packet loss at one hop can be control-plane rate limiting
If a router rarely answers probes directed to itself but later hops and the destination answer normally, the “loss” is not propagating through the path. That pattern is consistent with deprioritized or rate-limited diagnostic replies.
Stronger loss evidence: missing probes that begin at one point and remain missing or degraded at all later hops, including the destination, especially when corroborated by application or ping loss.
Responses stop after the edge—but the cause is still unresolved
This is stronger than one isolated silent hop because visibility never returns. But traceroute alone still cannot distinguish among downstream filtering, probe-type filtering, routing failure, destination policy, or a true forwarding outage.
A destination can work even when traceroute never visibly “finishes”
Firewalls and hosts can allow the real application while suppressing traceroute-related responses. If HTTPS to the destination succeeds but traceroute ends in asterisks near the destination, the application result is strong evidence that end-to-end forwarding exists for the actual service.
Private addresses near the beginning are often completely normal
RFC1918 ranges such as 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 commonly appear in enterprise or home paths. Their appearance in early hops simply indicates internal addressing on part of the path.
Some provider infrastructures also use non-public or carrier-internal address space. Do not conclude “the Internet is routing private addresses globally” based only on a traceroute line.
The RTT you see can include a different return path
Traceroute reveals the forward path taken by your probes only indirectly, and each router’s response can return by a different route. Internet paths are often asymmetric, so the return path may cross different providers or links.
A different path is evidence of routing change—not automatically a fault
Possible explanations include routing convergence, provider policy, traffic engineering, ECMP, failure recovery, or ordinary dynamic path selection. If latency or reachability also changed, the route change becomes relevant correlation—but not yet proof of root cause.
Different probes can legitimately reveal different next hops
Equal-Cost Multi-Path routing can distribute flows across multiple paths. Depending on the traceroute implementation and the fields used to identify a flow, different probes may traverse different next hops.
This does not necessarily mean the network is unstable. It can represent normal load sharing across parallel paths.
The number of visible hops is not always the number of physical routers crossed
Provider technologies such as MPLS can hide or abstract portions of the transit path. Tunnels and provider design choices can make several internal routers invisible to standard traceroute behavior.
Traceroute results can change when the probe type changes
Different operating systems and tools can use different probe strategies, including ICMP, UDP, or TCP-based methods. Firewalls may treat those differently. A path that looks incomplete with one probe type may become visible with another.
| Observation | Possible interpretation | Useful next test |
|---|---|---|
| ICMP-style trace stops; HTTPS works | Diagnostic replies may be filtered while application traffic is allowed. | TCP-based trace or service-specific reachability test. |
| UDP-style trace stops at firewall | UDP probes may be filtered. | Try ICMP/TCP method if available. |
| All probe types stop and service fails | Stronger evidence of a real path/policy/destination problem. | Route, firewall log, destination listener, provider check. |
Swipe horizontally to see the full probe-type comparison.
Ping and traceroute answer different but complementary questions
Ping
Primarily answers whether a destination returns ICMP Echo replies and gives end-to-end RTT/loss for that probe type.
Traceroute
Attempts to expose intermediate path behavior by causing TTL/Hop Limit expiration at successive hops.
A clean destination ping with one “lossy” intermediate traceroute hop is a classic sign that the intermediate hop is not forwarding poorly—it is simply not prioritizing its own diagnostic replies.
Application success can falsify a broad “network path is down” claim
If traceroute has asterisks but the target web application completes a TCP handshake, TLS negotiation, and HTTP response, then a total path outage is not a viable explanation for that transaction.
The last visible router is not automatically the broken router
If responses stop after hop 7, hop 7 may simply be the last device willing to answer. The failure or filtering could exist beyond it. Assigning blame to the last responsive hop is a common but unsupported leap.
A current trace becomes much more useful when you have a known-good trace
| Current observation | Baseline comparison | Interpretation strength |
|---|---|---|
| RTT jumps from 8 ms to 90 ms | Baseline also jumps there | Likely normal path characteristic. |
| RTT jumps from 8 ms to 90 ms | Baseline was 15 ms at same segment | Stronger evidence of changed path/queuing. |
| Path changes providers | Baseline used one provider consistently | Useful evidence of routing change. |
| One hop stops replying | Baseline also shows that hop silent | Likely normal filtering behavior. |
Swipe horizontally to compare current traces against baseline behavior.
Match the pattern before naming the cause
| Traceroute signature | Stronger interpretation | Do not claim yet |
|---|---|---|
| Single silent hop, later hops healthy | Intermediate diagnostic reply absent. | Router is down. |
| Single high RTT hop, later hops normal | Slow control-plane reply likely. | That hop adds the delay to transit traffic. |
| RTT increase persists downstream | Delay begins at or before that boundary. | Exact cause without baseline/other evidence. |
| Loss begins and persists to destination | Stronger evidence of actual path loss. | Exact device responsible. |
| Responses stop and service also fails | Real path/policy/destination issue more plausible. | Last visible hop is at fault. |
| Path changes but service stays healthy | Routing changed, possibly normally. | Routing failure. |
Swipe horizontally to see the complete failure-signature matrix.
Loss begins at hop 4 and persists to the destination
This is materially different from an isolated silent router. Loss-like behavior begins near hop 4, continues downstream, and is corroborated by destination loss.
Only one of three probes is slow
One outlier at hop 6 is weak evidence. The next hops return to normal values, so the better interpretation is an isolated response delay or transient event rather than sustained path latency.
Two traces disagree because the route is load balanced
If both traces are healthy and latency is similar, the difference may reflect ECMP or provider traffic engineering rather than instability. A changed path matters most when it aligns with changed performance or reachability.
Good troubleshooting asks what observation would prove your first idea wrong
- Hypothesis: “Hop 5 is dropping traffic.” Falsifier: later hops and the destination show no loss.
- Hypothesis: “The path is down after hop 7.” Falsifier: the destination application succeeds.
- Hypothesis: “Hop 3 adds 150 ms.” Falsifier: hop 4 and destination return to 20 ms.
- Hypothesis: “The ISP reroute caused the outage.” Falsifier: the path changed while application performance stayed normal.
- Hypothesis: “Private hop means invalid Internet routing.” Falsifier: the private hop is inside the local/provider architecture and forwarding continues normally.
Use artifact language that separates observation, interpretation, and next step
This structure is useful far beyond traceroute. It trains you to avoid overclaiming from incomplete evidence.
Ten traceroute mistakes to avoid
- Calling every asterisk “packet loss.”
- Blaming the last responsive hop when later devices are invisible.
- Assuming one slow intermediate response adds the same delay downstream.
- Treating RTT as one-way link latency.
- Ignoring asymmetric return paths.
- Assuming every visible address represents a separate physical link.
- Assuming path changes always indicate failure.
- Ignoring ECMP/load balancing.
- Failing to compare with ping, application tests, or a baseline.
- Using traceroute alone to name a root cause that requires routing, firewall, or provider evidence.
Before you finalize a traceroute conclusion, ask these questions
- Does the abnormality occur at one hop or persist downstream?
- Does the destination show the same latency or loss pattern?
- Could the router be rate-limiting its own diagnostic replies?
- Could the return path be different?
- Did the route itself change?
- Is ECMP or another load-balancing behavior possible?
- Does a known-good baseline show the same pattern?
- What alternate test could falsify the current hypothesis?
- What exactly is proven, and what remains unresolved?
24 traceroute analysis digital flashcards
Practice TTL logic, silent hops, persistent latency, packet-loss interpretation, path changes, asymmetry, ECMP, evidence boundaries, and falsifying tests.