Wireless LAN and WLC Scenarios

Enable DFS channels to avoid radar interference.

Why wrong: DFS (Dynamic Frequency Selection) channels are specifically intended for radar interference avoidance, not for mitigating co-channel interference between APs. The exhibit shows no radar events; enabling DFS would introduce unnecessary radar-detect downtime and channel unavailability without changing the fact that multiple APs share the same non-DFS channel. The root cause is poor channel planning, not radar coexistence.

Increase the channel width to 160 MHz to improve throughput.

Why wrong: Increasing the channel width to 160 MHz would enlarge the RF footprint and consume most of the available 5 GHz spectrum, but it would not address the existing co-channel contention between APs. In fact, wider channels reduce the number of non-overlapping channels available (often to just one 160 MHz block per regulatory domain), which would increase CCI and make the problem worse. The exhibit's issue is channel reuse, not insufficient channel bandwidth.

Disable the 2.4 GHz radios to force all clients to 5 GHz.

Why wrong: Disabling the 2.4 GHz radios only removes the legacy band and does nothing to alter the channel assignments on the 5 GHz band where the contention is occurring. This would also force clients that depend on 2.4 GHz (such as IoT or older devices) onto 5 GHz, potentially causing connectivity issues while leaving the 5 GHz co-channel interference completely unsolved. The exhibit's problem is AP-to-AP channel overlap on 5 GHz, not the presence of the 2.4 GHz band.

The SSID broadcast setting, because the client must not be joined correctly.

Why wrong: The SSID broadcast setting only controls whether the network name appears in probe responses, not whether an already-associated client can send or receive traffic. Because the client successfully joined and pulled an address from the correct subnet, it is not a join failure. If broadcast were disabled, the client would still be able to connect if it manually knew the SSID, and would not explain an application-specific issue.

The voice VLAN on the wired access port connected to the AP uplink.

Why wrong: The voice VLAN on the wired access port is used to separate VoIP traffic from data traffic on the wired infrastructure, and it does not affect how a wireless client forwards traffic after joining a WLAN. A client that has already received an address from the correct subnet is clearly operating on the data VLAN, not the voice VLAN, and general employee access works correctly. Since the problem is restricted to one application, changing the voice VLAN setting on the AP uplink would have no bearing on this scenario.

The OSPF router ID on the client device.

Why wrong: OSPF router IDs are used by routers participating in OSPF to identify themselves in link-state advertisements; end-client devices such as laptops or phones do not run OSPF and never exchange routing protocol information with the network. A client's network stack obtains an address via DHCP and uses a default gateway for off-subnet traffic, so OSPF router ID is irrelevant. The application-specific failure cannot be caused by a parameter that does not exist on the client device.

A missing OSPF router ID on the access point

Why wrong: A missing OSPF router ID on the access point is irrelevant to WLAN client authentication because OSPF is a dynamic routing protocol that operates at Layer 3 and is used for exchanging routes between network devices, not for securing wireless client access. The AP's OSPF configuration, or lack thereof, has no bearing on the 802.11 association or 802.1X/WPA supplicant process; client authentication depends on the wireless security settings and RADIUS/PSK validation. OSPF router ID issues would disrupt IP routing between the AP and other routers, but would not prevent a client from authenticating to a locally broadcast SSID.

A routed-port mismatch on the switch uplink

Why wrong: A routed-port mismatch on the switch uplink is a Layer 3 interface configuration problem affecting IP traffic between the switch and upstream devices, but it does not interfere with the client's ability to authenticate to the WLAN. Client authentication to the SSID occurs at the wireless link between the laptop and AP, involving 802.11 management frames and security handshakes; the switch uplink's port mode (routed vs. switched) only becomes relevant for forwarding user traffic after successful authentication. Therefore, this mismatch would cause routing or reachability issues for post-authentication traffic, not the described symptom of the client connecting to the correct SSID but repeatedly failing to gain access.

A DHCP relay problem on the client

Why wrong: A DHCP relay problem on the client is not a valid failure point because DHCP relay functionality resides on routers or multilayer switches, not on the client itself. Even conceptually, DHCP address assignment occurs only after the client has successfully authenticated and associated at Layer 2; if authentication fails, the client never reaches the DHCP discovery phase. Thus, a DHCP relay issue would manifest as a missing IP address after successful association, not as repeated authentication failures or the inability to complete the WLAN security handshake.

interface GigabitEthernet0/1 switchport mode trunk switchport trunk allowed vlan 10,20 power inline auto ! interface GigabitEthernet0/2 switchport mode access switchport access vlan 30 power inline never

