Wireless LAN and WLC Scenarios

The WLC is configured with the wrong authentication port; RADIUS uses port 1645, not 1812.

Why it fails: This is incorrect because RADIUS authentication uses UDP port 1812 as the IANA-assigned standard port; port 1645 is a legacy alternative from early RADIUS implementations that has been deprecated due to conflicts with the datametrics service. More importantly, the server logs in the scenario show that the WLC's Access-Request messages are being received, which proves the WLC is sending to the correct destination port (1812). If the WLC were mistakenly configured for 1645, the requests would never reach the RADIUS listener on 1812, and no Access-Reject entries would appear in the server logs.

The WLC's RADIUS server configuration has the wrong shared secret, causing the server to reject requests.

Why it fails: Incorrect because the server logs show 'Access-Reject', which indicates the server received the request and processed it; a shared secret mismatch would typically result in no response or a 'Access-Challenge' but not necessarily a reject. However, the server could still reject if the secret is wrong, but the WLC would still see a response, not 'server not responding'.

The WLC is not configured with a valid management interface IP address to reach the RADIUS server.

Why it fails: This is incorrect because the RADIUS server logs show that it is receiving Access-Request packets from the WLC, which proves the WLC's management interface has a valid IP address and can route to the server. An invalid management interface IP (or missing route) would prevent the WLC from sourcing or sending any RADIUS traffic, so the server would see nothing at all. The real issue is asymmetric routing or a source-address mismatch: the server replies from a different IP than the configured RADIUS server address, causing the WLC to drop those responses and log 'server not responding'.

Fabric Control node

Why it fails: The Fabric Control node is the LISP control plane responsible for maintaining the Endpoint Identifier (EID) to Routing Locator (RLOC) mappings. It does not physically attach to any endpoints; wireless clients are registered with the Control node through the Fabric Edge, which discovers them. Since it only provides mapping and registration services, it cannot directly integrate or enforce policies on user traffic.

Fabric Border node

Why it fails: The Fabric Border node serves as the exit or entry point between the SD-Access fabric and external networks such as a WAN or the Internet. It translates VXLAN encapsulated traffic to traditional IP routing and applies inter-VRF routing policies for north-south flows, but it never terminates wireless user connections. Wireless endpoints are always attached to a Fabric Edge node, not a Border node.

Wireless LAN Controller (WLC)

Why it fails: While the Wireless LAN Controller (WLC) manages access points, handles RF, and supports roaming, in an SD-Access deployment it does not enforce segmentation or policy on wireless clients. The WLC forwards wireless traffic to the Fabric Edge, which applies VXLAN encapsulation, SGT-based policy, and anycast gateway features. Therefore, the WLC is a management component, not the policy-integration point for wireless users.

All WLANs are currently active and serving clients.

Why it fails: The IoT WLAN shows Status Disabled, so it is not serving clients; only three of the four WLANs are active. Assuming every listed WLAN is operational is tempting because the summary lists all configured entries, but the Status column distinguishes enabled from disabled.

The Guest WLAN uses WPA2 security.

Why it fails: The Guest WLAN's Security column reads Open, so no WPA2 encryption is applied there; WPA2 appears only against Corporate, IoT and Management. Open is tempting because guest networks often use a captive portal, but that is a Layer 3 web-authentication overlay, not WPA2, and the output records the Layer 2 security type only.

The Management WLAN is on the guest-vlan interface.

Why it fails: The Management WLAN (ID 4) maps to mgmt-vlan, not guest-vlan, which belongs to the Guest WLAN. Reading across the wrong row is tempting because both are enabled WPA2 WLANs, but the Interface column pairs each SSID with its own VLAN.

The RADIUS server is not sending the correct VLAN ID in the Access-Accept.

Why it fails: This is incorrect because the symptom is that client devices receive an IP address in VLAN 100 and can associate, but cannot reach resources beyond the access switch. If the RADIUS server were sending an incorrect VLAN ID, the clients would either be placed in a different VLAN than intended (e.g., a guest VLAN) or authentication would fail outright. The problem is not on the RADIUS side; the Access-Accept is valid and correctly specifies VLAN 100 for the wireless clients.

The WLC is not configured for 802.1X on the uplink to the switch.

