Apply the CompTIA troubleshooting methodology to network problems
Use ping, traceroute, and pathping to diagnose connectivity
Interpret netstat and ss output to identify connection states
Use nslookup and dig for DNS troubleshooting
Capture and analyze packets with Wireshark at a basic level
The Troubleshooting Methodology
CompTIA defines a structured seven-step troubleshooting process. Memorize this -- it appears on Network+ and A+ exams, and more importantly, it works in real life.
1. Identify the problem
- Gather information from user and logs
- Question users about recent changes
- Determine scope: one user, one subnet, or everyone?
- Duplicate the problem if possible
2. Establish a theory of probable cause
- Start simple (Layer 1: cable? power?)
- Question the obvious
- Consider multiple approaches (top-down, bottom-up, divide-and-conquer)
3. Test the theory to determine cause
- If theory confirmed: determine next steps
- If theory not confirmed: establish new theory or escalate
4. Establish a plan of action
- Identify the fix and potential side effects
- Plan for a maintenance window if needed
- Have a rollback plan
5. Implement the solution or escalate
- Apply the fix
- If beyond scope: escalate with documentation
6. Verify full system functionality
- Confirm the fix resolved the issue
- Implement preventive measures if applicable
7. Document findings, actions, and outcomes
- Record everything for future reference
- Update knowledge base
ping -- Basic Connectivity Test
Ping sends ICMP Echo Request packets and waits for ICMP Echo Reply. It tests basic IP connectivity, measures round-trip time (RTT), and detects packet loss.
/* Basic ping */$ ping 192.168.1.1
PING 192.168.1.1: 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.23 ms/* Ping with count limit */$ ping -c 4 8.8.8.8# Linux: 4 pingsC:\> ping -n 4 8.8.8.8# Windows: 4 pings/* Continuous ping (useful for monitoring) */$ ping 192.168.1.1# Linux: continuous by defaultC:\> ping -t 192.168.1.1# Windows: -t for continuous/* Diagnostic ping sequence (bottom-up approach) */Step 1: ping 127.0.0.1# Test local TCP/IP stackStep 2: ping 192.168.1.50# Test own IP (NIC working?)Step 3: ping 192.168.1.1# Test default gatewayStep 4: ping 8.8.8.8# Test internet (by IP)Step 5: ping google.com# Test DNS resolution/* If Step 4 works but Step 5 fails = DNS problem
If Step 3 works but Step 4 fails = routing/ISP problem
If Step 2 works but Step 3 fails = local network problem */
traceroute / tracert -- Path Analysis
Traceroute reveals every router hop between you and the destination. It sends packets with incrementally increasing TTL values. Each hop that drops the packet (TTL=0) sends back an ICMP Time Exceeded message, revealing its IP address.
$ traceroute 8.8.8.8# Linux (uses UDP by default)C:\> tracert 8.8.8.8# Windows (uses ICMP)
traceroute to 8.8.8.8, 30 hops max
1 192.168.1.1 1.2 ms 1.1 ms 1.0 ms # your gateway 2 10.0.0.1 8.5 ms 8.2 ms 8.4 ms # ISP edge 3 72.14.215.85 12.1 ms 11.9 ms 12.0 ms # ISP core 4 * * * # filtered (no response) 5 8.8.8.8 15.3 ms 15.1 ms 15.2 ms # destination/* Reading the output:
- 3 time values = 3 probes per hop
- * * * = router doesn't respond to TTL exceeded (filtered, not down)
- Big jump in latency between hops = possible congestion point
- Same IP appearing twice = routing loop *//* Windows pathping combines ping + tracert */C:\> pathping 8.8.8.8# shows loss at each hop over time
ipconfig / ifconfig / ip -- Interface Information
/* Windows */C:\> ipconfig # basic IP infoC:\> ipconfig /all # detailed: MAC, DNS, DHCP leaseC:\> ipconfig /release # release DHCP leaseC:\> ipconfig /renew # request new DHCP leaseC:\> ipconfig /flushdns # clear DNS cache/* Linux */$ ip addr show # show all interfaces$ ip route show # show routing table$ ip neigh show # show ARP cache$ ip link set eth0 up # bring interface up$ sudo dhclient -r eth0 # release DHCP$ sudo dhclient eth0 # renew DHCP
netstat / ss -- Connection and Port Analysis
These tools show active network connections, listening ports, and routing tables. Essential for verifying that services are running and identifying suspicious connections.
/* netstat (Windows and legacy Linux) */C:\> netstat -an # all connections, numericC:\> netstat -ano # include PID (process ID)C:\> netstat -b # show executable name (admin)/* ss (modern Linux -- faster than netstat) */$ ss -tuln # TCP/UDP listening ports, numeric$ ss -s # summary statistics$ ss -tp # TCP connections with process names/* Connection States */LISTEN Service waiting for connections
ESTABLISHED Active connection
TIME_WAIT Connection closed, waiting for stale packets
CLOSE_WAIT Remote side closed; local app hasn't closed yet
SYN_SENT SYN sent, waiting for SYN-ACK (handshake in progress)
SYN_RECV SYN received, SYN-ACK sent (half-open connection)
Security Tip:
Many SYN_RECV connections from different IPs could indicate a SYN flood attack. Many ESTABLISHED connections to unusual ports or foreign IPs could indicate malware phoning home. Regular netstat/ss audits are a basic security practice.
DNS Troubleshooting Tools
/* nslookup -- quick DNS queries */$ nslookup hexworth.com
Server: 8.8.8.8
Address: 104.21.32.1$ nslookup -type=MX hexworth.com$ nslookup hexworth.com1.1.1.1# query specific server/* dig -- detailed DNS analysis */$ dig hexworth.com +short # just the answer$ dig hexworth.com +trace # full resolution path$ dig hexworth.com ANY # all record types$ dig @ns1.cloudflare.comhexworth.com# query authoritative/* Common DNS failures:
- "Server can't find": Record doesn't exist or DNS server unreachable
- "SERVFAIL": DNS server error (check upstream)
- "NXDOMAIN": Domain doesn't exist (typo? expired?) */
Wireshark Basics
Wireshark is the industry-standard packet analyzer. It captures every frame on the wire and decodes all protocol layers. Essential for deep troubleshooting when higher-level tools are not enough.
/* Essential Wireshark Display Filters */ip.addr == 192.168.1.50# traffic to/from this IPtcp.port == 443# HTTPS trafficdns# all DNS traffichttp.request# HTTP requests onlytcp.flags.syn == 1# SYN packets (new connections)tcp.flags.reset == 1# RST packets (rejected connections)icmp# ping trafficarp# ARP requests/repliestcp.analysis.retransmission# retransmitted packets (loss indicator)/* Capture filter (applied BEFORE capture -- limits data) */host 192.168.1.50# only capture this hostport 53# only DNS trafficnot port 22# exclude SSH (noisy on remote sessions)
Follow TCP StreamRight-click any packet, "Follow TCP Stream" to see the entire conversation reconstructed. Great for seeing HTTP requests/responses or identifying data exfiltration.
IO GraphsStatistics -> IO Graphs shows traffic volume over time. Spikes indicate bursts; flat lines followed by spikes suggest buffering or batch transfers.