Why wrong: This is incorrect because the IP phone port should be an access port, not a trunk. Using a trunk port would require the phone to negotiate trunking, which is not the standard Cisco IP phone deployment. The voice VLAN is configured via 'switchport voice vlan', not by trunking.

interface GigabitEthernet0/1 switchport mode access switchport access vlan 20 switchport voice vlan 10 power inline auto ! interface GigabitEthernet0/2 switchport mode access switchport access vlan 30 power inline never

Why wrong: This is incorrect because the voice VLAN should be 20, not the access VLAN. The access VLAN is for data traffic (typically VLAN 10), and the voice VLAN is for voice traffic. Swapping them would put voice traffic in VLAN 10 and data in VLAN 20, which is not the requirement.

interface GigabitEthernet0/1 switchport mode access switchport access vlan 10 switchport voice vlan 20 power inline never ! interface GigabitEthernet0/2 switchport mode access switchport access vlan 30 power inline auto

Why wrong: This is incorrect because PoE is disabled on the IP phone port (G0/1) and enabled on the AP port (G0/2), which is the opposite of what is required. The IP phone needs PoE to power on, and the AP should have PoE disabled.

Remove the 'ip dhcp excluded-address 192.168.1.1 192.168.1.10' command because it excludes too many addresses.

Why wrong: This is incorrect because excluding 10 addresses from a /24 subnet (254 usable addresses) is not excessive. The exclusion is necessary to reserve addresses for static devices like the router interface. The APIPA issue is not caused by this exclusion.

Change the DHCP pool network to 192.168.1.0/24 and add the default-router 192.168.1.1 command.

Why wrong: This change is unnecessary and would not resolve the problem because the DHCP pool on R1 already contains the correct 'network 192.168.1.0 255.255.255.0' and 'default-router 192.168.1.1' statements. The configuration as written is valid and would lease addresses properly if the DHCP service were enabled. Simply rewriting or re-adding these commands does nothing to activate the router's DHCP server engine, which is disabled by default and requires the 'service dhcp' global command. Without that global enable, the client will continue receiving no DHCP replies and will fall back to an APIPA address.

Configure the 'ip helper-address' command on the client's VLAN interface to forward DHCP requests to the server.

Why wrong: This is incorrect because the DHCP server is on the same router (R1) as the client's subnet. The 'ip helper-address' command is used to forward DHCP broadcasts to a remote server, which is unnecessary here. The client and server are on the same device.

802.11ac uses OFDMA, while 802.11ax uses only OFDM.

Why wrong: That statement reverses the actual evolution. 802.11ac relies on conventional OFDM, allocating the entire channel to a single user at a time. 802.11ax introduces OFDMA, which partitions each channel into smaller subcarrier groups (resource units) so multiple clients can transmit concurrently, improving spectral efficiency and reducing overhead, especially in dense environments.

Both 802.11ac and 802.11ax operate exclusively in the 5 GHz band.

Why wrong: This is incorrect because 802.11ax was designed to support both the 2.4 GHz and 5 GHz bands, while 802.11ac was defined for the 5 GHz band exclusively. The dual-band support in 802.11ax allows upgrades of legacy 2.4 GHz networks and improves efficiency in dense deployments, whereas 802.11ac's single-band limitation avoided the congested 2.4 GHz spectrum but reduced flexibility.

802.11ac introduces target wake time (TWT) for improved power saving, but 802.11ax does not support it.

Why wrong: This statement gets the technology generation backwards. Target Wake Time (TWT) is a key power-saving feature introduced in 802.11ax, enabling stations to schedule negotiated wake times and sleep between exchanges, which reduces contention and battery drain. 802.11ac did not include TWT; instead it relied on earlier power-save mechanisms like PS-Poll or U-APSD, making the claim false.

The AP is using the wrong RF channel

Why wrong: An incorrect RF channel assignment would prevent the AP from operating on the expected frequency, typically making the SSID undetectable or severely degrading signal quality so that clients cannot associate at all. Since the clients can see the corporate SSID, they are receiving beacons and successfully probing, meaning the RF channel is functioning at the physical layer. An authentication failure after a visible SSID points to a higher-layer issue such as RADIUS or EAP, not channel misconfiguration.

The SSID must be hidden for enterprise authentication

Why wrong: Hiding the SSID only suppresses the SSID from beacon frames and some probe responses; it does not alter the 802.1X/EAP authentication flow or RADIUS requirements. Enterprise authentication functions identically with a broadcast SSID, and clients that already know the SSID can still find and attempt to authenticate to a hidden network. The failure described occurs after the SSID is visible, so hiding it would not resolve or explain the authentication failure.

