High Availability in controllers allows you to reduce the downtime of the wireless networks that could occur due to failover of controllers.

A 1:1 (Active:Standby-Hot) stateful switchover of access points and clients is supported (HA SSO). In a High Availability architecture, one controller is configured as the primary controller and another controller as the secondary controller.

After you enable High Availability, 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 or cause for most switchover events is due to a manual trigger, a controller and/or a network failure.

During an HA SSO failover event, all of the AP CAPWAP sessions and client sessions in RUN state on the controller are statefully switched over to the standby controller without interruption, except PMIPv6 clients, which will need to reconnect and authenticate to the controller following an HA SSO switchover. For additional client SSO behaviors and limitations, see the "Client SSO" section in the High Availability (SSO) Deployment Guide at:

The standby-hot controller continuously monitors the health of the active controller through its dedicated redundancy port. Both the controllers share the same configurations, including the IP address of the management interface.

Before you enable High Availability, ensure that both the controllers can successfully communicate with one another through their dedicated redundancy port, either through a direct cable connection or through Layer 2. For more details, see the "Redundancy Port Connectivity" section in the High Availability (SSO) Deployment Guide:

In the Release 8.0 and later releases, the output of the show ap join stats summary 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:

• Synched—The access point joined the controller before the SSO.

• Connected—The access point joined the controller after the SSO.

• Joined—The access point rejoined the controller, or a new AP has joined the controller after the SSO.

In Release 8.0 and later, the output of the show 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:

• Pending— Indicates that synchronization of access points and the corresponding clients details from the active to standby controller is yet to begin.

• In-progress— Indicates that synchronization of access points and the corresponding clients details from the active to standby controller has begun and synchronization is in progress.

• 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 High Availability standby controller when these parameters are configured before High Availability 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.

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 mode.

• We recommend that you disable High Availability and add license in Cisco 5520and 8540 controllers (RTU based). However, it is not mandatory to disable High Availability as AP licenses added in Primary controller will be inherited to Secondary controller.

• 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 standby-hot controller.

• Certificates 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 maintenance mode.

  Note

  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 restarted. The mobilityHaMac is out of range XML message is seen during the active/standby second switchover in a High Availability setup. This occurs if mobility HA MAC field is more than 128.

• When High Availability is enabled, the standby controller always uses the Remote Method Invocation (RMI), and all the other interfaces—dynamic and management, are invalid.

  Note	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 High Availability is enabled, ensure that you do not use the backup image. If this image is used, the High Availability 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.

  • 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.

• All the configurations that require reboot of the active controller results in the reboot of the standby-hot controller.

• The Rogue AP Ignore 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 a High Availability 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.

• 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 High Availability 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 run 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.

• We recommend that you do not disable LAG physical ports when HA SSO is enabled.

• HA sync for Fabric-related statistics is not supported.

• You should apply an access list for SSH to the redundancy interface on upper switch, if controller is configured for HA SSO and redundancy management is configured over a dynamic interface. Failure to do so enables the SSH client to connect through the redundancy management interface regardless of the CPU ACL.

• 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.

• In an HA environment, an upgrade from an LDPE image to a non-LDPE image is not supported.

• It is not possible to pair two primary controllers or two secondary controllers.

• Standby controllers are unavailable on the APs connected switch port.

• An HA-SKU controller with an evaluation license cannot become a standby controller. However, an HA-SKU controller with zero license can become a standby controller.

• In an HA setup, CPU-ACL cannot be applied on the service port. However, if you want to block the service port using CPU-ACL, you can use the command config acl high-priority to configure as required.

• Service VLAN configuration is lost when moving from HA mode to non-HA mode and conversely. You should then configure the service IP address manually again.

