WLC and Supported APs in rel 8.7

The information in this document is based on these software and hardware versions:

■WLCs 3500 Series, 8500 Series and 5520.

■Legacy Wave-1 APs: 3700, 2700, 1700, 702, 702W, 1530, 1570

■Wave-2 APs: 1800 series, 2800 series, 3800 series, 1540, 1560

■The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Note: 5508, 7500, 8510 and WiSM-2 are supported up to release 8.5. 3504 series is supported starting with release 8.5.See release notes for complete details.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Topology

This document uses this network topology.

 

HA Connectivity Using Redundant Port on the 3504/5520/8500.

WLC 3500/5520/8500 WLCs have a dedicated Redundancy Port which should be connected back to back in order to synchronize the configuration from the Active to the Standby WLC.

Like 5520 and 8540, the 3504 Wireless Controller has a Redundancy port on the front of the unit. Like on other WLC, WLC 3504 supports both AP SSO and Client SSO. Given below is how one would connect two WLC 3504 using the RP port (back to Back) in HA Setup.

Keep-alive packets are sent on the Redundancy Port from the Standby to the Active WLC every 100 msec (default timer) in order to check the health of the Active WLC.

Both the WLCs in HA setup keep track of gateway reachability. The Active WLC sends an Internet Control Message Protocol (ICMP) ping to the gateway using the Management IP address as the source, and the Standby WLC sends an ICMP ping to the gateway using the Redundancy Management IP address. Both the WLCs send an ICMP ping to the gateway at a one-second interval. It is highly recommended to have back-to-back direct connectivity between Redundant Ports.

Note: A direct physical connection between Active and Standby Redundant Ports is highly recommended. The distance between the connections can go up to 100 meters at per Ethernet cable standards.

Introduction of New Interfaces for HA Interaction

Redundancy Management Interface

The IP address on this interface should be configured in the same subnet as the management interface. This interface will check the health of the Active WLC via network infrastructure once the Active WLC does not respond to Keepalive messages on the Redundant Port. This provides an additional health check of the network and Active WLC, and confirms if switchover should or should not be executed. Also, the Standby WLC uses this interface in order to source ICMP ping packets to check gateway reachability. This interface is also used in order to send notifications from the Active WLC to the Standby WLC in the event of Box failure or Manual Reset. The Standby WLC will use this interface in order to communicate to Syslog, the NTP server, and the TFTP server for any configuration upload.

 

Redundancy Port

This interface has a very important role in the new HA architecture. Bulk configuration during boot up and incremental configuration are synced from the Active WLC to the Standby WLC using the Redundant Port. WLCs in a HA setup will use this port to perform HA role negotiation. The Redundancy Port is also used in order to check peer reachability sending UDP keep-alive messages every 100 msec (default timer) from the Standby WLC to the Active WLC. Also, in the event of a box failure, the Active WLC will send notification to the Standby WLC via the Redundant Port. If the NTP server is not configured, a manual time sync is performed from the Active WLC to the Standby WLC on the Redundant Port. This port in case of standalone controller will be assigned an auto generated IP Address where last 2 octets are picked from the last 2 octets of Redundancy Management Interface (the first 2 octets are always 169.254).

Note: Redundancy Management Interface cannot be an Untagged Interface.

 

Configure HA from the CLI

Complete these steps:

1. Before you configure HA, it is mandatory to have both the controllers' management interface in the same subnet:

WLC 1:

 

WLC 2:

 

2. HA is disabled by default. Before you enable HA, it is mandatory to configure the Redundancy Management IP Address and Peer Redundancy Management IP Address. Both the interfaces should be in the same subnet as the Management Interface. In this example, 9.6.61.21 is the Redundancy Management IP Address for WLC 1, and 9.6.61.23 is the Redundancy Management IP Address for WLC 2. It also needs to be configured so that 9.6.61.23 is the Redundancy Management IP Address of WLC 2 and 9.6.61.21 is the Redundancy Management IP Address of WLC 1.

Use this CLI in order to configure the Redundancy and Peer Redundancy Management IP Address:

WLC 1:

 

WLC 2:

 

3. Configure one WLC as Primary (by default, the WLC HA Unit ID is Primary and should have a valid AP-BASE count license installed) and another WLC as Secondary (AP base count from the Primary WLC will be inherited by this unit) using the CLI in this step. In this example, WLC 1 is configured as Primary, and WLC 2 is configured as Secondary:

WLC 1:

 

WLC 2:

 

Note: You do not need to configure the unit as Secondary if it is a factory ordered HA SKU that can be ordered from release 7.3 onwards. A factory ordered HA SKU is a default Secondary unit, and will take the role of the Standby WLC the first time it is paired with an Active WLC that has a valid AP Count License.

If you want to convert any existing WLC as a Standby WLC, do so using the config redundancy unit secondary command in the CLI. This CLI command will only work if the WLC which is intended to work as Standby has some number of permanent license count. This condition is only valid for the 5508 WLC, where a minimum of 50 AP Permanent licenses are needed to be converted to Standby. There is no restriction for other WLCs such as the 5520, WiSM2, 7500, and 8500.

