- Introduction
- How it works?
- High availability supported platforms
- Redundancy Management Interface
- Redundancy Port
- Fast Facts on High Availability (HA)
- Reference
- Additional information
- High Availability Enhancements -Release 8.0.100.0
Introduction
HA Overview
High availability (HA) in controllers allows you to reduce the downtime of the wireless networks, due to the failure of controllers. In 7.3 it is true High Availability is introduced. Hot standby - That is when one box fails due to hardware issues or network connectivity almost instantaneously take over by the standby box. One WLC will be active state and second WLC will be Hot standby state who monitors the health of the active WLC through a direct wired connection over a dedicated Redundancy port. Configuration on active WLC is synched to standby WLC via redundant port.
Both the WLCs share the same set of configurations including the IP address of the Management interface. AP’s CAPWAP state is also synced. APs do not go in the Discovery state when Active WLC fails. That will ensure the AP sessions are intact after switch over. With this we achieve stateful switchover(SSO) for the Access Points(AP SSO). However, in this release Client SSO is not supported, the clients de-authenticated and forced to rejoin new Active WLC when failover occurs. Off Couse, we can do that with cache credential system. Both the active and stand by WLCs are expected to be next to each other, as we achieve HA over a network cable. Both the WLCs are going to share the same configuration information.
After you enable HA, the primary and secondary controllers are rebooted. During the boot process, the primary controller role is negotiated as active and 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.
How it works?
The New High Availability feature i.e. AP SSO set within the Cisco Unified Wireless Network software release v7.3 allows the AP to establish CAPWAP tunnel with Active WLC and share mirror copy of AP database with Standby WLC. APs do not go in Discovery state when Active WLC fails and Standby WLC takes over the network as Active WLC.
There is only one CAPWAP tunnel maintained at a time between APs and WLC that is in Active state. The overall goal for the addition of AP SSO support to the Cisco Unified Wireless LAN was to reduce major downtime in wireless network due to failure conditions that may occur due to box failover or network failover.
The HA Controller is a new manufacturing orderable controller for every controller series. The HA controller is in Standby state when it boots and pairs with a controller running a permanent count license. For controllers that have permanent count licenses, you can manually configure whether the controller is in the Active state or the Standby state.
High availability supported platforms
• Cisco 5500 Series Controllers
• Cisco Flex 7500 Series Controllers
• Cisco 8500 Series Controllers
• Cisco WiSM2
• The Cisco 5500, Flex 7500, and 8500 Series Controllers have a dedicated HA port, which is used to synchronize configuration between controllers in the Active and Standby states Keepalive messages are sent on HA ports from the standby controller to the active controller every 100 milliseconds (default frequency) to check the health of the active controller. Internet Control Message Protocol (ICMP) packets are also sent every 1 second from each controller to check reachability to the gateway using the redundant management interface. It is highly recommended to have direct physical connection between Active and Standby Redundant Ports. The distance between the connections can go upto 100 meters at per ethernet cable standards.
• . The Cisco WiSM2 also has a dedicated HA port, but it is hidden from users and is responsible for more than configuration synchronization. The Cisco WiSM2 has a dedicated redundancy VLAN, which is used to synchronize configuration between the active and standby controllers. Keepalive messages are sent on the redundant VLAN from the standby controller to the active controller every 100 milliseconds (default frequency) to check the health of the active controller. Internet Control Message Protocol (ICMP) packets are also sent every 1 second from each controller to check reachability to the default gateway using the redundant management interface. To achieve high availability between two WiSM2 controllers, the controllers can be deployed on a single chassis or can be deployed on multiple chassis using a virtual switching system (VSS).
Note:-
A redundancy VLAN should be a nonroutable VLAN where a Layer 3 interface should not be created for the VLAN and the interface can 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 IOS switches. 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.
Redundancy Management Interface
The Redundancy Management Interface is displayed on the controller GUI after you enable high availability. You must configure the IP addresses of the Redundancy Management Interface and the management interface in the same subnet. The Redundancy Management Interface checks the health of the active controller through the network infrastructure if the active controller does not respond to keepalive messages on the redundant port. The Redundancy Management Interface provides an additional health check of the network and the active controller and confirms if a switchover should be executed or not. ICMP packets are generated from the Redundancy Management Interface to check the default gateway reachability of controllers in the Active and Standby states. The Redundancy Management Interface is also used to send notifications from the active controller to the standby controller if a failure or manual reset occurs. The standby controller uses the Redundancy Management Interface to communicate to the syslog, NTP server, and TFTP server to upload any configuration.
Redundancy Port
The redundancy port is used in the following scenarios:
- The redundancy port is responsible for configuration and operational data synchronization between active and standby controllers.
- Controllers in a HA environment use the redundancy port to do HA role negotiation.
- The redundancy port checks for peer reachability by sending UDP keepalive messages every 100 milliseconds (default frequency) from the standby controller to the active controller.
- If a failure of the active controller occurs, the redundancy port notifies the standby controller.
- If an NTP server is not configured, the redundancy port does a time synchronization from the active controller to the standby controller.
- The redundancy port in standalone controllers and the redundancy VLAN in Cisco WiSM2 are assigned an automatically generated IP address where the last two octets are picked 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 209.165.200.225, the IP address of the redundancy port is 169.254.200.225.
Fast Facts on High Availability (HA)
- HA Pairing is possible only between same type of hardware and software version. Mismatch may result in Maintenance mode. Virtual IP Address should be same on both the WLCs before configuring AP SSO.
- It is recommended to have direct connectivity between Active and Standby Redundant Port for 5500/7500/8500 series of WLCs.
- WiSM-2 WLCs should be in same 6500 chassis OR can be installed in VSS setup for reliable performance.
- Physical connection between Redundant Port and Infrastructure Network should be done first before HA configuration.
- The stateful switchover of clients is not supported, which means that all clients, with the exception of clients on locally switched WLANs on access points in FlexConnect mode, are deauthenticated and forced to reassociate with the new controller in the Active state.
- Primary unit’s mac should be used as mobility mac in HA setup to form a mobility peer with another HA setup or independent controller. User also has a flexibility to configure custom mac address, which can be used as mobility mac address using a CLI “configure redundancy mobilitymac <custom mac address>”. Once configured user should use this mac address to form a mobility peer instead of using system mac address. Once HA is configured this mac cannot be changed.
- It is recommended to use DHCP address assignment for service port in HA setup. After HA is enabled if static ip is been configured for service port, WLC looses the service port IP and it has to be configured again.
- When AP SSO is enabled there is no SNMP/GUI access on service port for both the WLCs in HA setup.
- Configurations like changing virtual ip address, enabling secure web mode, configuring web auth proxy, etc. to get implemented needs a reboot of WLC. Rebooting of Active WLC in this case will also trigger reboot of Standby WLC simultaneously.
- When AP SSO is disabled on Active it will be pushed to Standby and after reboot all the ports will come up on Active and will be disabled on Standby.
- Keep alive and Peer Discovery timers should be left with default timer values for better performance
- Clear configuration on Active WLC will also initiate clear configuration on Standby WLC.
- Internal DHCP is not supported when AP SSO is enabled.
- SSO for LSC AP is not supported. L2 MGID is synched but L3 MGID database is cleared with SSO.
Following video provides more information about High Availability Architecture in WLC:
High Availability Configuration using GUI is explaned in detail in the following video:
High Availability Configuration using initial CLI configuration wizard is explained in the video provided below:
Reference
Additional information
- • Configuration of the IP address of the redundancy management interface to any of the dynamic interfaces, management interface IP address, management interface gateway IP address, and present peer-redundancy management interface IP addresses is not supported.
- • Before you configure HA, ensure that the management interfaces of both controllers are in the same subnet.
- • HA is disabled by default. Before you enable HA, ensure that you configure the IP addresses of the Redundant Management Interface and the peer Redundant Management Interface. Bot interfaces should be in the same subnet as the management interface.
- • The High Availability feature is not supported on the Cisco 600 Series Office Extend Access Points. It is not possible to upgrade a standby controller from a TFTP/FTP server. The active controller, after executing all the scripts, transfers the image to the standby controller. After the standby
- • Controller gets the image from the active controller, the standby controller starts executing the upgrade scripts. All the logs for image transfer and script execution on the standby controller can also be seen on the active controller.
- • An in-service upgrade is not supported. Therefore, you should plan your network downtime before you upgrade the controllers in a HA environment.
- • The peer controller should be in the Hot Standby state before you begin an upgrade.
- • We recommend that you reboot both controllers together after you upgrade, so that there is no software version mismatch.
- • A schedule reset applies to both controllers in an HA environment. The peer controller reboots one minute before the scheduled time expires on the active controller.
- • You can reboot the standby controller from the active controller by entering the reset peer-system command if the scheduled reset is not planned.
- • A preimage download does not work if an SSO is triggered at the time of the image transfer.
- • A debug transfer can be enabled on both controllers.
- • When HA is enabled, ensure that you do not use the backed up image. If used, the HA feature might not work as expected.
High Availability Enhancements - Release 8.0.100.0
Infrastructure Enhancements
- 802.11ac configuration is supported in a High Availability scenario.
- You can see the status of bulk synchronization of access points and clients after the active and standby Cisco WLCs pair up.
- Enhanced debug options included where new categories of statistics can be viewed:
- All
- Infra
- Transport
- Keep-Alive
- GW-Reachability
- Config-Sync
- You can configure the keep-alive and peer search parameters.
- ICMP ping on redundancy management interface (RMI) is replaced with UDP message. This is useful when ICMP pings might be discarded under heavy loads.
- Default gateway reachability is enhanced—upon six consecutive ping drops, address resolution protocol request is sent to the gateway.
- If the peer redundancy port (RP) and/or default gateway reachability is lost, the standby Cisco WLC enters into maintenance mode ‘on-the-fly’ without requiring a reboot.
- Faster HA pair-up—Comparison of XMLs and reboot of the standby Cisco WLC are not performed during pair-up.
Client SSO Enhancements
- Internal DHCP server—To serve wireless clients of the Cisco WLC, the internal DHCP server data is synchronized from the active WLC to the standby WLC. All the assigned IP addresses remain valid, and IP address assignation continues when the role changes from active WLC to standby WLC occurs.
- Sleeping client database synchronization is supported between active WLC and standby WLC.
Sleeping clients avoid web reauthentication if they wake up within the sleeping client timeout interval post switchover.
- Cisco 600 Series OfficeExtend Access Points (OEAPs) do not require the CAPWAP tunnel to be reset. Clients continue their connection with the new active WLC in a seamless manner.
Release Notes for Cisco Wireless LAN Controllers and Lightweight Access Points for Release 8.0.100.0
