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 newly 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.
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 maintenance mode.
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 standby-hot controller.
Certificates 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 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.
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.
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 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, 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 (LAG) configuration on the controllers before you enable the port channel in the infrastructure switches.
All 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 the 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 other states.
Only the 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.
Redundancy Management Interface
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.
The Redundancy 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 controllers.
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 22.214.171.124, 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 synchronization.
Encryption is 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.
Restrictions for High Availability
When you configure the controller for AP 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.
If both active and standby-hot controllers have different software releases in the backup, and if you enter 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.
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.
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
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
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
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 HA, 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 HA 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: