Your Access Point (AP) needs to be connected to the Wireless LAN Controller (WLC) via the management interface before it can serve network users. The connection is crucial because the WLC gives the AP the configuration information and firmware required for it to operate.
Wireless AP WLC registration issues are common and can be caused by a variety of reasons that are discoverable using appropriate debugging commands. Some common problems that cause WLC connection issues include:
- Duplicate IP addresses on the network.
- Regulatory domain mismatch error.
- AP missing on the WLC AP Authorization List.
- Corrupted certificates or keys on the AP.
- AP sending a discovery message from a VLAN that is not configured on the controller.
- Disabling of necessary ports on the firewall.
- AP configured as a mesh AP but being in bridge mode.
- AP address is marked as a bad address by the DHCP server.
In this article, you will find an overview of the Cisco AP discovery and join process, information on how to debug both your controller and your AP, and an analysis of the debugging results to find the most common reasons why your AP fails to join the WLC.
Download the guide and refer back to it at any time!
Before we continue, ask yourself a couple of questions:
Do I have the time and expertise to handle AP errors?
Do I have the resources to troubleshoot any issues on my network?
If you answered "No" to these questions, let PivIT handle it all with our EXTEND offering. Hire an engineer to take care of troubleshooting, configurations, and more. Click below to learn more about SmartHands.
The Cisco AP Discovery and Join Process
Before you begin diagnosing any AP joining issues, you should understand the Cisco AP registration process which takes place in two phases, namely, the discovery phase and the join phase.
The Discovery Phase
Immediately after you boot up the AP, it will attempt to discover as many controllers as possible using the following methods:
- Sending a layer 3 broadcast on the local subnet. All controllers available in the subnet that receive the discovery message will reply to the AP with a unicast discovery response.
- Using known locally stored controller IP addresses from previous connections. The AP will initiate communication with these previous controllers to determine whether they are active.
- Using DHCP option 43.
- DNS resolution of CISCO-CAPWAP-CONTROLLER.local-domain.
- Any controllers that were manually configured by a command-line interface (CLI).
Any controllers that are discovered during the discovery phase will send a response to the AP. The response includes the number of APs connected to it as well as the maximum number of APs it can support.
The Join Phase
The discovery phase ends with the AP having a list of potential controllers that it could join. It then sends a Control and Provisioning of Wireless Access Points (CAPWAP) discovery message to the controllers on the list, and the available controllers send back a CAPWAP response message.
The AP will follow the joining criteria shown below:
- Priority is given to any controllers that the AP had discovered before or any that had been configured as primary/secondary/tertiary (in that order).
- If the criterion at number 1 fails for all discovered controllers, the AP will attempt to join any controller configured as a master controller.
- Finally, if none of the controllers match the criteria above, the AP will attempt to join the controller with the least load, using the information received during the discovery phase.
Once it has determined which controller to join, the AP will send it a join request containing information about it and then wait for the controller to send a join response.
Debugging To View Events and Errors
When you are having issues with your AP connecting to the controller, it is always a good idea to debug the entire discovery and join process. The debug commands you use will show all events and errors that occurred during the process. The following section highlights the debug commands you can use on both the controller and the AP.
Debugging From the Controller’s Perspective
To view the entire discovery and join process from the controller’s perspective, issue the following debugging commands:
- debug disable-all: This command disables all debugs on the controller.
- debug capwap events enable: Using this command will give an output of all the CAPWAP events that occurred during the AP discovery and joining process. It will show all the discovery and join packets that were sent by the AP during the process.
- debug capwap errors enable: This command gives an output of CAPWAP errors that occurred during the discovery and joining process.
- debug mac addr 00:22:bd:19:6c:ce
- debug pm pki enable: This debug command shows the entire certificate validation process that occurs during the join phase. While no certificate validation takes place when the AP sends a discovery request, the AP must send an X.509 certificate during the joining phase. The controller then validates the certificate.
Debugging From the AP’s Perspective
If your AP has a console port, it is possible to view the join request sent by the AP by debugging it. Start by ensuring you are in the enable mode and then use the following debug CAPWAP commands to view the packets it sends as discovery and join requests:
- debug dhcp detail: Outputs DHCP option 43 details.
- debug ip udp: Gives an output of packets received and transmitted by the AP.
- debug capwap client event: Gives an output of the AP’s CAPWAP events.
- debug capwap client error: Gives an output of the AP’s CAPWAP errors.
- debug dtls client event: Gives an output of the AP’s DTLS events.
- debug dtls error enable: Gives an output of the AP’s DTLS errors.
- undebug all: Disables all debugs on the AP.
You should collect all the information you get after debugging from both the AP and controller and save it into a file.
Analyzing the Debugging Results To Discover the Causes of AP WLC Join Issues
Analyzing the output of the debugging commands can give you deeper insight into what the problem may be. Let’s go through an explanation of the most common debugging results and the reasons why your AP may fail to join the WLC.
Looking to purchase a new access point? Take a look at our comparison guides to find the perfect AP for your network:
- Comparing the Cisco Catalyst 9120AX and HPE Aruba 535 Access Points
- Juniper Mist AI and Cisco Battle for a Spot in Your Wireless Network
- Comparison Between the Cisco Catalyst 9130AX and Juniper Mist AP43
- Aruba AP 550 vs. Cisco Catalyst 9130AX AP - Future-Proof Your Network
‘No More AP Manager IP Addresses Remain’ Error Message
If you get this debug output, the problem is most likely the presence of duplicate IP addresses where one of the IP addresses on the network is the same as the AP manager’s IP address. This issue also causes the AP to reboot constantly without joining the controller.
Duplicate IP addresses are a common problem and running debug commands usually shows that the discovery phase occurred successfully but there was no join request sent from the AP. To resolve this issue, you can choose to remove the device with the duplicate IP address or change its address.
Regulatory Domain Mismatch Error
Your AP can only join the WLC if it has a similar regulatory domain. If the domains are dissimilar, a regulatory domain mismatch error occurs. You can view this error on the message log when you run the "debug capwap events" enable command. The image below shows the output on the WLC message log in case this is the issue.
Each regulatory domain supported by the WLC should be selected before an AP can be connected through it. It is recommended to buy APs that share a regulatory domain.
AP Authorization Failure Error
This error occurs if the AP is not included in the WLC AP authorization list, and you can usually discover it by running the "debug capwap events table" command on the WLC or the "debug capwap client error" command on the AP.
Running the debug command on the WLC gives an output like the one shown below.
On the other hand, running the debug command on the AP gives a message like the one shown below.
Solving this problem involves adding the access point to the authorization list by issuing the "config auth-list add mic <AP MAC Address>" command.
Corrupted Certificates or Keys Error
Your AP may fail to join the WLC because of a certificate or public key corruption error. To figure out whether there is corruption, issue the "debug capwap errors enable" and "debug pm pki enable" commands and analyze the output.
If there is a corruption error, output like the one below will be shown on the message log.
‘Received a Discovery Request With Subnet Broadcast With Wrong AP IP Address’ Error
This message is usually displayed if the main problem is the AP sending a discovery message from a VLAN not configured on the controller. This error usually means the controller will also drop the packets sent during the discovery phase.
‘AAA Authentication Failure for Username’ Error
This debugging output is usually displayed if the AP was configured as a mesh AP but is currently in bridge mode. If this is the case, you will need to add the AP to the WLC’s AP authorization list.
After adding the AP, it should download the image from the controller and then register in bridge mode. After that, change the mode to local mode. The AP will then download the image, reboot, and register in local mode.
Necessary Ports Are Disabled on the Firewall
Check and ensure that the following necessary ports for the AP to join the controller are enabled on the firewall:
- UDP ports 5247 (data) and 5246 (control) for CAPWAP traffic.
- UDP ports 16666 and 16667 for mobility traffic.
- TCP 161 and 162 for Simple Network Management Protocol (SNMP).
The DHCP Server Has Marked the AP’s Address as a Bad Address
Access points can constantly change their IP addresses when they are undergoing the AP discovery and join process. The constant renewal of IP addresses can cause the DHCP servers on the network to mark the AP’s addresses as bad addresses.
Conclusion
In summary, the process of AP registration on a WLC can be divided into the discovery phase and the join phase. If errors occur in any one of these phases, they can prevent the AP from joining the WLC. You can discover any existing errors by issuing debug commands. Studying the outputs of debug commands can give you deep insight into the problem causing the joining issues.
PivIT offers you a secure, isolated, and (most importantly) remote environment to pre-configure your network prior to deployment to your locations around the world using our out-of-band (OOB) management platform. Get your gear configured for deployment without overtaking your cubicle - everything you need and more is here.
