Official Troubleshooting Methodology and Evidence Handling
Key Takeaways
- The troubleshooting process starts with identifying the problem and gathering information before changing the environment.
- A theory should be tested before a plan of action is implemented.
- Escalation is appropriate when the issue is outside authority, skill, access, safety, or business impact limits.
- Verification includes confirming full system functionality and applying preventive measures when appropriate.
- Evidence handling requires accurate documentation, timestamps, preservation, and chain of custody when security or legal review may be involved.
Troubleshooting Methodology
Troubleshooting is a repeatable decision process. Network+ questions often reward the answer that follows the method, not the answer that jumps directly to a favorite fix. The best first step is usually to gather facts, define scope, and avoid unnecessary change.
Standard Process
| Step | What it means | Example |
|---|---|---|
| 1. Identify the problem | Gather information, question users, identify symptoms, determine scope, check recent changes | Ask who is affected, what changed, and when the issue began |
| 2. Establish a theory | Use symptoms to form a likely cause | Suspect DNS if users can ping an IP but not a hostname |
| 3. Test the theory | Confirm or reject the likely cause | Query DNS directly and compare expected records |
| 4. Establish a plan | Choose a fix and consider impact | Schedule firewall rule change or replace failed cable |
| 5. Implement the solution | Apply the approved fix or escalate if needed | Change route, renew certificate, replace transceiver |
| 6. Verify functionality | Confirm service works and apply prevention | Test user workflow, monitor logs, update alerting |
| 7. Document findings | Record cause, actions, results, and lessons | Close ticket with evidence and final state |
The steps can loop. If a theory is disproven, establish a new theory or escalate. If a fix creates a new symptom, roll back according to change control and continue with evidence-based testing.
Identifying Scope
Scope changes the likely cause.
| Scope clue | Likely direction |
|---|---|
| One user affected | Endpoint, cable, switch port, user account, local DNS cache |
| One VLAN affected | Default gateway, VLAN assignment, DHCP scope, ACL, trunk |
| One site affected | WAN link, edge router, site firewall, local ISP, power |
| One application affected | DNS record, certificate, load balancer, server pool, firewall rule |
| All Internet access affected | Default route, ISP, edge firewall, NAT, DNS forwarders |
Do not assume the largest possible outage. A single disconnected patch cable and a failed core switch can both produce "cannot connect" reports, but the scope will be different.
Change and Escalation
Recent changes are strong clues. Firmware updates, firewall changes, new switch deployments, DHCP scope edits, certificate renewals, routing changes, and ISP maintenance can all explain sudden symptoms. However, correlation is not proof. Verify before changing more.
Escalate when:
- The issue exceeds your access or authorization.
- The impact is high or safety critical.
- The required action needs a change window or business approval.
- Evidence suggests a security incident.
- Specialized vendor, cloud, or carrier support is required.
- You have tested reasonable theories and need additional expertise.
Evidence Handling
Some network troubleshooting produces evidence for security, compliance, or legal review. Examples include packet captures, firewall logs, authentication logs, switch port mappings, wireless association logs, screenshots, exported configurations, and device images.
| Evidence practice | Why it matters |
|---|---|
| Preserve original data | Prevents accidental alteration |
| Record timestamps and time zone | Supports a reliable timeline |
| Document who collected evidence | Supports accountability |
| Hash files when appropriate | Shows evidence integrity |
| Use chain of custody | Tracks possession and transfer |
| Work on copies | Protects original artifacts |
| Limit access | Reduces disclosure and tampering risk |
In a normal performance ticket, evidence handling may be simple documentation. In a suspected compromise, preserve logs and packet captures before making destructive changes when feasible. If policy requires incident response involvement, escalate.
Common Traps
- Rebooting a device before checking logs or scope.
- Implementing a fix before testing a theory.
- Ignoring recent changes because they came from another team.
- Failing to verify from the user perspective after a fix.
- Closing a ticket without documenting what changed.
- Altering security-sensitive evidence without recording who handled it and when.
PBQ style: Put the troubleshooting steps in the most appropriate order.
Arrange the items in the correct order
A technician suspects a firewall rule change caused an outage but has not confirmed scope or gathered logs. What should happen next?
Which practices support evidence handling during a suspected security incident? Select three.
Select all that apply