Why it fails: This is incorrect because 802.1X is a port-based access control method designed for point-to-point links and is not used on the uplink between a WLC and a switch. The WLC-to-switch link is normally configured as a trunk or an access port carrying multiple or a single VLAN, and it should not run 802.1X. Even if 802.1X were misconfigured on the uplink, it would not affect the drop of tagged VLAN 100 frames, because the issue is with VLAN pruning, not with port authentication.

The users' devices are not configured for MAB.

Why it fails: This is incorrect because MAB (MAC Authentication Bypass) is a fallback mechanism for devices that do not support 802.1X supplicants, such as printers or legacy devices. Wireless clients using 802.1X authenticate via the WLC, which acts as the authenticator (or passes EAP frames to the RADIUS server), and they do not require MAB. The problem described is about VLAN tagging on the trunk, not about the inability of the clients to perform 802.1X; MAB is irrelevant and would be a redundant fallback on the WLC, not a client-side setting.

Local mode

Why it fails: In Local mode, the AP is fully controlled by the WLC; all client traffic is tunneled via CAPWAP from the AP to the WLC, and if the WLC becomes unreachable, the AP cannot forward client data or authenticate new clients. This makes it unsuitable for scenarios expecting standalone survival when WAN connectivity to the controller is lost. So verdict: wrong because it doesn't support local switching or independent operation.

Monitor mode

Why it fails: Monitor mode converts the AP into a dedicated sensor that uses its radios to passively listen on all channels for intrusion detection and rogue AP scanning, but it does not provide any SSID or client connectivity. It cannot host BSSIDs or forward client frames, so it cannot serve the role described in the question. Thus it's wrong because it doesn't offer any client-serving functionality.

Sniffer mode

Why it fails: Sniffer mode instructs the AP to capture all 802.11 frames on a selected channel and forward those to a remote packet capture display, similar to a wired tap. The AP's radio is exclusively used for monitoring, so no client can associate to it and no user traffic is switched — making it impossible for it to operate as an access point. Therefore it's wrong for a distinct reason: it's a monitoring tool, not a serving mode.

The router's 'aaa authorization commands 15 default group tacacs+' command is missing the 'local' keyword, so if TACACS+ denies, there is no fallback.

Why it fails: Incorrect because the engineer wants TACACS+ to authorize commands, and the issue is that TACACS+ is responding with a deny, not that the router is failing to fall back. Adding 'local' would not help if TACACS+ explicitly denies.

The router's privilege level 15 is not correctly assigned to the user.

Why it fails: This is not the cause because the user is already operating at privilege level 15, as evidenced by the 'aaa authorization commands 15' statement in the router's configuration. The router's privilege level determines which commands require authorization and what local permissions exist, but in this scenario, the final decision lies with the TACACS+ server, which is explicitly denying the commands. A correct privilege level assignment does not guarantee that TACACS+ will authorize every command; the server's rules are separate and must allow the command regardless of the user's privilege level.

The TACACS+ server is not reachable due to a firewall change, causing the router to deny all commands.

Why it fails: The issue is not with reachability because the TACACS+ server logs confirm that it is receiving authorization requests and sending responses back to the router. If a firewall were blocking traffic, the router would not receive responses and would either time out or fall back to a default authorization method, which is not what the logs show. The fact that the server is responding indicates the network path is functional, so the problem must be in the server's authorization policy, not in connectivity.

Network Health dashboard

Why it fails: The Network Health dashboard provides an overall view of network device health, including wired and wireless devices, but it does not drill down into specific client association failures or correlate them with client device types. It is more suited for high-level monitoring rather than detailed troubleshooting of client issues.

Path Trace

Why it fails: Path Trace is a tool used to trace the path of a packet through the network, showing the forwarding path and any drops. It is not designed to analyze wireless client association failures or correlate them with client device types. It is more relevant for wired network path analysis and policy verification.

Application Health dashboard

Why it fails: The Application Health dashboard focuses on application performance and network latency for critical applications. It does not provide details about wireless client association failures or device types. This dashboard is used for monitoring application experience, not for troubleshooting client onboarding issues.

Switch CPU utilization

Why it fails: Switch CPU utilization is a wired network metric that does not directly affect wireless client SNR or retry rates. While high switch CPU can impact overall network performance, it is not a primary cause of wireless signal quality issues. The engineer should focus on wireless-specific metrics like RF conditions and channel utilization.

