Cisco Wireless LAN Controller Configuration Guide, Release 7.4
Configuring High Availability
Downloads: This chapterpdf (PDF - 1.22MB) The complete bookPDF (PDF - 17.75MB) | The complete bookePub (ePub - 4.37MB) | Feedback

Configuring High Availability

Configuring High Availability

Information About High Availability

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.

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.

    Note


    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.



    Note


    A redundancy VLAN should be a non-routable 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.



    Note


    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, the standby controller always uses redundancy-management interface (RMI) and all the other interfaces, dynamic and management, are invalid. A ping must only accept redundancy-management interface (RMI) as source and not any other interfaces.
  • 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.
  • 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.

Redundancy Port

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 209.165.200.225, the IP address of the redundancy port is 169.254.200.225.

Restrictions for High Availability

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


    Step 1   On the GUI of both controllers, choose Controller > Redundancy > Global Configuration.

    The Global Configuration page is displayed.

    Step 2   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.

    Step 3   From the Redundant Unit drop-down list, choose one of the controllers as primary and the other as secondary.
    Step 4   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 high availability, 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.

    Step 5   (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 high availability 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.

    Step 6   Click Apply.
    Step 7   Click Save Configuration.
    Step 8   View the redundancy status of the HA pair by choosing Monitor > Redundancy > Summary.

    The Redundancy Summary page is displayed.

    Step 9   Follow these steps to configure the peer network route:
    1. Choose Controller > Redundancy > Peer Network Route.

      The Network Routes Peer page is displayed.

      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.

    2. To create a new peer network route, click New.
    3. Enter the IP address, IP netmask, and the Gateway IP address of the route.
    4. Click Apply.

    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:

      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 redundancy by entering this command:

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

      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}

      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

      This command can be run only when SSO is disabled.

    • 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

      Execute this command only when you require a manual switchover.

    • Configure the redundancy timers by entering this command:

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

    • View the status of 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 Config, Event Logs, Crash files, and so on from the standby-hot controller by entering this command on the active controller:

      transfer upload peer-start

    • Debug the commands for the Redundancy Manager by entering this command:

      debug rmgr {packet | events | errors | detail}

    • Debug the commands for the Redundancy Sync Manager by entering this command:

      debug rsnyncmgr {packet | events | errors | detail}

    • Debug the commands for the Redundancy Facilitator by entering this command:

      debug rfrac {packet | events | errors | detail}