cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
106477
Views
0
Helpful
3
Comments
TCC_2
Level 10
Level 10

 

 

Introduction

 

How to configure the Lightweight Access Point in order to join the respective Wireless LAN Controller

Overview of the Wireless LAN Controller (WLC) Discovery and Join Process

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:

  1. The LAP boots and DHCPs an IP address if it was not previously assigned a static IP address.
  2. The LAP sends discovery requests to controllers through the various discovery algorithms and builds a controller list. Essentially, the LAP learns as many management interface addresses for the controller list as possible via:
  • DHCP option 43 (good for global companies where offices and controllers are on different continents)
  • DNS entry for cisco-capwap-controller (good for local businesses - can also be used to find where brand new APs join)
  • Note: If you use CAPWAP, make sure that there is a DNS entry for cisco-capwap-controller.
  • Management IP addresses of controllers the LAP remembers previously
  • A Layer 3 broadcast on the subnet
  • Over the air provisioning
  • Statically configured information

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):

  • Primary Controller system name (previously configured on LAP)
  • Secondary Controller system name (previously configured on LAP)
  • Tertiary Controller system name (previously configured on LAP)
  • Master controller (if the LAP has not been previously configured with any Primary, Secondary, or Tertiary controller names. Used to always know which controller brand new LAPs join)
  • If none of the above are seen, load balance across controllers using the excess capacity value in the discovery response.

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.

Resolution

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:

  1. The AP issues a DHCP DISCOVER in order to obtain an address.
     
  2. Layer 2 attempts LWAPP WLAN controller discovery and Ethernet broadcast.
     
  3. Layer 3 attempts LWAPP WLAN controller discovery : 
           
    • LWAPP discovery broadcast on local subnet
                   
      • ip helper-address
         
      • ip forward-protocol udp 12223
             
    • Over-the-air provisioning
       
    • Locally stored controller IP address(IP addresses of the controller learned from previously joined mobility group )
       
    • DHCP option 43
       
    • DNS resolution of CISCO-LWAPP-CONTROLLER.localdomain
       
       
  4. Once the APs join the controller, the primary, secondary and tertiary controllers of the AP can be manually configured to join upon the next bootup, through the Command Line Interface (CLI) on the controller, as shown:

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]

WLC>save config

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.

GUI Configuration

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.

 

wlc_failover-7.gif

 

 

 

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.

Products

Access point

Wireless LAN Controllers

Reference Links

Comments
justin_barnes
Level 1
Level 1

or you could just plug the AP in, console into it, and enter in the command: lwapp ap controller ip address

<xxx.xxx.xxx.xxx> that normally saves a lot of headache, so long as the infrastucture is set up correctly

Vinay Sharma
Level 7
Level 7

Thanks Justin for this useful Tip.

Vinay

Gareth Gudger
Level 1
Level 1

Another common cause for AP join problems can be that the AP is stuck in MESH mode. I ran into this recently with 3 of my 4 new N radios. This was my fix.

http://supertekboy.com/2014/01/13/cisco-lightweight-access-point-will-not-join-to-a-wireless-lan-controller/

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: