5.5 CompTIA A+ · Core 1 (220-1201) · Domain 5 — Hardware & Network Troubleshooting

Troubleshooting
Network Issues

Objective 5.5 Domain weight: 28% 10 testable symptoms

OVERVIEWIntroduction

Network troubleshooting sits at the intersection of hardware, software, and infrastructure. A user who cannot reach the internet may have a failed network adapter, a misconfigured IP address, a faulty cable, an overloaded router, a failing ISP connection, or a misconfigured firewall — and the symptoms may look identical from the user's perspective. The technician's job is to isolate which layer of the network stack the problem lives in and work systematically from the most likely and simplest cause toward the most complex.

Objective 5.5 covers ten distinct network symptoms that range from physical layer problems (external interference, port flapping) through transport layer issues (high latency, jitter) to application-level failures (VoIP quality, authentication failures). This section provides the foundational networking concepts needed to understand each symptom, followed by comprehensive coverage of each symptom's causes, diagnostic approach, and resolution.

The OSI Model as a Troubleshooting Framework

The most effective approach to network troubleshooting follows the OSI model — either bottom-up (start at Layer 1 physical, work up) or top-down (start at Layer 7 application, work down). Bottom-up is preferred for hardware-suspected issues; top-down for software-suspected issues. When in doubt, start at Layer 1: verify physical connectivity before investigating software or configuration.

FOUNDATIONNetwork Concepts for Troubleshooting

Several foundational concepts appear repeatedly across the ten symptoms in this objective. Understanding them deeply — not just their definitions — enables faster, more accurate diagnosis.

The Network Path

Every network problem exists somewhere along a path from the client device to the destination. Understanding this path is the most important mental model for network troubleshooting:

Typical Client-to-Internet Network Path

Client Device

→

NIC / Wi-Fi Adapter

→

Network Cable / Wi-Fi

→

Switch / AP

↓

ISP Network

←

Modem / ONT

←

Router / Firewall

← NAT / DHCP here

Each hop is a potential point of failure. Isolating which segment is affected is the primary diagnostic goal.

Key Network Metrics

Bandwidth The maximum theoretical data transfer rate of a connection, measured in Mbps or Gbps. Bandwidth is the capacity of the pipe. A 100 Mbps connection can transfer at most 100 megabits per second. Bandwidth is shared — multiple users on the same network segment divide the available bandwidth.

Throughput The actual data transfer rate achieved in practice, always lower than the rated bandwidth. Throughput is reduced by overhead, congestion, errors, and protocol inefficiencies. A 100 Mbps connection may achieve only 85 Mbps throughput under ideal conditions.

Latency (Round-Trip Time) The time it takes for a packet to travel from source to destination and a response to return. Measured in milliseconds (ms). Lower is always better. Latency is determined by physical distance, number of hops, and congestion at each hop. Latency is the primary metric for real-time applications like VoIP and gaming.

Jitter The variation in packet arrival times. If packets that should arrive every 20ms instead arrive at 15ms, 32ms, 18ms, and 40ms intervals, that variation is jitter. Jitter causes real-time audio and video to stutter and break up even when average latency is acceptable.

Packet Loss The percentage of packets sent that never arrive at the destination. Even 1% packet loss is significant for real-time applications. TCP retransmits lost packets (causing latency spikes); UDP does not (causing missing audio/video frames in VoIP and streaming).

SNR (Signal-to-Noise Ratio) For wireless networks, the ratio of the useful signal strength to background noise. Measured in dB. Higher SNR means cleaner, more reliable wireless connection. Low SNR from interference or weak signal causes retransmissions, lower data rates, and connectivity issues.

Essential Diagnostic Commands

# --- CONNECTIVITY TESTING --- ping 8.8.8.8 # Test internet connectivity (Google DNS) ping 192.168.1.1 # Test gateway connectivity ping localhost # Test TCP/IP stack (127.0.0.1) ping -t 8.8.8.8 # Continuous ping — watch for packet loss ping -n 100 8.8.8.8 # 100 pings — statistical packet loss measurement # --- PATH TRACING --- tracert 8.8.8.8 # Trace route — shows each hop and latency per hop pathping 8.8.8.8 # Combines ping + tracert + packet loss per hop # --- IP CONFIGURATION --- ipconfig /all # Full IP config: IP, subnet, gateway, DNS, DHCP server ipconfig /release # Release current DHCP lease ipconfig /renew # Request new IP from DHCP server ipconfig /flushdns # Clear DNS resolver cache # --- NAME RESOLUTION --- nslookup google.com # Test DNS resolution nslookup google.com 8.8.8.8 # Test against specific DNS server # --- CONNECTIONS --- netstat -an # All active connections and listening ports netstat -b # Connections with owning process (run as admin) arp -a # ARP cache — IP to MAC address mappings