The clients need a voice VLAN assignment first

Why wrong: Voice VLANs are a switch-level mechanism used to separate and prioritize VoIP traffic, often via LLDP-MED or CDP, and are not a prerequisite for wireless client authentication. In a WPA2-Enterprise network, the VLAN assignment is an outcome of successful RADIUS authentication, where the server returns attributes like Tunnel-Private-Group-ID, rather than a condition that must exist beforehand. Requiring a voice VLAN before authentication would create a circular dependency and misinterprets the role of VLANs in 802.1X.

Change the WLAN security to WPA2-Personal, enable TKIP encryption, and set the radio policy to 5 GHz.

Why wrong: Selecting WPA2-Personal with TKIP directly violates the stated security requirement of WPA3-Personal. WPA3 mandates AES-CCMP as the encryption cipher; TKIP is a legacy protocol that is not supported in any WPA3 configuration and is considered cryptographically broken. Moreover, while setting the radio policy to 5 GHz matches the client requirement, the security suite and encryption cipher are non-negotiable and must be WPA3-Personal with AES-CCMP.

Change the WLAN security to WPA3-Personal, enable AES-CCMP, but leave the radio policy as 'All' (both 2.4 GHz and 5 GHz).

Why wrong: This is incorrect because the requirement specifies that the SSID should be for 5 GHz clients only. Leaving the radio policy as 'All' would allow 2.4 GHz clients to associate, which is not desired and could cause configuration issues.

Change the WLAN security to WPA3-Personal, enable AES-CCMP, set the radio policy to 5 GHz, but do not enable the WLAN after changes.

Why wrong: Although this option correctly specifies WPA3-Personal, AES-CCMP, and a 5 GHz radio policy, it omits the critical step of enabling the WLAN after the changes are applied. On Cisco wireless controllers, a newly configured or modified WLAN remains administratively down until explicitly enabled with the 'config wlan enable <id>' command or the 'no shutdown' equivalent. Without this step, the access points will not broadcast the SSID and clients cannot associate, making the configuration functionally ineffective despite all other parameters being correct.

Enable SSID broadcast, change security to WPA2-PSK, and assign VLAN 20 in the policy tag.

Why wrong: Enabling the broadcast solves discovery, but switching to WPA2-PSK is incompatible with the client's WPA3-Personal configuration, because WPA3-Personal mandates the SAE (Simultaneous Authentication of Equals) handshake, not the older PSK key exchange. Furthermore, assigning VLAN 20 in the policy tag places this client on the wrong Layer 2 segment; the access point would tag its traffic with VLAN 20, isolating the client from the resources on VLAN 100 even if authentication somehow succeeded.

Disable SSID broadcast, change security to WPA3-Personal, and assign VLAN 100 in the policy tag.

Why wrong: Disabling SSID broadcast would keep the wireless LAN cloaked from clients performing active scanning; the client specifically needs a broadcasted SSID to discover the network during the probe/scan phase and cannot initiate association to an SSID it never sees. Even though WPA3-Personal and VLAN 100 would otherwise be acceptable, the hidden SSID prevents the client from even attempting connectivity, so this option fails to resolve the problem. Hiding the SSID is not a valid substitute for a proper security configuration.

Enable SSID broadcast, change security to WPA3-Enterprise, and assign VLAN 100 in the policy tag.

Why wrong: WPA3-Enterprise requires an IEEE 802.1X/EAP framework with a RADIUS server, whereas the client is configured for WPA3-Personal, which uses a pre-shared key negotiated via the SAE handshake; without valid enterprise credentials and backend authentication infrastructure, the AP will not complete the 4-way handshake. Although broadcast is enabled and VLAN 100 is correct, the security mode mismatch prevents the client from associating successfully.

Both 802.11ac and 802.11ax support 1024-QAM modulation.

Why wrong: 802.11ac supports modulation up to 256-QAM, whereas 802.11ax introduces 1024-QAM to increase peak data rates when signal-to-noise ratio is high. Although 802.11ac Wave 2 products may claim high efficiency, 1024-QAM is not part of the 802.11ac specification and remains a distinguishing feature of Wi-Fi 6. Therefore, saying both standards support 1024-QAM is false; the higher-order modulation is unique to 802.11ax among these two.

Both standards use only the 5 GHz band.

Why wrong: 802.11ac is specified to operate only in the 5 GHz band, but 802.11ax (Wi-Fi 6) is designed to support both 2.4 GHz and 5 GHz bands, with Wi-Fi 6E adding 6 GHz. Therefore, saying both standards use only 5 GHz is false. The dual-band support in 802.11ax is critical for backward compatibility and in congested 2.4 GHz environments where many legacy devices still operate.

