Walk me through how you troubleshoot a network problem.
Show the answer
Say this first
I define the problem before I touch anything: what exactly fails, for whom, since when, and what changed. Then I gather facts, rank the likely causes, and test one hypothesis at a time. I pick the method to fit the symptom: bottom-up for physical symptoms, top-down when one application fails, divide and conquer from a ping when I have no strong lead, or follow the path hop by hop. I verify the fix from the user's side and write down the root cause, not just what I changed.
Go deeper
The loop
- Define the problem. Turn "the network is slow" into "users on floor 3 see 5-second page loads to the CRM since 09:10".
- Gather facts. Scope, timing, recent changes, syslog, monitoring graphs, one reproducible example.
- List likely causes. Rank them by how likely they are and how cheap they are to test.
- Test one hypothesis at a time. Change one thing, observe, and revert it if it made no difference.
- Fix and verify from the user's point of view, not only from the router.
- Document. Timeline, cause, fix, and the follow-up actions that stop it happening again.
Picking a method
| Method | Start at | Best when |
|---|---|---|
| Bottom-up | Layer 1 | new install, link lights, interface errors |
| Top-down | The application | one app fails while others work |
| Divide and conquer | Layer 3, usually a ping | no strong lead; one test rules out half the stack |
| Follow the path | The source, hop by hop | multi-hop paths, firewalls, NAT, routing |
| Compare with working | A known-good device or config | one site or port fails, a similar one works |
| Swap components | Suspect hardware | cable, optic or NIC is the likely culprit |
What a senior answer adds
Read before you write. Capture show output before any change, keep a rollback ready, and tell the
incident lead before touching production config. Time-box each hypothesis so you do not sink an hour into
a guess.
They will ask next
How do you avoid making an outage worse while you troubleshoot?
Read-only commands first. Save the current state before changes. One change at a time, each with a rollback. On a remote device I use a safety net such as
reload in 10or an archived config andconfigure replace, so a mistake that cuts my access undoes itself.When do you escalate?
When the fault is outside my access or skill, when the impact is growing faster than I can restore it, or when my time box runs out. I escalate with facts: what fails, the scope, what I tested and what each test showed.
Traps
- Jumping to a fix before the problem is defined.
- Changing several things at once, so nobody learns which one fixed it.