CompTIA Network+ guideNetwork troubleshooting
CompTIA Network+ Troubleshooting Methodology: The Seven Steps on N10-009
On CompTIA Network+ N10-009, the troubleshooting methodology is objective 5.1. Here are the seven steps in order, what each one prevents, three worked network cases that stop at the NEXT decision, and the traps that cost points.
Short answer
Yes. On CompTIA Network+ N10-009, the troubleshooting methodology is objective 5.1, and it has seven steps: identify the problem, establish a theory of probable cause, test the theory, establish a plan of action and identify potential effects, implement the solution or escalate, verify full system functionality and add preventive measures, and document findings, actions, outcomes and lessons learned. Scenario questions usually test the order by asking what to do next. Once a theory is confirmed, planning comes before any change.
The methodology is objective 5.1 on N10-009
For CompTIA Network+ N10-009, the troubleshooting methodology is a formal exam objective. Objective 5.1 in the version 4.0 objectives asks you to "explain the troubleshooting methodology," and Network Troubleshooting, the domain it opens, is the largest on the exam at 24%. The other four objectives in that domain, 5.2 to 5.5, cover cabling, network services, performance and tools. The methodology is the order you apply them in.
Expect scenario questions that describe part of a troubleshooting story and ask what the technician should do first or next. Reciting the list helps only if you also know why each step sits where it does.
The seven steps, and what each one prevents
The steps below follow objective 5.1's order. The middle column groups the sub-steps by purpose in plain words. The right column is the mistake each step exists to stop.
| # | Step | What you do | What it prevents |
|---|---|---|---|
| 1 | Identify the problem | Gather facts: ask users, list the symptoms, find out what changed, reproduce the fault if you can. If there are several problems, separate them and work each one on its own. | Fixing the wrong problem, or two problems tangled into one |
| 2 | Establish a theory of probable cause | Start with the obvious. Pick an approach: up or down the OSI model, or divide and conquer. | Random changes with no hypothesis |
| 3 | Test the theory to determine the cause | If the test confirms it, decide the next steps to resolve it. If not, form a new theory or escalate. | Acting on a guess |
| 4 | Establish a plan of action and identify potential effects | Decide the exact change, what else it touches, when to make it, and how to back out. | A fix that causes a bigger outage |
| 5 | Implement the solution or escalate as necessary | Make the planned change, or hand it to whoever has the access or authority. | Working outside your access or authority |
| 6 | Verify full system functionality and implement preventive measures if applicable | Confirm the original symptom is gone and nothing else broke, then make a repeat less likely. | Closing a ticket that is only half fixed |
| 7 | Document findings, actions, outcomes and lessons learned | Record what you found and did. The objective says to do this throughout the process, not only at the end. | Losing the history the next technician needs |
Two details in the N10-009 wording are easy to miss. Escalation appears twice, as an option when a theory fails in step 3 and as an option at implementation in step 5. And step 7 says "throughout the process," so a ticket with notes from the first call is following the method, not jumping ahead.
Choosing an OSI approach in step 2
Objective 5.1 names three ways to build and test theories:
- Bottom to top. Start at the physical layer: link lights, cabling, interface status, then move up. A good fit when a link is down or errors are climbing.
- Top to bottom. Start at the application: does the service answer, does the name resolve, then move down. A good fit when one application fails and everything else works.
- Divide and conquer. Start in the middle, often with a ping to the gateway at layer 3. If it works, look up the stack. If it fails, look down.
The OSI model guide maps symptoms to layers, and the command-line tools guide shows which tool tests which layer.
Case 1: a VLAN change after a maintenance window
The three cases below are original and simplified. Each stops at a different decision point.
On Saturday night, the network team moved the third-floor printers from VLAN 30 to a new VLAN 35. On Monday at 8:00, nobody on the third floor can print. Users on other floors print normally.
- Identify. Only third-floor printers fail. The obvious change is Saturday's VLAN work, and the change record names the switches involved.
- Theory. The uplink trunk from the third-floor access switch does not carry VLAN 35, so the printers are isolated on their own switch.
- Test.
show vlanon the access switch shows the printer ports in VLAN 35.show configfor the uplink shows a trunk that allows VLANs 10, 20 and 30, but not 35. The theory is confirmed.
What comes NEXT? Not typing the fix straight away. The next step is step 4: plan the change and identify its potential effects. That uplink carries every VLAN on the floor, so a mistake while editing its allowed list could cut off far more than the printers. The plan names the exact change, who approves it under change management, when it happens, and how to back it out. Then the technician implements it, verifies by printing from the third floor and checking that the other VLANs still pass, and updates the documentation for that trunk.
Case 2: one floor loses DHCP
At 9:05, fourth-floor users report "no network." Their laptops show addresses in 169.254.0.0/16, the IPv4 link-local range a host assigns itself when it gets no other configuration (RFC 3927). Floors 1 to 3 are fine. In the same hour, someone on the second floor reports that a conference-room display flickers.
- Identify. The display is a separate problem, so it gets its own ticket. Objective 5.1 says to approach multiple problems individually. The fourth-floor fault started around 8:50, and the change log shows nothing for that floor.
- Theory. Question the obvious: the fourth floor's DHCP scope ran out of addresses.
- Test. The DHCP server shows the fourth-floor scope 40% used, and its log shows no requests at all from that subnet since 8:50. The theory is not confirmed.
What comes NEXT? Step 3 gives two choices when a theory fails: establish a new theory or escalate. The evidence suggests a new theory, that requests from the fourth floor are not reaching the server, because of the floor's uplink or the DHCP relay setting on its gateway. The help-desk technician has no access to those devices, so escalating is the right call here, with the evidence attached: the start time, the link-local addresses, the scope usage and the empty request log. The service and performance issues guide covers address pool exhaustion and relay faults in more detail.
Case 3: a link with rising CRC errors
Since a rack was rearranged on Tuesday, users in the east wing report slow file copies. show interface on the access switch's uplink port shows the CRC error counter climbing whenever a large copy runs.
- Identify and theory. Objective 5.2 lists CRC errors among interface counters, next to cable issues such as signal degradation and improper termination, so a bottom-to-top approach starts with the physical path. The rack move is the obvious change. Theory: the uplink patch cord was damaged in the move.
- Test. Even the test needs a short disconnect, so it is agreed with the wing's manager first. During a five-minute window, a cable tester reports a fault on the patch cord. The theory is confirmed.
- Plan and implement. Replace the cord at 12:30 with a new, labeled one routed away from the rack door, accepting the same brief outage. The link comes back up.
What comes NEXT? Step 6. A link that is up is not the same as a fixed problem. Clear the counters, run a large copy, and confirm the CRC count stays flat and the users' copies are back to normal speed. Then add the preventive measure: keep cords clear of the door hinge, and add the rack to the inspection checklist. Finally, complete the documentation with the cord, the counter readings before and after, and the cause. The cable and interface issues guide covers the other counters and port states.
Once you can say why each case stopped where it did, choose the step after a confirmed theory in a Network+ scenario. The free mixed set includes an item built on that decision, with an explanation for every option.
NEXT-step traps on N10-009 questions
| Trap | Why it is wrong | What the methodology says instead |
|---|---|---|
| Implementing as soon as the theory is confirmed | It skips planning and potential effects | Step 4 comes first: plan the change and its effects |
| Escalating a routine fault without gathering available evidence | It may hand off a problem you can diagnose within your role | Gather evidence and test when authorized. Escalate immediately for an urgent safety/security issue or work outside your authority |
| Asking users again after the cause is confirmed | Gathering information belongs to step 1 | Move forward to the plan |
| Treating the link coming back up as success | The original symptom may remain, or something else may break | Step 6: verify full functionality and add preventive measures |
| Writing everything up only at the end | The objective says to document throughout | Keep notes from the first report onward |
| Working two complaints as one ticket | Their causes can be unrelated | Step 1: approach multiple problems individually |
How A+ and the V10 draft treat the same method
The contrast is worth knowing if you hold, or are studying for, other CompTIA exams:
- CompTIA A+ 220-1201. The A+ V15 objectives (version 3.0) describe a six-step methodology, with planning and implementing combined into one step, and state that it is not tested and is not a formal objective. Passy's guide to whether the methodology is on A+ covers that exam.
- CompTIA Network+ N10-009. Objective 5.1, with seven steps, planning and implementing as separate steps, and escalation named at two points.
- The Network+ V10 draft. The September 2026 draft objectives (document version 1.2) do not list the methodology anywhere. That is a draft, and the N10-009 vs N10-010 guide tracks it. For an N10-009 appointment, learn all seven steps.
Trust the source
Official sources
Exam policies can change. Use these primary sources for the most current details.