The 1030 REAP Access Points do not associate to the WLAN controller
The Remote Edge Access Points (REAP) configuration is like regular Access Point (AP) configurations, where you have to configure Wireless Local Area Networks (WLANs) on the controller. The key is that you have to define a WLAN1 with open or WPA-PSK since that is the WLAN that the AP beacons and uses when it loses the controller connection. In REAP, mode clients get Dynamic Host Control Protocol (DHCP) addresses from a local DHCP server instead of the remote DHCP server configured on the interface associated to the WLAN.
If the AP cannot find the controller, it needs to be primed in order to learn about the controller in two different ways.
The AP can learn about the controller if it is on the same Layer 2 subnet. The AP does a Layer 3 broadcast to 255.255.255.255 when it boots. The controller responds to that broadcast. Once the AP is up, you can configure it as a REAP AP and then move it to the remote location, and it remembers the IP address of the controller. It is possible that this is the fastest way to do it, but if anything happens to make the AP forget the IP address of the controller, it needs to be repeated.
You can set DHCP option 43 on the subnet, where the AP gets its IP address. Each subnet that the APs are on needs this option configured. Alternatively, and as the third thing the AP checks, the APs try to resolve a Domain Name System (DNS) entry. It does a lookup on CISCO-LWAPP-CONTROLLER @ Local_Domain_Name. DHCP needs to give the AP its local domain name.
The Controller Discovery Process
In a CAPWAP environment, a lightweight access point discovers a controller by using CAPWAP discovery mechanisms and then sends the controller a CAPWAP join request. The controller sends the access point a CAPWAP join response allowing the access point to join the controller. When the access point joins the controller, the controller manages its configuration, firmware, control transactions, and data transactions.
Upgrade and downgrade paths from LWAPP to CAPWAP or from CAPWAP to LWAPP are supported. An access point with an LWAPP image starts the discovery process in LWAPP. If it finds an LWAPP controller, it starts the LWAPP discovery process to join the controller. If it does not find a LWAPP controller, it starts the discovery in CAPWAP. If the number of times that the discovery process starts with one discovery type (CAPWAP or LWAPP) exceeds the maximum discovery count and the access point does not receive a discovery response, the discovery type changes to the other type. For example, if the access point does not discover the controller in LWAPP, it starts the discovery process in CAPWAP.
If an access point is in the UP state and its IP address changes, the access point tears down the existing CAPWAP tunnel and rejoins the controller. In previous software releases, the access point notifies the controller, and the session continues with the changed IP address without tearing down the session.
You must install software release 22.214.171.124 or later on the controller before connecting 1100 and 1300 series access points to the controller. The 1120 and 1310 access points were not supported prior to software release 126.96.36.199.
During the discovery process, the 1140 series access point will only query for Cisco CAPWAP Controllers. It will not query for LWAPP controllers. If you want this access point to query for both LWAPP and CAPWAP controllers then you need to update the DNS.
The Cisco controllers cannot edit or query any access point information using the CLI if the name of the access point contains a space.
Note 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.
Access points must be discovered by a controller before they can become an active part of the network. The lightweight access points support these controller discovery processes:
•Layer 3 CAPWAP or LWAPP discovery—Can occur on different subnets from the access point and uses IP addresses and UDP packets rather the MAC addresses used by Layer 2 discovery.
•Over-the-air provisioning (OTAP)—This feature is supported by Cisco 4400 series controllers. If this feature is enabled on the controller (on the controller General page), all associated access points transmit wireless CAPWAP or LWAPP neighbor messages, and new access points receive the controller IP address from these messages. This feature is disabled by default and should remain disabled when all access points are installed.
You can find additional information about OTAP at this link:
•Locally stored controller IP address discovery—If the access point was previously associated to a controller, the IP addresses of the primary, secondary, and tertiary controllers are stored in the access point's non-volatile memory. This process of storing controller IP addresses on an access point for later deployment is called priming the access point.
•DHCP server discovery—This feature uses DHCP option 43 to provide controller IP addresses to the access points. Cisco switches support a DHCP server option that is typically used for this capability. For more information about DHCP option 43, see the "Using DHCP Option 43 and DHCP Option 60" section.
•DNS discovery—The access point can discover controllers through your domain name server (DNS). For the access point to do so, you must configure your DNS to return controller IP addresses in response to CISCO-LWAPP-CONTROLLER.localdomain, where localdomain is the access point domain name. When an access point receives an IP address and DNS information from a DHCP server, it contacts the DNS to resolve CISCO-LWAPP-CONTROLLER.localdomain. When the DNS sends a list of controller IP addresses, the access point sends discovery requests to the controllers.
The option 43 not only needs to be configured for each subnet that the APs are on, or globally, it also needs to look at the option 60 string in order to return the correct option 43 format. The easiest way is to configure DNS and return a master controller where you want to find the AP in order to configure it.