DHCP pool utilization

Why it fails: DHCP pool utilization indicates how many IP addresses are in use but does not impact wireless signal quality or retry rates. While DHCP issues can affect connectivity, they do not cause high retry rates or low SNR. This metric is irrelevant to the RF-related symptoms described.

WAN latency and jitter

Why it fails: WAN latency and jitter affect application performance over the wide area but are not directly related to wireless client SNR or retry rates. These metrics are relevant for WAN troubleshooting, not local wireless RF issues. The client's poor performance is likely due to local RF conditions, not WAN characteristics.

Path Trace

Why it fails: Path Trace is a tool used to trace the path of packets between two endpoints, showing the hop-by-hop forwarding and any ACL or QoS policies applied. It does not capture wireless onboarding events such as association, authentication, or DHCP. Therefore, it cannot provide the detailed onboarding timeline the administrator needs.

Application Health Dashboard

Why it fails: The Application Health Dashboard focuses on application performance and network latency for specific applications. It does not track client onboarding phases or wireless association details. The administrator needs client-centric onboarding data, not application-level metrics, so this dashboard would not provide the required timeline.

Network Health Dashboard

Why it fails: The Network Health Dashboard gives an aggregate view of network health across sites, devices, and clients. It does not provide per-client onboarding timelines or detailed phase breakdowns. While it can highlight that onboarding time is generally high, it lacks the drill-down capability to see individual client events, making it unsuitable for this specific troubleshooting task.

The APs are not running the recommended firmware version.

Why it fails: Registered, functional APs on a supported controller release associate clients normally; firmware mismatches typically cause AP join or CAPWAP failures, which the stem rules out. Firmware checks are correct when APs repeatedly deregister or fail to join the controller.

The wireless controller has reached its maximum number of APs.

Why it fails: The stem confirms the APs are registered, so the controller accepted them; an AP licence or capacity ceiling would block registration itself. Capacity exhaustion is the correct diagnosis when new APs cannot join while existing ones remain online.

The DNA Center Assurance module is not properly configured to monitor wireless events.

Why it fails: Assurance already reports the association failures, proving it collects wireless telemetry; misconfiguration would produce missing or blank data, not specific failure counts. Assurance misconfiguration is the right diagnosis when dashboards show no client or AP data at all.

Sniffer mode

Why it fails: Sniffer mode configures an access point to capture and forward all wireless traffic to a packet analyzer, such as Wireshark. It does not serve clients or tunnel client data to the WLC for normal network access. This mode is strictly for troubleshooting and analysis, not for providing wireless connectivity.

FlexConnect mode

Why it fails: FlexConnect mode allows access points to switch client traffic locally at the branch while still being managed by the WLC. This mode is used for branch offices with limited WAN bandwidth, where tunneling all traffic back to the WLC is not desirable. In this scenario, the requirement is to tunnel client traffic back to the WLC, so FlexConnect is not appropriate.

Monitor mode

Why it fails: Monitor mode is used for dedicated monitoring access points that only scan the air for security and interference, without serving clients. These access points do not provide client connectivity, so they cannot tunnel client traffic to the WLC. This mode is used for IDS/IPS and location services, not for general client access.

Local mode with CAPWAP control and data tunnels to the controller

Why it fails: In local mode, both control and data traffic are tunneled to the controller via CAPWAP, so if the WAN link fails, client traffic cannot be forwarded locally. This does not meet the requirement for local forwarding during WAN failure. Local mode is suitable for centralized forwarding, but not for branch survivability with limited bandwidth.

Sniffer mode with packet capture to a remote server

Why it fails: Sniffer mode is used for capturing wireless packets and sending them to a remote analyzer; it does not provide client access. Access points in sniffer mode cannot serve clients or forward their traffic. This mode is a troubleshooting tool, not a deployment mode for production client access.

Monitor mode with dedicated air monitoring on all access points

Why it fails: Monitor mode is used for wireless intrusion prevention and spectrum analysis, not for serving client traffic. Access points in monitor mode do not provide client connectivity, so they cannot forward client traffic locally or centrally. This mode is inappropriate for a branch office that needs to serve wireless clients.