Configuring backup controllers – Cisco WIRELESS LAN CONTROLLER OL-17037-01 User Manual

Page 42

Advertising
background image

7-42

Cisco Wireless LAN Controller Configuration Guide

OL-17037-01

Chapter 7 Controlling Lightweight Access Points

Configuring Backup Controllers

Configuring Backup Controllers

A single controller at a centralized location can act as a backup for access points when they lose
connectivity with the primary controller in the local region. Centralized and regional controllers need
not be in the same mobility group. In controller software release 4.2 or later, you can specify a primary,
secondary, and tertiary controller for specific access points in your network. Using the controller GUI
or CLI, you can specify the IP addresses of the backup controllers, which allows the access points to fail
over to controllers outside of the mobility group.

In controller software release 5.0 or later, you can also configure primary and secondary backup
controllers (which are used if primary, secondary, or tertiary controllers are not specified or are not
responsive) for all access points connected to the controller as well as various timers, including heartbeat
timers and discovery request timers. To reduce the controller failure detection time, you can configure
the fast heartbeat interval (between the controller and the access point) with a smaller timeout value.
When the fast heartbeat timer expires (at every heartbeat interval), the access point determines if any
data packets have been received from the controller within the last interval. If no packets have been
received, the access point sends a fast echo request to the controller.

Note

You can configure the fast heartbeat timer only for access points in local and hybrid-REAP modes.

The access point maintains a list of backup controllers and periodically sends primary discovery requests
to each entry on the list. When the access point receives a new discovery response from a controller, the
backup controller list is updated. Any controller that fails to respond to two consecutive primary
discovery requests is removed from the list. If the access point’s local controller fails, it chooses an
available controller from the backup controller list in this order: primary, secondary, tertiary, primary
backup, secondary backup. The access point waits for a discovery response from the first available
controller in the backup list and joins the controller if it receives a response within the time configured
for the primary discovery request timer. If the time limit is reached, the access point assumes that the
controller cannot be joined and waits for a discovery response from the next available controller in the
list.

Note

When an access point’s primary controller comes back online, the access point disassociates from the
backup controller and reconnects to its primary controller. The access point falls back to its primary
controller and not to any secondary controller for which it is configured. For example, if an access point
is configured with primary, secondary, and tertiary controllers, it fails over to the tertiary controller when
the primary and secondary controllers become unresponsive and waits for the primary controller to come
back online so that it can fall back to the primary controller. The access point does not fall back from the
tertiary controller to the secondary controller if the secondary controller comes back online; it stays
connected to the tertiary controller until the primary controller comes back up.

Note

If you inadvertently configure a controller that is running software release 5.2 with a failover controller
that is running a different software release (such as 4.2, 5.0, or 5.1), the access point might take a long
time to join the failover controller because the access point starts the discovery process in CAPWAP and
then changes to LWAPP discovery.

Advertising