Network Reliability Starts by Naming the Failure Domain

Resolve the symptom into DNS, routing, transport, policy, ingress or application before changing configuration.

I keep this as a field note because the failure mode is easy to misclassify: multiple layers are changed at once because the symptom is simply site unreachable. The useful move is to identify the boundary first, then change only the layer that owns it.

What I model

The system is easier to debug when intent, observation and transport are not collapsed into one state. For this case, my rule is simple: Change one failure domain at a time and keep the evidence.

Implementation pattern

Walk name -> address -> route -> port -> policy -> ingress -> application and stop at the first failed contract.

I prefer a small explicit contract over a clever implicit one. That gives logs, tests and dashboards something concrete to verify and keeps unrelated layers from compensating for each other.

What I verify

• each probe answers one question
• changes tie to evidence
• post-fix verification repeats the failing probe

Failure handling

When one of those checks fails, I preserve the failing evidence before restarting or changing configuration. The first broken contract determines the next investigation. That keeps troubleshooting causal instead of turning it into a sequence of guesses.

What I keep

Change one failure domain at a time and keep the evidence. The specific tools can change, but that ownership boundary remains useful across firmware, networks and infrastructure.