Controller Discovery Process
To support the IW916I AP, the controller must be running Cisco IOS XE Dublin 17.12.1 or a later release. For more information, see the Cisco Catalyst IW9167 Heavy Duty Series Data Sheet.
Guidelines and Limitations
-
It is not possible to edit or query an access point using the controller CLI if the name of the access point contains a space.
-
Make sure that the controller is set to the current time. If the controller is set to a time that has already occurred, the access point might not join the controller because its certificate may not be valid for that time.
The controller must discover AP before it can become an active part of the network. The AP supports the following controller discovery processes:
-
Locally stored controller IP address discovery: If the AP was previously joined to a controller, the primary, secondary, and tertiary controllers' IP addresses are stored in the AP's non-volatile memory. This process of storing controller IP addresses on an AP for later deployment is called priming the AP. For more information about priming, see Performing a Preinstallation Configuration (Optional).
-
DHCP server discovery: This feature uses DHCP option 43 to provide controller IP address to the AP. Cisco switches support a DHCP server option that is typically used for this capability. For more information about DHCP option 43, see Configuring DHCP Option 43.
-
DNS discovery: The AP can discover controllers through your domain name server (DNS). For the AP to do so, you must configure your DNS to return controller IP addresses in response to CISCO-CAPWAP-CONTROLLER.localdomain, where localdomain is the AP domain name. Configuring the CISCO-CAPWAP-CONTROLLER provides backward compatibility in an existing customer deployment. When an AP receives an IP address and DNS information from a DHCP server, it contacts the DNS to resolve CISCO-CAPWAP-CONTROLLER.localdomain. When the DNS sends a list of controller IP addresses, the AP sends discovery requests to the controllers.