4. After the WLCs are configured with Redundancy Management and Peer Redundancy Management IP Addresses and Redundant Units are configured, it is time to enable SSO. It is important to make sure that physical connections are up between both the controllers (that is, both the WLCs are connected back to back via the Redundant Port using an Ethernet cable) and the uplink is also connected to the infrastructure switch and the gateway is reachable from both the WLCs before SSO is enabled.

Once SSO is enabled, it will reboot the WLCs. While it boots, the WLCs negotiate the HA role as per the configuration via Redundant Port. If the WLCs cannot reach each other via Redundant Port or via the Redundant Management Interface, the WLC configured as Secondary may go in to Maintenance Mode. Maintenance Mode is discussed later in this document.

5. Use the CLI in this step in order to enable AP SSO. Remember that enabling AP SSO will initiate a WLC reboot.

WLC 1:

 

WLC 2:

 

6. Enabling SSO will reboot the WLCs in order to negotiate the HA role as per the configuration performed. Once the role is determined, configuration is synced from the Active WLC to the Standby WLC via the Redundant Port. Initially, the WLC configured as Secondary will report XML mismatch and will download the configuration from Active and reboot again. During the next reboot after role determination, it will validate the configuration again, report no XML mismatch, and process further in order to establish itself as the Standby WLC.

These are the boot-up logs from both the WLCs:

WLC 1:

 

WLC 2 on first reboot after enabling SSO:

 

Note: Once SSO is enabled, the Standby WLC can be accessed via console connection or via SSH on the service port and on the redundant management interface.

WLC 2 on second reboot after downloading XML configuration from Active:

 

7. After SSO is enabled, WLC is rebooted, and the XML configuration is synced, WLC 1 will transition its state to Active and WLC 2 will transition its state to Standby HOT. From this point onwards, GUI/Telnet/SSH for WLC 2 on the management interface will not work, as all the configurations and management should be done from the Active WLC. If required, the Standby WLC (WLC 2, in this example) can only be managed via the Console or Service Port.

Also, once the Peer WLC transitions to the Standby Hot state, -Standby keyword is automatically appended to the Standby WLCs prompt name.

 

8. Complete these steps in order to check the redundancy status:

a. For WLC 1, go to Monitor > Redundancy > Summary:

 

b. For WLC 2, go to Console connection:

 

Note: Once SSO is enabled, the Standby WLC can be accessed via console connection or via SSH on the service port and on the redundant management interface.

Disabling SSO on HA Pair

1. On primary controller, disable SSO using the command:

Config redundancy mode disable

The Active and Standby WLCs reboot once this command is executed.

The standby controller, when it comes back after the reboot, has the same IP address on interfaces as the primary controller and all the ports disabled.

2. On the standby controller, re-enter the correct IP addresses corresponding to the management and dynamic interfaces and execute the following command:

Config port adminmode all enable

3. Save the configuration on the controller.

4. To re-enable SSO, execute the command Config redundancy sso on the primary and secondary controllers.

Both controllers reboot and pair up in the SSO mode. The standby will sync its configuration from the primary and come back in Hot-standby mode.

Monitoring HA Redundancy in release 8.7

For Management - SNMP MIB is part of - MIB CISCO-LWAPP-HA-MIB.my is updated to capture the statistics discussed below.

By going to Monitor TAB on the controller and then choosing Redundancy, you can Monitor Statistics.

On the same tab by selecting Summary, you can see Redundancy summary of the Active Controller.

The new enhancement in the 8.7 release is the Peer Statistics with additional information about Peer Serial Number and Fan Status.

Same can be achieved through the CLI command:

show redundancy peer-system statistics

Upgrade Procedure in HA Setup

Complete these steps:

1. Copy the target image into your TFTP directory and go to the Web UI on your wireless LAN Controller.

2. Navigate to the download page located at Commands -> Download File and download the image to the active controller.

3. Once the image has downloaded to the primary and been extracted, the controller will upload the file to the standby controller.

4. You can now verify this image by using the CLI show boot. The target image will be shown as the default image and will be loaded on the next reload.

5. Optional: Prime the AP’s with the new image. You don’t have to perform this step, but it will minimize network downtime as the AP’s will not have to download a new image when the controller reboots as they will already have it.

6. Use the CLI: config ap image predownload primary all

7. This will push the primary image to all APs. This process may take some time depending on the number of APs present on the controller.

8. You can monitor the progress with the command show ap image all.

9. Once this is complete, reload the controllers. To ensure both controllers reload together use the command reset system in <>

10. Using this command will reboot both devices.

11. To minimize downtime even more you can add the reset-aps keyword at the end of the command. This will start the AP’s reloading instead of waiting for the controller to come back with the new image.

