Network Troubleshooting N10-009

Slide 1 of 10  |  N10-009 Obj 5.1 – 5.5  |  Troubleshooting
Network Troubleshooting
Methodology, Tools, Layers
Systematic thinking solves problems. Guessing wastes time.
Users can't reach the intranet. Some can ping the gateway, others can't. One user has internet but no internal access. Three different symptoms — is it one problem or three? The methodology will tell you.
10 Slides N10-009 Obj 5.1 – 5.5 7-Step Method to Wireless Methodology + Tools
Slide 2 of 10
CompTIA 7-Step Troubleshooting Methodology
Not optional. Not suggested. Memorize this sequence — it appears on the exam by number.
1 Identify the problem Gather information, question users, identify symptoms, duplicate if possible, determine scope
2 Establish a theory Question the obvious first. Consider multiple causes. Start simple — is it plugged in?
3 Test the theory Confirm or eliminate the theory. If wrong, establish a new theory or escalate.
4 Establish a plan of action Plan the resolution. Identify side effects. Obtain change approval if required.
5 Implement the solution Apply the fix. If escalation is needed, do it — don't attempt a fix beyond your scope.
6 Verify full functionality Confirm the fix works. Implement preventive measures to avoid recurrence.
7 Document findings Document what was done, why, and the outcome. This is non-optional — future you will thank you.
Our scenario: three user symptoms, possible one cause. Step 1 is to map the scope: which users, which locations, which resources. That data drives Step 2.
Slide 3 of 10
Troubleshooting Approach Strategies
Same 7 steps — different directions through the OSI stack.
Bottom-Up
Start at Layer 1 (Physical) and work up to Layer 7. Best when you suspect a physical or Layer 2 issue. Check cables, link lights, switch ports, MAC table, VLANs, then IP, then app. Most common approach for new issues.
Top-Down
Start at Layer 7 (Application) and work down. Best when users report app-specific failures and physical infrastructure is known good. Can it reach the server? Can the server respond? Is the application service running?
Divide-and-Conquer
Start in the middle (usually Layer 3) and branch up or down based on results. Can you ping the gateway? Yes — go up. No — go down. Efficient when you have experience narrowing issues quickly. Our scenario: start with ping to isolate Layer 1-3 vs Layer 4-7.
Scenario: Which Approach?
Some users can ping the gateway, others cannot. This symptom variation suggests a Layer 1-2 issue for the failing group and a Layer 3+ issue for the user who has internet but not internal access. Divide-and-conquer: confirm ping to gateway for each affected user first.
Exam Note
CompTIA may ask "which troubleshooting approach starts at the physical layer" — that is bottom-up. "Which approach begins by testing network connectivity mid-stack" — that is divide-and-conquer. Know all three, know when each fits.
Slide 4 of 10
Layer 1 & 2 Physical + Data Link Checks
Half of all network problems are physical. Check the obvious first.
Layer 1 Physical Cable connected at both ends? Correct cable type (straight-through vs crossover)? Link light on the NIC and the switch port? Try a known-good cable. Check for damaged connectors or kinks. Verify speed/duplex settings match on both ends — mismatch causes intermittent drops.
Layer 2 Data Link Is the device in the MAC address table? Correct VLAN assigned on the switch port? STP blocking the port unexpectedly? Duplex mismatch? Check port status — show interfaces on Cisco shows errors, input/output discards. Excessive CRC errors indicate a Layer 1 cable problem.
Common Layer 1 Failures
Damaged RJ45 connector — passes loopback test, fails under load.
Cable too long — Cat5e max is 100 meters; beyond that, signal degrades.
Wrong port speed — NIC auto-negotiated to 10Mbps instead of 1Gbps.
Half-duplex mismatch — one side sends while the other is still sending (collisions).
Scenario: Users Who Cannot Ping Gateway
Start here. Users who can't ping the gateway at all have a Layer 1 or Layer 2 problem. Check link lights, cable, VLAN assignment on the switch port. If the link light is up but ping fails, check the VLAN — device may be in the wrong VLAN.
STP (Spanning Tree Protocol) can leave a port in Blocking or Listening state for up to 50 seconds after it goes live. A port that shows a link light but no connectivity may just need to wait for STP convergence — or you need PortFast enabled on access ports.
Slide 5 of 10
Layer 3 & 4 Network + Transport Checks
Can the packet get there? Can the session open?
Layer 3 Network Correct IP address configured? Correct subnet mask? Default gateway set? ping the gateway — success means Layer 1/2 is fine. traceroute/tracert shows the hop-by-hop path and where packets stop. Check routing table — is there a route to the destination? NAT configured correctly for outbound traffic?
Layer 4 Transport Is the destination port open? Is the service listening? netstat -an shows listening ports and established sessions. A firewall may block port 443 but allow port 80. traceroute works (ICMP/UDP) but the application fails (TCP port blocked). Check both source and destination firewall rules.
C:\> ping 10.0.0.1
Reply from 10.0.0.1: bytes=32 time=1ms TTL=64
Gateway responds — Layer 3 to gateway is good