The Ping Isolation Method

When a user cannot reach the internet, pinging specific targets in sequence isolates exactly where the problem lies. This is one of the most powerful and efficient diagnostic techniques available:

Ping Isolation — Step-by-Step

Ping 127.0.0.1 (loopback). Tests the local TCP/IP stack. If this fails, the network adapter or TCP/IP stack itself is broken — reinstall the adapter driver or TCP/IP stack. This virtually never fails.

Ping your own IP address. Run ipconfig first to find it. If this fails, the NIC is not properly configured or the driver is faulty.

Ping the default gateway (router). If steps 01–02 pass but this fails, the problem is between the computer and the router — check the cable, switch port, NIC, or Wi-Fi connection. If you got an APIPA address (169.254.x.x), DHCP is not responding.

Ping a known IP on the internet (e.g., 8.8.8.8). If the gateway pings but this fails, the problem is between the router and the internet — check the modem, WAN connection, or contact the ISP.

Ping a domain name (e.g., google.com). If 8.8.8.8 pings but google.com does not, DNS resolution is failing. Run ipconfig /flushdns, check DNS server settings, or try a different DNS server (8.8.8.8 or 1.1.1.1).

SYMPTOM 01Intermittent Wireless Connectivity

Intermittent wireless connectivity describes a Wi-Fi connection that connects and disconnects unpredictably — the user can browse the web, then suddenly loses connection, then it returns, then drops again. Unlike consistent poor performance (Symptom 02) or complete failure to connect, the defining characteristic is unpredictability. This makes it one of the more frustrating symptoms to diagnose.

Causes and Characteristics

Signal strength fluctuation The client device is on the boundary of the access point's reliable range. When the user moves or the environment changes (a door closes, someone walks between the device and the AP), signal drops below the minimum reliable threshold and the connection drops. The connection returns when conditions improve. Confirmed by checking signal strength in real time — Wi-Fi analyzer apps show signal in dBm; below -75 dBm is marginal, below -85 dBm is typically unreliable.

Channel interference Multiple access points (neighbor networks, corporate APs) using the same or overlapping 2.4 GHz channels compete for the same radio spectrum. On 2.4 GHz, only channels 1, 6, and 11 are non-overlapping. When a neighboring AP on the same channel transmits, your AP must wait — causing latency spikes and dropped connections under heavy traffic. Use a Wi-Fi analyzer to identify congested channels and switch to the least-used non-overlapping channel.

DHCP lease issues A DHCP lease that expires and is not successfully renewed causes the device to lose its IP address and connectivity — even though the Wi-Fi association remains. The device appears connected to Wi-Fi but cannot communicate. Running ipconfig /release then ipconfig /renew resolves this temporarily; the root cause may be a DHCP server that is overloaded, running out of available addresses, or experiencing a bug.

Power management Windows and laptop firmware include Wi-Fi adapter power management features that reduce the adapter's power consumption when idle. Aggressive power management settings cause the adapter to enter a low-power state during periods of inactivity and may take a moment to fully wake when traffic resumes — causing apparent disconnections. Disable in Device Manager → Wi-Fi adapter → Properties → Power Management → uncheck "Allow the computer to turn off this device to save power."

Access point overload An AP that has more clients than it can efficiently serve begins dropping connections or de-authenticating clients. Common in high-density environments (offices, schools, apartment buildings with many APs in range). Adding additional APs or adjusting the AP's transmit power to reduce its coverage area (so clients associate with the closest AP rather than all clients fighting for one) resolves this.

Outdated driver or firmware A Wi-Fi adapter driver with bugs, or an access point running old firmware, can cause intermittent disconnections. Driver updates from the adapter manufacturer and firmware updates from the AP manufacturer are worth applying when intermittent issues cannot be attributed to environmental factors.

Intermittent Wireless — Diagnostic Steps

Check signal strength. Use a Wi-Fi analyzer app to measure signal strength (dBm) at the problem location. Values between -30 and -67 dBm are excellent to good; -68 to -75 is acceptable; below -75 is marginal and intermittent behavior is expected.

Check which channel neighboring networks are using. Wi-Fi analyzer shows all visible SSIDs and their channels. If your AP is on channel 6 and five neighbors are also on channel 6, switch to channel 1 or 11.

Test with a wired connection. Connect via Ethernet. If the problem disappears, it is definitively wireless-related — not a router, modem, or ISP issue.

Disable Wi-Fi adapter power management. Device Manager → Network Adapters → Wi-Fi adapter → Properties → Power Management tab → uncheck the power saving option.

Update Wi-Fi adapter driver and AP firmware. Download the latest driver from the manufacturer's website (not Windows Update, which may have older drivers). Update AP firmware from the router's admin interface.