12. Once the controller has come back, go to Wireless / Access Points and make sure all your AP’s are coming back online and are running the correct image.

Important Guidelines before Initiating a WLC Upgrade in HA Setup

■Service Upgrade is not supported in this release, so network downtime should be planned before you upgrade the WLCs in the HA setup.

■The peer should be in the Hot Standby state before you start the upgrade in the HA setup.

■It is recommended to reboot both the WLCs almost together after upgrade so that there is no software version mismatch.

■Schedule Reset applies to both the WLCs in the HA setup.

■The Standby WLC can be rebooted from the Active WLC using the reset peer-system command if a scheduled reset is not planned.

■Debug transfer can be enabled on the Active WLC as well as the Standby WLC.

■If Active WLC unexpectedly reboot between software download and reboot both WLCs, you need to reboot both WLCs in order to complete software upgrade.

Download/Upload Facts in HA Setup

■No direct download and upload configuration is possible from the Standby WLC.

■All download file types like Image, Configuration, Web-Authentication bundle, and Signature Files will be downloaded on the Active WLC first and then pushed automatically to the Standby WLC.

■Once the configuration file is downloaded on the Active WLC, it is pushed to the Standby WLC. This results in the reset of the Standby WLC first, followed by the reset of the Active WLC.

■The Peer Service Port and Static route configuration is a part of a different XML file, and will not be applied if downloaded as part of the configuration file.

■The download of certificates should be done separately on each box and should be done before pairing.

■Uploading different file types like Configuration, Event Logs, Crash files, and so forth can be done separately from the Standby WLC. However, the CLI to configure different parameters for upload like Server IP, file type, path and name should be done on the Active WLC. Once the upload parameters are configured on the Active WLC, the transfer upload peer-start command should be issued on the Active WLC in order to initiate the upload from the Standby WLC.

■The service port state will be synced from the Active WLC to the Standby WLC. That is, if DHCP is enabled on the Active WLC service port, the Standby WLC will also use DHCP for getting the service port IP address. If the service port of the Active WLC is configured with a Static IP Address, the Standby WLC also needs to be configured with a different Static IP Address. The CLI to configure the IP Address for the Standby WLC service port is configure redundancy interface address peer-service-port <IP Address>. This command should be executed from the Active WLC. Also, in order to configure the route on the Standby WLC for out-of-band management on the service port, issue the configure redundancy peer-route add <Network IP Address > <IP Mask> <Gateway> command from the Active WLC.

Steps to Simulate Box Failover

Complete these steps:

1. Complete the steps as explained in the configuration section in order to configure HA between two WLCs, and make sure before force switchover is initiated that both the WLCs are paired up as the Active WLC and the Standby WLC.

For WLC 1:

 

For WLC 2, go to Console connection:

 

2. Associate an AP to the WLC and check the status of the AP on both the WLCs. In the HA setup, a mirror copy of the AP database is maintained on both the WLCs. That is, APs CAPWAP state in maintained on Active as well as Standby WLC (only for APs which are in Run state) and when switchover is initiated, the Standby WLC takes over the network. In this example, WLC 1 is an Active WLC, WLC 2 is in a Standby state, and the AP database is maintained on both the WLCs.

WLC 1:

 

WLC 2

 

3. Create an open WLAN and associate a client to it. The client database is not synced on the Standby WLC, so the client entry will not be present on the Standby WLC. Once the WLAN is created on the Active WLC, it will also be synced to the Standby WLC via the Redundant Port.

WLC 1:

 

WLC 2:

 

4. Issue the redundancy force-switchover command on the Active WLC. This command will trigger a manual switchover where the Active WLC will reboot and the Standby WLC will take over the network. In this case, the client on the Active WLC will be de-authenticated and join back on the new Active WLC.

WLC 1:

 

WLC 2:

 

Note: Observe that the prompt in this example changed from 5508-Standby to 5508. This is because this WLC is now the Active WLC and the time taken for AP switchover is 1 msec.

WLC 2:

 

Observe the AP CAPWAP State on WLC 2, which was the Standby WLC initially and is now the Active WLC after switchover. AP Up Time as well as Association Up Time is maintained, and the AP did not go in to the discovery state.

These matrices provide a clear picture of what condition the WLC Switchover will trigger:

 

 

Maintenance Mode

There are few scenarios where the Standby WLC may go into Maintenance Mode and not be able to communicate with the network and peer:

■Non reachability to Gateway via Redundant Management Interface

■WLC with HA SKU which had never discovered peer

■Redundant Port is down

■Software version mismatch (WLC which boots up first goes into active mode and the other WLC in Maintenance Mode)

 

Note: The WLC should be rebooted in order to bring it out of Maintenance Mode. Only the Console and Service Port is active in Maintenance Mode.

One WLC has a valid AP Count license and the other WLC has a HA SKU UDI

■HA SKU is a new SKU with a Zero AP Count License.

■The device with HA SKU becomes Standby the first time it pairs up.