802.11ac uses 80 MHz channels, while 802.11ax uses 160 MHz channels exclusively.

Why wrong: The claim that 802.11ac uses 80 MHz channels and 802.11ax uses 160 MHz exclusively misrepresents the channelization. Both standards support 20, 40, 80, and 160 MHz channel widths, with 160 MHz support introduced in 802.11ac Wave 2 and carried forward into 802.11ax. In the 2.4 GHz band, 802.11ax typically uses only 20 or 40 MHz because of regulatory constraints and narrow channel availability, so 160 MHz is definitely not exclusive to 802.11ax.

Modify the existing GuestNet WLAN: change security to WPA3-Personal, enable SSID broadcast, and change the interface to 'guest' (VLAN 20).

Why wrong: Selecting the 'guest' interface during WLAN modification binds that SSID to guest VLAN 20 (assuming the interface is mapped accordingly). Even after updating the security to WPA3-Personal and enabling broadcast, all client traffic is still switched into VLAN 20 rather than VLAN 30, which is explicitly required for the customer network. The interface assignment determines Layer 2 segmentation for wireless clients; unless it points to an interface mapped to VLAN 30, the WLAN remains on the incorrect segment.

Create a new WLAN with SSID 'CustomerNet', set security to WPA2-PSK, enable SSID broadcast, and assign the 'guest' interface (VLAN 20).

Why wrong: WPA2-PSK is not functionally equivalent to WPA3-Personal because WPA3 uses the Simultaneous Authentication of Equals (SAE) handshake, providing stronger protection against offline dictionary attacks. Additionally, assigning the 'guest' interface places the new CustomerNet SSID on VLAN 20 instead of the required VLAN 30, meaning clients are placed in the wrong broadcast domain and DHCP scope. Even though a new SSID is created and broadcast is enabled, this option simultaneously violates two mandatory requirements for the WLAN configuration.

Modify the GuestNet WLAN: change security to WPA3-Personal, keep SSID broadcast disabled, and change the interface to a new interface mapped to VLAN 30.

Why wrong: Keeping SSID broadcast disabled makes CustomerNet a hidden network, meaning clients must manually probe for the exact SSID name to discover and associate. The requirement explicitly states that SSID broadcast must be enabled, so even with WPA3-Personal and the correct VLAN-30 interface, this option does not allow automatic discovery by client devices. Hidden SSIDs also introduce probe overhead and can cause connectivity issues with some client implementations, making this configuration functionally incomplete.

On interface FastEthernet0/5: switchport voice vlan 150, power inline auto. On interface FastEthernet0/10: switchport access vlan 100, power inline auto. Verify with show interfaces switchport and show power inline.

Why wrong: This is incorrect because the access point on FastEthernet0/10 is already in VLAN 100 by default or previous configuration; the question does not require changing the access VLAN. Adding switchport access vlan 100 is unnecessary and may cause issues if the port was already configured differently.

On interface FastEthernet0/5: switchport voice vlan 150, power inline auto. On interface FastEthernet0/10: power inline auto. Verify with show vlan and show power inline.

Why wrong: This option fails at the verification step because show vlan displays only the global VLAN list and which ports belong to each VLAN as access ports; it never reports an interface's voice VLAN assignment. Voice VLAN is an interface-scoped parameter that appears only in show interfaces switchport under the 'Voice VLAN' field, so show vlan cannot confirm that VLAN 150 is actually active on Fa0/5. While the show power inline command would properly validate PoE status, the lack of an interface-level voice VLAN check leaves the configuration unverified and the answer incomplete.

On interface FastEthernet0/5: switchport voice vlan 150, power inline auto. On interface FastEthernet0/10: power inline auto. Verify with show interfaces trunk and show power inline.

Why wrong: This option is wrong because show interfaces trunk is only useful for switchports that are administratively or dynamically in trunking mode, whereas Fa0/5 and Fa0/10 are access ports connecting an IP phone and an access point, respectively. Voice VLAN configuration on an access port is a separate feature that carries 802.1Q-tagged voice traffic from the phone, and it is confirmed with show interfaces switchport—not with show interfaces trunk, which would show nothing for these non-trunking ports. Thus, even though the configuration commands themselves are correct, the chosen verification command would not produce any relevant output to validate the setup.

WPA3 uses TKIP encryption for backward compatibility with legacy devices.

