Field Guide · Networking
The habits a veteran runs on before reaching for a tool. Where the rest of the Networking family explains how things work and the Misconceptions guide catches false beliefs, this one is the method between them — the small set of stances that decide whether an incident takes ten minutes or all afternoon. None of it is clever; all of it is the discipline that clever people skip under pressure and regret.
Most of what separates a fast diagnosis from a slow one isn't knowledge of protocols — the other guides cover that — it's a handful of reflexes about how to move: treat blame as a claim to be tested, suspect change first, halve the problem instead of guessing at it, believe measurements over assumptions, protect your evidence and your access, and hand off with data. Each maxim below is stated with the mechanism that makes it true, so it's a tool rather than a slogan.
The network is the default suspect for every problem it didn't cause, because it sits between everything and is the one layer most users can't see. The sage's first move is to demote that blame from a diagnosis to a hypothesis — one that has to earn its place with a check like any other. Often the fault is a service bound to loopback, an expired credential, a full disk, an application bug; the packets were fine the whole time.
This cuts both ways. Just as "it's the network" is an unproven claim, so is "it's not the network" when it comes from the network team's reflex to deflect. Both are hypotheses. The discipline is symmetric: whoever asserts a cause owns the check that would confirm it, and "not my layer" is only credible with the evidence that the layer is clean.
The single highest-yield question in troubleshooting is "what changed?" A system that worked and now doesn't was almost always changed — a config push, a patch, a deploy, a cable, a certificate that expired, a DHCP lease that lapsed, a scheduled job that fired. Start at the change log, not the packet capture. But hold the discipline that separates a lead from a verdict:
A guess tests one candidate; a bisection eliminates half the candidates. Split the path at its midpoint, test there, and the result tells you which half to keep — then repeat. A path of hundreds of hops and components collapses in a handful of tests instead of a linear crawl, and each test is chosen to be maximally informative rather than merely convenient.
"Should work" is not "does work." A configuration that reads correctly can be shadowed by an earlier rule, served from a stale cache, or bypassed by a different code path — so the sage tests the actual path rather than reasoning about the intended one. When the measurement and the mental model disagree, the mental model is the hypothesis, and it loses.
The companion habit is to credit each signal with exactly what it proves and no more — the discipline the Misconceptions guide is built around. A successful ping proves Layer 3 reachability; a listening port proves a process is bound; neither proves the application is healthy or that you're authorized. Stacking narrow "yes" answers into a broad one is how confident people reach wrong conclusions quickly.
"Trust but verify" only works if you verify from where the problem lives. Testing from the jump box proves the jump box can reach it — not the user, who has different routing, DNS, identity, and firewall context. Reproduce from the client's actual position, or you're answering a different question than the one you were asked.
You cannot call a reading abnormal without knowing what normal looks like. Capture the baseline while the system is healthy — interface counters, typical latency, the working config, a reference capture — so that when something breaks, "different" is a measurement rather than a feeling. The time to learn your normal RTT and error rates is not during the incident.
This matters most for the hardest class of problem: the intermittent one. Intermittent faults clear on their own and take the evidence with them, which is exactly why the reflexive reboot is so costly — it "fixes" the symptom by destroying the proof, guaranteeing a second incident with no more information than the first. Resist it. Instead, instrument and wait: continuous tools that sample over time (mtr, pathping, a running capture, logged counters) catch what a single-shot test at a quiet moment never will.
When opinions conflict and everyone is sure, the packet capture decides; it is usually the most reliable artifact in the room. But it is bounded evidence: it sees only what crossed that vantage point, drops frames under load, truncates at the snaplen, and shows rewritten addresses through NAT and proxies. So capture as close to the problem as you can, and remember the rule that keeps it honest — the absence of a packet is not proof the event didn't happen, only that it didn't cross your capture point.
Change one thing at a time, reversibly, with a backout ready. If you change three things and the problem clears, you've learned nothing about which one mattered and you can't cleanly undo the other two — attribution requires isolation. The slow-looking discipline of one change, one test is almost always faster than the fast-looking flailing it replaces.
Two guardrails ride alongside. Don't lock yourself out: before any deny rule on a live remote device, confirm a rule permits your own management access ahead of it, keep out-of-band access, and arm an automatic rollback so a mistake self-heals instead of stranding the box. And fail safe and visible: decide deliberately whether a control fails open or closed for the threat you care about, and make failures loud — a silent failure is the worst outcome, because it wears the appearance of success while protecting nothing.
Name the threat model. "Is this secure?" is unanswerable; "does this stop an on-path eavesdropper, a stolen credential, a lateral move from a compromised host?" can be answered. A defense is only evaluable against a defined adversary, so least privilege, defense in depth, and assuming breach are means to named ends, not virtues you accumulate. State the adversary, then judge the control against it — and say what it leaves open.
Simplicity is a feature. Complexity is where faults hide and where the 3 a.m. outage lives. The clever configuration that only its author understands is a liability the moment its author is asleep; the boring, legible design that a tired stranger can follow is more robust than the elegant one that assumes everything goes right. Prefer the arrangement you can explain in one breath.
Hand off with data, and leave a trail. Document as you go, escalate with evidence rather than impressions, and write the runbook entry while the fix is fresh. The measure of an incident isn't only that it got solved — it's whether the next person who hits it starts from your notes instead of from zero. A good runbook entry is the difference between a five-minute fix and a full re-investigation.
Blame is a hypothesis — symmetric, whoever claims a cause owns the check. Ask "what changed?" first. Bisect, don't guess. Measure, don't assume ("should work" ≠ "does work"), and from the client's real vantage. Change one thing, reversibly.
Take a baseline before you need it. For intermittent faults, instrument and wait — don't reboot the proof away. The capture decides when opinions conflict, within its vantage; absence of a packet isn't proof of absence.
Name the threat model — nothing is "secure" in the abstract. Simplicity is a feature; the config you can't explain will surprise you. Fail safe and visible. Hand off with data and a runbook entry.
These are stable operational heuristics, not version-specific facts, and each is the method behind a tool elsewhere in the collection: the bisection here is the Command Card's order of attack; "what changed?" and the one-hypothesis loop are the Triage Decision Trees' first fifteen minutes; "credit a signal with what it proves" is the whole of the Misconceptions guide; the capture's vantage limits come from the packet-capture coverage; and the lockout guardrail is stated on the Triage Trees. No unqualified assurance is intended — §07's point is precisely that a control is only meaningful against a named adversary, and every defense should be paired with the threat it addresses and the risk it leaves. Terms are in the Glossary; 00 · Start Here indexes the set.