■AP-count license info will be pushed from Active to Standby.

■On event of Active failure, HA SKU will let APs join with AP-count obtained and will start 90-day countdown. The granularity of this is in days.

■After 90-days, it starts nagging messages. It will not disconnect connected APs.

■With new WLC coming up, HA SKU at the time of paring will get the AP Count:

–If the new WLC has a higher AP count than the previous, the 90-day counter is reset.

–If the new WLC has a lower AP count than the previous, the 90-day counter is not reset.

–In order to lower AP count after switchover, the WLC offset timer will continue and nagging messages will be displayed after time expiry.

• Elapsed time and AP-count will be remembered on reboot.
• The factory default HA-SKU controller should not allow any APs to join.

Both the WLCs have a valid AP Count license

■The CLI should be used to configure one WLC as the Standby WLC (as mentioned in the configuration section) provided it satisfies the requirement of minimum permanent license count. This condition is only valid for the 5508 WLC, where a minimum of 50 AP Permanent licenses are needed to be converted to Standby. There is no restriction for other WLCs such as the 5520, WiSM2, 7500, and 8500.

■AP-count license information will be pushed from Active to Standby.

■In the event of a switchover, the new Active WLC will operate with the license count of the previous Active WLC and will start the 90-day countdown.

■The WLC configured as Secondary will not use its own installed license, and only the inherited license from the active will be utilized.

■After 90-days, it starts nagging messages. It will not disconnect connected APs.

■With the new WLC coming up, HA SKU at the time of paring will get the AP Count:

–If the new WLC has a higher AP count than the previous, the 90-day counter is reset.

–If the new WLC has a lower AP count than the previous, the 90-day counter is not reset.

–After switchover to a lower AP count, the WLC offset timer will continue and nagging messages will be displayed after time expiry.

One WLC has an Evaluation license and the other WLC has a HA SKU UDI or Permanent license

■The device with HA SKU becomes the Standby WLC the first time it pairs up with an existing Active WLC running Evaluation License. Or, any WLC running a permanent license count can be configured as the Secondary unit using the CLI configuration provided if it satisfies the requirement of minimum permanent license count. This condition is only valid for the 5508 WLC, where a minimum of 50 AP Permanent licenses are needed to be converted to Standby. There is no restriction for other WLCs such as the 5520, WiSM2, 7500, 3504 and 8500.

■AP-count license information will be pushed from Active to Standby.

■In the event of a switchover, the new Active WLC will operate with the license count of the previous Active WLC and start the 90-day countdown.

■After 90-days, it starts nagging messages. It will not disconnect connected APs.

■With new the WLC coming up, HA SKU at the time of paring will get the AP Count:

–If the new WLC has a higher AP count than the previous, the 90-day counter is reset.

–If the new WLC has a lower AP count than the previous, the 90-day counter is not reset.

–After switchover to a lower AP count, the WLC offset timer will continue and nagging messages will be displayed after time expiry.

Supported HA Topologies in Release 7.5-8.7

3500(rel 8.5)/5500/7500/8500 Series Controllers

1. Back-to-back Redundancy Port (RP) connectivity between the two WLCs, Redundancy Management Interface (RMI) connectivity to check peer and management gateway reachability.

2. RP connectivity with L2 adjacency between the two WLCs, RMI connectivity to check peer and management gateway reachability. This can be within the same or different data centers.

3. Two 5508, 7500 or 8500 connected to a VSS pair. Primary WLC connected to one 6500 and the Stand-by WLC to the other 6500.

Back-to-back RP Connectivity

Figure 1 Back-to-back RP connectivity

 

■This is the same topology as was supported in controller release 7.3.

■Configuration Sync and Keepalive messages are sent via Redundancy Port.

■RMI interface is created as part of Management subnet and is used to check peer and management gateway reachability.

■RTT Latency is 80 milliseconds by default. The RTT should be 80% of the Keepalive timer which is configurable in the range 100-400 milliseconds.

■Failure detection time is 3*100 + 60 + jitter (12 msec) = ~400 msec

Note: In the above equation, 3 is the Keepalive retry count, 100 is the Keepalive timer, and 60 is
3*10 + 3*10 (3 RMI pings to peer + 3 pings to gateway).

■Bandwidth: 60 Mbps or more

■MTU: 1500

Configuration on Primary WLC:

configure interface address management 9.5.56.2 255.255.255.0 9.5.56.1

configure interface address redundancy-management 9.5.56.10 peer-redundancy-management 9.5.56.11

configure redundancy unit primary

configure redundancy mode sso

Configuration on Hot Standby WLC:

configure interface address management 9.5.56.3 255.255.255.0 9.5.56.1

configure interface address redundancy-management 9.5.56.11 peer-redundancy-management 9.5.56.10

configure redundancy unit secondary

configure redundancy mode sso

RP Connectivity via Switches

Figure 2 RP connectivity via switches

 

■Redundancy Port connectivity via switches across data centers is supported in this topology.

