Intermittent Client Drops That Nobody Can Reproduce
Users in one wing report intermittent drops - a few seconds of no connectivity several times an hour, worse in the afternoon. The help desk cannot reproduce it. APs show normal client counts. The controller is in a remote data center; APs tunnel back over a WAN. Afternoon drops coincide with a scheduled backup job that saturates the WAN. There is no dedicated monitoring beyond basic AP up/down alerts.
1. Form a troubleshooting plan that isolates whether the drops are RF, controller, or WAN-related.
Read the worked answer
Work from evidence, not guesses:
- Correlate timing - compare drop timestamps with the backup job schedule; if they align, WAN congestion is the prime suspect.
- Check tunnel health - on the controller, review AP tunnel/heartbeat statistics and latency/jitter to the remote APs during the afternoon window.
- Check RF - review channel utilization, retries, and noise floor for the affected APs; rule out interference.
- Check controller - CPU, memory, and tunnel counts during the window.
- Client-side capture - capture on an affected client to see whether traffic stalls at the tunnel or at the radio.
If drops align with WAN saturation and tunnel latency spikes, the cause is WAN congestion affecting tunneled traffic, not RF.
2. If WAN congestion is confirmed, what remediation and monitoring changes do you recommend?
Read the worked answer
Remediation:
- QoS on the WAN to prioritize controller/AP tunnel and voice traffic over backup.
- Reschedule or rate-limit the backup job so it does not saturate the link.
- Consider local breakout / distributed forwarding for latency-sensitive traffic so it does not traverse the WAN.
Monitoring:
- Add tunnel latency/jitter and WAN utilization alerts, not just AP up/down.
- Alert on backup job start/completion and correlate with client drop events.
- Dashboard the affected wing's client experience metrics.
This converts an unreproducible complaint into a monitored, bounded condition.