• The following 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:

  • A software upgrade on the active controller ensures the upgrade of the standby-hot controller.

  • An in-service upgrade is not supported. Therefore, you should plan your network downtime before you upgrade the controllers in an HA environment.

  • Rebooting the active controller after a software upgrade also reboots the standby-hot controller.

  • We recommend that both active and standby-hot controllers have the same software image in the backup before running the config boot backup command. If both active and standby-hot controllers have different software images in the backup, and if you run the config boot backup command in the active controller, both the controllers reboot with their respective backup images breaking the HA pair due to a software mismatch.

  • A schedule 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 reset 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 are lost. Therefore, ensure that you save the configurations on the active controller before you reset the standby-hot controller.

  • If an SSO is triggered at the time of the image transfer, a preimage download is reinitiated.

  • Only debug and show commands are allowed on the standby-hot controller.

  • After a 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 its console.

• When you enable both RADIUS profiling and WSA in an SSID, local profiling gets enabled in the same SSID.

• In an HA setup, client Tx or Rx packets are not sent to the standby controller, hence, Remote Method Invocation (RMI) is not supported.

• 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.

  Note	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.

• When a failover occurs and the standby controller becomes the new active controller, it takes approximately 15–20 minutes to synchronize the database (AP, client, and multicast) between the two controllers. If another failover occurs during this time, the HA structures would not yet be synchronized. Therefore, the APs and clients would have to get reassociated and reauthenticated respectively.

• Pairwise Master Key (PMK) cache synchronization is not supported on FlexConnect local-authenticated clients.

• Client SSO restrictions:

  • New mobility is not supported.

  • Posture and network admission control out-of-band are not supported because the client is not in the Run state.

  • The following are not synchronized between the active and standby controller:

    • Cisco Compatible Extension-based applications

    • Client statistics

    • Proxy Mobile IPv6, Application Visibility and Control, session initiation protocol (SIP), and static call admission control (CAC) tree

    • Workgroup bridges and the clients that are associated with them

    • Passive clients

  • Encryption is supported.

• Encryption is 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.

• You cannot 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.

• After you enable SSO, you must access both the standby and active controller using:

  • The console connection

  • SSH facility on the service port

  • SSH facility on the redundant management interface

  Note	While SSO is enabled, you cannot 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. This issue is addressed via CSCuf71713 in Release 8.2 and later releases.

• Synchronization of bulk configurations is supported only for the configurations that are stored in XMLs. Scheduled reboot is a configuration that is not stored in XMLs or Flash. Therefore, the scheduled reboot configuration is not included in the synchronization of bulk configurations.

• When a switchover occurs, the controller does not synchronize the information on DHCP dirty bit from the active to standby controller even when DHCP dirty bit is set on the active controller. After a switchover, the controller populates the DHCP dirty bit based on the client DHCP retries.

• NTP server status per AP is only periodically updated from the AP to the controller. Therefore, the NTP server status is not synchronized with the standby controller. We recommend that you check the NTP server statistics in the active controller.

  During switchover, the time taken to get the NTP server status to the new active controller that was the standby controller previously is about 20 minutes.

Cisco Wireless Controller (WLC) Release 8.4 introduces support for N+1 High Availability (HA) on the Cisco Virtual Wireless Controller (vWLC) platform. For information on how to configure HA, see:

https://www.cisco.com/c/en/us/td/docs/wireless/technology/hi_avail/N1_High_Availability_Deployment_Guide/N1_HA_Overview.html#pgfId-1054644

The Cisco vWLC HA has the following prerequisites:

• The primary, secondary, and tertiary vWLCs should be part of the same mobility group.

• The vWLC in the mobility group should have a uniform set of hash keys to seamlessly move an AP from one vWLC to another. For example, if we have vWLCs, N, in a mobility group, or vWLC, M, and normal WLCs (where M is greater than N), then all vWLCs should have the hashes of other vWLCs in the same group.

• For effective connectivity of the APs on all the vWLCs in a mobility group (including vWLC mobility members in N+1 format), the mobility hash table should contain all the vWLC hash keys.

Note	A hash table works only when vWLCs are paired as mobility members.