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:

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.

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

  Note

  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 a High Availability 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. For more information, see the "High Availability Connectivity Using Redundant VLAN on WiSM-2 WLC" section in the in the High Availability (SSO) Deployment Guide at: https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-1/HA_SSO_DG/High_Availability_DG.html#pgfId-43232

  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.

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

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

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

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

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

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

• When you configure the controller for HA 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 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.

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

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

• If you are using Cisco WiSM2, we recommend that you use the following release versions of Cisco IOS on Cisco Catalyst 6500 Series Supervisor Engine 2T:

  • 15.1(02)SY

  • 15.1(01)ICB40.1

  • 15.1(01)ICB29.36

  • 15.1(01)ICB29.1

  • 15.1(01)IC66.25

  • 15.1(01)IB273.72