SOP-003: Network Troubleshooting Runbook¶

Sep 29, 2026 · @Lloyd

1. Document Control¶

2. Purpose and Scope¶

This runbook applies one repeatable method to every network fault, so diagnosis follows evidence instead of guesses. It covers the home office network, the Windows workstation, remote access over Tailscale, and the ISP uplink.

Each case in Sections 5 to 7 is a real incident, recorded in the method's own seven steps. New incidents are added the same way.

3. The Seven-Step Method¶

Follow the steps in order. If a theory fails at step 3, return to step 2; if no theory holds, escalate.

1. Identify the problem. Gather information, question users, identify symptoms, determine what changed, duplicate the problem, and approach multiple problems one at a time.
2. Establish a theory of probable cause. Question the obvious; work top-to-bottom or bottom-to-top through the OSI model, or divide and conquer.
3. Test the theory. If confirmed, move on; if not, form a new theory or escalate.
4. Establish a plan of action and identify potential effects of the fix.
5. Implement the solution or escalate as necessary.
6. Verify full system functionality and, if applicable, implement preventive measures.
7. Document findings, actions, outcomes, and lessons learned.

Source: CompTIA Network+ N10-009 exam objectives, 5.1. Verify wording against the current objectives PDF before marking Reviewed.

4. Diagnostic Commands by Layer¶

Work bottom-up by default: each layer that passes rules out everything beneath it.

5. Case 1: ISP WAN Outage After Power Interruption¶

Outcome: fault was upstream at the ISP; no local configuration was changed.

6. Case 2: RDP Session Hangs at "Securing connection"¶

Outcome: two stacked causes, found one at a time. Fixing the first did not clear the symptom, which is why step 3 loops back to step 2.

7. Case 3: VPN Client Breaks Local Inference¶

Outcome: the error message named the wrong component. Questioning the obvious (step 2) found the real cause.

8. Escalation and Case Template¶

Escalate when the fault is outside your control (ISP, vendor, client-owned systems) or no tested theory holds. When escalating, give the evidence, not the guess: what layer passes, what fails, and what you already ruled out.

Record each new incident in this format:

## Case N: <symptom in plain words>

Outcome: <one sentence>

| Step | What happened |
| --- | --- |
| 1 Identify | Symptoms, what changed, can it be reproduced |
| 2 Theory | Probable cause and the OSI layer |
| 3 Test | Command or check run, and the result |
| 4 Plan | Fix and its side effects |
| 5 Implement | What was changed, or who it was escalated to |
| 6 Verify | Tests passed; preventive measure added |
| 7 Document | Lesson learned; which SOP was updated |

9. Control Mapping and Revision History¶

These cases are operational faults, not security incidents, so the mapping is to documented operating procedures and maintenance records rather than to incident response controls. If a case turns out to be a security incident, hand it off to the incident response process (see SOP-006). Verify each reference against the published text before marking Reviewed.