AP Load Balancing and AP Fallback in Unified Wireless Networks

Introduction

This document discusses how access point (AP) load balancing and AP fallback work in the Cisco Unified Wireless solution. This document also explains how to set up multiple wireless LAN (WLAN) controllers (WLCs) for a failover condition. A failover condition occurs when a primary controller goes down or fails for any reason. Then, a second controller takes over the operation. Failover is also called controller redundancy.

Note: AP fallback discussed in this document is only related to the controller firmware version before 3.2.171.5. Later versions of controller firmware do not behave in this way. In the latest version of firmware, the AP falls back to the primary controller whenever it comes online. If you have an AP fallback issue, read this document or upgrade your controller firmware to the latest available code.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• Configuration of lightweight APs and Cisco WLCs

• Lightweight AP Protocol (LWAPP)

• Configuration of an external DHCP server

• DNS Server

Components Used

The information in this document is based on these software and hardware versions:

• Cisco Aironet 1000 Series Lightweight AP

• Two Cisco 2000 Series WLCs that run firmware 3.2.78.0

• Microsoft Windows Server 2003 Enterprise DHCP server

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Related Products

This configuration can also be used with any other Cisco WLC and any lightweight AP.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Configure

Refer to WLAN Controller Failover for Lightweight Access Points Configuration Example for information on how to configure the WLC and lightweight AP for failover.

AP Load Balancing

You can perform AP load balancing on two (or more) WLCs if you configure mobility groups properly. The LWAPP allows for dynamic redundancy and load balancing. For example, if you specify more than one IP address for option 43, an AP sends LWAPP discovery requests to each of the IP addresses that the AP receives. In the WLC LWAPP discovery response, the WLC embeds this information:

• Information on the current AP load, which is defined as the number of APs that are joined to the WLC at the time

• The AP capacity

• The number of wireless clients that are connected to the WLC

The AP then attempts to join the least loaded WLC, which is the WLC with the greatest available AP capacity. After an AP joins a WLC, the AP learns the IP addresses of the other WLCs in the mobility group from its joined WLC.

Subsequently, the AP sends LWAPP primary discovery requests to each of the WLCs in the mobility group. The WLCs respond with a primary discovery response to the AP. The primary discovery response includes information about the WLC type, total capacity, and current AP load. As long as the WLC has the AP Fallback parameter enabled, the AP can decide to change over to a less loaded WLC.

When the AP boots or resets, it only knows the controller management IP addresses from DNS (Cisco-lwapp-controller@local_domain.com) (20 max), DHCP option 43 (20 max), OTAP, 255.255.255.255, and the previously joined controller. The controllers in the mobility group of the previously joined controller are not retained across reboots.

However, if the AP loses connectivity with the controller, it does not reboot. It moves directly into discovery mode and remembers the mobility group members. It can then send a discovery request to all members of the mobility group.

Note: Once an AP joins a controller, it only leaves the currently joined controller for a limited number of reasons. One reason that the AP does not leave the currently joined controller is if the APs are not exactly load balanced across all controllers. For that reason, this load balancing algorithm is only an approximate load balancing algorithm unless you manually define a primary controller for each AP.

These rules are best described with some examples:

• The AP is new, out of the box, and never joined to a controller. Does this AP load balance across 3 controllers in a mobility group?

  No. The AP must discover all 3 controller management IP addresses during boot via OTAP, DNS (with all 3 management ip addresses defined), 255.255.255.255, and DHCP Option 43 (with all 3 management ip addresses included) for load balancing. The AP sends a discovery request to all known controllers and joins the controller with the most excess AP capacity. If only 1 controller is defined in DHCP option 43/DNS, the new APs always join that controller.

• If there is 1 controller defined in DHCP option 43/DNS and there are 3 controllers in the mobility group, does it load balance across the 3 controllers in a mobility group if you reboot the AP after it joins the controller in DHCP option 43?

  No. If the AP reboots or is reset, it always joins the controller in the DHCP option 43/DNS or the last joined controller. However, if the AP loses the heartbeat to the current controller, it does not reboot. Instead, the AP goes directly into discovery mode. Because it did not reboot, the AP still has the mobility members and sends each controller in the mobility group a discovery request.

• What does the AP use mobility members for?

  AP fallback (unconfigured controller to configured controller [primary/secondary/tertiary]) and learning other controller IP addresses after it joins a controller in case it loses contact with the current controller. Remember that the AP forgets the mobility members across reboots.

  Note: There can be a race condition on this algorithm. Between the time the controller replies to the discovery request of the AP and the time the AP sends in a join request to the AP-manager, the number of APs joined to the AP-manager might have changed if there is a large number of APs that join the controller simultaneously. For example, if there is a power outage and the power on the APs comes back simultaneously, the APs might not load balance evenly across the controllers.

