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 22.214.171.124. 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.
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
The information in this document is based on these software and
Cisco Aironet 1000 Series Lightweight AP
Two Cisco 2000 Series WLCs that run firmware
Microsoft Windows Server 2003 Enterprise DHCP
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.
This configuration can also be used with any other Cisco WLC and any
Technical Tips Conventions for more information on document
Controller Failover for Lightweight Access Points Configuration Example
for information on how to configure the WLC and lightweight AP for
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 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
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
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
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
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
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
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.
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
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
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
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
Note: The behavior explained in this section about AP fallback is
applicable to controllers that run version 126.96.36.199 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 188.8.131.52, 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
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
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
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
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
Ensure that these configuration parameters are correctly
AP fallback must be Enabled on all WLCs. You can
verify this on the Controller GUI page.
Before WLC versions 184.108.40.206, 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
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.