Why Anchored PSK WLAN Clients Fail with 11r MIC Error
Refer to the exhibit.
A network engineer must create a PSK WLAN that will be anchored to the DMZ. After this WLAN is created, users cannot connect to it. Based on the output from the RA trace, which action must the engineer take to resolve the issue?
Community Insight
The question tests interpreting an RA trace for an anchored PSK WLAN; the trap is blaming anchoring or passwords when the trace explicitly names 802.11r MIC validation as the failure point.
A PSK WLAN anchored to the DMZ can fail client joins when 802.11r Fast Transition is enabled, because the radio authentication trace reports an EAPOL Message 2 MIC mismatch and an '11r MIC validation failed' condition. The page establishes that disabling Fast Transition on the WLAN (option A) is the action that restores connectivity.
Choosing option D (matching WLANs on foreign and anchor) because anchoring is mentioned, or option B (password mismatch) because the error is a MIC failure — but a PSK mismatch would fail differently, and the trace names 11r MIC validation, not an anchor/WLAN mismatch.
Community Discussion (2 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The RA trace output shows a failed validation of the EAPOL key message MIC together with an explicit '11r MIC validation failed' message, which is a signature of 802.11r Fast Transition key derivation problems between the client and the WLC during a PSK handshake. Because the WLAN is a plain PSK design anchored to the DMZ, enabling FT on that WLAN creates a PMK-R1/FT key exchange the client cannot complete, so the MIC check fails and association never finishes. Removing Fast Transition (option A) forces a conventional WPA2 PSK four-way handshake, which resolves the MIC validation failure and lets users connect. This matches the trace evidence rather than the anchoring configuration, which is not what the log flags.Why the Other Options Are Wrong
Option B is wrong because a genuine password mismatch would surface as a four-way handshake or key negotiation failure, not as an FT-specific '11r MIC validation failed' error during EAPOL message processing. Option C is wrong because the anchor WLC must remain in the mobility group — removing it would break the foreign-to-anchor mobility tunnel entirely and could never repair a MIC error on the local WLAN. Option D is wrong because although matching WLAN configurations on foreign and anchor WLCs are required for a valid anchored WLAN, the trace does not report an anchor or WLAN-identity problem; it reports a Fast Transition integrity check failure. Option A directly addresses the only fault the trace identifies.Community Comment Notes
JS2025 answered A, reasoning to "Disable Fast Transition on the Wireless LAN (WLAN) configuration" because "PSK mismatch or key derivation issues with 802.11r enabled can trigger 11r MIC validation failed errors." The same commenter's second note reinforces that "The WLC received EAPOL Key Message 2 from the client, but the Message Integrity Check (MIC) does not match," and that this "almost always happens during FT (802.11r) key derivation," which aligns exactly with the trace shown in the exhibit.Exam Strategy
In anchored-WLAN troubleshooting items, read the trace output first and fix the exact layer it names — here an FT MIC failure, not an anchoring misconfiguration. Eliminate options that would break required design elements, such as removing the anchor from the mobility group.
Frequently Asked Questions
Why doesn't a PSK password mismatch explain the 11r MIC validation failed trace error?
A wrong PSK fails the ordinary four-way handshake, whereas this trace shows the MIC failing specifically during 802.11r Fast Transition key derivation.
Why is configuring matching WLANs on foreign and anchor WLCs not the fix here?
Matching WLANs are required for anchoring, but the RA trace reports no anchor or WLAN identity problem — only a Fast Transition MIC validation failure.