■Configuration sync and Keepalives via Redundancy Port.

■RMI interface is created as part of Management subnet and is used to check peer and management gateway reachability.

■RTT Latency is 80 milliseconds by default. The RTT should be 80% of the Keepalive timer which is configurable in the range 100-400 milliseconds.

■Failure detection time is 3*100 + 60 + jitter (12 msec) = ~400 msec

■Bandwidth: 60 Mbps or more

■MTU: 1500

Configuration on Primary WLC

configure interface address management 9.5.56.2 255.255.255.0 9.5.56.1

configure interface address redundancy-management 9.5.56.10 peer-redundancy-management 9.5.56.11

configure redundancy unit primary

configure redundancy mode sso

Configuration on Hot Standby WLC

configure interface address management 9.5.56.3 255.255.255.0 9.5.56.1

configure interface address redundancy-management 9.5.56.11 peer-redundancy-management 9.5.56.10

configure redundancy unit secondary

configure redundancy mode sso

5508, 7500, or 8500 Connected to VSS Pair

Figure 3 WLCs connected to VSS Pair

 

Supported HA Topologies for WiSM2 Controllers

WiSM2 in the Same Chassis

Figure 4 WiSM2 in Single Chassis

 

WiSM2 in Different Chassis: Redundancy VLAN over L2 Network

Figure 5 WiSM2 connectivity using Redundancy VLAN over L2 network

Configuration on Cat6k for WiSM2

wism service-vlan 192 ( service port VLAN)

wism redundancy-vlan 169 ( redundancy port VLAN)

wism module 6 controller 1 allowed-vlan 24-38 ( data VLAN)

WiSM2 HA configuration remains the same.

WiSM2 in Different Chassis: VSS Pair

Figure 6 WiSM2 connectivity using VSS Pair

 

Figure 7 Active and Standby VSS Pair connected via VSL Link

 

Figure 8 WiSM2 connectivity using VSS Pair

 

VSS Configuration

 

 

Recommendations

■Round trip latency on Redundancy Link should be less than or equal to 80 milliseconds.

■Preferred MTU on Redundancy Link is 1500 or above.

■Bandwidth on Redundancy Link should be 60 Mbps or more.

■If redundancy ports are connected via switches such that there is L2 adjacency between the two controllers, the RP VLAN should be excluded from the access VLAN configured on the switch for the management ports.

■For WiSM2 connectivity between two different chassis connected across the L2 network, the “redundancy-vlan” should be excluded from the access-VLAN configured on the switch for the management ports.

■It is important to use different sets of switches for the RP port connectivity and the management port traffic. Failure to do so results in an active-active scenario if the L2 switch reloads, causing the APs to lose connectivity, leading to downtime to clients.

■When deploying WiSM2 in VSS setup, it is recommended to set the peer search time to 180 seconds.

AP And Client State Sync

1. At this stage both the controllers are paired up in HA setup. Any configuration done on Active will be synced to Standby controller via redundant port. Check the WLAN summary and Interface summary on standby WLC from console connection.

2. In High Availability setup, APs’ CAPWAP state in maintained on Active as well as Standby controller (only for APs which are in Run state) i.e. UP time and Associated UP time is synced from the active to the standby controller. In an example below WLC 1 is an Active state and serving the network and WLC 2 is in Standby state monitoring active controller. Although WLC 2 is in standby state it still maintains CAPWAP state of AP.

WLC 1->Console Connection:

 

Observe the AP UP Time and Association UP Time on Active WLC

WLC 2->Console Connection:

 

Observe the AP Uptime and Association UP Time on Standby WLC will be in sync with active WLC.

3. In case of Box Failover i.e. Active controller crashes / system hang / manual reset / force switchover direct command is sent from Active controller via Redundant Port as well as from Redundant Management Interface to Standby controller to take over the network. Failover may take ~2-360 millisecond depending on number of APs/Clients on the active controller. In case of power failure on Active WLC or some crash where direct command for switchover cannot be sent to the standby controller, it may take ~360 – 990 msec depending upon number of APs/Clients on the active controller and the Keepalive timer configured. The default Keepalive timer is 100 milliseconds. Make sure that default RTT latency is less than or equal to 80 msec.

4. With release 7.5 as part of Client SSO, the client database is also synced to standby WLC so Run state client entries will be present on Standby WLC.

WLC 1-> Console/Telnet/SSH Connection:

 

 

Client entry is present on Active WLC.

WLC2-> Console Connection:

 

 

Client entry is present on Standby WLC.

5. PMK cache is also synced between the two controllers

WLC 1:

 

WLC 2:

 

Failover Process

1. Issue a command redundancy force-switchover on Active controller. This command will trigger manual switchover where Active controller will reboot and Standby controller will take over the network. In this case Run state client on Active WLC will not be de-authenticated. The command save config is initiated before redundancy force-switchover command.

WLC 1-> Console Connection:

 

