High availability (HA) in controllers allows you to reduce the downtime of the wireless networks that occurs due to the failover of controllers.

A 1:1 (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 failure.

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.

The standby-hot 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 interface.

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

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.

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.

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

• Service VLAN configuration is lost when moving from HA mode to non-HA mode and vice versa. You should 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 is lost. Therefore, ensure that you save the configurations on the active controller before you reset the standby-hot controller.

  • A preimage download is reinitiated if an SSO is triggered at the time of the image transfer.

  • 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 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 to 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 associated with them

    • Clients that are associated with Cisco 600 Series OfficeExtend Access Points

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

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

• After the switch over of controller, clients along with children mesh access points (MAPs) are disconnected and are rejoined with the new active controller. The entire mesh tree is rebuilt. The clients of root access points (RAPs) are also disconnected but the RAPs are intact with the controller.

• 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

• Configure a local-redundancy IP address and a peer-redundancy management IP address by running this command:

  config interface address redundancy-management ip-addr1 peer-redundancy-management ip-addr2

• Configure the role of a controller by entering this command:

  config redundancy unit {primary | secondary}

• Configure the redundancy mode by entering this command:

  config redundancy mode {sso | none}

  Note	Both controllers reboot and then negotiate the roles of active and standby-hot controllers.

• Configure redundancy by entering this command:

  config redundancy mode {sso {ap | client} | disable}

  Note	You can choose between an AP SSO and a client SSO.

• Configure the route configurations of the standby controller by entering this command:

  config redundancy peer-route {add network-ip-addr ip-mask | delete network-ip-addr}

  Note	This command can be run only if the HA peer controller is available and operational.

• Configure a mobility MAC address by entering this command:

  config redundancy mobilitymac mac-addr

  Note	This command can be run only when SSO is disabled. If you upgrade from Release 8.0.110.0 to a later release, this command's setting is removed. You must manually reconfigure the mobility MAC address after the upgrade.

• Configure the IP address and netmask of the peer service port of the standby controller by entering this command:

  config redundancy interface address peer-service-port ip-address netmask

  This command can be run only if the HA peer controller is available and operational.

• Initiate a manual switchover by entering this command:

  redundancy force-switchover

  Note	Execute this command only when you require a manual switchover.

• Configure a redundancy timer by entering this command:

  config redundancy timer {keep-alive-timer time-in-milliseconds | peer-search-timer time-in-seconds}

• Configure encryption of communication between controllers by entering this command:

  config redundancy link-encryption {enable | disable}

• Configure the hash distribution as fixed by entering this command:

  config port-channel hash-distribution fixed

• Verify a port channel member order and load value by entering this command:

  show etherchannel port-channel

• View the status of the redundancy by entering this command:

  show redundancy summary

• View information about the redundancy management interface by entering this command:

  show interface detailed redundancy-management

• View information about the redundancy port by entering this command:

  show interface detailed redundancy-port

• Reboot a peer controller by entering this command:

  reset peer-system

• Start the upload of file types, such as configuration, event logs, crash files, and so on from the standby-hot controller by entering this command on the active controller:

  transfer upload peer-start

• View information about sleeping clients after a switchover, by entering this command on the then active controller :

  show custom-web sleep-client summary

• Debug the redundancy modules by entering these commands:

  Note	Ensure that SSO is enabled to use these debug commands. Enter config redundancy mode SSO command to enable SSO.

  debug redundancy {infra | facilitator | transport | keepalive | gw-reachability | config-sync | ap-sync | client-sync | mobility}

  • infra—Configures debug of the Redundancy Infra Module.

  • facilitator—Configures debug of the Redundancy Facilitator Module.

  • transport—Configures debug of the Redundancy Transport Module.

  • keepalive—Configures debug of the Redundancy Keepalive Module.

  • gw-reachability—Configures debug of the Redundancy Gw-reachability Module.

  • config-sync—Configures debug of the Redundancy Config-Sync Module.

  • ap-sync—Configures debug of the Redundancy AP-Sync Module.

  • client-sync—Configures debug of the Redundancy Client-Sync Module.

  • mobility—Configures debug of the Redundancy Mobility Module.

You can view the status and health information of active and standby WLC separately. This section describes the details of getting health information and traps from the standby WLC.

The standby WLC uses the redundancy management interface for any external communications such as when talking to Syslog, NTP server, TFTP server, and so on. On the standby WLC, the management user authentication and accounting is performed on the redundancy management interface. RADIUS or TACACS+ server can be used for user authentication, apart from a local management user account. To support this, the redundancy interface IP address(es) should be added as network device on the RADIUS or TACACS+ server. The authentication request is sent to RADIUS or TACACS+ server over redundancy management interface. Whenever you log on to the standby WLC, accounting message is sent to the RADIUS server. The purpose of the accounting message is to log the admin logon events on the standby WLC console.

This feature is supported on all WLC models supporting HA SSO feature:

• Cisco 8500 Series WLCs

• Cisco Flex 7500 Series WLCs

• Cisco 5500 Series WLCs

• Cisco WiSM2