Network Troubleshooting

Almost every question in this domain hands you a symptom ("the call breaks up", "the new desk can't get online", "the link light is on but nothing reaches the server") and asks for the next move. The single mental model that answers all of them is the OSI layer the fault lives on: a dead or out-of-spec cable is Layer 1, a frame that arrives corrupted or a VLAN that boxes a host in is Layer 2, a wrong gateway or a missing route is Layer 3, and a slow but reachable network is a performance problem measured on top of all three. Name the layer first and the right cause, the right tool, and the right fix usually fall out of it. The classic trap here is acting before you have isolated the layer (swapping a perfectly good cable because the symptom "felt physical"), which is exactly what CompTIA's seven-step methodology exists to prevent.

Read this page as a map and follow the five subtopics in order. Troubleshooting Methodology comes first because the seven-step process (identify, theorize, test, plan, implement or escalate, verify, document) is graded directly and frames everything else: investigation finishes before action. Cabling and Physical Issues is the Layer 1 and 2 floor: the 100 m copper limit, termination and TX/RX faults, interface error counters, and PoE budgets. Network Services Issues climbs to the Layer 2 and 3 configuration faults that cut a host off with a healthy link, such as an APIPA address, the wrong VLAN, or a missing route. Performance Issues covers the four named slowness faults (congestion, latency, packet loss, wireless interference) once reachability already works. Troubleshooting Tools then ties it together by matching each instrument, from ping to a time-domain reflectometer, to the layer its symptom lives on.

Across all five subtopics the same instinct wins: gather information and test the specific theory before you swap hardware or push a config change, and reach for the simplest tool that answers the question. That means running a continuous ping to confirm packet loss before blaming a router, using nslookup or dig to prove a name-resolution fault rather than guessing, and saving a protocol analyzer such as Wireshark for last, after the cheap command-line tools have narrowed the problem. The seven-step method encodes this discipline: a confirmed test advances to a plan, a disproven one loops back to a new theory or escalates, and verification plus documentation close the loop so the same fault does not recur. You rarely need an exotic answer; the methodical, least-disruptive step is the exam-correct one far more often than not.