WLC 2-> Console Connection:

 

Observe the change in prompt in above screen capture.

WLC 2->Console Connection:

 

Observe the AP CAPWAP State on WLC 2 which was standby initially and is Active now after switchover. AP uptime as well as Association UP Time is maintained and AP did not go in discovery state.

2. Also notice client connectivity when switchover is initiated. Client will be not be de-authenticated.

Ping from wireless client to its gateway IP Address and management IP Address during switchover shows minimal loss.

 

 

3. To check the redundancy status

WLC 1 -> Console connection issue a command show redundancy summary:

 

WLC 2 -> Console connection issue a command show redundancy summary:

 

WLC 2-> Click on Monitor > Redundancy > Summary:

 

4. Initiate a force switchover again on current active WLC.

WLC, which was configured as Primary Unit, should now be active and WLC, which was configured as Secondary Unit i.e., WLC 2 should be in Hot Standby State.

WLC 2:

 

WLC 1: Make sure Local state should be Active and Unit should be Primary on WLC 1 after switchover:

 

Observe the switchover history. WLC maintains 10 switchover histories with switchover reason.

 

 

Client SSO Behavior and Limitations

■The Bonjour dynamic database comprising of the services and service providers associated with a service and the domain name database is synced to standby.

■Only clients that are in Run state are synced between the Active and Standby WLC. Client SSO does not support seamless transitions for clients that are in the process of associating/joining the controller. The clients in the transition phase will be de-authenticated after switchover and will need to rejoin the controller.

■Posture and NAC OOB are not supported if the client is not in Run state.

■With release 8.2.111.0 WGB and clients associated to the WGB will be state fully switched over with client SSO.

■CCX based applications need to be re-started post Switchover.

■New mobility is not supported.

 

■Client statistics are not synced.

■PMIPv6, NBAR, SIP static CAC tree are not synced, need to be re-learned after SSO.

■OEAP (600) clients are not supported.

■Passive clients need to be re-associated after SSO.

■Device and root certificates are not automatically synced to the Standby controller.

■AP and Client Rogue information is not synced to the Standby controller and needs to be re-learnt when the hot standby becomes the active controller.

■Sleeping client information is not synced to the standby controller.

■NBAR statistics are not synced to the secondary controller.

■Native Profiling data is not synced to the secondary controller, therefore, clients will be re-profiled after switchover.

■The below table captures the behavior w.r.t SSO with MAPs and RAPs.

 

Enhancements and Improvements

Bulk Sync Status

Currently, the controller does not provide any indication for the completion of Bulk Sync configuration once it is initiated. The Bulk Sync can be verified only by user observation and by manually checking the number of clients synced to the standby WLC. As part of this feature, a mechanism is provided to convey the status of Bulk Sync (both AP and client sync) when standby WLC comes up.

A new field called BulkSync Status is added in the GUI under Controller > Redundancy > Summary. This field points to the status of the bulk sync to the standby WLC and the status can be Pending/In-progress/Complete.

Figure 9 BulkSync Status GUI

 

The output of the CLI command show redundancy summary also displays the Bulk Sync status, which can be Pending/In-progress/Complete as shown below while pairing with the standby controller.

When the standby controller is booting up, the BulkSync status shows Pending.

Figure 10 BulkSync Status—Pending

 

Once the standby controller completes, the boot-up process and the bulk sync starts, the status changes to In-Progress.

Figure 11 BulkSync Status—In-Progress

 

When the bulk sync process is complete, the BulkSync status changes to Complete.

Figure 12 BulkSync Status—Complete

 

Debug/Show Command Enhancements

As HA plays a major role in avoiding network outage, it should also be pertinent to be able to debug the state changes on the boxes at the time of SSO or at a later point in time.

The following new categories of statistics are introduced under Monitor > Redundancy > Statistics:

a. All

b. Infra

c. Transport

d. Keep-Alive

e. GW-Reachability

f. Config-Sync

Figure 13 Redundancy Statistics GUI

 

The Infra statistics contain RF Client details and Sanity Counters as shown in Figure 14.

Figure 14 Redundancy Statistics—Infra

Figure 15 Redundancy Statistics —Transport

 

The Heartbeat debugs include events of reception of heartbeats, loss of heartbeats, and subsequent actions related to them.

Figure 16 Redundancy Keep-alive Statistics

 

The HA system monitors management gateway reachability to reduce network outage.

On the Standby controller, serviceability debugs related to the gateway reachability of the active controller and standby controller, their health states, and actions taken based on this information is reported. While on the active controller, the reachability of active WLC to the gateway alone is reported.

Figure 17 Redundancy GW-Reachability Statistics

 

Figure 18 Redundancy Config-Sync Statistics

 

The following debug/show CLI commands are introduced for this feature:

1. debug redundancy infra detail/errors/event

2. debug redundancy transport detail/errors/events/packet

3. debug redundancy keepalive detail/errors/events

4. debug redundancy gw-reachability detail/errors/events

