Wireless Operations, Monitoring, and Troubleshooting
What to look at first
Effective troubleshooting follows a fixed order: physical/RF layer, then AP join, then client join, then policy/path. On the RF side, monitor channel utilization, noise floor, retry rate, and client SNR. Retry rates above roughly 20% signal a problem; high utilization with low client count points to interference or a sticky, slow client hogging airtime. CleanAir classifies non-Wi-Fi interferers (microwave, DECT, video cameras) that a spectrum-blind AP cannot see.
AP join and client debugging
AP join failures usually trace to discovery (option 43, DNS), certificate/time skew, image or regulatory-domain mismatch, or CAPWAP being blocked. Confirm NTP is synchronized before blaming certificates. For clients, scoped debugs such as debug client <mac> plus show client summary reveal which join stage fails; avoid broad debugs on a production controller.
Monitoring and telemetry
Day-to-day operations use controller dashboards, syslog, SNMPv3, and streaming telemetry, with Catalyst Center providing assurance and AIOps across sites. Baselining matters: a “bad” day is easier to prove against a known-good capture of channel utilization and client counts.
Traps: high RSSI with poor throughput usually means interference or a low data rate, not weak signal; packet captures taken on the controller in local mode show tunneled traffic, while FlexConnect captures belong at the AP; and debugging too broadly can overload a busy controller.
Rule of thumb: check channel utilization and retries before touching transmit power - most “coverage” complaints on modern networks are really airtime problems.