Troubleshooting Latency, Jitter and Throughput
Performance complaints need measurement before action. Distinguish latency from jitter from loss, because each points at a different cause and remedy.
Exam tip. Correlate symptoms with time of day. A problem that appears at predictable hours is capacity, not a fault, and the answer involves QoS or more bandwidth rather than replacing hardware.
Identifying Failed Network Hardware
Sometimes the fault really is the hardware. Substitution and error counters are the evidence that distinguishes a failing device from a misconfiguration.
Exam tip. When a PoE device fails to power on and others still work, check the switch PoE budget before suspecting the device. Budgets are consumed cumulatively.
Troubleshooting Client-Side Network Problems
Not every network complaint is a network fault. Establishing whether one client or many are affected is the fastest way to decide where to look.
Exam tip. Scoping is the highest-value first step in any network scenario. A single affected user rules out core infrastructure immediately and saves you from the distractor answers.
Escalation, Verification and Documenting Outcomes
The final steps of the methodology are tested as often as the diagnosis itself. Knowing when to escalate, and what verification and documentation actually require, earns straightforward marks.
Exam tip. Verification always precedes documentation, and documentation is always last. Questions that place you immediately after implementing a fix are asking for verification.
Diagnosing Cabling and Physical Layer Faults
Objective 5.2 covers cable problems. Each fault has a characteristic symptom, and knowing which tool identifies which fault is half the answer.
Exam tip. A working link with dreadful performance and logged collisions is duplex mismatch, not a bad cable. Setting both ends to auto-negotiate, or both to the same fixed setting, resolves it.
Troubleshooting Switching and VLAN Problems
Layer 2 faults show up as devices that cannot reach anything, reach the wrong things, or bring the network down entirely. Each has a specific configuration cause.
Exam tip. The signature of an MTU problem is that basic connectivity tests pass while real data transfers fail. Standard ping uses small packets and will not reveal it.
The Network Troubleshooting Methodology in Order
Objective 5.1 asks you to explain the troubleshooting methodology, and the exam tests the steps in sequence. Questions frequently give a scenario mid-process and ask what comes next.
Exam tip. Documentation is always the last step and verification always precedes it. If a question describes a fix just applied and asks what comes next, the answer is verify, not document.
Command-Line Tools for Network Troubleshooting
Objective 5.5 tests diagnostic commands. Learn what each proves rather than its syntax, because questions ask which command would confirm a particular hypothesis.
Exam tip. A failed ping does not prove a host is down, because ICMP is often blocked by firewalls. Expect questions where this distinction is the point.
Troubleshooting Wireless Connectivity and Performance
Wireless faults divide into coverage, interference, capacity and authentication. Identifying which category the symptom falls into determines the fix.
Exam tip. Use the affected population to classify the fault. All users equals a shared cause such as interference or the access point; one user equals a client-side or credential problem.
Troubleshooting DHCP, DNS and Addressing Problems
Service faults produce recognisable signatures. The APIPA address and the name-versus-address test resolve the large majority of these scenarios.
Exam tip. Scope exhaustion has a distinctive signature: existing clients keep working because they already hold leases, while new arrivals get nothing.
Troubleshooting Routing and Reachability
Routing faults present as selective reachability - some destinations work and others do not. Traceroute and the routing table resolve nearly all of them.
Exam tip. If some services between two hosts work and others do not, the cause is a filter or ACL, not a routing or cabling fault. Routing failures are not protocol-selective.