Cisco high availability technology helps to facilitate network-wide resilience to increase IP network availability. It provides continuous access to applications, data, and content anywhere, anytime by addressing potential causes of downtime with functionality, design, and best practices.
This module provides information on the theory of operation for Cisco 5700 Series Wireless Controller as it supports stateful switchover of access points (AP SSO). In addition to AP SSO, the chapter also provides information on the ISSU high availability feature. These features reduce major downtime in wireless networks due to failure conditions that may occur due to box failover or network failover.
In Cisco 5700 Series Wireless Controller a high availability SKU AIR-CT5760-HA-K9 is available to deploy as a redundant N+1 controller in case the primary controller goes down. You do not need to purchase duplicate AP scale licensing on the redundant controller.
In Cisco 5700 Series Wireless Controller the high availability feature is enabled by default and you will not be able to disable it. You can only initiate a manual graceful-switchover using the command line interface.
During an AP SSO, all the AP sessions are switched over statefully and all the clients are deauthenticated and reassociated with the new active controller except for the locally switched clients in FlexConnect mode.
Before you enable HA (AP SSO), ensure that both 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.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Restrictions for Switchover
This section lists the restrictions that you should keep in mind while performing a switchover from the active unit to the standby unit:
Verify that the unit has been reloaded using the stack manager.
Verify if the logging console is enabled.
Verify the progression failures. The progression is bound by a time unit of 30 seconds.
Verify if no process failures occur.
Verify if any congestion occurs in the up coming unit.
Post Switchover Tasks
This section defines the steps that you must perform to ensure that successful switchover from the active to standby switch is performed. On successful switchover of the standby switch as active, all access points connected to the active need to re-join the standby (then active) switch.
SUMMARY STEPS
1.show ap uptime
2.show wireless summary
3.show wcdb database all
4.show power inline
DETAILED STEPS
Command or Action
Purpose
Step 1
show ap uptime
Verify the uptime of the access point uptime after the switchover is large enough
Step 2
show wireless summary
Display the clients connected in the active switch.
Step 3
show wcdb database all
Display if the client has reached the uptime.
Step 4
show power inline
Display the power over Ethernet power state.
Information on Mobility
On switchover, the mobility states will be removed from the mobility domain. Once the switchover is complete, the MC and MA messages are sent to the peer nodes. These messages aid in identifying the status of the peers in the network. Each switch is part of the stack, and the MA and MC software is available on both the active and standby switches. The mobility control session up and down is identified using the keep alive messages. The details of the mobility client database data synchronization between the active and standby is performed. For more details on mobility, see the Cisco
You must remove the following when client SSO is supported as the switch-over event in this release is AP SSO:
The switch-over notification from mobility controller to mobility oracle and to all the mobility anchors in the same group.
Mobility anchors in the sub-domain that deletes all the client.
The mobility oracle deletes clients with switchover mobility controller as foreign or anchor.
The other mobility agents of the group cleans up the clients that are associated to the switchover mobility agent.
Delete client messages to the mobility oracle.
Debugging Mobility before the Switchover
This section provides steps on how you can debug mobility before the switch-over.
SUMMARY STEPS
1.
show etherchannel summary
2.
show platform etherchannel
3.
show wireless mobility summary
4.
show wireless mobility dtls connections
5.
show mgmt-infra trace messages devshell
DETAILED STEPS
Command or Action
Purpose
Step 1
show etherchannel summary
Display port channel summary.
Step 2
show platform etherchannel
Display the states of the platform port channel.
Step 3
show wireless mobility summary
Display the mobility link state.
Step 4
show wireless mobility dtls connections
Display the mobility DTLS connection table.
Step 5
show mgmt-infra trace messages devshell
Display the mobility DTLS lookup table.
Debugging Mobility after the Switchover
This section provides steps on how you can debug mobility after the switchover. You must perform the same steps displayed in the debug mobility before the switchover to debug the mobility after switchover.
Information About Radio Resource Management
This section provides the theory of operations for the Radio Resource Management (RRM) feature in this release. RRM allows Cisco’s Unified WLAN Architecture to continuously analyze the existing RF environment, automatically adjusting APs’ power levels and channel configurations to help mitigate such things as co-channel interference and signal coverage problems. RRM reduces the need to perform exhaustive site surveys, increases system capacity, and provides automated self-healing functionality to compensate for RF dead zones and AP failures.
During a switchover, the AP's Radio Slot Data, RF measurement, CleanAir, and RF grouping state is synchronized to the standby switch during AP SSO. The standby switch then does not participate in any RF grouping unless it is in active state. The standby unit participates in the RF group as a new member. During a switchover, incremental data synchronization of data from active switch to standby switch is performed.
Information on Security
Wireless security is the prevention of unauthorized access or damage to computers using wireless networks. In Cisco Wireless Controller 5700 series, you can:
Configure IEEE 802.1x global configurations.
Configure Locally Significant Certificates.
Configure strong password enforcement options.
Enable over-the-air frame padding.
Configure access point neighbor authentication.
Enable protection from Denial of Service (DoS) attacks.
Configure Intrusion Detection System (IDS) sensors for the Wireless Protection System (WPS).
Configure client exclusion policies.
Configure Management Frame Protection (MFP).
Enforce the controller to synchronize with other controllers in the mobility group for the shun list.
On switchover, the following security features continue to be up and running:
Datagram Transport Layer Security (DTLS) protocol for CAPWAP and mobility.
Infrastructure Management Frame.
Rogue access points and client detection.
The access point list in the controller continues to work by re-learning.
Synchronization of the Intrusion Detection System (IDS)/ Shun List in the mobility anchor and mobility client.
The Wireless Intrusion Prevention System (wIPS) continues to work by re-learning and configuration methods.
Synchronization of pairwise master key to enable faster re-association of the wireless clients.
Information on Location and Certificate Management
The states of the TCP port (16113) that the controller and mobility services engine communicate are not synchronized. So, once a switchover occurs, the client must re-associate to the location server. You must also manually download the LSC certificate and install in both the units.
Information on CAPWAP, Multicast, and CDP
In a CAPWAP environment, a lightweight access point discovers a controller by using CAPWAP discovery mechanisms and then sends the controller a CAPWAP join request. The controller sends the access point a CAPWAP join response allowing the access point to join the controller. When the access point joins the controller, the controller manages its configuration, firmware, control transactions, and data transactions. On switch-over, all the clients associated need to de-associate. The following occurs, after a switchover:
The CAPWAP control message sequence number continues to be functional.
The multicast protocol functions by re-learning the routes.
The CDP protocol discovers all network elements in the network, and the access point sends the CDP update.
Event log of the access point will not be synchronized during the switchover.
Information on Voice and QoS
QoS enables you to provide preferential treatment to specific types of traffic at the expense of other traffic types. Without QoS, the controller offers best-effort service to each packet, regardless of the packet contents r size. On switchover, the voice and QoS statistics values displayed in the controller will be reset. This implies that the Voice and QoS statistics are not synchronized while switchover happens from active unit to standby unit.