Cisco 9800 High Availability on IOS XE 17.x

Information About High Availability

High Availability (HA) allows you to reduce the downtime of wireless networks that occurs due to the fail over of controllers.

The HA Stateful Switch Over (SSO) capability on the controller allows AP to establish a CAPWAP tunnel with the active controller.

The active controller shares a mirror copy of the AP and client database with the standby controller.

The APs won’t go into the discovery state and clients don’t disconnect when the active controller fails. The standby controller takes over the network as the active controller.

This is a configuration guide, for a thorough understanding please read the IOS XE 9800 17.x deployment guide (chapter 98)

Lab setup – there are three scenarios on which HA can be designed/deployed this lab will focus on the HSRP Active/Standby

Lab in eve-ng

SSO Pr-requisites
■ HA Pair can only be form between two wireless controllers of the same form factor
■ Both controllers must be running the same software version in order to form the HA Pair
■ Maximum RP link latency = 80 ms RTT, minimum bandwidth = 60 Mbps and minimum MTU = 1500

Connecting a C9800 wireless controller HA pair to upstream switches
Prior to 17.1 following typologies were supported in terms of upstream connectivity to the network:

SSO pair connected to upstream VSS pair with split links and RP connected back to back.
SSO pair connected to upstream VSS pair with RP connected via the upstream set of switches in order to detect gateway down scenario.
SSO pair connected to upstream HSRP active and standby and RP connected via upstream set of switches in order to detect gateway down scenario.

The active controller and the standby controller must be paired with the same interface name.

Static IP addressing can synch to standby, but the IP address cannot be used from the standby controller.

• You can map a dedicated HA port to a 1 GB interface only.

• To use EtherChannels in HA mode in releases until, and including, Cisco IOS XE Gibraltar 16.12.x, ensure that the channel mode is set to On.

• LACP is not supported in HA mode in releases until, and including, Cisco IOS XE Gibraltar 16.12.x.

• When the controller works as a host for spanning tree, ensure that you configure portfast trunk in the uplink switch using spanning-tree port type edge trunk or spanning-tree portfast trunk command to ensure faster convergence.

Information About Redundancy Management Interface

The Redundancy Management Interface (RMI) is used as a secondary link between the active and standby Cisco Catalyst 9800 Series Wireless Controllers.

This interface is the same as the wireless management interface, and the IP address on this interface is configured in the same subnet as the Wireless Management interface.

The RMI is used for the following purposes:
• Dual Active Detection
• Exchange resource health between controllers, for instance, gateway reachability status from either controller.

• Gateway Reachability detection: Gateway reachability is checked on the active and the standby controller through the RMI interface when the feature is enabled. It takes approximately 8 seconds to detect that a
controller has lost gateway reachability.

Note The RMI might trigger a switchover based on the gateway status on the controllers.

The chassis number can be verified using the show chassis command.

A chassis can be renumbered using the chassis x renumber x command

The configuration on 17.x is fairly straight forward.

Define the ports that will be used for redundancy. The physical appliance has a dedicated port while the virtual appliance has GigabitEthernet 3 as the HA interface

Pair the devices on their respective interface

2. Configures Redundancy Management Interface. In the example above the wireless management interface = 10.0.24.46/26

Note: The command above must be implemented on both controllers if HA is being configured for the first time

Each controller must have a unique chassis number for RMI to form the
HA pair. The chassis number can be observed as SWITCH_NUMBER in
the output of show romvar command. Modification of SWITCH_NUMBER is currently not available through the web UI.

Reload both wireless controllers by executing the command reload from the CLI

Note: It is recommended to configure HA using the Redundancy Management Interface (RMI) starting Release 17.1.

Active and Standby Election Process

An active C9800 wireless controller retains its role as an Active Controller unless one of the following events occur:
■ The wireless controller HA pair is reset.
■ The active wireless controller is removed from the HA pair.
■ The active wireless controller is reset or powered off.
■ The active wireless controller fails.
The active wireless controller is elected or re-elected based on one of these factors and in the order listed below:

The wireless controller that is currently the active wireless controller.
The wireless controller with the highest priority value.
Note: We recommend assigning the highest priority value to the wireless controller C9800 you prefer to be the active controller. This ensures that the controller is re-elected as active controller if a re-election occurs. Setting the Switch Priority Value chassis chassis -number priority new-priority-numberChassis-number Specifies the chassis number and the new priority for the chassis. The chassis number range is 1 to 2. The priority value range is <1-2>
Example
wireless controller#chassis 1 priority 2
You can display the current priority value by using the show chassis user EXEC command. The new priority value takes effect immediately but does not affect the current Active Controller.
The new priority value helps determine which controller is elected as the new Active Controller when the current active wireless controller or HA redundant pair reloads.
The wireless controller with the shortest start-up time.
The wireless controller with the lowest MAC Address.
The HA LED on the chassis can be used to identify the current Active Controller.