AP Fallback

Unlike Hot Standby Router Protocol (HSRP) standby, AP fallback disrupts wireless service while the AP failsover and then falls back to the configured controller. Remember that once an AP joins a controller, the AP is only programmed to leave that controller if:

• The AP loses responses from its keepalives to the controller.

• The customer resets the AP via the controller.

• The AP receives notification, via the mobility group members update from the current controller, that a configured controller (Primary/Secondary/Tertiary) is up, and the AP is currently joined to an unconfigured controller with AP fallback enabled.

It is important to note that the AP only performs AP fallback from an unconfigured controller to a configured controller (Primary/Secondary/Tertiary). The AP does not fall back from a secondary controller to the primary controller if it is currently joined to the secondary controller. This is because the secondary controller is a configured controller.

When the AP is joined to an unconfigured controller and it is notified that a configured controller is up and available via the mobility group members, it immediately leaves the current controller and joins the configured controller.

Note: The behavior explained in this section about AP fallback is applicable to controllers that run version 3.2.171.5 or earlier. Later versions of controller firmware do not have these problems. In the latest version of firmware, the AP falls back to the primary controller whenever it comes online. If you have an AP fallback issue, upgrade your controller firmware to the latest available code.

Note:  When a brand new LWAPP AP1242 first connects to a WLC2006 or WLC4400 that runs firmware 2.3.116.21, the secondary controller name (i.e. "WIRELESS"->"Detail") in GUI is not blank. The show AP config general command also shows that the secondary controller name is not blank. This has been reported in Cisco bug id CSCse30514. Although there is not a workaround, this behavior is not present in the 4.0 software release.

Note: When you run 5.2 code or later on WLCs and set up AP High Availability, if the global 802.11g configuration between the controllers does not match (enable vs. disabled), this can cause AP join issues when a failover event occurs. Make sure that all WLC settings are identical between primary/secondary/tertiary WLCs.

Recommendations

For random load balancing, none of the primary/secondary/tertiary controllers need to be configured. However, all of the controllers that you want the AP to load balance across must be defined in DHCP option 43 or DNS.

If you want to ensure perfect load balancing every time, Cisco recommends that you manually configure the primary controller on the AP and leave the other two controllers blank. As long as the primary controller is up and functional, and the mobility group is defined across any controller that the AP can join, the AP tries to join the primary controller whenever it is up and operational.

If you want the AP to fall back to a secondary controller at the remote site before you try another controller across the WAN, all 3 controllers need to be defined in the DHCP option 43 or DNS. However, only define the primary and secondary controllers on the APs at the remote site.

If the WAN controller is not defined in the DHCP option 43 or DNS, the AP only failsover to it if the WAN controller is in the mobility group of the currently joined controller and if the local controllers then go down. If the AP reboots, it does not join the WAN controller, except if the last controller it joined was the WAN controller, until one of the DHCP option 43 or DNS controllers is available to tell the AP about mobility group members.

Note: The controller name in the AP configuration is case sensitive. Therefore, make sure to configure the exact system name on the AP configuration. Failure to do this results in the AP fallback not working.

Ensure that these configuration parameters are correctly configured:

• AP fallback must be Enabled on all WLCs. You can verify this on the Controller GUI page.

• Before WLC versions 5.0.148.0, only controller system names could be entered in the AP Primary/Secondary/Tertiary Controller name fields. Now the IP addresses of the controller management interface can be used as well.

• AP failover and fallback require controllers to be configured in the same mobility group.

  Use the CLI mping command in order to verify mobility group membership communication. Use the show mobility summary command in order to display a controller's mobility group configuration information.

  Controllers configured in the Mobility Group
   MAC Address        IP Address       Group Name    Status
   00:0b:85:44:36:e0    192.168.240.10   Wireless     Up
   00:1f:9e:9b:08:20    192.168.251.250  Wireless     Control Path Down

  If you see the status as Control Path Down, verify that there is no firewall between the WLCs, or make sure to permit these protocol/ports.

Related Information

• Configure Mobility Groups for the WLCs
• Wireless LAN Controller (WLC) Troubleshoot FAQ
• Cisco Wireless LAN Controllers
• Cisco Wireless LAN Controller Configuration Guide, Release 4.0
• Cisco Wireless LAN Controller Configuration Guide, Release 3.2
• Technical Support & Documentation - Cisco Systems