Switch from 2.4 GHz to 5 GHz (or vice versa). If the AP broadcasts both bands, try the other band. 5 GHz has more non-overlapping channels and less interference but shorter range.

SYMPTOM 02Slow Network Speeds

Slow network speeds manifest as web pages loading slowly, file transfers taking far longer than expected, streaming buffering frequently, or general network unresponsiveness. The cause may be at the client device level, the local network level, or the ISP/WAN level — and these must be distinguished before troubleshooting can proceed.

Isolating the Scope

The first and most critical question is: is the slowness affecting one device, all devices on the local network, or specific destinations on the internet?

Scope	Likely Location of Problem	Starting Point
One device only	Client device NIC, driver, or configuration	Check NIC speed/duplex, driver, cable; compare to another device on same network
All devices, LAN is fast but internet is slow	ISP connection or WAN link	Run speed test; call ISP; check modem lights; check for ISP outage
All devices, LAN and internet both slow	Router, switch, or DHCP server	Restart router and switch; check router CPU/memory utilization
Specific destination slow (e.g., one website)	Routing to that destination or the destination server	Tracert to destination; issue is outside your control if slow beyond your ISP

Causes of Slow Network Speeds

Local / Device Causes

Speed/duplex mismatch — NIC and switch port negotiated different speeds (see below)
Damaged cable — Cat5e cable running at 100 Mbps instead of 1 Gbps due to a broken pair
Wrong cable category — Cat5 cable (max 100 Mbps) where Cat5e/Cat6 needed
Wi-Fi instead of wired — unexpected Wi-Fi fallback at lower speed
Malware — consuming upload bandwidth for spam or mining
Background downloads — Windows Update, cloud sync saturating link

Network Infrastructure Causes

Network congestion — too many users sharing limited bandwidth
ISP throttling — ISP reducing speeds after data cap exceeded
Overloaded router — consumer router CPU overwhelmed by many connections
Half-duplex collision domain — hub instead of switch causing collisions
QoS misconfiguration — traffic not being prioritized correctly
Broadcast storm — excessive broadcast traffic consuming bandwidth

Speed/Duplex Mismatch

A speed/duplex mismatch occurs when a NIC and a switch port auto-negotiate to different settings — one ends up at full duplex and the other at half duplex, or at different speeds (10/100/1000 Mbps). The result is dramatically reduced throughput — often 10–20% of expected speed — and high error rates. In Device Manager → NIC Properties → Advanced, the speed and duplex can be forced to a specific setting. The switch port must match.

Exam Focus

Speed/duplex mismatch is a classic exam scenario: a user gets much slower speeds than expected on a wired connection, the cable and hardware appear fine, but performance is consistently poor. The answer is to check and correct the speed/duplex settings on the NIC and switch port — set both to the same value (auto-negotiate, or manually set both to 1Gbps Full Duplex).

SYMPTOM 03Limited Connectivity

Limited connectivity is the Windows status message displayed when a device is connected to the network but cannot access the internet or certain network resources. The device has a network connection but something is preventing full communication — typically an IP addressing, DNS, or routing problem rather than a physical failure.

APIPA — The Most Common Cause

The most frequent cause of limited connectivity is the device failing to obtain a valid IP address from the DHCP server and instead self-assigning an APIPA (Automatic Private IP Addressing) address in the 169.254.0.0/16 range. APIPA addresses are automatically assigned by the OS when no DHCP server responds within a timeout period.

A device with a 169.254.x.x address can communicate with other devices on the same segment that also have APIPA addresses, but cannot reach the router (which has a real IP like 192.168.1.1) or the internet. This is why Windows shows "Limited connectivity" — the device is physically connected to the network but functionally isolated from anything useful.

# Check current IP — is it APIPA? ipconfig # If you see 169.254.x.x — DHCP failed. Try: ipconfig /release ipconfig /renew # If renewal fails — check DHCP server or assign static IP manually # Expected IP format for home/SOHO: 192.168.x.x or 10.x.x.x # Gateway: usually .1 (192.168.1.1 or 10.0.0.1) # Subnet mask: 255.255.255.0 (/24) for most SOHO networks

Other Causes of Limited Connectivity

Cause	Indicator	Resolution
APIPA address (169.254.x.x)	ipconfig shows 169.254.x.x; no DHCP response	ipconfig /release + /renew; check DHCP server; check cable; assign static IP
Incorrect static IP	Has a manually assigned IP but wrong subnet, gateway, or DNS	Verify IP settings match the network's addressing scheme
DNS failure	Can ping IP addresses (8.8.8.8) but not domain names	ipconfig /flushdns; change DNS to 8.8.8.8 or 1.1.1.1; check DNS server setting
Default gateway unreachable	Can ping own IP but cannot ping gateway	Check router is powered on; check cable to switch; check Wi-Fi association
IP address conflict	Windows "IP address conflict" warning; sporadic connectivity	Two devices have same IP; one must be changed; check DHCP server for duplicates
Firewall blocking traffic	Connected but specific ports/services unreachable	Check Windows Firewall rules; check router firewall/ACL settings

