City hall reports a WLAN client that will not authenticate. Per ENCOR emphasis, which troubleshooting approach should staff prioritize first on the WLC?
Select an answer to reveal the explanation.
Short Explanation
Start where the client story is told — the WLC GUI shows associate, auth, and exclusion without boiling the ocean. OSPF LSAs will not explain a bad PSK or 802.1X reject.
Full Explanation
For a City Hall WLAN client that will not authenticate, ENCOR-oriented troubleshooting starts on the WLC where association, authentication, and exclusion state are visible. GUI client and WLAN monitoring views show whether the station associated, which EAP/PSK outcome occurred, whether it was excluded, and related connection events—before engineers escalate into unrelated core routing debugs.
Capturing only OSPF LSAs on the core as the first step fails by concept because auth failures are predominantly WLAN/AAA/client issues, not IGP database problems. Disabling NTP enterprise-wide fails because wireless authentication does not depend solely on PTP grandmasters, and breaking time sync harms logs and certificates rather than fixing PSK/802.1X. Replacing every access-switch uplink with hubs “to simplify CAPWAP” fails operationally and conceptually: hubs create collisions and do not diagnose auth policy failures.
Exam caveat: After WLC client state points to AAA, you may still need RADIUS logs—but the first pass should establish whether the failure is association, auth, DHCP, or exclusion on the controller, not boil the ocean on the routing core.
Operational check: On the WLC GUI, open the failing client’s detail/connection log; note association vs authentication vs exclusion; validate WLAN security settings and AAA server status; only then expand to switchport or routing if CAPWAP or upstream path is implicated.