Why wrong: WPA3 does not use TKIP under any circumstances; TKIP is a legacy WPA/WPA2 cipher that is deprecated because of known cryptographic weaknesses. The Wi-Fi Alliance explicitly forbids TKIP in WPA3-certified devices. Backward compatibility with older clients is handled through transition mode, where the AP can simultaneously support WPA2 and WPA3, not by falling back to TKIP.

WPA3 relies solely on 802.1X/EAP authentication for both personal and enterprise modes.

Why wrong: WPA3 Personal mode does not use 802.1X/EAP at all; it authenticates users with a passphrase via SAE. The 802.1X/EAP framework is reserved for WPA3 Enterprise mode, where it supports multiple user identities and an authentication server. Thus, the statement incorrectly conflates the two modes and ignores SAE as the mandatory Personal-mode authentication method.

WPA3 mandates the use of GCMP-256 encryption for enhanced security.

Why wrong: WPA3 does not mandate GCMP-256 encryption across all deployments. The baseline WPA3 specification requires CCMP-128 (AES) as the minimum security suite. GCMP-256 is used in the optional WPA3-Enterprise 192-bit security mode, but it is not a universal mandate. Therefore, saying WPA3 mandates GCMP-256 overstates its use and ignores the baseline CCMP-128 requirement.

WPA3 makes Protected Management Frames (PMF) optional to support older clients.

Why wrong: WPA3 makes Protected Management Frames (PMF) mandatory, not optional, for all certified devices. PMF uses 802.11w mechanisms to encrypt management frames, preventing attackers from forging deauthentication and disassociation frames to disrupt clients. Older clients that cannot support PMF are simply not allowed to connect in pure WPA3 networks; transition mode handles legacy devices separately.

The AP is using an incorrect channel width of 80 MHz, which is not supported by 802.11ac.

Why wrong: 802.11ac explicitly defines channel bonding support for 80 MHz and even 160 MHz as optional, so an 80 MHz width is fully compliant with the standard. The real problem is that bonding to 80 MHz consumes a large contiguous slice of spectrum, and in a dense environment this increases the chances of overlapping basic service sets and co-channel interference. Therefore, the channel width is not unsupported; it is simply too wide for the RF environment, misidentifying the root cause.

The AP has DFS non-compliance, which prevents it from using channel 36 and causes the radio to operate at reduced power.

Why wrong: DFS non-compliance means the AP is not properly detecting radar, but it does not necessarily reduce power; it may cause the AP to avoid certain channels. The power level is set to maximum (1), so power reduction is not the issue.

The AP is using WPA2-PSK instead of WPA3, which causes lower throughput due to weaker encryption.

Why wrong: WPA2-PSK uses AES-CCMP for encryption, whose per-frame overhead is negligible and comparable to the AES-GCMP used by WPA3; neither cipher adds enough processing delay or header size to materially reduce throughput. Performance drops in dense environments are driven by RF layer issues such as interference, channel utilization, and retransmissions, not by the security handshake or encryption algorithm. Thus, attributing the problem to WPA2-PSK is technically unfounded and confuses security configuration with physical-layer capacity.

Downgrade the WLAN security to WPA2-Enterprise for backward compatibility.

Why wrong: Downgrading to WPA2-Enterprise does not resolve the underlying PMF misconfiguration; while WPA2 allows optional PMF, WPA3 and 802.11ax mandate PMF as a hard requirement. The reported drops stem from management frame protection negotiation failing during association, not from WPA3 protocol incompatibility. Moreover, WPA2-Enterprise omits SAE and weakens the security posture, making it an inappropriate workaround that masks rather than fixes the root cause.

Disable OFDMA and MU-MIMO on the WLC for the affected APs.

Why wrong: OFDMA and MU-MIMO are channel-access and spatial multiplexing techniques that boost throughput in dense 802.11ax environments; they have no role in authentication, key management, or management frame protection. Disabling these features would not alter PMF negotiation or change how the WLAN advertises its security capabilities. The reported disconnections occur at the protocol level immediately after connecting, not from PHY-layer contention or scheduling, so this action is irrelevant.

Adjust the 5 GHz channel width from 80 MHz to 40 MHz to avoid interference.

Why wrong: Reducing the 5 GHz channel width from 80 MHz to 40 MHz narrows the occupied spectrum and can improve SNR by avoiding overlapping channels, but it does not influence the management frame exchange or PMF capability negotiation that is failing. The symptom pattern—clients dropping right after association rather than suffering persistent throughput loss or RSSI fluctuation—points to a logical security parameter mismatch, not RF interference. Without changing the PMF policy, clients will still be disconnected regardless of channel geometry.