Build the idea first, then use the next activity to check it.
A method for finding faults
A repeatable way to find a fault, so you are narrowing the problem down rather than guessing at it.
What you will be able to do
- Follow a fixed sequence instead of changing settings at random
- Use the layer stack to halve the search space with each test
- Change one thing at a time, and verify before moving on
Before this: You need to know what a host, a switch and a router each do - see "Hosts, switches and routers". Nothing else; this lesson is deliberately early.
Why it matters: Almost every lab in this path is a broken network you have to fix. Without a method you will change things until something works and never know what was wrong. With one, you will find the same fault in a fraction of the time, and be able to say what it was.
The difference between someone who fixes networks quickly and someone who does not is rarely how much they know. It is whether they are working through a method or trying things. A method is what turns a vague "the internet is down" into a specific broken setting.
The sequence
- Identify the problem: what exactly fails, and what still works?
- Establish a theory of probable cause, based on what the symptoms rule in and out.
- Test the theory with one command that would prove or disprove it.
- Fix one thing.
- Verify the original symptom is gone - not something adjacent to it.
- Note what it was, so the next person does not start from nothing.
Work up the layers
Test from the bottom up, because a fault low down produces confusing symptoms everywhere above it. There is no point investigating a routing protocol on an interface that is administratively down.
| Question | Command | If this fails |
|---|---|---|
| Is the interface up? | ip -brief link show | Stop here. Nothing above this matters yet. |
| Does it have the right address and mask? | ip -brief address show | A wrong mask makes a host misjudge what is local. |
| Can it reach its own subnet? | ping <neighbour on the same subnet> | The fault is local - address, mask, or the switch. |
| Can it reach its gateway? | ping <gateway> | The gateway address is wrong, or the router is not on that subnet. |
| Does the router know the way? | show ip route | A missing or wrong route. This is where most of these labs land. |
Halving the problem
reports that she cannot open anything on . Rather than logging into the server first, pings it from a host on its own subnet. If that works, everything about the server is fine and the fault is in the path between the two subnets - she has eliminated half the network with one command. If it fails, the server or its local segment is at fault and the routing between sites is irrelevant.
Terminology
- Symptom
- What the user observes. Not the fault - "email is slow" and "a route is missing" are different statements.
- Theory of probable cause
- A specific, testable guess. "Something is wrong with DNS" is not one; "the client has the wrong resolver address" is.
- Scope
- Who is affected. One host, one subnet, or everyone - each points at a different layer.
Key takeaways
- Establish what still works before investigating what does not; the boundary locates the fault.
- Test upward from the physical link - a low-level fault makes everything above it look broken.
- Turn a symptom into a specific, testable theory before touching any configuration.
- Change one thing, then verify against the original symptom.
- Scope tells you the layer: one host, one subnet, or everyone are three different faults.
Ready to keep going?
Create a free account to save your progress and take the knowledge check.