The AP can discover controllers through your DNS. For the AP to do so, you must configure your DNS to return controller management IP addresses in response to a DNS query, nslookup, for CISCO-LWAPP-CONTROLLER.localdomain, where localdomain is the AP domain name, that is, company.com. When an AP receives DNS server information and the domain name (Option 15) in a DHCP offer, it can perform an nslookup to resolve CISCO-LWAPP-CONTROLLER.localdomain. When the DNS response returns a list of controller management IP addresses, the AP sends discovery requests to the controllers.
If the AP was previously associated to a controller, the IP addresses of the primary, secondary, and tertiary controllers can be stored in the nonvolatile memory of the AP. This process of storing controller IP addresses on an AP for later deployment is called priming the AP. Some deployments might have limitations in which you cannot configure DNS or DHCP options. In these cases you can place an AP in a network where the controller is already configured and can join it easily. After the AP joins the WLC, you can configure it as needed and even add a static IP address. You can configure the AP with primary/ secondary/tertiary controller information using either the WLC GUI or the CLI. To configure this using the CLI, use the following commands:
The key element here is that the controller it is going to join must be a member of the current WLC mobility group.
If the OTAP feature is enabled on the controller (on the Controller, General page), the controller will accept AP discoveries with an IE 58 value of 2. All associated APs transmit wireless LWAPP neighbor messages, and new APs receive the controller IP address from these messages over the air. This feature is disabled by default and should remain disabled after all APs are installed.
Controller Details Learned During the Discovery Process
In the discovery responses, the AP receives several details that it will use later in the join process:
■ Controller system name
■ Controller type
■ Max AP capacity
■ Active APs
■ AP manager address or addresses.
■ AP load per AP-manager interface
■ Master controller flag
The "Dissecting the Discovery Response" section, later in this topic, reviews the fields sent in the discovery response. Those fields can be quite useful for troubleshooting.
The WLC evaluates several conditions before answering the discovery request:
■ Invalid VLAN: If broadcast discovery requests are received via a VLAN in which the WLC does not have a management interface, they are discarded.
■ Resource conservation mode: If the WLC is doing AP upgrades, it limits the number of APs that can join, regardless of the platform limit.
■ MAX AP reached: If the maximum number of supported APs is reached, new APs are rejected. In code Release 5.1 and higher, you can, however, configure AP join priorities so that if critical APs need to join, the WLC can drop an AP with a lower priority so the higher priority AP can join. The WLC CLI command to set the priority is as follows:
A priority of 1 is the lowest, and a priority of 4 is the highest.
Note To avoid high CPU or memory utilization problems, during resource conservation mode, the WiSM/4400 will handle a maximum of 10 simultaneous APs. The 2100/NM-WLC will handle a maximum of 5 simultaneous APs.
At the end of the discovery process, the AP has a list of potential WLC candidates that can be selected for the join process.
The AP selects the WLC using the following criteria, in order of precedence:
■ If the AP has primary/secondary/tertiary or global backup WLC names configured, it tries to match them to the system name provided in the discovery response, in that order.
■ If none of the system names match or none of them have been configured, the AP sees if any of the WLCs it has learned about through the various discovery methods have the "Master Controller" flag set. If so, the AP sends a join request to the Master Controller.
■ If no WLC is found with the master flag set, the AP selects the WLC with the most available capacity from its list of discovered WLCs.
Note The name selection is done against the system name, not against a DNS name for the WLC. The distinction is quite important, and it is a common configuration mistake. You can see the system name in the home page of the GUI, or you can do a show sysinfo command as shown in Example 3-5.
Example 3-5 WLC System Name shown in show sysinfo Command Output
The join request contains the AP certificate, AP name, location, and radios installed. It is normally large, so it will be fragmented in at least two frames when it is sent from the AP side.
The WLC evaluates several conditions before answering the join request:
■ Resource conservation mode: If the controller is doing AP upgrades, it limits the number of APs that can join, regardless of the maximum limit of the platform.
■ MAX AP reached: If the maximum number of APs is reached, new APs are rejected. Again, AP join priority can override this in 5.1 and higher code releases.
■ AAA: If AP authorization is enabled, the controller tries to authenticate the AP MAC against the Authentication, Authorization, and Accounting (AAA) subsystem.
■ Certificate validation: In the LWAPP join request, the AP embeds a digitally signed X.509 certificate. When the certificate is validated, the WLC sends an LWAPP join response to indicate to the AP that it is successfully joined to the controller. The WLC embeds its own digitally signed X.509 certificate in the LWAPP join response that the AP must validate. Make sure you have configured the time, date, and year correctly on your WLC or the certificate validation will fail.
This is an optional phase, where APs download a new image from the WLC. This is normally triggered if the AP software version number does not match the version number that the WLC provides.
For 1000 series and 1510 APs, you might see that after a network down situation, or on stranded mesh APs, this family of APs might trigger a software download, even if no WLC software change has taken place. These APs can downgrade to a previous software version (backup image) if the discovery process has failed a number of times. On the next successful join, these APs will download the AP image version from the WLC again.
The transfer is done inside the LWAPP control tunnel using a single packet window protocol with sequence number validation. In some situations, you can see sequence number errors, which is normal if the AP is doing retransmits per timeouts.
Before using the image, the AP does a checksum validation to make sure that it received the entire image and that the image is not corrupted.
After joining, the AP does a configuration request to obtain the current configuration from the WLC.
Caution During the configuration request process, the wireless regulatory domain is validated. A WLC answers a discovery request for APs of different regulatory domains (for example, a U.S. AP trying to join a European WLC), but fails to answer a join request if the country/domain validation fails.
The AP sends the following information in the configuration request:
■ Regulatory domain for each of the radios
■ AP serial number
■ Current administrative status
■ AP group (if configured)
■ Radio details (configuration, power levels, antennas, and so on)
The WLC answers with a configuration response. The response includes the H-REAP RADIUS group, deletes mismatched override WLANs and AP groups, and provides a list of other WLCs in the current WLC mobility group.
Normally, depending on whether an AP is newly added to the WLC or if the configuration has changes, the WLC starts a set of configuration commands to bring the AP to the current status. Based on some of the performed changes, an expected AP reload might occur. An example of a configuration change that results in an AP reload is if the 802.11g network status had been enabled or disabled since the AP last joined the WLC.
After an AP has joined the WLC, has the correct configuration, and has the same image version as the WLC, it remains in the run or maintenance state. This is basically a working AP, joined to the WLC.
During the run state, the AP might be subject to several LWAPP control processes:
■ Configuration updates: The WLC might send changes to an AP (AutoRF, admin triggered, and so on). The AP acknowledges with a configuration response.
■ Statistics update: The AP sends periodic status updates involving AutoRF metrics, rogue reports, and so on.
■ Echo response/request: The AP sends an echo request to the WLC every 30 seconds by default. The WLC should answer with an echo response. In case of timeout, the AP then sends five echo requests at 1-second intervals to check for WLC availability and triggers a new discovery process if needed.
Periodically, the WLC triggers a key update request to change the security key used for LWAPP Control messages.
■ Reset request: The WLC can send a reset request, which the AP answers with a request response before reloading.
■ Event request/response: The AP can send asynchronous events to a WLC as a reaction to a nonscheduled event, such as a duplicate address, Message Integrity Check (MIC) error, or rogue on wire detected.
Remember that every LWAPP control packet contains a sequence number. The sequence number matches request/response packet exchanges. The sequence number in the response packet is the same value as the request packet.
When an LWAPP control frame is sent, the device monotonically increments its internal sequence number and eventually wraps back to 0. This ensures that no two pending requests have the same sequence number.