Limited vs. No Connectivity

Limited connectivity = physically connected, has network link, but IP/DNS/routing issue prevents full communication. No connectivity = no physical link at all — cable unplugged, switch port off, NIC failed. The distinction is important: limited connectivity is almost always a software/configuration problem; no connectivity is often a physical/hardware problem.

SYMPTOM 04Jitter

Jitter is the variation in the timing of packet delivery. In a perfect network, packets sent at regular intervals arrive at regular intervals. In the real world, network congestion, queuing delays, and routing inconsistencies cause packets to arrive with uneven spacing — some arrive early, some late, and some may be reordered.

Visualizing Jitter

Packet Arrival: Low Jitter vs High Jitter

Sent (regular)

Equal spacing

Low jitter

≈ Consistent arrival ✓

High jitter

Irregular, reordered, dropped

Why Jitter Matters for VoIP and Real-Time Audio

Voice over IP transmits voice as a stream of small UDP packets sent at regular intervals (typically every 20ms). The receiving device must play back these packets in order, at the correct timing, to produce intelligible speech. When jitter causes packets to arrive out of order or at irregular intervals, the receiving device's jitter buffer compensates by holding packets briefly before playing them back — smoothing out the irregularity. However, jitter buffers have limits: if jitter exceeds the buffer size, packets play back incorrectly or are dropped, causing choppy, robotic, or broken audio.

Acceptable jitter for VoIP is generally below 30ms. Above 50ms, call quality degrades noticeably. Above 100ms, calls become unintelligible.

Causes of Jitter

Network congestion — queues at overloaded routers/switches cause variable delays as packets wait for transmission slots
Wi-Fi contention — wireless medium access is inherently non-deterministic; multiple devices competing for transmission cause irregular packet timing
Insufficient QoS (Quality of Service) — without QoS, voice packets compete equally with large file downloads; one large packet in front of a voice packet adds significant delay to that voice packet
Overloaded router — a consumer router at high CPU utilization introduces variable processing delays
Long network path with many hops — each hop adds variable delay; paths with many hops accumulate more jitter

Measuring and Resolving Jitter

Jitter is measured using tools like ping (observe the variance in round-trip times across many pings), iPerf, or dedicated VoIP testing tools. The variance between the minimum and maximum RTT in a ping test approximates jitter.

Resolution centers on reducing congestion: implement QoS to prioritize voice traffic (DSCP marking), reduce overall network utilization during VoIP usage, switch VoIP devices to wired connections, and upgrade network hardware if the router is the bottleneck.

SYMPTOM 05Poor VoIP Quality

Voice over IP (VoIP) transmits voice calls as data packets over IP networks. Because voice is a real-time application with strict timing requirements, it is extraordinarily sensitive to network conditions that other applications tolerate easily. A network that appears perfectly functional for web browsing or file transfers can be completely inadequate for VoIP.

VoIP-Specific Network Requirements

Metric	Acceptable Range	Poor Quality Threshold	Impact if Exceeded
Latency (one-way)	Below 150ms	Above 150ms one-way (300ms RTT)	Noticeable conversation delay; talking over each other
Jitter	Below 30ms	Above 50ms	Choppy, robotic, broken audio
Packet loss	Below 1%	Above 3%	Gaps in audio; clipping; dropped syllables
Bandwidth per call	80–120 Kbps per call (bidirectional)	N/A — insufficient bandwidth	All calls degraded; audio compression artifacts

VoIP Quality Issues and Their Causes

Echo The caller hears their own voice played back with a delay. Caused by acoustic echo (microphone picking up speaker output) or electrical echo in the phone equipment. Most VoIP systems include echo cancellation — if echo persists, the echo cancellation algorithm is not working, or the hardware is causing the echo. Also caused by high latency — when one-way delay exceeds ~50ms, the speaker's voice returns audibly.

Choppy / robotic voice Audio breaks up into fragments, sounds digitized, or has a mechanical quality. The primary causes are high jitter (jitter buffer overflow causing packet reordering or drops) and packet loss. A jitter buffer that is undersized for the network conditions cannot smooth out the irregularity — the gaps become audible.

One-way audio One party can hear the other but not vice versa. A firewall or NAT issue preventing the return audio stream is the most common cause. VoIP uses RTP (Real-time Transport Protocol) for audio on dynamically assigned UDP ports — firewalls that don't properly track these sessions may block the return path.