5. debug redundancy config-sync errors/events/detail

6. debug redundancy ap-sync errors/events/detail

7. debug redundancy client-sync errors/events/detail

8. debug redundancy mobility events/errors/detail

9. show redundancy infra statistics

10. show redundancy transport statistics

11. show redundancy keepalive statistics

12. show redundancy gw-reachability statistics

13. show redundancy config-sync statistics

14. show redundancy ap-sync statistics

15. show redundancy client-sync statistics

Configurable Keep-alive and Peer-Search Parameters

To address the variable network latencies in different customer deployment scenarios, keep-alive and peer-search parameters are made configurable. As part of this enhancement, the maximum number of Keepalives between active and standby controllers to trigger a failover is now configurable. Also, peer-search timer and keep-alive timer are modified to support an extended range.

The following new CLI command is added to configure the number of redundancy keep-alive retries in the range of 3 to 10.

Figure 19 Redundancy retries CLI Command

 

The existing CLI command config redundancy timer keep-alive-timer of keep-alive timer is modified to support keep-alive timer from 100 to 1000 msecs.

The existing CLI command config redundancy timer peer-search-timer of peer-search timer is modified to support peer-search timer from 60 to 300 secs.

Figure 20 Redundancy timer CLI Command

 

 

The following CLI is introduced to view the redundancy keep-alive-retry value.

Figure 21 Show redundancy retries CLI Command

Use the show redundancy timers command to view the peer-search-timer and keep-alive-timer values.

Figure 22 Show redundancy timers CLI Command

 

Use the show redundancy detail command to display the keep-alive and peer-search timeout values.

Figure 23 Show redundancy detail CLI Command

 

The keep-alive timer, keep-alive retries, and peer-search timer can also be configured and viewed from the Controller > Redundancy > Global Configuration page in the GUI.

Figure 24 Redundancy Global Configuration GUI

 

Peer RMI ICMP Ping Replaced with UDP Messages

Prior to release 8.0, ICMP ping is used to heart-beat with the peer WLC over the Redundancy Management Interface. As part of this feature for release 8.0, ICMP ping is replaced with a UDP message.

This will benefit due to the following factors:

■ICMP ping packets might get discarded under heavy loads.

■Any other device with the same IP might also reply to the ping.

It is recommended to tag the RMI and management interfaces to avoid false Switchovers. Tagging of the RMI and management interfaces is now mandatory in release 8.0 to pair WLCs in SSO mode.

Standby WLC On-the-Fly Maintenance Mode (MTC)

Prior to release 8.0 when the standby controller looses reachability to the “Default Gateway” or “Peer RP”, the controller reboots and checks that condition while booting up and enters into the MTC mode. With this feature, the standby WLC will enter into the MTC mode “on-the-fly” without rebooting when such error scenarios occur. Once Peer-RP and the default gateway reachability is restored, the MTC mode auto-recovery mechanism introduced in release 7.6, will reboot the WLC and pair it with the active WLC. This mechanism is applicable only to the standby WLC. The active controller will still reboot before going to MTC mode.

Default Gateway Reachability Check Enhancement

As part of this enhancement, the gateway (GW) reachability check mechanism is modified to avoid false positives and it is also modified for the ideal time to start checking for gateway reachability once the controller boots up.

Prior to release 8.0, the “GW reachability check” is performed during Role negotiation. In release 8.0 and later, during Role negotiation, GW reachability check is not performed and is initiated only after the HA Pair-Up is complete.

Also, it is observed that certain Switch/Router configurations rate limits ICMP ping packets or drop them altogether. To avoid such conditions triggering false-positives, the new design ensures not to take switchover decisions purely based on ICMP ping losses. By the modified logic, upon 6 consecutive ping drops, an ARP request is sent to the GW IP address. A successful response to this request is considered as the GW being reachable.

Faster HA Pair Up

Currently during the HA pairing process, once the active-standby role is determined, the configuration is synced from the active WLC to the standby WLC via the Redundancy Port. If the configuration is different, the secondary WLC reports XML mismatch and downloads the configuration from the active controller and reboots again. In the next reboot after role determination, it validates the configuration again, reports no XML mismatch, and process further in order to establish itself as the Standby WLC.

With this feature enhancement, the XMLs are sent from the to-be-Active to to-be-Standby controller at the time of initialization, just before the validation of the XMLs. This avoids the extra step of comparison and reboot since no other modules are initialized yet, resulting in faster pair up of Active and Standby WLCs.

As seen in the boot logs below, there are no comparison of XMLs and no reboot of standby WLC.

Figure 25 Standby WLC bootup log

 

New Features Support in SSO

SSO Support for Internal DHCP Server

Prior to release 8.0, configuration of “Internal DHCP Server” is not allowed on HA enabled controllers because the internal DHCP server data is not synced to the standby WLC. In release 8.0 and later, “Internal DHCP Server” is configured on HA enabled controllers and this data is synced to the standby WLC so that soon after a switchover, the “Internal DHCP Server” on the new active controller starts serving clients.

