Traceroute manufactures controlled expiration points along a routed path
Traceroute is useful because it does not wait for routers to volunteer a network map. It sends probes designed to expire after progressively more routed hops and records the responses that come back.
In IPv4, the Time to Live field is reduced by routers as a packet is forwarded. A router that reduces TTL to zero discards that packet and can return an ICMP Time Exceeded message. Traceroute exploits this behavior by beginning with TTL 1, then 2, then 3, continuing upward. TTL 1 can expire at the first router; TTL 2 can survive the first router and expire at the second; TTL 3 can expose the third, and so forth.
IPv6 uses a Hop Limit field for the corresponding hop-count behavior. The important reasoning is the same: the tool controls how far each probe can travel and uses returned evidence to infer responding points along the path.
Follow three probes to see why successive routers appear
The source associates each response with the probe that produced it and displays the responding address and timing information. Repeating probes at a given TTL can produce several timing columns or even different responding routers when load balancing or path variation is involved.
Different implementations may send UDP, ICMP Echo, or TCP probes. That changes what devices and filters see and can change the destination's final response. The progressive TTL/hop-limit technique—not one specific transport—is the transferable concept.
24 traceroute interpretation flashcards
These are evidence cards rather than vocabulary cards. Filter the deck to drill mechanism, asterisks, latency, destination behavior, path interpretation, loops, or troubleshooting.
A silent hop is missing response evidence—not proof of a forwarding failure
Hop 5 did not provide the expected replies, but hops 6 and 7 did. Those later responses are extremely valuable: the probes traveled beyond the silent position. Whatever happened at hop 5, the trace does not support the claim that traffic could not pass it.
Possible explanations include response filtering, rate limiting, control-plane policy, or a device that forwards transit traffic without returning the expected traceroute response. The right interpretation is narrow: “No response was observed for these probes at TTL 5.”
Contrast that with a trace where every later TTL also receives no response. That pattern deserves investigation, but it still does not identify a cause by itself. The last responding router, the next router, a firewall, a return-path problem, or response suppression farther downstream can all produce similar visible boundaries.
One high intermediate time does not prove that hop is slowing user traffic
If hop 4 were truly imposing roughly 175 milliseconds of transit delay on every packet, you would expect that added delay to influence later observations too. Instead, later responding hops return to much lower values. A more cautious explanation is that hop 4 answered the traceroute-related control traffic slowly while forwarding transit traffic without the same penalty.
A latency increase becomes more persuasive when it begins at one point and remains elevated through subsequent hops and the destination, especially when the pattern repeats and matches the user's end-to-end symptoms. Even then, traceroute is evidence to combine with other measurements, not an automatic congestion detector.
The trace can finish with different messages because the probe method differs
UDP-style trace
Traditional implementations can send UDP probes toward unlikely destination ports. Arrival may be indicated when the destination returns ICMP Port Unreachable.
ICMP-style trace
An implementation using ICMP Echo probes may receive an Echo Reply from the target when the probe arrives.
TCP-style trace
TCP probes can produce a TCP response or other evidence associated with the target and selected port.
This matters when a firewall treats ICMP, UDP, and TCP differently. Two trace tools aimed at the same host can produce different visible results without the underlying IP route having changed. Before comparing traces, know which probe behavior the tool uses.
The first responding router is a checkpoint, not automatically “the Internet router”
On a typical routed LAN, the first responding hop is often the endpoint's local default gateway because that is the first router to decrement the probe's TTL. But VPNs, tunnels, host routing, virtual networking, response policy, or unusual designs can complicate the visible result.
If an expected first hop is absent, start close to the source: verify the endpoint's IP address and prefix, selected route/default gateway, link or Wi-Fi association, VLAN placement, and whether the first-hop device responds to the chosen probe type. If ordinary remote communication works despite a silent first line, response suppression is more plausible than a dead gateway.
For a gateway-specific failure pattern, use Wrong Default Gateway Symptoms. Traceroute is most useful after you understand which route the endpoint should select.
A silent traceroute hop is a perfect example of why students must separate missing evidence from evidence of failure. If later hops respond, the silent device may still be forwarding traffic normally while declining, filtering, rate-limiting, or deprioritizing the traceroute response. Explore this and other diagnostic traps in the guide to network evidence that looks wrong but may not be, including ping, ARP, DNS, DHCP, routing, firewall, wireless, and performance examples.
Repeated router patterns are stronger evidence than repeated asterisks
This alternating pattern suggests that packets may be cycling between two routing decisions. Each pass consumes TTL until a probe expires. The trace does not tell you which route statement is wrong, but it gives a much more specific hypothesis than “the network is down.”
Next, inspect the route to the destination on the repeating devices. Router A may point the prefix toward Router B while Router B points the same destination back toward Router A. A bad summary, missing specific route, redistribution issue, or incorrect static route can create that behavior. Confirm with Routing Table Analysis Practice rather than changing routes from the trace alone.
The visible path can change without proving instability
Routing decisions are made independently at multiple devices, and the path from source to destination does not have to match the path used by replies. Traceroute therefore cannot be read as a guaranteed two-way topology map. A firewall or other stateful device can make this distinction operationally important because it may care about which direction or session state it observes.
Load balancing adds another complication. Repeated probes can be distributed across equal-cost or otherwise parallel paths, causing different router addresses to appear at the same TTL or causing two runs to differ. That variation can be legitimate. Before calling it a route flap, look for stable alternate branches and correlate the variation with actual packet loss or application failure.
When comparing traces, control the source and destination. A trace from another VLAN, VPN-connected laptop, or different site may legitimately take another path because its routing and policy context is different.
A working destination can turn a failing trace into much higher-information evidence
Working target
Failing target
The shared first three hops become a control. The paths diverge after that point, so changing the client's local cable, DNS server, or first-hop gateway is less compelling than investigating the route/policy associated with the divergent destination path.
Be careful with the conclusion: divergence is expected when destinations live in different networks. The value is not that “hop 4 is wrong,” but that the common local path has passed the same test for both destinations. Your next evidence should focus where routing choices cease to be shared.
Reaching the target narrows the problem above basic IP routing
If traceroute produces convincing evidence that probes reach the destination, yet a web application still fails, the trace has done something useful: it has weakened the hypothesis that no routed path exists at all. It has not proven that TCP port 443 is permitted, the web service is listening, TLS succeeds, authentication works, or the application dependency chain is healthy.
Move upward deliberately. Test the required transport/service, inspect firewall rules, confirm the application port, and compare with a known-good service. Do not keep changing routes merely because the original user-facing symptom remains.
The same principle works in reverse. If a trace cannot establish destination arrival, do not claim the server is down. The missing evidence may be caused by filtering of the trace probes even while the actual application protocol is allowed.
Translate a trace pattern into the next evidence—not a premature verdict
| Observed pattern | What it supports | What it does not prove | High-value next evidence |
|---|---|---|---|
| One silent hop, later hops respond | Probes traveled beyond the silent position | That the silent router failed | Continue path analysis; compare actual service behavior |
| Latency spike disappears at later hops | Intermediate response handling may be slow | Persistent transit congestion there | Destination latency, repeated tests, loss/throughput evidence |
| A-B-A-B repeating routers | Possible routing loop | Which configuration is wrong | Routing tables on A and B |
| Destination appears, application fails | Useful routed-reachability evidence | Required service/port works | Port, firewall, service-state tests |
| Trace ends after enterprise edge | Boundary is beyond local interior path | Provider outage or edge failure specifically | Edge route, adjacency, policy, upstream evidence |
Swipe horizontally to see the full table.
The strongest answer separates observation, inference, and next test
Suppose a trace shows hops 1–4, then an asterisk at hop 5, then hops 6–9 including the destination. The observation is that no expected reply was recorded for hop 5 while later TTL probes produced responses. The justified inference is that hop 5's silence does not represent a complete forwarding stop. The next action depends on the original symptom; if the destination application works, there may be nothing to repair at hop 5.
Now suppose the pattern repeats Router A and Router B until probes expire. The observation is repeated responding addresses at increasing TTL values. The inference is a possible forwarding loop. The next test is to inspect the route to the destination on those routers and determine whether each sends the prefix toward the other.
This three-part format prevents a common error: promoting a clue into a cause. Traceroute is especially powerful when you state exactly what the output proves, what remains unresolved, and which evidence would distinguish the remaining explanations.
Traceroute can cross a device without telling you every function that device performs
A routed boundary may also perform firewall filtering, address translation, tunneling, or other policy functions. The address shown in a trace identifies a responding interface or device context; it does not automatically reveal every transformation applied to the user's application traffic. That is why a trace reaching an edge device does not prove that NAT state exists for the required flow or that the application's transport port is permitted.
Probe type matters here. A policy may permit established web traffic while treating ICMP Time Exceeded, UDP probes, ICMP Echo, or unusual TCP probes differently. When the actual application succeeds but traceroute looks incomplete, do not “repair” the network solely to make every hop answer. When the application fails too, compare policy and session evidence with the trace boundary.
The highest-information question is not “Why is there an asterisk?” but “Does the missing traceroute response correlate with failure of the traffic I actually care about?” That keeps the diagnostic goal tied to service delivery rather than cosmetic completeness of a tool's output.
Change one dimension at a time to make traceroute more diagnostic
Same source, two targets
Trace a working and failing destination from the same endpoint. Shared hops provide a local-path control; divergence focuses attention on destination-specific routing or policy.
Same target, two sources
Trace the same destination from two source subnets. If one path succeeds and another fails, compare their gateways, policies, route domains, VPN state, and return paths.
Same endpoints, different probe method
Where tools permit it, compare probe types carefully. A difference can reveal filtering or response-policy behavior, but it does not mean the IP topology physically changed between tests.
Controlled comparison is stronger than collecting many unrelated traces. Each experiment should be chosen to separate hypotheses. If two clients share the same access switch but use different VLANs, their differing traces can expose a routing or policy boundary. If two targets share the first five hops but diverge at the provider edge, local endpoint changes become less compelling.
Connect traceroute evidence to routing and CLI diagnosis
Related troubleshooting deep dive
For a narrower evidence-based scenario, use Traceroute Failure Location Analysis: Where Did the Path Actually Break?. It includes a free interactive reasoning activity and step-by-step diagnostic evidence.