Calls drop unexpectedly VoIP calls disconnect mid-conversation. Causes include: intermittent internet connectivity (the SIP signaling session times out), NAT timeout (the NAT table entry for the VoIP session expires), or network congestion causing SIP keepalive packets to be lost.

QoS — The Primary VoIP Fix

Quality of Service (QoS) is a set of router/switch features that prioritize certain types of traffic over others. For VoIP, QoS ensures that voice packets are processed before large data transfers even when the network is congested. Without QoS, a large file download happening simultaneously with a VoIP call can cause the router's output queue to fill with file transfer packets — voice packets sit in queue behind them, arriving late and causing jitter.

VoIP traffic is typically marked with a DSCP (Differentiated Services Code Point) value of EF (Expedited Forwarding) — the highest priority class. Configuring QoS on the router to honor this marking, or using application-aware QoS to detect and prioritize VoIP ports, is the standard solution for VoIP quality issues on shared networks.

Exam Focus — VoIP Quality

On the exam, poor VoIP quality questions almost always point to one of three causes: high latency, jitter, or insufficient bandwidth. The recommended fixes are: enable QoS on the router, switch VoIP devices to wired connections, and ensure adequate internet bandwidth. Know that VoIP uses UDP (not TCP) — lost packets are not retransmitted, they are simply gaps in the audio.

SYMPTOM 06Port Flapping

Port flapping describes a switch or router port that rapidly and repeatedly cycles between an up (active) and down (inactive) state — potentially dozens of times per minute. The term comes from the log entries it generates, which appear as alternating "link up" and "link down" messages for the same interface. From the user's perspective, the device experiences frequent, brief connectivity interruptions.

Causes

Faulty network cable The most common cause. A cable with a broken conductor that makes intermittent contact — bending with vibration or small movements — causes the link to drop when the conductor loses contact and return when contact is reestablished. The fault is usually near the RJ-45 connector end where the cable is flexed most often. Replace the cable to confirm.

Failing NIC A network interface card that is electrically unstable — due to a failing capacitor, overheating, or physical damage — may repeatedly lose synchronization with the switch port, causing the link to cycle. Test by substituting a known-good NIC.

Speed/duplex mismatch When auto-negotiation fails and the NIC and switch port cannot agree on operating parameters, some hardware implementations respond by repeatedly attempting to re-establish the link — causing flapping. Manually setting both ends to the same speed/duplex resolves this.

Failing switch port or switch hardware The switch port's physical interface has degraded. Moving the cable to a different port on the switch and observing whether the flapping follows the cable (cable/NIC issue) or stays on the original port (switch port issue) isolates this.

Spanning Tree Protocol (STP) instability In networks with redundant links, STP manages which paths are active to prevent loops. STP instability — caused by misconfiguration, a misbehaving switch, or topology changes — can cause ports to cycle between STP states, appearing as port flapping in logs. This is more common in managed enterprise networks.

Diagnostic Approach

The fastest diagnostic for port flapping: replace the cable first. It's free, takes 30 seconds, and resolves the majority of port flapping cases. If flapping continues with a new cable, move the connection to a different switch port. If it follows the original switch port, the switch port is faulty. If it follows the device, the NIC is faulty.

SYMPTOM 07High Latency

Latency is the time delay between sending data and receiving a response. It is measured in milliseconds (ms) using the ping command. High latency makes the network feel slow and unresponsive even when bandwidth is adequate — web pages begin loading slowly, interactive applications feel sluggish, remote desktop sessions lag, and games become unplayable.

Latency Reference Scale

Round-Trip Time (RTT) — lower is better

0ms 50ms 100ms 200ms 500ms 1000ms+

<10ms

LAN / SSD

10–50ms

Excellent internet

50–100ms

Good; gaming ok

100–200ms

Noticeable delay

200–500ms

VoIP degraded

500ms+

Severe impairment

Causes of High Latency

Cause	Where Latency Is Added	Diagnosis
Network congestion	Overloaded router/switch buffers; queuing delay	Latency is higher during peak hours; improves at off-peak; tracert shows high latency at specific hop
ISP issues	WAN link or ISP backbone congestion	Ping to gateway is low but ping to internet IPs is high; call ISP
Wireless interference	Wi-Fi retransmissions add delay	High latency on Wi-Fi, normal on wired from same location
Geographic distance	Physical propagation delay — light travels ~200km/ms in fiber	Normal for servers far away; tracert shows geographically distant hops
Overloaded router	Router CPU at 100%; packets queued waiting for processing	Check router CPU in admin interface; high CPU during peak usage
DNS lookup delay	Slow DNS resolution adds to perceived latency	IP addresses load fast; domain names load slowly; test with nslookup

Using Tracert to Locate High Latency