C:\> tracert 10.0.1.50
1 10.0.0.1 (1ms) <-- gateway responds
2 * * * Request timed out
Traffic reaches gateway but stops — routing or firewall between segments
Scenario: Internet but No Internal Access
This user can reach external hosts but not internal servers. This is a routing problem — the routing table has a default route (internet) but no specific route to the internal subnet, or the internal firewall is blocking cross-segment traffic. Check routing table: route print (Windows) or ip route (Linux/Cisco).
traceroute uses increasing TTL values. Each hop decrements TTL by 1. When TTL=0, the router sends an ICMP "Time Exceeded" back to you — that response is one hop in the traceroute output. A * * * means that hop did not respond (firewall blocking ICMP or ICMP not enabled).
Slide 6 of 10
Diagnostic Tools
Know what each tool tests and which layer it operates at.
ping
ICMP echo — confirms Layer 3 reachability between two hosts
traceroute
Shows hop-by-hop path and latency. Reveals where packets stop
nslookup
Queries DNS — confirms name resolves to expected IP
netstat
Shows active connections, listening ports, routing table (-r flag)
arp -a
Displays ARP cache — IP-to-MAC mappings on the local segment
ipconfig
Shows IP config, subnet, gateway, DNS. /all includes MAC and DHCP lease
tcpdump
Linux packet capture. Capture and display raw traffic on an interface
nmap
Port scanner. Discovers open ports, OS, services on a target host
Wireshark
GUI packet analyzer. Full packet decode across all layers. Capture filters + display filters
pathping
Windows: combines ping + traceroute — shows loss % per hop over time
ip / ss
Linux modern equivalents of ifconfig/netstat. ss -tlnp shows listening TCP ports
route print
Windows routing table — shows all network routes and the default gateway
Exam tip: if ping works but the application doesn't, the issue is Layer 4+ — check the port, the service, and the firewall. If DNS resolves but ping fails, the route is missing or a firewall is blocking ICMP. Layer the tools: ping first, then traceroute, then nslookup, then netstat.
Slide 7 of 10
Performance Metrics
Slow network vs broken network require different diagnoses.
Latency
Time for a packet to travel from source to destination and back (round-trip time). ping measures this.
Normal LAN: <1ms | WAN: <50ms | VoIP max: <150ms
Jitter
Variation in latency between packets. Causes choppy voice and video even when average latency is acceptable.
VoIP max: <30ms | Measured with iperf or Wireshark delta column
Bandwidth
Maximum theoretical throughput of a link. 1Gbps port does not guarantee 1Gbps throughput — interference, collisions, overhead reduce it.
Measure with: iperf3, speedtest, iPerf
Packet Loss
Percentage of packets that never arrive. Even 1% loss kills TCP performance due to retransmits. Causes: congestion, bad cable, interference.
Acceptable: <0.1% | ping -n 100 to measure
Diagnosing Slowness vs Outage
Full outage: ping fails entirely. Investigate Layer 1-3.
Intermittent drops: ping shows occasional timeouts. Bad cable, duplex mismatch, or wireless interference.
Slow but connected: measure bandwidth with iperf. Check for congestion on the uplink. Check for packet loss — TCP retransmissions destroy throughput.
Choppy voice/video: measure jitter. QoS misconfiguration.
Baseline Comparison
You can only know if performance is abnormal if you have a baseline. Document normal latency, packet loss, and bandwidth utilization during healthy operation. When users complain about slowness, compare current metrics to the baseline to determine whether it's a network problem or a "Monday morning everyone in at once" problem.
Slide 8 of 10
Wireless Troubleshooting
Wireless adds RF to your problem space — physical media you cannot see.
Channel Overlap
2.4GHz has 11 channels but only 3 non-overlapping (1, 6, 11). Adjacent APs on overlapping channels cause co-channel interference. Use a Wi-Fi analyzer to see what channels neighbors are using. 5GHz has more non-overlapping channels — preferred in dense deployments.
Interference Sources
Microwave ovens, Bluetooth, baby monitors, cordless phones all operate at 2.4GHz. Physical obstructions (concrete, metal) attenuate signal. Attenuation: signal strength decreases with distance (inverse square law). Site survey identifies dead zones and interference sources.
Roaming Issues
Client stickiness: device clings to the original AP even after moving into another AP's coverage zone. Results in poor signal + low throughput. BSS Transition Management (802.11v) signals to clients when to roam. Band steering moves capable devices from congested 2.4GHz to 5GHz.
Wireless Diagnostic Steps
1. Check signal strength — RSSI below -75dBm is poor
2. Check channel utilization — above 80% causes contention
3. Run a Wi-Fi analyzer (inSSIDer, Ekahau) to map nearby SSIDs
4. Test throughput close to AP, then at distance — compare
5. Verify security settings match: WPA3 client connecting to WPA2 AP may drop
AP Association vs Authentication Failure
Cannot associate: client never gets an IP — Layer 1/2 issue. Wrong SSID, wrong band, too far from AP, MAC filter blocking the client.
Associates but no IP: DHCP problem — check DHCP scope, check IP helper address if DHCP server is on a different subnet.
IP obtained but no connectivity: Layer 3+ — check gateway, routing, firewall.
Slide 9 of 10
Applying the Methodology to the Scenario
Three symptoms. Walk the 7 steps. Find the root cause.
Step 1: Identify — Map the Symptoms
Group A: Cannot ping gateway. No connectivity at all.
Group B: Can ping gateway but cannot reach intranet.
User C: Has internet (external) but no internal access.
Scope: multiple users, multiple buildings, same time of day.
Step 2-3: Theory + Test
Group A's theory: Layer 1/2 issue (cable, VLAN, switch port).
Test: check link lights, switch port status, VLAN assignment.

