Reachability Is a Chain of Dependencies

When an application says “cannot connect,” the network may be blamed immediately.

That phrase is too broad to diagnose anything.

A better approach is to model the path as dependencies and find the first layer where the observed evidence stops matching the expected state.

Build the chain

For a simple client-to-server connection:

APPLICATION
   ↓
NAME / DESTINATION
   ↓
LOCAL ADDRESS
   ↓
ROUTE DECISION
   ↓
NEXT HOP / LINK
   ↓
REMOTE PATH
   ↓
TRANSPORT CONNECTION
   ↓
LISTENING SERVICE
   ↓
APPLICATION RESPONSE

A failure at any stage can look like “the website is down” from the user's point of view.

Systems reasoning asks which stage is actually supported by evidence.

Supplied incident: RNX Status Client

The fictional client should reach a fictional status service at 198.51.100.20:8080.

Baseline host state:

eth0: UP
address: 192.0.2.10/24
default: via 192.0.2.1

Baseline packet evidence:

client SYN
server SYN-ACK
client ACK
HTTP request
HTTP 200 response

Changed state:

eth0: UP
address: 192.0.2.10/24
default: via 192.0.2.99

Changed evidence:

route get 198.51.100.20 → via 192.0.2.99
next-hop resolution → failed
packet capture → repeated local attempts, no server response observed
application → timeout

Separate observation from mechanism

Observations

• interface is reported up;
• client still has expected local address;
• route selection points to 192.0.2.99;
• supplied next-hop resolution fails;
• no server response appears at the client capture point;
• application times out.

Hypothesis

The changed default route prevents the client from reaching the expected next hop in the lab model.

Limitation

The client-side evidence does not independently prove what the remote server was doing during the failed run.

That limitation does not make the hypothesis useless. It tells you how far the evidence reaches.

Why “ping works” is not a complete application test

A host responding to one network control protocol does not prove a particular application service is healthy.

Likewise, an application failure does not prove all IP connectivity is broken.

Different tests ask different questions.

Always map the test to the claim.

Examples:

No single row proves the entire system.

Lab: build the evidence ladder

You are given five fictional states. Put them in diagnostic order and explain what each adds:

A. HTTP 200 response from /status
B. route to 198.51.100.20 via 192.0.2.1
C. TCP SYN / SYN-ACK / ACK
D. eth0 up with 192.0.2.10/24
E. application resolved destination as 198.51.100.20

A reasonable chain is:

D → E → B → C → A

but your explanation matters more than the letters.

Then remove C while keeping the others before it. What can you still claim? You can describe local configuration and route selection, but you cannot claim the transport connection completed.

Controlled correction and retest

Restore the documented default route in the fictional model.

Retest should include:

1. local interface state;
2. route selection;
3. next-hop success;
4. transport handshake evidence; and
5. application response.

Why test all five?

Because fixing the route may reveal a second problem. A strong retest checks the original failure and the end-to-end required function.

Finish the Network Path Evidence Record

Submit:

1. host/interface baseline;
2. destination and selected route;
3. packet/transport observation;
4. first failed dependency;
5. primary hypothesis;
6. alternate hypothesis that is less supported;
7. one-variable correction;
8. end-to-end retest; and
9. limitation tied to your observation point.

A strong final claim:

In the supplied RNX client model, changing the default route from the unreachable lab next hop back to the documented gateway restored next-hop resolution, the TCP handshake, and the HTTP status response. The client-side evidence does not establish the remote server's state during the earlier failed interval.

That is the difference between “network broken” and a defensible network diagnosis.