# tracert shows latency at each hop tracert google.com # Example output — latency spikes at hop 4 indicate ISP issue 1 1 ms 1 ms 1 ms 192.168.1.1 # Your router — fast = good 2 8 ms 9 ms 8 ms 10.0.0.1 # ISP gateway — normal 3 12 ms 11 ms 12 ms 172.16.x.x # ISP backbone — normal 4 210 ms 198 ms 215 ms 203.x.x.x # ← SPIKE HERE — problem at this hop 5 212 ms 205 ms 211 ms 64.x.x.x # Remains high after the spike hop # Key: latency that appears at a specific hop and stays high = problem at that hop # Latency at hop 4 with hop 3 normal = hop 4 router/link is congested # * * * = hop does not respond to ICMP (not necessarily an error)

SYMPTOM 08External Interference

External interference refers to electromagnetic signals from outside sources that corrupt or compete with network signals — primarily affecting wireless (Wi-Fi) networks and, to a lesser extent, unshielded wired networks. Understanding interference sources is critical because many intermittent wireless problems that appear to be hardware or configuration issues are actually environmental.

Wireless Interference Sources

Microwave ovens Operate at 2.45 GHz — directly overlapping the 2.4 GHz Wi-Fi band. When a microwave is in use, it radiates significant RF energy that severely degrades nearby 2.4 GHz Wi-Fi. The interference is intermittent — only when the microwave is running — which can make it difficult to identify. Mitigation: switch to 5 GHz Wi-Fi; relocate AP away from the break room.

Bluetooth devices Bluetooth operates in the 2.4 GHz band using frequency hopping spread spectrum (FHSS). In environments with many Bluetooth devices (wireless headphones, keyboards, mice, speakers), Bluetooth can cause interference to 2.4 GHz Wi-Fi. Modern devices use adaptive frequency hopping to minimize this, but high-density Bluetooth environments (conference rooms, gaming setups) can still cause issues.

Cordless phones (2.4 GHz) Older 2.4 GHz cordless phones transmit continuously when in use, causing severe 2.4 GHz Wi-Fi interference. Less common today as most newer cordless phones use 1.9 GHz DECT or 5.8 GHz, but still found in many offices.

Neighboring Wi-Fi networks The most common source of Wi-Fi interference in urban and multi-tenant environments. Neighboring SSIDs on the same or overlapping channels compete for airtime. Use a Wi-Fi analyzer to identify channel congestion and select the least-used non-overlapping channel (1, 6, or 11 for 2.4 GHz).

Physical obstructions and materials Not electromagnetic interference, but physical impedance. Concrete walls (especially reinforced with rebar), metal structures, filing cabinets, elevator shafts, and thick glass all significantly attenuate Wi-Fi signals. 5 GHz is more affected by physical obstructions than 2.4 GHz due to its shorter wavelength.

EMI from electrical equipment Fluorescent light ballasts, large electric motors, industrial equipment, and poorly shielded electrical wiring generate electromagnetic interference that can affect both wireless networks and unshielded twisted pair (UTP) wired networks. Shielded twisted pair (STP) or fiber optic cabling is immune to EMI. Running UTP cable alongside high-voltage power cables in the same conduit causes induced interference.

Identifying and Mitigating Interference

External Interference — Diagnostic and Mitigation

Use a Wi-Fi analyzer app. Tools like NetSpot (Windows/Mac), Wi-Fi Analyzer (Android), or inSSIDer show signal strength, channel usage, and noise floor in real time. A high noise floor (above -85 dBm) confirms interference regardless of source.

Switch from 2.4 GHz to 5 GHz. Eliminates microwave, Bluetooth, cordless phone, and most neighboring network interference simultaneously. Most modern dual-band routers support both bands.

Change Wi-Fi channel. Use Wi-Fi analyzer to identify which channels neighbors use, and select the channel with the least competing networks. Stick to non-overlapping channels: 1, 6, or 11 (2.4 GHz); any 20/40 MHz channel (5 GHz has many non-overlapping options).

Relocate the access point. Move the AP away from identified interference sources (microwaves, cordless phone bases, industrial equipment). Physically center the AP in the coverage area.

For wired interference: replace UTP with shielded twisted pair (STP) or fiber optic cabling in high-EMI environments. Ensure wired cables are not running parallel to high-voltage electrical wiring.

SYMPTOM 09Authentication Failures

Authentication failures occur when a device or user cannot prove their identity to the network, preventing access. In network troubleshooting, authentication failures most commonly manifest as inability to connect to a Wi-Fi network (wrong password, incorrect security settings), inability to log on to a domain, or inability to access network resources.

Wireless Authentication Failures

