ENWLSI 300-430 common mistakes
ENWLSI 300-430 · Understand the traps and how to avoid them.
Configuring a FlexConnect AP's local switching and then testing client traffic through the WLC data path, expecting the WLC to enforce ACLs and QoS on that traffic.
Candidates memorize the FlexConnect local switching feature list but never internalize that locally switched client traffic does not traverse the WLC, so centralized policy constructs (WLC ACLs, some QoS markings, central web auth) behave differently or are not applied at all. They then misdiagnose the resulting behavior as a misconfiguration.
What to do instead
Build a decision table for each FlexConnect mode you study: which traffic is locally switched, which is centrally switched, and which policies must be pushed to the AP (local split ACL, FlexConnect ACL, local QoS) versus applied at the WLC. When a scenario says 'clients are on a FlexConnect AP with local switching', immediately check whether the question is testing AP-applied policy rather than WLC-applied policy.
Treating AP join order and discovery as a single step, and answering questions about AP registration assuming the AP learns the WLC address only via DHCP option 43.
Study material often presents discovery methods as a list, so candidates forget the actual order (broadcast/local subnet, DHCP option 43/other DHCP options, DNS resolution of CISCO-CAPWAP-CONTROLLER, then previously configured controller). Scenario questions exploit the case where the AP is on a different subnet than the WLC, which removes the broadcast step and makes DNS or DHCP the deciding factor.
What to do instead
Memorize the discovery sequence and the fallback behavior, including what happens when the AP has a saved controller (it tries that first on subsequent boots). For any 'AP will not join' scenario, walk the list in order and identify the first method that should have worked given the stated network topology.
Choosing a guest access design that puts the guest SSID on an interface mapped to the management or a corporate dynamic interface, or forgetting that the guest anchor must be reachable for mobility tunneling.
Candidates focus on getting the guest WLAN to broadcast and associate, and treat the anchor/foreign topology as an afterthought. They also forget that the guest traffic is tunneled in CAPWAP/EoIP to the anchor, so the anchor's reachability and the mobility tunnel state determine whether guest clients actually get an address.
What to do instead
For every guest scenario, state three things explicitly: which WLC is foreign, which is anchor, and how the guest traffic reaches the DMZ. Verify the mobility tunnel is up before troubleshooting client DHCP. Practice mapping a guest WLAN to a dedicated guest interface on the anchor, not to management, and confirm the anchor's guest interface is the one bound to the guest subnet.
Assuming a guest WLAN with web authentication is secure by itself, and not specifying the need for HTTPS/SSL policy, a per-WLAN pre-auth ACL, or a guest user policy to restrict post-authentication access.
Web authentication is often described as 'guest access with a login page', so candidates conflate authentication with authorization and network security. Exam scenarios ask what else must be configured to prevent guests from reaching internal resources, or why the login page is not redirecting over HTTPS.
What to do instead
Learn web auth as a chain: pre-authentication ACL (allow DHCP/DNS, redirect to the virtual interface), virtual interface DNS name resolution, the web auth certificate/HTTPS policy on the WLC, and post-authentication authorization (ACL or guest role). For each scenario, ask which link in the chain is missing rather than whether web auth is enabled.
Mixing up 802.1X, web authentication, and PSK on the same WLAN in a way the controller does not support, or assuming a WLAN can layer multiple Layer 2 security types simultaneously.
Candidates see 'enable 802.1X and web auth' in real deployments (where web auth is a fallback via a separate mechanism) and assume the WLAN security tab allows arbitrary combinations. The WLC's Layer 2 security selection is exclusive per WLAN, and the fallback behavior is a specific feature, not a free combination.
What to do instead
Memorize the Layer 2 security options (None, WPA/WPA2/WPA3 with 802.1X or PSK, Static WEP, CKIP) and that only one is active per WLAN. When a scenario requires both, identify the actual mechanism (for example, web auth as a Layer 3 policy on a WLAN whose Layer 2 is open, or a separate WLAN/SSID). Answer the question the scenario asks about the WLAN configuration, not the desired end state.
Configuring an AAA/RADIUS server and assuming authentication success implies authorization, without checking the returned attributes (VLAN override, ACL name, or role) and the WLC's AAA override setting.
Candidates test with a simple accept/deny and never exercise the returned AV pairs. Exam items describe a client that authenticates but lands in the wrong VLAN or gets the wrong access, and the candidate blames RADIUS reachability instead of the override/attribute path.
What to do instead
Trace the full path: RADIUS returns Tunnel-Private-Group-ID or an ACL/role attribute, the WLAN must have AAA override enabled, and the returned VLAN must exist as a dynamic interface on the WLC. Build a checklist for 'authenticated but wrong policy' that starts at the returned attributes and works toward the WLC's override configuration.
Applying QoS at only one point (for example, marking on the WLAN) and expecting end-to-end treatment, ignoring the wired uplink trust boundary, the AP's QoS mode, and whether the traffic is locally or centrally switched.
QoS is taught as a per-WLAN profile setting, so candidates treat it as a single configuration. In practice the profile maps to a DSCP/CoS value that must be trusted and honored upstream, and on FlexConnect APs the local switching path changes where classification happens.
What to do instead
For each QoS scenario, identify the classification point, the marking, the trust boundary (switch port trust, AP mode), and the egress treatment. Know which WLAN profile maps to which DSCP/802.1p values and that Fastlane/AVC and application visibility interact with those profiles. Practice explaining why a voice client on a locally switched FlexConnect AP needs the AP and the access switch to trust the marking.
Configuring multicast on the WLC and expecting it to work without enabling multicast on the infrastructure, or forgetting that multicast mode (multicast vs. unicast) changes how the WLC forwards traffic and how client roaming behaves.
The WLC multicast configuration page is prominent, but the dependency on the wired network's multicast routing, IGMP snooping, and the AP's multicast mode is easy to overlook. Candidates also miss that multicast delivery is tied to the client's VLAN and the AP's group membership.
What to do instead
Study multicast as a path: source on the wired network, multicast routing/IGMP toward the WLC, the WLC's multicast address and mode, and the AP's multicast configuration. For mDNS, know that the WLC can snoop and bridge Bonjour services between VLANs and that the service policy (profile) determines which services are advertised. For each scenario, ask where the multicast group membership must exist.
Assuming a mobility group member automatically provides seamless roaming for all clients, without checking that the client's VLAN/interface exists on the target controller or that the mobility tunnel is in a healthy state.
Mobility is presented as 'add controllers to a mobility group and roam', so candidates skip the prerequisites: matching interface names/VLANs, consistent WLAN configuration, and the tunnel state. Exam items describe a client that roams but loses connectivity or cannot get an IP, which points to a missing interface or a down tunnel.
What to do instead
For any roaming scenario, verify in order: mobility group membership and tunnel status, the client's interface/VLAN present on the target controller, and WLAN configuration parity. Know the difference between intra-controller roaming, inter-controller roaming with the same subnet, and roaming that requires the anchor/foreign data path. Also review HA (SSO/AP SSO) behavior so you can distinguish failover effects from mobility effects.
Troubleshooting from the client side only, using show commands without first establishing the expected state (AP join, client state machine, DHCP/auth path), and not knowing which WLC/AP debug or show command answers which question.
Candidates memorize command names but not the question each command answers, so under time pressure they pick a plausible command instead of the one that reveals the failing stage. Scenario items are usually built around a specific stage (AP discovery, client association, 802.1X, DHCP, mobility), and the correct command is the one that inspects that stage.
What to do instead
Build a stage-by-stage troubleshooting map with one or two commands per stage (for example, AP join and CAPWAP state, client detail and exclusion list, authentication/AAA events, DHCP and interface status, mobility tunnel status). For each practice scenario, name the failing stage before choosing a command, and be able to explain what a healthy output looks like versus the symptom described.