To configure the Internal DHCP server using the GUI, navigate to Controller > Internal DHCP Server

Figure 26 Internal DHCP Server GUI

 

The same is synced to the standby controller and is verified by executing the CLI command show dhcp summary

Figure 27 show dhcp summary on Active and Standby WLC

 

AP Radio CAC Statistics Sync

As part of this enhancement, Static CAC method bandwidth allocation parameters for Voice and Video and Call Statistics are synced to the Standby WLC, so that soon after a switchover, respective information is available on the new active controller that will be used for call admission control.

SSO Support for Sleeping Clients

Release 7.5 did not provide SSO support for sleeping clients. The sleeping client database was not synced to the standby controller, which caused the sleeping clients to re-authenticate after a switchover occurred. With this release, sleeping client database is synced to the standby controller, allowing sleeping clients to avoid web re-authentication if they wake up within the sleeping client timeout interval.

The CLI command show custom-web sleep-client summary is used to verify the sleeping client database sync between the active and standby WLC.

Figure 28 Sleeping Client Database on Primary WLC

 

Figure 29 Sleeping Client Database on Standby WLC

 

Figure 30 Sleeping Client Details on Active and Standby WLC

 

SSO Support for OEAP 600 APs

Prior to release 8.0, when a switchover occurs on an HA pair, OEAP 600 APs restarts the CAPWAP tunnel and joins back the new active controller, and all the connected clients are de-authenticated. As a part of this feature, OEAP 600 APs ensure not to reset their CAPWAP tunnel. Also, clients continue their connection with the new active controller in a seamless manner.

As shown below, the output of show ap summary and show client summary command on the active and standby controllers displays the AP and client database sync.

Figure 31 OEAP 600 AP on Active WLC

 

Figure 32 OEAP 600 AP Sync to Standby WLC

 

Figure 33 Clients on Active WLC

 

Figure 34 Client Sync to Standby WLC

 

HA Standby Monitoring Feature Introduction

From the client’s perspective, although the Active and Hot Standby controllers constitute a single entity, from the administrator’s perspective, they are still considered, maintained, and monitored as two separate controllers. The administrator fetches the status and health information of Active and Standby WLCs separately to monitor and maintain the controllers on a continuous basis with the help of management infrastructure and various user interfaces.

This section outlines the interfaces to fetch the health state information and traps from the Standby controllers and also describes how to use these user interfaces through the CLI, GUI, and SNMP.

Events and Notifications

Trap When WLC Turns Hot Standby

A trap is reported with time stamp when HA peer becomes Hot-Standby, and the following trap is reported:

A new trap type is added in CISCO-LWAPP-HA-MIB.my.

 

Trap when Bulk Sync Complete

After the HA pairing is done and Bulk sync is complete, the following trap is reported:

A new trap type is added in CISCO-LWAPP-HA-MIB.my.

 

Trap when Standby WLC goes Down

When the standby peer goes down due to any of the following events,

■Manual Reset

■Crash

■Memory Leak/Hang

■Moving to maintenance mode

the below trap is reported:

A new trap type is added in CISCO-RF-SUPPLEMENTAL-MIB.my.

 

On the CLI, the trap can be viewed by executing the command show traplog.

 

Syslog notification when Admin login on Standby

Admin Login to Standby Using SSH

This generates an event in msglog / syslog and message snippet is as follows:

This message can be viewed on the Standby WLC by executing the CLI ‘ show msglog ’

Admin Login to Standby Using Console

This generates an event in msglog/syslog and message snippet is as follows:

This message can be viewed on the Standby WLC by executing the CLI ‘ show msglog ’

Peer Process Statistics on CLI

As part of this feature, CPU and Memory statistics of all the threads of the Standby WLC are synced to Active controller every 10 seconds. This information is displayed when the user queries for the Peer statistics on the active WLC.

New Commands on Active WLC to display peer process System, CPU and memory statistics are as follows:

■ show redundancy peer-system statistics

■ show redundancy peer-process cpu

■ show redundancy peer-process memory

MIB CISCO-LWAPP-HA-MIB.my is updated to capture these statistics.

 

 

Peer Process Statistics on GUI

Peer statistics on the GUI can be viewed under Monitor > Redundancy > Peer Statistics.

Figure 35 Peer Process System Statistics

 

 

 

MIB CISCO-LWAPP-HA-MIB.my is updated to capture these statistics.

Figure 36 Peer Process CPU Statistics

 

 

Figure 37 Peer Process Memory Statistics

Related Information

■ Technical Support & Documentation - Cisco Systems

■ N+1 Deployment guide

■To add additional licenses on the HA Pair and replace WLC while in HA Setup, please refer to:
https://www.cisco.com/c/en/us/support/docs/interfaces-modules/wireless-services-module-2-wism2/117729-configure-wlan-00.html#anc7