Incorrect WPA2/WPA3 passphrase The most common cause of Wi-Fi authentication failure. The pre-shared key (PSK) entered on the client does not match the AP configuration. Case-sensitive — verify capitalization. Check for hidden characters (spaces at the end, substituted special characters). Solution: retype the passphrase carefully, or use the AP's admin interface to confirm or reset it.

Security protocol mismatch The client device supports only WPA2 but the AP is configured for WPA3-only (or vice versa). Older devices may not support WPA3. AP configuration should be set to WPA2/WPA3 transition mode to support both simultaneously. WEP should never be used — it is completely broken cryptographically.

802.1X / RADIUS authentication Enterprise Wi-Fi networks use 802.1X authentication where each user authenticates with their own credentials (username/password or certificate) against a RADIUS server, rather than a shared passphrase. Authentication failures can be caused by: expired user credentials, certificate errors (untrusted CA), incorrect RADIUS server configuration, or a RADIUS server that is unreachable. The client may need the RADIUS server's root certificate installed to validate the server's identity.

MAC address filtering Some APs are configured to only allow connections from devices whose MAC addresses are explicitly listed. A new or replaced device will fail to connect even with the correct passphrase because its MAC address is not in the allowed list. Add the new device's MAC address to the AP's allowed list, or disable MAC filtering (it provides minimal security benefit and significant administrative overhead).

Domain / Network Resource Authentication Failures

Symptom	Cause	Resolution
Cannot log on to domain	Domain controller unreachable; incorrect credentials; account locked or disabled	Check network connectivity to DC; verify credentials; check AD for account status; check DNS points to DC
Network share access denied	NTFS or share permissions do not allow the user's account	Check share permissions and NTFS permissions on the target folder; verify user is in correct group
Kerberos authentication errors	System clock is not synchronized with domain controller (Kerberos requires clocks within 5 minutes)	Sync the client's clock to the domain's NTP server: `w32tm /resync`
Certificate authentication errors	Client certificate expired; untrusted CA; wrong certificate store	Renew or reissue certificate; add CA certificate to Trusted Root store

Exam Focus — Kerberos Clock Skew

Kerberos (the authentication protocol used by Windows Active Directory) requires the client's system clock to be within 5 minutes of the domain controller's clock. If the clocks drift beyond this threshold — most commonly from a dead CMOS battery (see Objective 5.1) or a workstation that was offline for an extended period — domain authentication fails with a cryptic error. The fix is to synchronize the client clock: net time /domain /set /y or w32tm /resync.

SYMPTOM 10Intermittent Internet Connectivity

Intermittent internet connectivity differs from intermittent wireless connectivity (Symptom 01) in an important way: the local network is functioning normally, but internet access drops in and out. The LAN is healthy — file shares, printers, and local servers work — but websites and external services are intermittently unreachable.

Distinguishing Local vs WAN Issues

The most important diagnostic distinction for this symptom is confirming that the local network is working. If users can access local resources (internal file shares, local printers, internal servers) but internet access is intermittent, the problem is at the WAN boundary — the router, modem, or ISP.

Causes and Diagnosis

ISP connection instability The physical connection between the modem/ONT and the ISP's network is unstable. For cable internet, this can be caused by a deteriorated coaxial cable, a failing splitter, or line noise from water intrusion in the junction box. For DSL, line quality degrades with distance and moisture. Checking the modem's diagnostic page (log in to modem admin interface) shows line statistics: downstream power, SNR margin, and error counts. Abnormal values confirm a physical line issue — ISP dispatch is required.

ISP outage or maintenance The ISP's network is experiencing planned maintenance or an unplanned outage. Intermittent connectivity that affects all users in an area simultaneously and correlates with no local changes. Check the ISP's status page or outage reporting services (Downdetector). Call the ISP support line. No action is possible on the customer side.

Failing or overheating modem/router A modem or router that has been running continuously for years may develop thermal issues — overheating under load causes it to drop the WAN connection and reboot. If the router is hot to the touch and connectivity drops under heavy usage, overheating is suspect. Ensure the router has adequate ventilation, is not enclosed, and is not stacked with other heat-generating equipment. Old routers may simply require replacement.

DNS server instability The DNS server is intermittently unreachable or slow. Web browsing appears to fail intermittently because DNS lookups time out — but IP addresses (like 8.8.8.8) can still be pinged. Confirmed by: nslookup google.com intermittently fails. Resolution: change the DNS server in network settings to a reliable public DNS — Google (8.8.8.8 / 8.8.4.4) or Cloudflare (1.1.1.1).

DHCP WAN lease not renewing The modem/router obtains its WAN IP from the ISP via DHCP. If the lease expires and the ISP's DHCP server does not respond to the renewal, the router loses its WAN IP and internet access drops until the lease is renewed. Most routers handle this gracefully, but a bug in the router firmware or an ISP DHCP server issue can cause this to fail intermittently. Power cycling the router forces a fresh DHCP lease.

