Build a reachability explanation from layered evidence

Start by reproducing the application's exact name and address-family choice, then verify the answer it actually uses. Querying a different resolver or forcing IPv4 can be a useful comparison, but label the changed variable. Once an address exists, inspect the selected route and relevant policy table, its resolved next hop, and local neighbor state. A packet capture showing that the request never leaves the source host changes the next action: distant BGP inspection is unlikely to explain a local configuration or allocation failure.

Continue outward with paired observations. A request seen before a translator but not after it suggests inspecting allocation and filtering there; a request arriving at a server without a reply suggests checking server policy, listener state, or return routing. Absence in a capture is meaningful only if the capture point, filter, time window, and offload behavior are understood. Record a successful control with one variable changed, such as a nearby destination in the same prefix or a different packet size, to sharpen the hypothesis.

Traceroute-style probes vary IPv4 TTL or IPv6 Hop Limit so routers may return time-exceeded responses at successive distances. A missing response can reflect rate limiting, filtering, a router that forwards traffic while declining to answer, or a failed return path for the ICMP message. If later hops respond, an earlier star is not proof that the earlier router dropped all transit packets. Likewise, loss of diagnostic replies does not automatically equal loss of application traffic, because the traffic classes and processing paths can differ.

Responses can travel back by a different route, so a displayed round-trip time includes an unobserved return component. Load balancing may also send different probes along different paths, and tunnels can hide or alter visible hop structure. Compare probe protocol and flow identifiers deliberately; do not assemble one sequence of independently sampled hops into a guaranteed single flow path. Use source and destination captures, interface counters, and application-level checks to test the proposed explanation. A convincing diagram is not stronger evidence than the packets that support it.

If small exchanges work while larger ones stall, investigate path MTU behavior, filtering of required ICMP information, encapsulation overhead, and transport retransmissions. IPv6 routers do not fragment transit packets; packet-too-big feedback helps the source adapt. IPv4 behavior depends on fragmentation rules and the Don't Fragment flag. A size-dependent symptom is evidence for a class of mechanisms, not proof of one blocked message: capture the actual packets and returned errors, and account for offloads when interpreting packet sizes on a host.

The probability lab helps plan repeated probes under a limited independent-loss hypothesis. Set p as per-probe failure probability and n as probe count; predict the chance of zero observed failures and compare the bar. Real bursts and shared paths violate independence, so retain timestamps and group observations by source network, family, destination prefix, and packet size. The lab cannot identify a failing router. It shows why a short clean sample is weak evidence for intermittent reliability and why mechanism-directed tests outperform indiscriminate repetition.