How to configure the Lightweight Access Point in order to join the respective Wireless LAN Controller
In a Cisco Unified Wireless network, the LAPs must first discover and join a WLC before they can service wireless clients.
Originally, the controllers only operated in Layer 2 mode. In Layer 2 mode, the LAPs are required to be on the same subnet as the management interface and the Layer 3 mode AP-manager interface is not present on the controller. The LAPs communicate with the controller using Layer 2 encapsulation only (ethernet encapsulation) and do not Dynamic Host Configuration Protocol (DHCP) an IP address.
When Layer 3 mode on the controller was developed, a new Layer 3 interface called AP-manager was introduced. In Layer 3 mode, the LAPs would DHCP an IP address first and then send their discovery request to the management interface using IP addresses (Layer 3). This allowed the LAPs to be on a different subnet than the management interface of the controller. Layer 3 mode is the dominate mode today. Some controllers and LAPs can only perform Layer 3 mode.
However, this presented a new problem: how did the LAPs find the management IP address of the controller when it was on a different subnet?
In Layer 2 mode, they were required to be on the same subnet. In Layer 3 mode, the controller and LAP are essentially playing hide and seek in the network. If you do not tell the LAP where the controller is via DHCP option 43, DNS resolution of "Cisco-lwapp-controller@local_domain", or statically configure it, the LAP does not know where in the network to find the management interface of the controller.
In addition to these methods, the LAP does automatically look on the local subnet for controllers with a 255.255.255.255 local broadcast. Also, the LAP remembers the management IP address of any controller it joins across reboots. Therefore, if you put the LAP first on the local subnet of the management interface, it will find the controller's management interface and remember the address. This is called priming. This does not help find the controller if you replace a LAP later on. Therefore, Cisco recommends using the DHCP option 43 or DNS methods.
When the LAPs discover the controller, they do not know if the controller is in Layer 2 mode or Layer 3 mode. Therefore, the LAPs always connect to the management interface address of the controller first with a discovery request. The controller then tells the LAP which mode it is in the discovery reply. If the controller is in Layer 3 mode, the discovery reply contains the Layer 3 AP-manager IP address so the LAP can send a join request to the AP-manager interface next.
Note: By default both management and AP-manager interfaces are left untagged on their VLAN during configuration. In case these are tagged, make sure they are tagged to the same VLAN in order to properly receive discovery and join response from the WLC.
The LWAPP AP goes through this process on startup for Layer 3 mode:
From this list, the easiest method to use for deployment is to have the LAPs on the same subnet as the management interface of the controller and allow the LAP’s Layer 3 broadcast to find the controller. This method should be used for companies that have a small network and do not own a local DNS server.
The next easiest method of deployment is to use a DNS entry with DHCP. You can have multiple entries of the same DNS name. This allows the LAP to discover multiple controllers. This method should be used by companies that have all of their controllers in a single location and own a local DNS server. Or, if the company has multiple DNS suffixes and the controllers are segregated by suffix.
DHCP option 43 is used by large companies to localize the information via the DHCP. This method is used by large enterprises that have a single DNS suffix. For example, Cisco owns buildings in Europe, Australia, and the United States. In order to ensure that the LAPs only join controllers locally, Cisco cannot use a DNS entry and must use DHCP option 43 information to tell the LAPs what the management IP address of their local controller is.
Finally, static configuration is used for a network that does not have a DHCP server.You can statically configure the information necessary to join a controller via the console port and the AP’s CLI. For information on how to statically configure controller information using the AP CLI, refer to Manually Configuring Controller Information Using the Access Point CLI http://www.cisco.com/en/US/docs/wireless/access_point/1240/installation/guide/124h_c4.html#wp1082991.
For a detailed explanation on the different discovery algorithms that LAPs use to find controllers, refer to LAP Registration with WLC http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a00806c9e51.shtml.
For information on configuring DHCP option 43 on a DHCP server, refer to DHCP OPTION 43 for Lightweight Cisco Aironet Access Points Configuration Example http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a00808714fe.shtml.
3. Send a discovery request to every controller on the list and wait for the controller's discovery reply which contains the system name, AP-manager IP addresses, the number of APs already attached to each AP-manager interface, and overall excess capacity for the controller.
4. Look at the controller list and send a join request to a controller in this order (only if the AP received a discovery reply from it):
If two controllers have the same excess capacity, then send the join request to the first controller that responded to the discovery request with a discovery response. If a single controller has multiple AP-managers on multiple interfaces, choose the AP-manager interface with the least number of APs.
The controller will respond to all discovery requests without checking certificates or AP credentials. However, join requests must have a valid certificate in order to get a join response from the controller. If the LAP does not receive a join response from its choice, the LAP will try the next controller in the list unless the controller is a configured controller (Primary/Secondary/Tertiary).
5. When it receives the join reply, the AP checks to make sure it has the same image as that of the controller. If not, the AP downloads the image from the controller and reboots to load the new image and starts the process all over again from step 1.
6. If it has the same software image, it asks for the configuration from the controller and moves into the registered state on the controller.
After you download the configuration, the AP might reload again to apply the new configuration. Therefore, an extra reload can occur and is a normal behaviour.
Priming is a process by which the Lightweight Access Point (LWAP) can be configured to associate to the respective Wireless LAN Controller (WLC). Priming can be done with the use of CLI commands or GUI configuration.
These are the steps to configure Priming in LWAP. Before you configure the access point, make sure that the access point discovers the Controller.
The different methods by which the access point (AP) discovers the controller are:
WLC>config ap primary-base [Switch name] [Cisco AP]
WLC>config ap secondary-base [Switch name] [Cisco AP]
WLC>config ap tertiary-base [Switch name] [Cisco AP]
Note: Switch name refers to the primary, secondary and tertiary controller names.
After the configuration is saved, issue the WLC> config ap reset command in order to clear the AP from the CLI. Upon reboot, the AP joins the primary-base controller that is configured for that AP.
From the GUI, click the Wireless tab in the menu at the top of the window, select the AP from the list of APs that are registered to the WLC, and clickDetail beside the AP.
The All APs > Details window appears.
In this window, define the primary, secondary, and tertiary controllers.
Note: Define only system names under the primary, secondary, and tertiary controller name fields. Do not enter the IP address or the MAC address of the controller in these fields.
Note: This example does not add a tertiary controller name because there are only two controllers.
Wireless LAN Controllers