Technical Solution: Resolving AP Discovery Failures on Cisco 9800 WLC in Layer 3 Environments
Settle a problem:16
This document addresses a common issue where Cisco Access Points (APs), such as the Catalyst 9120AXI series, fail to be discovered by and join a Cisco Catalyst 9800 Series Wireless LAN Controller (WLC), particularly the 9800-CL virtual controller.
The primary symptom is that the AP successfully obtains an IP address from a DHCP server but remains in a “Discovery” state, continuously rebooting or cycling through discovery attempts without successfully establishing a CAPWAP (Control and Provisioning of Wireless Access Points) tunnel with the WLC. This scenario typically occurs in a Layer 3 network topology where the APs and the WLC management interface reside on different IP subnets or VLANs.
Diagnostic checks often confirm that basic Layer 3 connectivity exists; for example, the AP is able to ping the WLC’s management IP address, ruling out fundamental routing or firewall issues. The root cause, as identified in the referenced case, is frequently a misconfiguration of the AP discovery mechanism, specifically DHCP Option 43.
Before implementing a solution, it is crucial to understand how a lightweight AP discovers its controller in a Layer 3 network. When an AP and WLC are not on the same broadcast domain, the AP cannot rely on Layer 2 broadcasts. It must use a Layer 3 discovery method. The AP attempts the following methods in order:
CISCO-CAPWAP-CONTROLLER.localdomain
, where localdomain
is the domain name the AP learns from DHCP. If this name resolves to the WLC’s IP address, the AP will initiate a connection.In the scenario described, the focus is squarely on the proper configuration of DHCP Option 43.
The core of the problem lies in the precise formatting of the DHCP Option 43 hexadecimal string. A single incorrect digit will cause the AP to attempt to contact a non-existent or incorrect IP address, leading to discovery failure.
The Option 43 value for Cisco APs must follow a Type-Length-Value (TLV) format:
F1
(hex).04
.08
.0C
.Case Study from the Forum Post:
192.168.10.10
F104C0A80A0B
Let’s deconstruct the incorrect value:
F1
(Correct)04
(Correct, for one controller)C0A80A0B
Now, let’s convert this hexadecimal value back to a decimal IP address:
C0
-> 192A8
-> 1680A
-> 100B
-> 11The DHCP server was incorrectly instructing the APs to join a controller at 192.168.10.11
. Since the actual controller was at 192.168.10.10
, the AP’s CAPWAP discovery requests were being sent to the wrong destination, resulting in a timeout and failure to join.
The solution is to correct the DHCP Option 43 value to accurately reflect the WLC’s management IP address.
Step 1: Convert the Correct WLC IP Address to Hexadecimal
192.168.10.10
192
-> C0
168
-> A8
10
-> 0A
10
-> 0A
C0A80A0A
Step 2: Assemble the Complete Option 43 String
Using the TLV format for a single controller:
F1
04
C0A80A0A
F104C0A80A0A
Step 3: Apply the Configuration to the DHCP Server
Update the DHCP scope that serves the APs’ VLAN with the corrected hexadecimal string. The exact method varies by DHCP server platform. Below is an example for a Cisco IOS-XE router acting as a DHCP server.
! Enter configuration mode
conf t
! Select the DHCP pool for the Access Points
ip dhcp pool AP-VLAN-POOL
! Remove the old, incorrect option
no option 43
! Add the new, correct option 43 as a hexadecimal string
option 43 hex F104C0A80A0A
! Exit configuration
end
! Save the configuration
write memory
Step 4: Renew the AP’s DHCP Lease
After applying the change, the AP must acquire the new DHCP information. This can be achieved by:
clear ip dhcp lease
and then reload
.Once the AP reboots and receives the corrected Option 43 from the DHCP server, it will correctly identify the WLC’s IP address (192.168.10.10
), initiate the CAPWAP discovery request to the right destination, and successfully join the controller.
In Layer 3 wireless deployments, AP discovery failures are most commonly traced back to client-to-server reachability issues or misconfigurations in the discovery aids like DHCP Option 43 or DNS. The hexadecimal nature of Option 43 makes it prone to typos. It is imperative for network engineers to double-check the IP-to-hexadecimal conversion and the final string assembly. Using an online decimal-to-hexadecimal converter for each octet is a reliable method to prevent errors. By systematically verifying Layer 3 connectivity first and then meticulously inspecting the discovery mechanism configuration, these issues can be resolved efficiently.