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 newly
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 switch over.
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, then a 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, then the controller with the lower redundancy management
address becomes the active controller and the other controller goes into
All download file
types, such as Image, Config, 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 Config, 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, that is the same as the management VLAN. Note that the RMI
and the RP should be in two separate L2 VLANs, which is a mandatory
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 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.
VLAN should be a non-routable 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 in pair, that are mapped to same VLAN and connected to same
Layer 3 Switch stop working, the standby controller is restarted.
When HA is enabled, the
standby controller always uses redundancy-management interface (RMI) and all
the other interfaces, dynamic and management, are invalid. A ping must only
accept redundancy-management interface (RMI) as source and not any other
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:
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
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
that you do not use the
on the standby-hot controller directly. If you use this, unsaved configurations
will be lost.
We recommend that
you enable link aggregation (LAG) configuration on the controllers before you
enable the port channel in the infrastructure switches.
that require reboot of the active controller results in the reboot of the
The Ignore AP list
is not synchronized from the active controller to the standby-hot controller.
The list is relearned through SNMP messages from the Cisco Prime
Infrastructure, after the standby-hot controller becomes active.
Client SSO related
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 other states.
clients that are in Run state are maintained during failover. Clients that in
transition such as roaming, 802.1X key regeneration, web authentication logout,
and so on, are dissociated.
Similar to AP
SSO, Client SSO is supported on only WLANs. The controllers must be in the same
subnet. L3 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 Cisco WLC are deauthenticated and are 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.
The active and
standby-hot controllers use the Redundancy Management Interface to check the
health of the peer controller and the default gateway of the management
interface through the network infrastructure.
Management Interface 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 Redundancy Management Interface to
communicate to the syslog, NTP 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 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 is 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 Redundancy Management Interface. The first two octets are always
169.254. For example, if the IP address of the Redundancy Management Interface
is 220.127.116.11, 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 millisecionds, or 80% 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.
Encryption of HA
related messages between the active and standby controllers is supported with
the use of data transport layer security (DTLS). The encryption is disabled by
default. The encryption is supported for configuration, AP and client
supported only if the active and standby controllers communicate through the
redundancy interface on the management ports. Encryption is not supported if
the redundancy port is used for communication between the active and standby
controllers. However, redundant management interface that is mapped to the
redundancy port is the default option. If the redundancy management interface
is not mapped to the redundancy port, the encryption is enabled because the HA
information goes over the network.
If encryption is
enabled on one controller and disabled on the other, the controllers do pair
up, but data synchronization over the redundancy link is unencrypted.
Encryption is supported for configurations, AP, and client synchronization.
Role negotiation and keepalive messages are not encrypted.
When you configure
the controller for
SSO, the Cisco 600
Series OfficeExtend Access Points are not supported.
In an HA
environment using FlexConnect locally switched clients, the client information
might not show the username. To get details about the client, you must use the
MAC address of the client. This restriction does not apply to FlexConnect
centrally switched clients or central (local) mode clients.
It is not
possible to access the Cisco WiSM2 GUI through the service interface when you
have enabled HA. The workaround is to create a service port interface again
after HA is established.
In an HA
environment, an upgrade from an LDPE image to a non-LDPE image is not
It is not possible
to pair two primary controllers or two secondary controllers.
controllers are unavailable on the APs connected switch port
controller with an evaluation license cannot become a standby controller.
However, an HA-SKU controller with zero license can become a standby
configuration is lost when moving from HA mode to non-HA mode and vice versa.
You should configure the service IP address manually again.
scenario is not supported: The primary controller has the management address
and the redundancy management address in the same VLAN, and the secondary
controller has the management address in the same VLAN as the primary one, and
the redundancy management address in a different VLAN.
The following is a
list of some software upgrade scenarios:
upgrade on the active controller ensures the upgrade of the standby-hot
upgrade is not supported. Therefore, you should plan your network downtime
before you upgrade the controllers in an HA environment.
active controller after a software upgrade also reboots the standby-hot
active and standby-hot controllers have different software releases in the
backup, and if you enter the
backup command in the active controller, both the controllers
reboot with their respective backup images breaking the HA pair due to a
reset applies to both the controllers in an HA environment. The peer controller
reboots a minute before the scheduled time expires on the active controller.
You can reboot
the standby-hot controller from the active controller by entering the
peer-system command if the scheduled reset is not planned. If you
reset only the standby-hot controller with this command, any unsaved
configurations on the standby-hot controller is lost. Therefore, ensure that
you save the configurations on the active controller before you reset the
download is reinitiated if an SSO is triggered at the time of the image
are allowed on the standby-hot controller.
switchover, if a peer controller has a controller software release that is
prior to Release 7.5, all the mobility clients are deauthenticated.
It is not possible
to access the standby-hot controller through the controller GUI, Cisco Prime
Infrastructure, or Telnet. You can access the standby-hot controller only on
When a failover occurs, the standby controller must be in a standby-hot state and the redundant port in a terminal state in SSO for successful switchover to occur.
To enable or
disable LAG, you must disable HA.
If LAG is
disabled and both primary and backup ports are connected to the management
interface and if the primary port becomes nonoperational, a switchover might
occur because the default gateway is not reachable and backup port failover
might exceed 12 seconds.
If an HA SSO
setup has LAG in enabled state and two ports that are connected to both primary
and secondary controllers, and if one switch port on the active controller
becomes nonoperational, a switchover occurs. Also, if the Redundancy Management
Interface is mapped to a DP and if any port is nonoperational for more than 300
milliseconds, SSO occurs because LAG convergence takes about 5 seconds.
Key (PMK) cache synchronization is not supported on FlexConnect
is not supported.
network admission control out-of-band are not supported because the client is
not in the Run state.
following are not synchronized between the active and standby controller:
Compatible Extension-based applications
Mobile IPv6, Application Visibility and Control, session initiation protocol
(SIP), and static call admission control (CAC) tree
Workgroup bridges and the clients associated with them
that are associated with Cisco 600 Series OfficeExtend Access Points
supported only if the active and standby controllers communicate through the
Redundancy Management Interface on the management ports. Encryption is not
supported if the redundancy port is used for communication between the active
and standby controllers.
change the NAT address configuration of the management interface when the
controllers are in redundancy mode. To enable NAT address configuration on the
management interface, you must remove the redundancy configuration first, make
the required changes on the primary controller, and then reenable the
redundancy configuration on the same controller.
On Cisco WiSM2
and Cisco Catalyst 6500 Series Supervisor Engine 2T, if HA is enabled, post
switchover, the APs might disconnect and reassociate with the WiSM2 controller.
To prevent this from occurring, before you configure HA, we recommend that you
verify, in the port channel, the details of both the active and standby Cisco
WiSM2 controllers that the ports are balanced in the same order and the port
channel hash distribution uses fixed algorithm. If they are not in order, you
must change the port channel distribution to be fixed and reset Cisco WiSM2
from the Cisco Catalyst 6500 Series Supervisor Engine 2T.
After you enable SSO, you
must access both the standby and active controller using:
The console connection
SSH facility on the service
SSH facility on the
redundant management interface
While SSO is enabled, you can not access both the standby and
active controller either using the web UI/the telnet facility or using Cisco
Prime Infrastructure/Prime NCS on the service port.
Configuring High Availability (GUI)
Before You Begin
Ensure that the management interfaces of both controllers are in the same subnet. You can verify this on the GUI of both the controllers by choosing Controllers > Interfaces and viewing the IP addresses of the management interface.
On the GUI of both controllers, choose Controller > Redundancy > Global Configuration.
The Global Configuration page is displayed.
Enter the addresses of both the controllers in the Redundant Management IP and the Peer Redundant Management IP text boxes.
Ensure that the Redundant Management Interface IP address of one controller is the same as the Redundancy Management Interface IP address of the peer controller.
From the Redundant Unit drop-down list, choose one of the controllers as primary and the other as secondary.
On the GUI of both the controllers, set the SSO to Enabled state.
After you enable an SSO, the service port peer IP address and the service port netmask appear on the configuration page. Note that the service port peer IP address and the netmask can be pushed to the peer only if the HA peer is available and operational. When you enable high availability, you do not have to configure the service port peer IP address and the service port netmask parameters. You must configure the parameters only when the HA peer is available and operational. After you enable SSO, both the controllers are rebooted. During the reboot process, the controllers negotiate the redundancy role through the redundant port based on the configuration. The primary controller becomes the active controller and the secondary controller becomes the standby controller.
(Optional) When the HA pair becomes available and operational, you can configure the peer service port IP address and the netmask when the service port is configured as static. If you enable DHCP on the service port, you do not have to configure these parameters on the Global Configuration page:
Service Port Peer IP—IP address of the service port of the peer controller.
Service Port Peer Netmask—Netmask of the service port of the peer controller.
Mobility MAC Address—A common MAC address for the active and standby
controllers that is used in the mobility protocol. If an HA pair has to be added as a mobility member for a mobility group, the mobility MAC address (instead of the system MAC address of the active or standby controller) should be used. Normally, the mobility MAC address is chosen as the MAC address of the active controller and you do not have to manually configure this.
Keep Alive Timer—The timer that controls how often the standby controller sends heartbeat keepalive messages to the active controller.
The valid range is between 100 to 400 milliseconds, in multiples of 50.
Peer Search Timer—The timer that controls how often the active controller sends peer
search messages to the standby controller.
The valid range is between 60 to 180 seconds.
After you enable the high availability and pair the controllers, there is only one unified GUI to manage the HA pair through the management port. GUI access through the service port is not feasible for both the active and standby controllers. The standby controller can be managed only through the console or the service port.
Only Telnet and SSH sessions are allowed through the service port of the active and standby controllers.
Click Save Configuration.
View the redundancy status of the HA pair by choosing Monitor > Redundancy > Summary.
The Redundancy Summary page is displayed.
Follow these steps to configure the peer network route:
This page provides a summary of the existing service port network routes of the peer controller to network or element management systems on a different subnet. You can view the IP address, IP netmask, or gateway IP address.
To create a new peer network route, click New.
Enter the IP address, IP netmask, and the Gateway IP address of the route.
Configuring High Availability (CLI)
Before You Begin
Ensure that the management interfaces of both controllers are in the same subnet.
Configure a local redundancy IP address and a peer redundancy management IP address by entering this command: