High availability (HA)
in controllers allows you to reduce the downtime of the wireless networks that
occurs due to the failover of controllers.
(Active:Standby-Hot) stateful switchover of access points (AP SSO) is
supported. In an HA architecture, one controller is configured as the primary
controller and another controller as the secondary controller.
After you enable HA,
the primary and secondary controllers are rebooted. During the boot process,
the role of the primary controller is negotiated as active and the role of the
secondary controller as standby-hot. After a switchover, the secondary
controller becomes the active controller and the primary controller becomes the
standby-hot controller. After subsequent switchovers, the roles are
interchanged between the primary and the secondary controllers. The reason for
switchovers are either because of manual trigger, or a controller, or network
During an AP SSO, all
the AP sessions statefully switch over and all the clients are deauthenticated
and reassociated with the new active controller except for the locally switched
clients in the FlexConnect mode.
controller continuously monitors the health of the active controller through a
direct wired connection over a dedicated redundancy port. Both the controllers
share the same configurations, including the IP address of the management
Before you enable HA,
ensure that both the controllers are physically connected through the redundant
port using an Ethernet cable. Also, ensure that the uplink is connected to an
infrastructure switch and that the gateway is reachable from both the
In HA architecture,
the redundancy port and redundant management interfaces have been introduced.
A seamless transition of clients from the active controller to
the standby controller is also supported. Clients that are not in the Run state
are removed after the switchover. During the stateful switchover of a client
(Client SSO), the information of the client is synchronized with the standby
controller when the client is associated with the controller, or is configured.
Clients that are fully authenticated, that is, clients that are in the Run
state, are synchronized with the peer controller. The data structures of
clients are synchronized based on the client state. Clients that are in the
transient state are dissociated after a switchover.
In the Cisco Wireless LAN
Controller Release 8.0 and later, the output of the
show ap join
command displays the status of the access points based on
whether the access point joined the controller or it was synchronized from
Active controller. One of the following statuses is displayed:
In Release 8.0 and later,
the output of the
redundancy summary command displays the bulk synchronization status
of access points and clients after the pair-up of active and standby
controllers occurs. The values are:
Synched—The access point joined the controller before
Connected—The access point joined the controller after
Joined—The access point rejoined the controller, or a
new AP has joined the controller after the SSO.
Indicates that synchronization of access points and the corresponding clients
details from the active to standby controller is yet to begin.
Indicates that synchronization of access points and the corresponding clients
details from the active to standby controller has begun and synchronization is
- Complete—Indicates that synchronization is complete
and the standby controller is ready for a switchover to resume the services of
the active controller.
From release 8.0 and later,
in a High Availability scenario, the sleeping timer is synchronized between
active and standby.
ACL and NAT IP
configurations are synchronized to the HA standby controller when these
parameters are configured before HA pair-up. If the NAT IP is set on the
management interface, the access point sets the AP manager IP address as the
NAT IP address. This issue is seen only when the NAT IP address and ACL are set
on the management interface before you enable high availability.
The following are some
guidelines for high availability:
We recommend that
you do not pair two controllers of different hardware models. If they are
paired, the higher controller model becomes the active controller and the other
controller goes into maintenance mode.
We recommend that
you do not pair two controllers on different controller software releases. If
they are paired, the controller with the lower redundancy management address
becomes the active controller and the other controller goes into maintenance
All download file
types, such as image, configuration, web-authentication bundle, and signature
files– are downloaded on the active controller first and then pushed to the
should be downloaded separately on each controller before they are paired.
You can upload
file types such as configuration files, event logs, crash files, and so on,
from the standby-hot controller using the GUI or CLI of the active controller.
You can also specify a suffix to the filename to identify the uploaded file.
To perform a peer
upload, use the service port. In a management network, you can also use the
redundancy management interface (RMI) that is mapped to the redundancy port or
RMI VLAN, or both, where the RMI is the same as the management VLAN. Note that
the RMI and the redundancy port should be in two separate Layer2 VLANs, which
is a mandatory configuration.
If the controllers
cannot reach each other through the redundant port and the RMI, the primary
controller becomes active and the standby-hot controller goes into the
To achieve HA between two Cisco Wireless Services Module 2 (WiSM2) platforms, the controllers should be deployed on a single chassis, or on multiple chassis using a virtual switching system (VSS) and extending a redundancy VLAN between the multiple chassis.
A redundancy VLAN should be a nonroutable VLAN in which a Layer 3 interface should not be created for the VLAN, and the interface should be allowed on the trunk port to extend an HA setup between multiple chassis. Redundancy VLAN should be created like any other data VLAN on Cisco IOS-based switching software. A redundancy VLAN is connected to the redundant port on Cisco WiSM2 through the backplane. It is not necessary to configure the IP address for the redundancy VLAN because the IP address is automatically generated. Also, ensure that the redundancy VLAN is not the same as the management VLAN.
When the RMIs
for two controllers that are a pair, and that are mapped to same VLAN and
connected to same Layer3 switch stop working, the standby controller is
The "mobilityHaMac is out of range" XML message is seen during the active/standby second switchover in an HA setup. This occurs if mobility HA MAC field is more than 128.
- When HA is enabled, the standby controller always uses the Remote Method Invocation (RMI), and all the other interfaces—dynamic and management, are invalid.
The RMI is meant to be used only for active and standby communications and not for any other purpose.
You must ensure
that the maximum transmission unit (MTU) on RMI port is 1500 bytes or higher
before you enable high availability.
When HA is enabled, ensure that you do not use the backed-up image. If this image is used, the HA feature might not work as expected:
The service port and route information that is configured is lost after you enable SSO. You must configure the service port and route information again after you enable SSO. You can configure the service port and route information for the standby-hot controller using the peer-service-port and peer-route commands.
For Cisco WiSM2, service port reconfigurations are required after you enable redundancy. Otherwise, Cisco WiSM2 might not be able to communicate with the supervisor. We recommend that you enable DHCP on the service port before you enable redundancy.
We recommend that you do not use the reset command on the standby-hot controller directly. If you use this, unsaved configurations will be lost.
We recommend that
you enable link aggregation configuration on the controllers before you enable
the port channel in the infrastructure switches.
configurations that require reboot of the active controller results in the
reboot of the standby-hot controller.
The Ignore AP list
is not synchronized from the active controller to the standby-hot controller.
The list is relearned through SNMP messages from Cisco Prime Infrastructure
after the standby-hot controller becomes active.
Client SSO related guidelines:
The standby controller maintains two client lists: one is a list of clients in the Run state and the other is a list of transient clients in all the other states.
Only the clients that are in the Run state are maintained during failover. Clients that are in transition, such as roaming, 802.1X key regeneration, web authentication logout, and so on, are dissociated.
As with AP SSO, Client SSO is supported only on WLANs. The controllers must be in the same subnet. Layer3 connection is not supported.
In Release 7.3.x, AP SSO is supported, but client SSO is not supported, which means that after an HA setup that uses Release 7.3.x encounters a switchover, all the clients associated with the controller are deauthenticated and forced to reassociate.
You must manually configure the mobility MAC address on the then active controller post switchover, when a peer controller has a controller software release that is prior to Release 7.2.
To enable an access point to maintain controlled quality of service (QoS) for voice and video parameters, all the bandwidth-based or static call admission control (CAC) parameters are synchronized from active to standby when a switchover occurs.
From 8.0 release and later, the standby controller does not reboot; instead enters the maintenance mode when unable to connect to the default gateway using the redundant port. Once the controller reconnects to the default gateway, the standby controller reboots and the HA pair with the active controller is initiated. However, the active controller still reboots before entering the maintenance mode.
The following are supported from Release 8.0:
Static CAC synchronization—To maintain controlled Quality-of-Service (QoS) for voice and video parameters, all the bandwidth-based or static CAC parameters services are readily available for clients when a switchover occurs.
Internal DHCP server—To serve wireless clients of the controller, the internal DHCP server data is synchronized from the active controller to the standby controller. All the assigned IP addresses remain valid, and IP address assignation continues when the role changes from active to standby occurs.
Enhanced debugging and serviceability—All the debugging and serviceability services are enhanced for users.
The physical connectivity or topology of the access points on the switch are not synchronized from the active to the standby controller. The standby controller learns the details only when the synchronization is complete. Hence, you must execute the show ap cdp neighbors all command only after synchronization is complete, and only when the standby becomes the then active controller.
To enable access points to join the HA-SKU secondary controller that has been reset to factory defaults, you must:
Configure the HA SKU controller as secondary controller. To do this, you must execute the config redundancy unit secondary command on the HA SKU controller.
Reboot the HA SKU controller after you successfully execute the config redundancy unit secondary command.
The active and
standby-hot controllers use the RMI to check the health of the peer controller
and the default gateway of the management interface through network
The RMI is also
used to send notifications from the active controller to the standby-hot
controller if a failure or manual reset occurs. The standby-hot controller uses
the RMI to communicate to the syslog, NTP/SNTP server, FTP, and TFTP server.
It is mandatory to
configure the IP addresses of the Redundancy Management Interface and the
Management Interface in the same subnet on both the primary and secondary
The redundancy port
is used for configuration, operational data synchronization, and role
negotiation between the primary and secondary controllers.
The redundancy port
checks for peer reachability by sending UDP keepalive messages every 100
milliseconds (default frequency) from the standby-hot controller to the active
controller. If a failure of the active controller occurs, the redundancy port
is used to notify the standby-hot controller.
If an NTP/SNTP
server is not configured, the redundancy port performs a time synchronization
from the active controller to the standby-hot controller.
In Cisco WiSM2, the redundancy VLAN must be configured on the Cisco Catalyst 6000 Supervisor Engine because there is no physical redundancy port available on Cisco WiSM2.
The redundancy port and the redundancy VLAN in Cisco WiSM2 are assigned an automatically generated IP address in which the last two octets are obtained from the last two octets of the RMI. The first two octets are always 169.254. For example, if the IP address of the RMI is 188.8.131.52, the IP address of the redundancy port is 169.254.200.225.
The redundancy ports can connect over an L2 switch. Ensure that
the redundancy port round-trip time is less than 80 milliseconds if the
keepalive timer is set to default, that is, 100 milliseconds, or 80 percent of
the keepalive timer if you have configured the keepalive timer in the range of
100 milliseconds to 400 milliseconds. The failure detection time is calculated,
for example, if the keepalive timer is set to 100 milliseconds, as follows: 3 *
100 = 300 + 60 = 360 + jitter (12 milliseconds) = ~400 milliseconds. Also,
ensure that the bandwidth between redundancy ports is 60 Mbps or higher. Ensure
that the maximum transmission unit (MTU) is 1500 bytes or higher.