Network troubleshooting: commands and method
Method first, then the command that answers the question
Network troubleshooting questions test two things: the order of the steps and which tool answers which question. The method, in the order CompTIA’s N10-009 outline lists it: identify the problem, establish a theory of probable cause, test the theory, establish a plan of action (including its side effects), implement the fix or escalate, verify full functionality and put preventive measures in place, then document what happened. The decision rule for any “what should the technician do next” question: take the step that follows the one already completed, and never jump to the fix before a theory has been tested.
The steps, and what each one means in practice
| Step | What it means | Trap |
|---|---|---|
| Identify the problem | Gather information, question users, identify symptoms, ask what changed, reproduce if possible, handle multiple problems one at a time | Skipping “what changed” |
| Establish a theory | Question the obvious first; work top-down or bottom-up through the OSI model, or divide and conquer | Theory is not yet a fix |
| Test the theory | Confirmed: decide next steps. Not confirmed: form a new theory or escalate | Changing things to “see if it helps” |
| Plan and implement | State the plan and its potential effects (outage windows, who is affected), then implement or escalate | Making the change before assessing the impact |
| Verify and prevent | Confirm everything works, not only the original symptom; add preventive measures | Closing the ticket when one user is fixed |
| Document | Findings, actions, outcomes, lessons learned | Treating it as optional |
Bottom-up starts at the cable and link lights (Layer 1), then addressing and VLANs, then routing, then services. Top-down starts at the application. Divide and conquer starts in the middle, usually with ping to the gateway, and moves up or down depending on the result. For layer background see OSI vs TCP/IP.
Which command answers which question
| Question | Windows | Linux or macOS | Router or switch (Cisco IOS style) |
|---|---|---|---|
| What IP address, mask, gateway and DNS server do I have? | ipconfig /all | ip addr, ip route (older: ifconfig) | show ip interface brief |
| Can I reach that host at the IP layer? | ping | ping | ping (extended ping sets source and size) |
| Where along the path does it stop? | tracert | traceroute | traceroute |
| Does the name resolve, and to what? | nslookup | dig, nslookup | not the device’s job |
| What connections and listening ports exist? | netstat -an (-o adds the process ID) | ss or netstat | show commands for the device itself |
| Which MAC belongs to that IP? | arp -a | ip neigh, arp | show arp |
| Which port learned that MAC, and which VLAN? | not applicable | not applicable | show mac address-table, show vlan |
| Is the interface up, and are there errors? | not applicable | not applicable | show interfaces (CRC, runts, giants, drops) |
| What does the traffic actually look like? | protocol analyzer | tcpdump | packet capture feature |
Facts worth knowing precisely. ping sends ICMP echo requests and reports the replies and round-trip times (Microsoft). tracert sends ICMP echo requests with incrementing TTL values; each router decrements the TTL, and the one that reaches zero returns an ICMP “time exceeded”, which reveals that hop (Microsoft). The Linux traceroute sends UDP probes by default; -I makes it use ICMP echo (traceroute man page). netstat -a lists connections and listening ports, -n shows numbers instead of names and -o adds the process ID (Microsoft). ipconfig /all, /release, /renew and /flushdns are documented on the ipconfig page. A failed ping proves less than it seems, because firewalls often drop ICMP.
Worked example: “the internet is down” for one PC
A user reports that no websites open. Using divide and conquer, a technician gathers facts (step 1) and finds a colleague on the same switch is fine, so the fault is local to this PC. The theory: the PC has a bad IP configuration. Test it:
C:\> ipconfig /all
IPv4 Address. . . . . : 169.254.37.8
Subnet Mask . . . . . : 255.255.0.0
Default Gateway . . . :
DHCP Enabled. . . . . : Yes
An address in 169.254.0.0/16 is a link-local address the PC gave itself because no DHCP server answered (RFC 3927). The theory is confirmed: the PC is not getting a lease. Now the second-level theories, tested one at a time: is the cable or port up (link light, show interfaces on the switch)? Is the port in the right VLAN (show vlan)? Is the DHCP scope exhausted (address pool exhaustion appears in the N10-009 outline)? Suppose the port is in VLAN 99 instead of VLAN 10. The plan: move the port to VLAN 10, which affects only that port. Implement, then verify: ipconfig /renew returns a 10.x address, ping to the gateway works, a name resolves with nslookup and a page opens. Last, document the wrong VLAN assignment and add a port-configuration check to the patching procedure. DHCP and DNS and VLANs and trunking explain the two failure points.
Which exams test this
| Exam | How it appears | Where on this site |
|---|---|---|
| N10-009 | Network Troubleshooting (24%, the largest domain): 5.1 methodology, 5.2 cabling and interface issues, 5.3 service issues (STP, VLANs, ACLs, routing, addressing), 5.4 performance, 5.5 tools and device commands | Network troubleshooting |
| 200-301 | v2.0 (from Feb 3, 2027): Switching and Network Access (25%), 2.4, troubleshoot Layer 2/3 connectivity with show commands, ping, extended ping, trace route and packet capture; Network Infrastructure and Connectivity (25%), 1.6, client connectivity checks on Windows, macOS and Linux. v1.1 (until Feb 2, 2027) has no equivalent objective of this kind | Switching and network access, Network infrastructure |
| 200-901 | Network Fundamentals (15%), 6.8: diagnose application connectivity (NAT problem, blocked port, proxy, VPN) | Network fundamentals |
| AZ-104 | Virtual networking (15 to 20%): troubleshoot network connectivity, which in Azure means Network Watcher tools rather than ping alone | Virtual networking |
| AZ-802 | Monitor and troubleshoot Windows Server (15 to 20%): connectivity, name resolution and IP addressing in hybrid environments | Monitoring and troubleshooting |
How troubleshooting questions are built
- Sequence. The stem says what has just been done (“a theory has been confirmed”); the answer is the next step, not the best step overall.
- Tool selection. “Which hop drops traffic” is traceroute; “does the name resolve” is nslookup or dig; “which process owns port 443” is netstat with the process option; “see the actual packets” is a protocol analyzer or tcpdump.
- Symptom to cause. A 169.254.x.x address means DHCP failed; duplicate IP conflicts, wrong mask or wrong default gateway each have a signature; for example, local hosts reachable but nothing remote is the classic wrong-gateway or wrong-mask clue. Interface counters rising with CRC errors point to cabling or duplex, not routing.
- Scope words. “Only one user” suggests the endpoint or access port; “all users on the switch” suggests the uplink, VLAN or STP (spanning tree); “only remote sites” suggests routing.
Practice questions
Question 1. A technician has confirmed that a duplicate IP address is causing a user's intermittent connectivity. What should the technician do next?
- A. Document the findings and close the ticket
- B. Establish a plan of action and identify its potential effects
- C. Establish a new theory of probable cause
- D. Implement the fix on the user’s workstation immediately
Show answer
Answer: B
After a theory is confirmed, the next step is to establish a plan of action, including its potential effects, before implementing. Implementing straight away skips the planning step. Documentation comes last. Establishing a new theory is only needed if the theory is not confirmed.
Question 2. A user can open a website by typing its IP address but not by typing its name. Which command should the technician run to investigate the cause?
- A. tracert
- B. netstat -an
- C. arp -a
- D. nslookup
Show answer
Answer: D
Reaching the site by IP address shows the connection and routing work, so the suspect is name resolution, which nslookup (or dig) tests directly. Tracert would show a path that is already working. Netstat lists local connections and ports. Arp shows IP-to-MAC mappings on the local segment and does not involve DNS.
Go deeper
- Microsoft: tracert and ping for what the probes really do.
- RFC 792, ICMP for echo and time exceeded messages.
- On this site: network devices, common ports cheat sheet, ACLs explained, and the study method.