Group B's theory: routing or firewall blocking the internal segment.
Test: traceroute to intranet server — where does it stop?

User C's theory: missing route to internal subnet or DNS pointing wrong.
Test: route print, nslookup intranet.corp
Step 4-5: Plan + Implement
Group A: switch port reconfiguration — wrong VLAN was assigned after a network change last Friday.
Group B: ACL on the core router was updated Friday — a rule was added that blocked internal segment traffic.
User C: the DHCP scope was modified — gateway IP changed but DNS still served the old gateway.
One maintenance window, three downstream symptoms.
Steps 6-7: Verify + Document
Test all three user groups after each fix. Confirm ping, traceroute, and application access. Document the change window, the ACL modification, the VLAN fix, and the DHCP correction. Update the network diagram to reflect the current state. Create a post-incident review entry.
One change window on Friday caused three different symptoms Monday morning. Without methodology, you chase three separate tickets. With methodology, you correlate to one root cause.
Slide 10 of 10  |  N10-009 Obj 5.1 – 5.5
The Problem Was One Root Cause
Three different symptoms Monday morning. All traceable to a single Friday change window. Group A: wrong VLAN on switch port — cannot reach gateway (Layer 2). Group B: ACL modification blocked internal segment traffic — gateway reachable but intranet is not (Layer 3). User C: DHCP scope change — old gateway IP in DNS, routing to internal subnet broken (Layer 3).

The 7-step methodology surfaced the common factor: a Friday evening change. Without step 1 (identify scope), you would have chased three separate tickets. With it, you made three targeted fixes from one root cause analysis.
5 Facts to Carry Out of This Presentation
1 7-step method: Identify → Theory → Test → Plan → Implement → Verify → Document. In that order, every time.
2 Approaches: bottom-up (L1 upward), top-down (L7 downward), divide-and-conquer (start at L3, branch based on ping results).
3 Cannot ping gateway = Layer 1/2 problem. Can ping gateway but not remote host = Layer 3 routing or firewall. App fails but ping works = Layer 4+ firewall or service down.
4 Key tools: ping (L3 reachability), traceroute (path), netstat (ports/sessions), nslookup (DNS), arp -a (L2 cache).
5 Wireless non-overlapping channels: 2.4GHz use 1, 6, 11. Poor roaming = client stickiness. Choppy VoIP = jitter. Signal loss = attenuation or interference.