Intermittent Internet Connectivity — Diagnostic Sequence

Confirm local network is working. Can you access a local network resource (printer, NAS, another computer on the LAN)? Can you ping the default gateway? If yes, the problem is WAN-side only.

Check modem/ONT indicator lights. Most modems have LEDs for power, downstream sync, upstream sync, and internet connectivity. A flashing or unlit "internet" or "online" LED during outage periods confirms a WAN sync issue.

Check ISP status. Visit the ISP's status page (from a mobile data connection) or Downdetector to see if a regional outage is reported. If yes, wait for ISP resolution — no local action needed.

Power cycle the modem and router. Turn off the modem, wait 30 seconds, power it on. After the modem fully synchronizes (all lights stable), power on the router. This forces new DHCP leases at both the WAN and LAN levels and resolves many transient issues.

Log into the modem's admin interface. Check signal levels, SNR margin, and the event log. High error counts, low SNR, or repeated re-synchronization events confirm a physical line problem — contact the ISP for a line quality check or technician visit.

Change DNS servers. Set the router's upstream DNS to 8.8.8.8 / 8.8.4.4 or 1.1.1.1 / 1.0.0.1. This rules out ISP DNS instability as a contributing factor.

Set up a continuous ping log. Run ping -t 8.8.8.8 > ping_log.txt and let it run for hours. Review the log to identify the exact times and frequency of connectivity drops — useful data when calling ISP support.

Master Reference — All 10 Symptoms

Intermittent wirelessSignal strength, channel interference, power management, AP overload, driver

Slow network speedsSpeed/duplex mismatch, damaged cable, congestion, ISP throttling — isolate scope first

Limited connectivityAPIPA (169.254.x.x) = DHCP failed; also check DNS, IP conflict, gateway

JitterVariable packet timing; caused by congestion; measured in ms; implement QoS

Poor VoIP qualityLatency <150ms, jitter <30ms, loss <1% — QoS and wired connection are primary fixes

Port flappingReplace cable first; then move to different switch port; then test NIC

High latencyUse tracert to find which hop adds delay; congestion, ISP, or wireless

External interference2.4 GHz: microwaves, BT, phones, neighbors. Fix: switch to 5 GHz, change channel

Authentication failuresWi-Fi: wrong PSK, security mismatch, MAC filter. Domain: clock skew, DC unreachable

Intermittent internetConfirm LAN works; check modem lights; ISP outage; power cycle modem+router; DNS

REFERENCEDiagnostic Tools & Commands Summary

Windows CLI Tools

ipconfig /all — full IP configuration including DHCP server
ipconfig /release + /renew — refresh DHCP lease
ipconfig /flushdns — clear DNS resolver cache
ping -t [host] — continuous ping for packet loss monitoring
ping -n 100 8.8.8.8 — statistical packet loss over 100 pings
tracert [host] — hop-by-hop latency to destination
pathping [host] — combined tracert + packet loss per hop
nslookup [domain] — DNS resolution test
netstat -an — active connections and listening ports
arp -a — ARP cache; IP to MAC mappings

Additional Tools & Concepts

Wi-Fi Analyzer — channel usage, signal strength, noise floor
iPerf — bandwidth and jitter testing between two endpoints
Speedtest.net — ISP bandwidth and latency test
Ping isolation method — loopback → own IP → gateway → internet IP → domain name
APIPA range — 169.254.0.0/16 = DHCP failure indicator
QoS / DSCP EF — VoIP traffic prioritization
Non-overlapping 2.4 GHz channels — 1, 6, and 11 only
w32tm /resync — synchronize Windows clock to domain

Final Exam Reminders

APIPA (169.254.x.x) = DHCP server unreachable. Release/renew; check cable; check DHCP server.

Limited connectivity = has link, no full communication. Check IP config, DNS, gateway reachability.

Ping isolation = loopback → own IP → gateway → 8.8.8.8 → domain name. Failure at each step points to a different layer.

VoIP quality = latency below 150ms, jitter below 30ms, packet loss below 1%. Fix: QoS + wired connection.

VoIP uses UDP — lost packets create audio gaps, not retransmissions.

Port flapping = replace the cable first. Then move switch port. Then test NIC.

Speed/duplex mismatch = wired connection much slower than expected with no other explanation.

Tracert spike at hop N = congestion or failure at that hop; stays high for all subsequent hops.

Kerberos authentication fails = check system clock — must be within 5 minutes of domain controller.

Intermittent internet, LAN works = check modem lights → ISP outage → power cycle → modem line stats → call ISP.

2.4 GHz interference = microwaves, Bluetooth, cordless phones, neighbors. Switch to 5 GHz or change to channels 1, 6, or 11.