High Availability

A high availability feature is a wireless controller capability that

reduces network downtime by enabling seamless failover between active and standby controllers,
preserves AP and client connectivity through stateful switchover by maintaining CAPWAP tunnels and client sessions during failover, and
mirrors AP and client databases from the active controller to the standby controller to prevent APs from entering discovery state and avoid client disconnections.

Feature history for High Availability

This table provides release and related information for the features explained in this module.

These features are available in all the releases subsequent to the one they were introduced in, unless noted otherwise.

Table 1. Feature history
Release	Feature	Feature information
Cisco IOS XE 17.18.1	Enhanced Gateway Reachability Statistics	Improves visibility into gateway reachability and provides detailed statistics for ICMP, ARP, and ND probes. This feature enables simplified troubleshooting, greater transparency, and more reliable diagnostics for HA and RMI functionality. This command is introduced: show platform software rif-mgr chassis { active \| standby} r0 gateway-statistics This command is modified: show platform software rif-mgr chassis { active \| standby} r0 resource-status
Cisco IOS XE 17.5.1	Auto-Upgrade	The auto-upgrade feature enables the standby controller to upgrade to active controller's software image, so that both controllers can form an high availability (HA) pair.
Cisco IOS XE 17.5.1	Standby Monitoring Enhancements	The Standby Monitoring Enhancements feature monitors the standby CPU or memory information from the active controller. Also, this feature independently monitors the standby controller using SNMP for the interface MIB. The cLHaPeerHotStandbyEvent and cLHaPeerHotStandbyEvent MIB objects in CISCO-HA-MIB are used to monitor the standby HA status.
Cisco IOS XE 17.4.1	Gateway Reachability Detection	Gateway reachability feature minimizes the downtime on APs and clients when the gateway reachability is lost on the active controller.
Cisco IOS XE 17.1.1s	Redundant Management Interface	The Redundancy Management Interface (RMI) is used as a secondary link between the active and standby 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.

Additional reference information

High availability enables seamless controller failover, ensuring that APs and clients remain connected during controller outages. These notes and recommendations apply to HA deployments:

Do not shut or unshut the RP port during controller bootup in HA mode.
When the controller operates as a spanning tree host, configure portfast trunk on the uplink switch to ensure faster convergence. Use spanning-tree port type edge trunk or spanning-tree portfast trunk.
You can configure FIPS in an HA setup. For information, see the Configuring FIPS in HA Setup.
Do not configure the secondary IPv4 address. The controller uses the IPv4 secondary address internally for RMI purposes.

Configure only one management IPv6 address on the Wireless Management Interface (WMI). The controller uses any secondary address for RMI-IPv6.

Configuring more than one management IPv4 address or more than one management IPv6 address on the WMI may cause unpredictable behavior.

During a failover event, only one CAPWAP tunnel is maintained between APs and the active controller. This ensures zero downtime for client services and no SSID outages. Database mirroring prevents APs from entering the discovery state and ensures that clients remain connected without interruption.

Prerequisites for High Availability

To ensure high availability, configure interfaces properly, select the appropriate HA port, and meet latency, bandwidth, and MTU requirements for RP links.

External interfaces and IPs

All interfaces are configured on the Active box and synchronized with the Standby box. Therefore, the same set of interfaces is present on both controller s.

External nodes connect to the same IP addresses regardless of which controller they are connected to.

APs, clients, DHCP servers, Cisco Prime Infrastructure, Cisco Catalyst Center, and Cisco Identity Services Engine (ISE) servers, as well as other controller members in the mobility group, always connect to the same IP address.

The SSO switchover is transparent to these devices. However, if TCP connections exist from external nodes to the controller , reset and reestablish those connections.

HA interfaces

The HA interface provides:

Provides connectivity between the controller pair before an IOSd comes up,
provides IPC transport across the controller pair, and
enables redundancy across control messages exchanged between the controller pair. The control messages include HA role resolution, keepalive messages, notifications, HA statistics, and similar messages.

You can select an SFP or RJ-45 connection for the HA port. Supported Cisco SFPs are:

GLC-SX-MMD
GLC-LH-SMD

HA operates when either an SFP or RJ-45 connection is present between the two controllers. SFP connectivity takes priority over RJ-45 connectivity.

If you connect an SFP link while RJ-45 HA is active, the HA pair restarts. The restart occurs even if the SFP link is not connected.

HA operates when either an SFP or RJ-45 connection is present between the two controllers. If you connect an SFP link while RJ-45 HA is active, the HA pair restarts. The restart occurs even if the SFP link is not connected.

Note

Use a dedicated physical network interface card (NIC) and switch for the redundancy port (RP) when deploying the HA pair across two hosts. This prevents keepalive losses and false HA switchovers or alarms.
Disable security scans on VMware virtual instances to prevent HA issues.

Note

Connect RP links using switches to enable controller HA. Keep the round-trip time between the two controllers under 80 milliseconds.

High Availability restrictions

Wait until configuration synchronization completes on the standby controller. Before initiating a fail-safe Stateful Switchover (SSO), ensure that the standby controller has been powered on for sufficient time (up to 24 minutes [up to 1,440 seconds] on some platforms) to achieve readiness. Use the show wireless stats redundancy config database command to view database statistics.
During a switchover in local mode, NBAR engine flow states are lost. As a result, classification restarts and may lead to incorrect packet classification.
You can use HA connections only with IPv4.
When you perform a switchover or an active reload, the high-availability link goes down on the new primary controller.
Do not enable hyper-threading in HA systems. If enabled, HA keepalives are lost, and a stack merge may occur.
You cannot access the web UI from the standby RMI interface.
Configure two HA interfaces, RMI and RP, on the same subnet. Do not share this subnet with any other interfaces on the device.
After a switchover, you must re-establish any TCP session because synchronization is not possible.
Client SSO does not address clients that have not reached the RUN state. These clients are removed after a switchover.
Statistics tables are not synchronized from the active controller to the standby controller.
Creating a machine snapshot of a VM hosting controller HA interfaces is not supported. This action may lead to a crash in the HA controller.
Clients that are not in RUN state are reauthenticated after a switchover.
Application classification may not be retained after SSO:
- AVC limitation—After a switchover, context transfer or synchronization to the standby controller does not occur. The new active flow must be relearned. AVC QoS does not take effect during classification failure.
- A voice call cannot be recognized after a switchover because a voice policy is based on RTP or RTCP protocol.
- Auto QoS does not work due to AVC limitation.
For virtual platforms, pair the active controller and the standby controller with the same interface. For hardware appliances, use a dedicated HA port.
You can synchronize static IP addressing to the standby controller, but you cannot use the IP address from the standby controller.
You can map a dedicated HA port to a 1-gigabit (1,000 Mbps) interface only.
To use EtherChannels in HA mode in releases up to Cisco IOS XE Gibraltar 16.12.x, ensure that the channel mode is set to On.
EtherChannel Auto-mode is not available in HA mode in releases up to Cisco IOS XE Gibraltar 16.12.x.
LACP and PAGP protocols cannot be used in HA mode in releases up to Cisco IOS XE Gibraltar 16.12.x.
When the controller operates as a host for spanning tree, configure portfast trunk on the uplink switch using spanning-tree port type edge trunk or spanning-tree portfast trunk command to ensure faster convergence.
The clear chassis redundancy and write erase commands do not reset the chassis priority to the default value.
While configuring devices in HA, ensure that members do not have wireless trustpoints with the same name but different keys. If you form an HA pair between two standalone controllers with mismatched trustpoints, the wireless trustpoint does not come up after SSO. The rsa keypair file exists but is incorrect because the nvram:private-config file is not synchronized with the actual WLC_WLC_TP key pair.
Before forming HA, delete existing certificates and keys from each controller that was previously deployed as standalone. This is a best practice.
Do not configure the WLAN or WLAN policy after a switchover while recovery is in progress. Doing so may cause the controller to crash.
After a switchover, clients that are not in RUN state and not connected to an AP are removed after 300 seconds (5 minutes).

Best practices for RP port configuration

When you configure RP ports, use these best practices:

Ensure that the Local and Remote IP addresses are in the same subnet.
Use the 169.254.X.X/16 subnet, deriving the last two octets from the management interface.
Do not use the 10.10.10.x/24 subnet for the RP port.
For more information about RMI+RP chosen as the redundancy method, see Information About Redundancy Management Interface .

Configure High Availability (CLI)

Set up high availability for network redundancy and automatic failover between devices using the CLI.

Before you begin

Ensure that the active and standby controllers use the same mode—either Install mode or Bundle mode—and the same image version. Use Install mode.

Procedure

Step 1

(Optional) Configure the priority of the device.

Example:

Device# chassis chassis-num priority chassis-priority

Note

From Cisco IOS XE 16.12.x onward, a device reload is not required for the chassis priority to take effect.

chassis-num —Enter the chassis number (range: one to two).
chassis-priority —Enter the chassis priority (range: one to two; default: one).

Note

If both devices boot up simultaneously, the device with the higher priority (2) becomes active. The other device becomes standby. If both devices have the same priority, the device with the smaller MAC address becomes active, and the peer device becomes standby.

Step 2

Set the chassis high-availability parameters.

Example:

Device# chassis redundancy ha-interface GigabitEthernet num local-ip local-chassis-ip-addr network-mask remote-ip remote-chassis-ip-addr

Example:

Device# chassis redundancy ha-interface 
                        GigabitEthernet 2 local-ip 4.4.4.1 /24 remote-ip 4.4.4.2

num —GigabitEthernet interface number (range: zero to 32).
local-chassis-ip-addr —Enter the IP address of the local chassis high-availability interface.
network-mask —Enter the network mask or prefix length in slash nn or dotted decimal format.
remote-chassis-ip-addr —Enter the remote chassis IP address.

Step 3

Configure the peer keepalive timeout value.

Example:

Device# chassis redundancy keep-alive timer timer

Set the time interval in multiples of 100 milliseconds (ms). Enter one for the default value.

Step 4

Set the peer keepalive retry value that determines when the system considers the peer down.

Example:

Device# chassis redundancy keep-alive retries retry-value

The default value is five.

After you complete these steps, high availability is configured between two devices. The system uses device priorities, high-availability interfaces, and keepalive parameters to ensure redundancy and seamless failover if a device fails.

Disable High Availability

When you disable high availability, all HA-related parameters are removed and the controller returns to stand-alone mode.

Use clear chassis redundancy with the RP method to clear the local IP, remote IP, HA interface, mask, timeout, and priority.
Use no redun-management interface vlan chassis with the RMI method.
After you unpair the controllers, the startup and HA configuration of the standby controller are cleared, and it enters Day zero state.

If you configure the controller using the RP method for SSO, use this command to clear all HA-related parameters: local IP, remote IP, HA interface, mask, timeout, and priority:

clear chassis redundancy

If you configure the controller using the RMI method, use this command:

no redun-management interface vlan chassis

Note

This command is not supported on these models:

Cisco Catalyst CW9800H1 Wireless Controller .
Cisco Catalyst CW9800H2 Wireless Controller .
Cisco Catalyst CW9800M Wireless Controller .

RMI-based High Availability is mandatory in the Cisco Catalyst CW9800H1 Wireless Controller , Cisco Catalyst CW9800H2 Wireless Controller , and Cisco Catalyst CW9800M Wireless Controller .

Note

Reload your devices to apply the changes.

Before you execute the command, you see this warning on the active controller:


Device# clear chassis redundancy
WARNING: Clearing the chassis HA configuration will result in both the chassis move into
Stand Alone mode. This involves reloading the standby chassis after clearing its HA
configuration and startup configuration which results in standby chassis coming up as a totally
clean after reboot. Do you wish to continue? [y/n]? [yes]:
*Apr 3 23:42:22.985: received clear chassis.. ha_supported:1yes
WLC#
*Apr 3 23:42:25.042: clearing peer startup config
*Apr 3 23:42:25.042: chkpt send: sent msg type 2 to peer..
*Apr 3 23:42:25.043: chkpt send: sent msg type 1 to peer..
*Apr 3 23:42:25.043: Clearing HA configurations
*Apr 3 23:42:26.183: Successfully sent Set chassis mode msg for chassis 1.chasfs file updated
*Apr 3 23:42:26.359: %IOSXE_REDUNDANCY-6-PEER_LOST: Active detected chassis 2 is no
longer standby

On the standby controller, these messages indicate that the configuration is being cleared:

Device-stby#
*Apr 3 23:40:40.537: mcprp_handle_spa_oir_tsm_event: subslot 0/0 event=2
*Apr 3 23:40:40.537: spa_oir_tsm subslot 0/0 TSM: during state ready, got event 3(ready)
*Apr 3 23:40:40.537: @@@ spa_oir_tsm subslot 0/0 TSM: ready -> ready
*Apr 3 23:42:25.041: Removing the startup config file on standby
!Standby controller is reloaded after clearing the chassis.

Copy a WebAuth tar bundle to the standby controller (GUI)

Ensure the standby controller receives the WebAuth tar bundle to maintain seamless high-availability functionality.

Copy a WebAuth tar bundle to the standby controller in a high-availability configuration.

Procedure

Step 1	Go to Administration , select Management , and then select Backup and Restore.
Step 2	Select To Device from the Copy drop-down list.
Step 3	Select WebAuth Bundle from the File Type drop-down list.
Step 4	Select TFTP , SFTP , FTP , or HTTP from the Transfer Mode drop-down list. The required values for the Server IP Address and File Path fields depend on the selected transfer mode. TFTP IP Address (IPv4/IPv6) : Enter the server IP address (IPv4 or IPv6) of the TFTP server you want to use. File Path: Enter the file path. Start the file path with a slash, such as /path. File Name: Enter a file name. Do not use spaces in the file name. Use underscores and hyphens. Make sure the file name ends with .tar, for example, webauthbundle.tar. SFTP IP Address (IPv4/IPv6): Enter the server IP address (IPv4 or IPv6) of the SFTP server that you want to use. File Path: Enter the file path. Start the file path with a slash, such as /path. File Name: Enter a file name. Do not use spaces in the file name. Only underscores and hyphens are allowed. Make sure the file name ends with .tar, for example, webauthbundle.tar. Server Login Username: Enter the SFTP server login user name. Server Login Password: Enter the SFTP server login passphrase. FTP IP Address (IPv4/IPv6): Enter the server IP address (IPv4 or IPv6) of the FTP server that you want to use. File Path: Enter the file path. Start the file path with a slash, such as /path . File Name: Enter a file name. Do not use spaces in the file name. Only underscores and hyphens are allowed. Make sure the file name ends with .tar, for example, webauthbundle.tar. Logon Type: Choose Anonymous or Authenticated . If you choose Authenticated, these fields are activated: Server Login Username: Enter the FTP server login user name. Server Login Password: Enter the FTP server login passphrase. HTTP Source File Path: Click Select File to select the configuration file, and click Open.
Step 5	Click the Yes or No radio button to back up the existing startup configuration to Flash. Save the configuration to Flash to propagate the WebAuth bundle to other members, including the standby controller.
Step 6	Click Download File.

The WebAuth tar bundle is successfully copied to the standby controller, ensuring high-availability readiness.

System and network fault handling

If the standby controller crashes, the system reboots it as the standby controller. The system then performs bulk synchronization, which makes the standby controller ready for operation. If the active controller crashes, the system promotes the standby controller to active. The new active controller becomes the primary controller and checks for a dual-active state.

These matrices show the conditions that trigger a controller switchover.

Table 2. System and Network Fault Handling
System Issues
Trigger	RP Link Status	Peer Reachability through RMI	Switchover	Result
Critical process crash	Up	Reachable	Yes	The system initiates a switchover.
Forced switchover	Up	Reachable	Yes	The system initiates a switchover.
Critical process crash	Down	Reachable	No	The system does not take action. One controller enters recovery mode.
Forced switchover	Down	Reachable	N/A	The system does not take action. One controller enters recovery mode.
Critical process crash	Down	Unreachable	No	A double fault occurs—see the Network Error handling section for more information.
Forced switchover	Down	Unreachable	N/A	A double fault occurs—see the Network Error handling section for more information.


RP Link	Peer Reachability Through RMI	Gateway From Active	Gateway From Standby	Switchover	Result
Up	Reachable	Reachable	Reachable	Stateful switchover (SSO) is not available	The system does not take action.
Up	Reachable	Reachable	Unreachable	Stateful switchover (SSO) is not available	The standby controller enters recovery mode. If the RP goes down, the standby (in recovery mode) becomes active.
Up	Reachable	Unreachable	Reachable	SSO occurs	Gateway reachability messages are exchanged over RP and RMI links. The active controller reboots, promoting the standby to active.
Up	Reachable	Unreachable	Unreachable	Stateful switchover (SSO) is not available	When both active and standby SVIs go down, a switchover is triggered. If the new active finds its gateway reachable, the system stabilizes in Active–Standby Recovery mode; otherwise, repeated switchovers occur in a controlled sequence.
Up	Unreachable	Reachable	Reachable	Stateful switchover (SSO) is not available	The system does not take action.
Up	Unreachable	Reachable	Unreachable	Stateful switchover (SSO) is not available	The standby controller enters recovery mode. LMP messages are exchanged over the RP link.
Up	Unreachable	Unreachable	Reachable	SSO occurs	Gateway reachability messages are exchanged over RP link. The active controller reboots, promoting the standby to active.
Up	Unreachable	Unreachable	Unreachable	Stateful switchover (SSO) is not available	When both active and standby SVIs go down, a switchover is triggered. If the new active finds its gateway reachable, the system stabilizes in Active–Standby Recovery mode; otherwise, repeated switchovers occur in a controlled sequence.
Down	Reachable	Reachable	Reachable	SSO occurs	The standby becomes active. The previous active enters active-recovery mode, where configuration mode is disabled. All interfaces are ADMIN DOWN except the wireless management interface using the RMI IP. The controller reloads to become standby when the RP link comes up. Recovery mode is indicated with rp-rec-mode in the hostname.
Down	Reachable	Reachable	Unreachable	Stateful switchover (SSO) is not available	The standby enters recovery mode as described above.
Down	Reachable	Unreachable	Reachable	SSO occurs	RP link down causes active to lose gateway. The old active goes into active-recovery mode, while gateway reachability messages over RP+RMI determine switchover timing. All interfaces are ADMIN DOWN except wireless management interface using RMI IP. Controller reloads to standby or standby-recovery when RP link comes up.
Down	Reachable	Unreachable	Unreachable	Stateful switchover (SSO) is not available	The standby controller enters standby-recovery mode.
Down	Unreachable	Reachable	Reachable	SSO occurs	Double fault occurs. Both controllers may become active, causing a network conflict. Role negotiation occurs after connectivity is restored; the controller that came up last remains active.
Down	Unreachable	Reachable	Unreachable	SSO occurs	Double fault occurs. Both controllers may become active. Role negotiation occurs after connectivity is restored; the controller that came up last remains active.
Down	Unreachable	Unreachable	Reachable	SSO occurs	Double fault occurs. Both controllers may become active. Role negotiation occurs after connectivity is restored; the controller that came up last remains active.
Down	Unreachable	Unreachable	Unreachable	SSO occurs	Double fault occurs. Both controllers may become active. Role negotiation occurs after connectivity is restored; the controller that came up last remains active.

Handling recovery mechanism

This topic provides details about the Active-to-Active and Standby-to-Standby High Availability (HA) recovery mechanisms and the system behaviors for each scenario.

Active-to-Active recovery

Active recovery occurs if the Route Processor (RP) is down but the Redundancy Management Interface (RMI) is up during boot. The system triggers active recovery after startup.
In a stable active–standby HA state, if RMI goes down followed by RP, and RMI recovers before RP, the system enters Active-to-Active recovery. After RP is restored, the system reloads active recovery and re-establishes HA.

Standby-to-Standby recovery

If the Gateway fails, the standby node enters standby recovery mode. In this mode, the standby node stays synchronized with the active unit but cannot become active without the Gateway. When in a hot state, the standby node is ready to take over when Gateway connectivity resumes.
If only the Gateway is unavailable, restore the Gateway to allow HA to recover without rebooting.
If a Route Processor (RP) failure triggers standby recovery, wait for the RP to return online. The standby node then reboots automatically, and the system restores HA.

Verify high availability configurations

To view the HA configuration details, use this command:

Device# show romvar
ROMMON variables:
 LICENSE_BOOT_LEVEL =
 MCP_STARTUP_TRACEFLAGS = 00000000:00000000
 BOOTLDR =
 CRASHINFO = bootflash:crashinfo_RP_00_00_20180202-034353-UTC
 STACK_1_1 = 0_0
 CONFIG_FILE =
 BOOT = bootflash:boot_image_test,1;bootflash:boot_image_good,1;bootflash:rp_super_universalk9.vwlc.bin,1;
 RET_2_RTS =
 SWITCH_NUMBER = 1
 CHASSIS_HA_REMOTE_IP = 10.0.1.9
 CHASSIS_HA_LOCAL_IP = 10.0.1.10
 CHASSIS_HA_LOCAL_MASK = 255.255.255.0
 CHASSIS_HA_IFNAME = GigabitEthernet2
 CHASSIS_HA_IFMAC = 00:0C:29:C9:12:0B
 RET_2_RCALTS =
 BSI = 0
 RANDOM_NUM = 647419395

Verify AP or client SSO statistics

To view the AP SSO statistics, use this command:

Device# show wireless stat redundancy statistics ap-recovery wnc all
AP SSO Statistics                                                     

Inst    Timestamp     Dura(ms)   #APs  #Succ  #Fail  Avg(ms)  Min(ms)  Max(ms)
------------------------------------------------------------------------------
   0    00:06:29.042        98     34     34      0        2        1       35
   1    00:06:29.057        56     33     30      3        1        1       15
   2    00:06:29.070        82     33     33      0        2        1       13


Statistics:

WNCD Instance   : 0
No. of AP radio recovery failures          : 0
No. of AP BSSID recovery failures          : 0
No. of CAPWAP recovery failures            : 0
No. of DTLS recovery failures              : 0
No. of reconcile message send failed       : 0
No. of reconcile message successfully sent : 34
No. of Mesh BSSID recovery failures: 0
No. of Partial delete cleanup done : 0
.
.
.

To view the Client SSO statistics, use this command:

Device# show wireless stat redundancy client-recovery wncd all
Client SSO statistics                                                      
----------------------                                                     

WNCD instance  : 1
Reconcile messages received from AP                     : 1
Reconcile clients received from AP                      : 1
Recreate attempted post switchover                      : 1
Recreate attempted by SANET Lib                         : 0
Recreate attempted by DOT1x Lib                         : 0
Recreate attempted by SISF Lib                          : 0
Recreate attempted by SVC CO Lib                        : 1
Recreate attempted by Unknown Lib                       : 0
Recreate succeeded post switchover                      : 1
Recreate Failed post switchover                         : 0
Stale client entries purged post switchover             : 0

Partial delete during heap recreate                     : 0
Partial delete during force purge                       : 0
Partial delete post restart                             : 0
Partial delete due to AP recovery failure               : 0
Partial delete during reconcilation                     : 0

Client entries in shadow list during SSO                : 0
Client entries in shadow default state during SSO       : 0
Client entries in poison list during SSO                : 0

Invalid bssid during heap recreate                      : 0
Invalid bssid during force purge                        : 0
BSSID mismatch with shadow rec during reconcilation     : 0
BSSID mismatch with shadow rec reconcilation(WGB client): 0
BSSID mismatch with dot11 rec during heap recreate      : 0

AID mismatch with dot11 rec during force purge          : 0
AP slotid mismatch during reconcilation                 : 0
Zero aid during heap recreate                           : 0
AID mismatch with shadow rec during reconcilation       : 0
AP slotid mismatch shadow rec during reconcilation      : 0
Client shadow record not present                        : 0

To view the mobility details, use this command:

Device# show wireless stat redundancy client-recovery mobilityd
Mobility Client Deletion Reason Statistics
-------------------------------------------
Mobility Incomplete State         : 0
Inconsistency in WNCD & Mobility  : 0
Partial Delete                    : 0

General statistics
--------------------
Cleanup sent to WNCD, Missing Delete case   : 0

To view the Client SSO statistics for SISF, use this command:

Device# show wireless stat redundancy client-recovery sisf
Client SSO statistics for SISF
--------------------------------
Number of recreate attempted post switchover    : 1
Number of recreate succeeded post switchover    : 1
Number of recreate failed because of no mac     : 0
Number of recreate failed because of no ip      : 0
Number of ipv4 entry recreate success           : 1
Number of ipv4 entry recreate failed            : 0
Number of ipv6 entry recreate success           : 0
Number of ipv6 entry recreate failed            : 0
Number of partial delete received               : 0
Number of client purge attempted                : 0
Number of heap and db entry purge success       : 0
Number of purge success for db entry only       : 0
Number of client purge failed                   : 0
Number of garp sent                             : 1
Number of garp failed                           : 0
Number of IP entries validated in cleanup       : 0
Number of IP entry address errors in cleanup    : 0
Number of IP entry deleted in cleanup           : 0
Number of IP entry delete failed in cleanup     : 0
Number of IP table create callbacks on standby  : 0
Number of IP table modify callbacks on standby  : 0
Number of IP table delete callbacks on standby  : 0
Number of MAC table create callbacks on standby : 1
Number of MAC table modify callbacks on standby : 0
Number of MAC table delete callbacks on standby : 0

To view the HA redundancy summary, use this command:

Device# show wireless stat redundancy summary
HA redundancy summary
---------------------

AP recovery duration (ms)        : 264
SSO HA sync timer expired        : No

Verify high availability

Table 3. Commands for monitoring chassis and redundancy

Command Name

Description

show chassis

Displays the chassis information.

Note

When the peer timeout and retries are configured, the show chassis ha-status command output may show incorrect values.

To check the peer keep-alive timer and retries, use these commands:

show platform software stack-mgr chassis active r0 peer-timeout
show platform software stack-mgr chassis standby r0 peer-timeout

show redundancy

Displays details about Active box and Standby box.

show redundancy switchover history

Displays the switchover counts, switchover reason, and the switchover time.

To start the packet capture in the redundancy HA port (RP), use these commands:

test wireless redundancy packet dump start
test wireless redundancy packet dump stop
test wireless redundancy packet dump start filter port 2300

Device# test wireless redundancy packetdump start
Redundancy Port PacketDump Start
Packet capture started on RP port.

Device# test wireless redundancy packetdump stop
Redundancy Port PacketDump Start
Packet capture started on RP port.
Redundancy Port PacketDump Stop
Packet capture stopped on RP port.
Device# dir bootflash:                           
Directory of bootflash:/
1062881  drwx           151552  Oct 20 2020 23:15:25 +00:00  tracelogs
47      -rw-            20480  Oct 20 2020 23:15:24 +00:00  haIntCaptureLo.pcap
1177345  drwx             4096  Oct 20 2020 19:56:14 +00:00  certs
294337  drwx             8192  Oct 20 2020 19:56:05 +00:00  license_evlog
15      -rw-              676  Oct 20 2020 19:56:01 +00:00  vlan.dat
14      -rw-               30  Oct 20 2020 19:55:16 +00:00  throughput_monitor_params
13      -rw-           134808  Oct 20 2020 19:54:57 +00:00  memleak.tcl
1586145  drwx             4096  Oct 20 2020 19:54:45 +00:00  .inv
1103761  drwx             4096  Oct 20 2020 19:54:39 +00:00  dc_profile_dir
17      -r--              114  Oct 20 2020 19:54:17 +00:00  debug.conf
1389921  drwx             4096  Oct 20 2020 19:54:17 +00:00  .installer
46      -rw-       1104760207  Oct 20 2020 19:26:41 +00:00  leela_katar_rping_test.SSA.bin
49057   drwx             4096  Oct 20 2020 16:11:21 +00:00  .prst_sync
45      -rw-       1104803200  Oct 20 2020 15:39:19 +00:00  C9800-L-universalk9_wlc.2020-10-20_14.57_yavadhan.SSA.bin
269809  drwx             4096  Oct 19 2020 23:41:49 +00:00  core
44      -rw-       1104751981  Oct 19 2020 17:42:12 +00:00  C9800-L-universalk9_wlc.BLD_POLARIS_DEV_LATEST_20201018_053825_2.SSA.bin
43      -rw-       1104286975  Oct 16 2020 12:05:47 +00:00  C9800-L-universalk9_wlc.BLD_POLARIS_DEV_LATEST_20201010_001654_2.SSA.bin

Device# test wireless redundancy packetdump start filter port 2300
Redundancy Port PacketDump Start
Packet capture started on RP port with port filter 2300.

To check connection between the two HA Ports (RP) and check if there are any drops, delays, or jitter in the connection, use this command:

Device# test wireless redundancy rping
Redundancy Port ping
PING 169.254.64.60 (169.254.64.60) 56(84) bytes of data.
64 bytes from 169.254.64.60: icmp_seq=1 ttl=64 time=0.083 ms
64 bytes from 169.254.64.60: icmp_seq=2 ttl=64 time=0.091 ms
64 bytes from 169.254.64.60: icmp_seq=3 ttl=64 time=0.074 ms

--- 169.254.64.60 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2041ms
rtt min/avg/max/mdev = 0.074/0.082/0.091/0.007 ms
test wireless redundancy

To see the HA port interface setting status, use the show platform hardware slot R0 ha_port interface stats command.


Device# show platform hardware slot R0 ha_port interface stats
HA Port
ha_port   Link encap:Ethernet  HWaddr 70:18:a7:c8:80:70
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:e0900000-e0920000

Settings for ha_port:
        Supported ports:            [ TP ]
        Supported link modes:       10baseT/Half 10baseT/Full
                                    100baseT/Half 100baseT/Full
                                    1000baseT/Full
        Supported pause frame use:   Symmetric
        Supports auto-negotiation:   Yes
        Supported FEC modes:         Not reported
        Advertised link modes:       10baseT/Half 10baseT/Full
                                     100baseT/Half 100baseT/Full
                                     1000baseT/Full
        Advertised pause frame use:  Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes:        Not reported
        Speed:                       Unknown!
        Duplex:                      Unknown! (255)
        Port:                        Twisted Pair
        PHYAD:                       1
        Transceiver:                 internal
        Auto-negotiation:            on
        MDI-X:                       off (auto)
        Supports Wake-on:            pumbg
        Wake-on:                     g
        Current message level:       0x00000007 (7)
                                     drv probe link
        Link detected:               no

NIC statistics:
     rx_packets:             0
     tx_packets:             0
     rx_bytes:               0
     tx_bytes:               0
     rx_broadcast:           0
     tx_broadcast:           0
     rx_multicast:           0
     tx_multicast:           0
     multicast:              0
     collisions:             0
     rx_crc_errors:          0
     rx_no_buffer_count:     0
     rx_missed_errors:       0
     tx_aborted_errors:      0
     tx_carrier_errors:      0
     tx_window_errors:       0
     tx_abort_late_coll:     0
     tx_deferred_ok:         0
     tx_single_coll_ok:      0
     tx_multi_coll_ok:       0
     tx_timeout_count:       0
     rx_long_length_errors:  0
     rx_short_length_errors: 0
     rx_align_errors:        0
     tx_tcp_seg_good:        0
     tx_tcp_seg_failed:      0
     rx_flow_control_xon:    0
     rx_flow_control_xoff:   0
     tx_flow_control_xon:    0
     tx_flow_control_xoff:   0
     rx_long_byte_count:     0
     tx_dma_out_of_sync:     0
     tx_smbus:               0   
     rx_smbus:               0
     dropped_smbus:          0
     os2bmc_rx_by_bmc:       0
     os2bmc_tx_by_bmc:       0
     os2bmc_tx_by_host:      0
     os2bmc_rx_by_host:      0
     tx_hwtstamp_timeouts:   0
     rx_hwtstamp_cleared:    0
     rx_errors:              0
     tx_errors:              0
     tx_dropped:             0
     rx_length_errors:       0
     rx_over_errors:         0
     rx_frame_errors:        0
     rx_fifo_errors:         0
     tx_fifo_errors:         0
     tx_heartbeat_errors:    0
     tx_queue_0_packets:     0
     tx_queue_0_bytes:       0
     tx_queue_0_restart:     0
     tx_queue_1_packets:     0
     tx_queue_1_bytes:       0
     tx_queue_1_restart:     0
     rx_queue_0_packets:     0
     rx_queue_0_bytes:       0
     rx_queue_0_drops:       0
     rx_queue_0_csum_err:    0
     rx_queue_0_alloc_failed:0
     rx_queue_1_packets:     0
     rx_queue_1_bytes:       0
     rx_queue_1_drops:       0
     rx_queue_1_csum_err:    0
     rx_queue_1_alloc_failed:0

Configure a switchover

Enable manual failover to the standby unit and verify that high availability and redundancy work as expected.

Procedure

Force a failover to the standby unit by entering this command:

Example:

Device#redundancy force-switchover

After you enter this command, the standby controller takes the active role. The active controller reloads and becomes the standby controller. Use this command to test high availability cluster stability and confirm that switchovers work as expected.

Note

Use only the recommended command to test switchovers between Cisco Catalyst 9800 series wireless controllers. Using other commands, such as reload slot X (where X is the active controller), might cause unexpected behavior.

Note

In a scaled environment, avoid performing an immediate switchover after modifying WLAN or policy profile configurations. Doing so might cause unexpected behavior.

The system completes the switchover. The standby controller becomes active, and the previous active controller reloads to become standby. The switchover verifies high availability cluster stability.

Redundancy management interfaces

A redundancy management interface is a high availability feature that

enables pairing scenarios and gateway monitoring for Cisco Catalyst 9800 Series Wireless Controllers
supports both IPv4 and IPv6 dual stack environments, and
facilitates dynamic pairing, upgrade/downgrade behaviors, ARP handling, and AAA integration.

Gateway monitoring

Gateway monitoring is a network management capability that

selects the gateway IP based on the static routes that match the RMI subnet using the broadest mask and least gateway IP
provides enhanced visibility and statistics related to gateway reachability and RMI state, and
simplifies troubleshooting and control over high availability (HA) and RMI functionality by offering detailed diagnostics.

Key aspects

Gateway IP selection:

From Cisco IOS XE 17.2.1 onwards, the ip default-gateway gateway-ip command is deprecated for RMI gateway configuration.
The system automatically chooses a gateway IP by evaluating static routes and selecting the gateway that:
- matches the RMI subnet,
- uses the broadest subnet mask,
- and has the lowest IP address.
If no matching static route exists, gateway failover does not operate—even if management gateway-failover is enabled.

Refer to the Gateway statistics monitoring for gateway monitoring commands.

Airport's air traffic control system

Gateway monitoring works like an airport's air traffic control system. Instead of a pilot manually selecting a runway (like using the old ip default-gateway command), a central system automatically identifies the best runway based on current conditions (route matching, subnet mask, and lowest IP address). It then tracks the success or failure of each takeoff and landing (probe statistics and diagnostics), making sure the whole airport runs smoothly and efficiently while providing real-time updates and troubleshooting support when issues arise.

Configure gateway monitoring interval (CLI)

Set the interval at which the management gateway failover feature monitors gateway availability on a switch.

Adjusting the gateway monitoring interval determines how frequently the device checks gateway status to trigger failover if necessary. This procedure is performed using command-line interface (CLI) commands.

Before you begin

Ensure you have access to the device CLI in privileged EXEC mode.
Confirm that you have the required permissions to enter configuration mode and modify gateway monitoring settings.

Follow these steps to configure the gateway monitoring interval using the CLI:

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

management gateway-failover interval interval-value

Example:

Device(config)# management gateway-failover interval 6

Configures the gateway monitoring interval.

interval-value - Refers to the gateway monitoring interval. The valid range is from 6 to 12. Default value is 8.

Step 3

end

Example:

Device(config)# end

Saves the configuration and exits configuration mode and returns to privileged EXEC mode.

The system monitors the gateway at the specified interval. Your configuration is saved, and the device returns to privileged EXEC mode.

Configure gateway monitoring (CLI)

Enable and configure gateway monitoring on a device.

This task is typically performed to ensure that network devices can effectively monitor and manage gateway connections, facilitating smooth network operations and management. Gateway monitoring involves setting up a default gateway and enabling monitoring features.

Follow these steps to configure gateway monitoring (CLI):

Procedure

Step 1

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 2

[no] management gateway-failover enable

Example:

Device(config)# management gateway-failover enable

Enables gateway monitoring. (Use the no form of this command to disable gateway monitoring.)

Step 3

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

The gateway monitoring is enabled and configured, and the configuration changes are active.

What to do next

To save the configuration, use the write memory command.

Gateway Reachability Detection

Gateway reachability detection

Gateway reachability detection is a feature that

minimizes the downtime on APs and clients when the gateway reachability is lost on the active controller
enables both active and standby controllers to keep track of gateway reachability by sending Internet Control Message Protocol (ICMP) and ARP requests periodically to the gateway, and
detects gateway failures within approximately 8 seconds using consecutive failure monitoring.

Gateway reachability detection behavior

Both active and standby controllers use the RMI IP as the source IP. The messages are sent at 1 second interval. If it takes 8 (or configured value) consecutive failures in reaching the gateway, the controller declares the gateway as non-reachable. It takes approximately 8 seconds to detect if a controller has lost gateway reachability.

Gateway monitoring with native IPv6 uses ICMP Neighbor Discovery protocols and ICMPv6 ECHO to check gateway reachability.

Therefore, you can monitor only the IPv6 gateway when RMI IPv6 is configured.

This means that only one IPv4 or IPv6 gateways can be monitored.

Note

If the standby controller loses gateway, the standby moves to the standby recovery mode.

If the active controller loses gateway, the active reloads and standby becomes active.

Requirement: proper configuration of default gateway

To ensure the gateway reachability check functions correctly, configure the default gateway next hop in the same subnet as the WMI, which also serves the RMI.

If you configure the default gateway with a next hop IP address outside the WMI subnet, the controller does not send packets for the gateway reachability check. This configuration can cause failover or redundancy issues.

Configure system redundancy workflow

Summary

The key components involved in the configuration workflow are:

Redundancy Management Interface (RMI): Provides redundancy capabilities through GUI or CLI configuration
Controllers: Require reloading for RMI configuration to take effect
IPv6 Static Route: Enables network routing configuration
Gateway Monitoring Interval: Monitors gateway connectivity at specified intervals

Workflow

The configuration workflow involves these stages:

Configure Redundancy Management Interface using either GUI or CLI method For more information, see Configure redundancy management interface (GUI).

Note

For RMI configuration to take effect, ensure that you reload your controllers.

Configure IPv6 Static Route to establish network routing For information, see Gateway monitoring.
Configure Gateway Monitoring Interval using CLI to set monitoring parameters For more information, see Configure gateway monitoring interval (CLI).

Migrate to RMI IPv6

You can migrate to RMI IPv6 from two different configurations: from RMI IPv4 or from HA pairing without RMI. The migration process varies depending on your current configuration.

Before you begin

Follow these steps to migrate to RMI IPv6:

Procedure

Determine your current configuration and follow the appropriate migration path.

If migrating from RMI IPv4, continue with the following substeps:

Unconfigure the RMI IPv4 using the following CLIs:


Device# conf t
Device(config)# no redun-management interface <vlan_name> chassis 1 address <ip_address1> chassis 2 address <ip_address2>

Note

This CLI unconfigures RMI on both the controllers.

Note

Take a backup of the running config on active before you reload the controller.

Reload the controller.

Copy the backed up config to the running config on the box which would have lost all the config.
Configure the RMI IPv6 on both the controllers.
Reload the controller.

If migrating from HA Pairing (without RMI), for information on HA pairing, see Configuring Redundancy Management Interface (GUI).

Standby monitoring

Standby monitoring is a system health feature that

monitors the health of a system on a standby controller using programmatic interfaces and commands
allows monitoring of parameters such as CPU, memory, interface status, power supply, fan failure, and the system temperature
is enabled when Redundancy Management Interface (RMI) is configured, and
cannot be dynamically enabled or disabled.

Requirements and configuration

Standby Monitoring is enabled when Redundancy Management Interface (RMI) is configured, no other configuration is required. The RMI itself is used to connect to the standby and perform standby monitoring.

Note

The active controller uses the management or RMI IP to initiate AAA requests. Whereas, the standby controller uses the RMI IP to initiate AAA requests. Thus, the RMI IPs must be added in AAA servers for a seamless client authentication and standby monitoring.

To enable standby console, ensure that the following configuration is in place:

redundancy
main-cpu
secondary console enable

Note

The Standby Monitoring feature is not supported on a controller in the active-recovery and the standby-recovery modes.

The Standby Monitoring feature supports only the following traffic on the RMI interface of the standby controller:

Address Resolution Protocol (ARP)
Internet Control Message Protocol (ICMP)
TCP Traffic (to or from) ports: 22, 443, 830, and 3200
UDP RADIUS ports:1645 and1646
UDP Extended RADIUS ports: 21645 to 21844

Feature scenarios include:

Monitoring the health of the standby directly from the standby controller using Standby RMI IP
Getting syslogs from the standby controller using the Standby RMI IP

Use cases include:

Enabling SNMP agent and programmatic interfaces on the standby controller: You can directly perform an SNMP query or programmatic interface query to the standby's RMI IP and active controller
Enabling syslogs on the standby controller: You can directly get the standby syslogs from the standby controller

RADIUS accounting support:

TACACS+ authentication support:

TACACS+ accounting support:

Note

This configuration must be in place to configure AAA to send the accounting packets:

aaa accounting exec {default | named-list} start-stop group {RAD | tac-group-name}

Note

The TACACS+ login to the standby device is not supported when TACACS+ server is configured with hostname.

Monitoring the Health of Standby Parameters Using SNMP

Standby monitoring using standby RMI IP

Standby monitoring using standby RMI IP is a network management capability that

enables direct SNMP queries to the standby controller's RMI IP address
supports IF-MIB monitoring for interface statistics on standby controllers from Release 17.5 onwards, and
automatically enables SNMP on the standby controller when SNMP agent is enabled on the active controller.

Supported mibs and monitoring capabilities

When an SNMP agent is enabled on the standby controller, you can directly perform an SNMP query to the standby's RMI IP. From Release 17.5 onwards, you can query the following MIB on the standby controller:

Table 4. MIB name and notes
MIB Name	Notes
IF-MIB	This MIB is used to monitor the interface statistics of the standby controller using the standby RMI IP address.

Note

If an SNMP agent is enabled on the active controller, by default, the SNMP is enabled on the standby controller.

Standby monitoring using the active controller

Monitor the health parameters of the standby controller, including memory, CPU, port status, power statistics, and peer gateway latencies, using various MIB objects through the active controller.

CISCO-LWAPP-HA-MIB

The CISCO-LWAPP-HA-MIB monitors the health parameters of the standby controller, that is, memory, CPU, port status, power statistics, peer gateway latencies, and so on.

You can query these MIB objects of CISCO-LWAPP-HA-MIB.

Table 5. MIB objects and notes
MIB Objects	Notes
cLHaPeerHotStandbyEvent	This object can be used to check if the standby controller has turned hot-standby or not.
cLHaBulkSyncCompleteEvent	This object represents the time at which the bulksync is completed.

CISCO-PROCESS-MIB

The CISCO-PROCESS-MIB monitors CPU and process statistics. Use it to monitor CPU-related or memory-related BINOS processes. The standby CISCO-PROCESS-MIB can be monitored using the active controller.

ENTITY-MIB

The ENTITY-MIB is used to monitor hardware details of the active and standby controllers using the active controller.

Note

The standby Route Processor (RP) sensors are appended in the active RP sensors.

Standby IOS linux syslogs

Standby IOS Linux syslogs are a logging mechanism that

relay logs using the same method as on the active Cisco IOS for wireless controllers
enable external logging from the standby IOS starting from Release 17.5 onwards, and
forward all syslogs generated on the standby controller to the configured external server through BINOS processes.

Standby syslog behavior

From Release 17.5 onwards, external logging of syslogs from the standby IOS is enabled. As BINOS processes on standby also forwards the syslogs to Cisco IOS, all the syslogs generated on the standby controller is forwarded to the configured external server.

Note

RMI IP address is used for logging purpose.

The standby controller tries to send syslogs to the IPv4 server because logging is only configured on IPv4 even though IPv4 is not supported by standby. This is the expected behavior when an HA pair is configured with the RMI IPv6 address, the active controller has dual stack, and logging is configured on the IPv4 address

Standby controller health monitoring using programmatic interfaces

You can monitor parameters such as CPU, memory, sensors, and interface status on a standby controller using programmatic interfaces such as NETCONF and RESTCONF. The RMI IP of the standby controller can be used for access to the following operational models:

The models can be accessed through:

Cisco-IOS-XE-device-hardware-oper.yang
Cisco-IOS-XE-process-cpu-oper.yang
Cisco-IOS-XE-platform-software-oper.yang
Cisco-IOS-XE-process-memory-oper.yang
Cisco-IOS-XE-interfaces-oper.yang

For more information on the YANG models, see the Programmability Configuration Guide, Cisco IOS XE 17.3.x.

Standby controller health monitoring (CLI)

This section describes the different commands that can be used to monitor the standby device.

You can connect to the standby controller through SSH using the RMI IP of the standby controller. The user credentials must have been configured already. Both local authentication and RADIUS authentication are supported.

Note

The redun-management command needs to be configured on both the controllers, primary and standby, prior to high availability (HA) pairing.

Port state monitoring

This is a sample output of the show interfaces interface-name command:

Device-standby# show interfaces GigabitEthernet1        

GigabitEthernet1 is down, line protocol is down                                 
Shadow state is up, true line protocol is up
  Hardware is CSR vNIC, address is 000c.2909.33c2 (bia 000c.2909.33c2)
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full Duplex, 1000Mbps, link type is force-up, media type is Virtual
  output flow-control is unsupported, input flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:06, output 00:00:24, output hang never
  Last clearing of "show interface" counters never
  Input queue: 30/375/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 389000 bits/sec, 410 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     3696382 packets input, 392617128 bytes, 0 no buffer
     Received 0 broadcasts (0 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 0 multicast, 0 pause input
     18832 packets output, 1218862 bytes, 0 underruns
     Output 0 broadcasts (0 multicasts)
     0 output errors, 0 collisions, 2 interface resets
     3 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

This is a sample output of the show ip interface brief command:

Device# show ip interface brief

Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet1       unassigned      YES unset  down                  down    
GigabitEthernet0       unassigned      YES NVRAM  administratively down down    
Capwap1                unassigned      YES unset  up                    up      
Capwap2                unassigned      YES unset  up                    up      
Capwap3                unassigned      YES unset  up                    up           
Capwap10               unassigned      YES unset  up                    up      
Vlan1                  unassigned      YES NVRAM  down                  down    
Vlan56                 unassigned      YES unset  down                  down    
Vlan111                111.1.1.85      YES NVRAM  up                    up

CPU or memory monitoring

This is a sample output of the show process cpu sorted 5sec command:

Device-standby# show process cpu sorted 5sec

CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0%
 PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process 
  10     1576556      281188       5606  0.15%  0.05%  0.05%   0 Check heaps      
 232      845057    54261160         15  0.07%  0.05%  0.06%   0 IPAM Manager     
 595         177         300        590  0.07%  0.02%  0.01%   2 Virtual Exec     
 138     1685973   108085955         15  0.07%  0.08%  0.08%   0 L2 LISP Punt Pro 
 193       19644      348767         56  0.07%  0.00%  0.00%   0 DTP Protocol     
   5           0           1          0  0.00%  0.00%  0.00%   0 CTS SGACL db cor 
   4          24          15       1600  0.00%  0.00%  0.00%   0 RF Slave Main Th 
   6           0           1          0  0.00%  0.00%  0.00%   0 Retransmission o 
   7           0           1          0  0.00%  0.00%  0.00%   0 IPC ISSU Dispatc 
   2      117631      348801        337  0.00%  0.00%  0.00%   0 Load Meter       
   8           0           1          0  0.00%  0.00%  0.00%   0 EDDRI_MAIN

To check CPU and memory utilization of binOS processes, run this command:

Device-standby# show platform software process slot chassis standby R0 monitor 

top - 23:24:14 up 8 days, 3:38, 0 users, load average: 0.69, 0.79, 0.81 
Tasks: 433 total, 1 running, 431 sleeping, 1 stopped, 0 zombie 
%Cpu(s): 1.7 us, 2.8 sy, 0.0 ni, 95.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 32059.2 total, 21953.7 free, 4896.8 used, 5208.6 buff/cache 
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 26304.6 avail Mem 

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23565 root 20 0 2347004829924 100840 S 6.7 2.5 550:29 btrace_rotator
23595 root 20 0 1820072 334636 100840 S 3.3 1.0 179:05 wcm
23597 root 20 0 1820072 334636 100840 S 3.3 1.0 179:03 wcm
23599 root 20 0 1820072 334636 100840 S 3.3 1.0 179:04 wcm
23601 root 20 0 1820072 334636 100840 S 3.3 1.0 179:05 wcm
23603 root 20 0 1820072 334636 100840 S 3.3 1.0 179:04 wcm

To check the environment temperature and fan status, run this command:

Device-standby# show environment summary

 Switch   FAN               FAN               POWER SUPPLY      POWER SUPPLY
          (Intake)          (Exhaust)         1                 2            
--------- ----------------- ----------------- ----------------- -----------------
 R0       Normal            Normal            Normal            Normal           

 Switch   Inlet Temp (C)    Outlet Temp (C)
--------- ----------------- -----------------
 R0       22                28               

 R0          Stby Temp: DDC INormal          22   Celsius	(55 ,65 ,75 ,80 )(Celsius)
 R0          Stby Temp: DDC ONormal          28   Celsius	(75 ,85 ,95 ,100)(Celsius)

Note

The command displays both active and standby hardware details.

Note

The show environment summary command displays data only for physical appliances such as Cisco Catalyst 9800-80 Wireless Controller, Cisco Catalyst 9800-40 Wireless Controller, Cisco Catalyst 9800-L Wireless Controller, and Cisco Catalyst 9800 Embedded Wireless Controller for Switch. The command does not display data for Cisco Catalyst 9800 Wireless Controller for Cloud.

Gateway-monitoring configuration verification

Verify the status of the gateway-monitoring configuration on active and standby controllers using specific show commands.

To verify the status of the gateway-monitoring configuration on an active controller, run this command:

Device# show redundancy states

my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Primary
Unit ID = 1

Redundancy Mode (Operational) = sso
Redundancy Mode (Configured) = sso
Redundancy State = sso
Maintenance Mode = Disabled
Manual Swact = enabled
Communications = Up

client count = 129
client_notification_TMR = 30000 milliseconds
RF debug mask = 0x0
Gateway Monitoring = Disabled
Gateway monitoring interval = 8 secs

To verify the status of the gateway-monitoring configuration on a standby controller, run this command:

Device-stby# show redundancy states

my state = 8 -STANDBY HOT
peer state = 13 -ACTIVE
Mode = Duplex
Unit = Primary
Unit ID = 2

Redundancy Mode (Operational) = sso
Redundancy Mode (Configured) = sso
Redundancy State = sso
Maintenance Mode = Disabled
Manual Swact = cannot be initiated from this the standby unit
Communications = Up

client count = 129
client_notification_TMR = 30000 milliseconds
RF debug mask = 0x0
Gateway Monitoring = Disabled
Gateway monitoring interval = 8 secs

RMI IPv4 configuration verification

Verify the RMI IPv4 configuration.

Device# show running-config interface vlan management-vlan

Building configuration...

Current configuration : 109 bytes
!
interface Vlan90
ip address 9.10.90.147 255.255.255.0 secondary
ip address 9.10.90.41 255.255.255.0
end

To verify the interface configuration for a standby controller, use this command:

Device-stby# show running-config interface vlan 90

Building configuration...
 
Current configuration : 62 bytes
!
interface Vlan90
ip address 9.10.90.149 255.255.255.0
end

To verify the chassis redundancy management interface configuration for an active controller, use this command:

Device# show chassis rmi

Chassis/Stack Mac Address : 000c.2964.1eb6 - Local Mac Address
Mac persistency wait time: Indefinite
			H/W Current
Chassis# Role      Mac Address     Priority  Version  State  IP             RMI-IP
--------------------------------------------------------------------------------------------------------
*1       Active    000c.2964.1eb6  1         V02      Ready  169.254.90.147 9.10.90.147
2        Standby   000c.2975.3aa6  1         V02      Ready  169.254.90.149 9.10.90.149

To verify the chassis redundancy management interface configuration for a standby controller, use this command:

Device-stby# show chassis rmi

Chassis/Stack Mac Address : 000c.2964.1eb6 - Local Mac Address
Mac persistency wait time: Indefinite
                                             H/W   Current
Chassis#   Role    Mac Address     Priority Version  State  IP              RMI-IP
------------------------------------------------------------------------------------------------
1         Active   000c.2964.1eb6     1      V02     Ready  169.254.90.147  9.10.90.147
*2        Standby  000c.2975.3aa6     1      V02     Ready  169.254.90.149  9.10.90.149

To verify the ROMMON variables on an active controller, use this command:

Device# show romvar | include RMI

RMI_INTERFACE_NAME = Vlan90
RMI_CHASSIS_LOCAL_IP = 9.10.90.147
RMI_CHASSIS_REMOTE_IP = 9.10.90.149

To verify the ROMMON variables on a standby controller, use this command:

Device-stby# show romvar | include RMI

RMI_INTERFACE_NAME = Vlan90
RMI_CHASSIS_LOCAL_IP = 9.10.90.149
RMI_CHASSIS_REMOTE_IP = 9.10.90.147

To verify the switchover reason, use this command:

Device# show redundancy switchover history

Index  Previous  Current  Switchover             Switchover
       active    active   reason                 time
-----  --------  -------  ----------             ----------
   1       2        1     Active lost GW         17:02:29 UTC Mon Feb 3 2020

RMI IPv6 configuration verification

Verify the RMI IPv6 configuration.

To verify the chassis redundancy management interface configuration for both active and standby controllers, run this command:

Device# show chassis rmi

Chassis/Stack Mac Address : 00a3.8e23.a540 - Local Mac Address
Mac persistency wait time: Indefinite
Local Redundancy Port Type: Twisted Pair
                                             H/W   Current
Chassis#   Role     Mac Address    Priority Version State     IP             RMI-IP
---------------------------------------------------------------------------------------------
  1        Standby  706d.1536.23c0    1      V02     Ready  169.254.254.17   2020:0:0:1::211
 *2        Active   00a3.8e23.a540    1      V02     Ready  169.254.254.18   2020:0:0:1::212

To verify the RMI related ROMMON variables for both active and standby controllers, run this command

Device# show romvar | i RMI

RMI_INTERFACE_NAME = Vlan52
RMI_CHASSIS_LOCAL_IPV6 = 2020:0:0:1::212
RMI_CHASSIS_REMOTE_IPV6 = 2020:0:0:1::211

Redundancy management interfaces

A redundancy management interface is a network interface that

acts as a secondary link between active and standby wireless controllers,
enables resource health information exchange (such as gateway reachability), and
assists in the detection of dual-active controller conditions to maintain high availability.

The RMI might trigger a switchover based on the gateway status of the active controller.

Subdefinitions:

Active controller: Uses the management IP as the primary address and RMI as the secondary IPv4 address on the management VLAN. RMI configuration is automatic.

Analogy: Like a city’s current mayor who’s in charge, but always ready to hand over leadership if needed.
Standby controller: Has the RMI IP as the primary address; upon switchover, roles and addresses are swapped.

Analogy: Like a vice-mayor who takes the mayor’s seat (with all responsibilities and keys) when the mayor is away.
RP (Redundancy Port): The main dedicated physical link for state and configuration synchronization between active and standby controllers; loss of both RP and RMI links results in high availability (HA) failures.

(Analogy: Like the main road connecting two city offices, critical for daily business and coordination).
WMI (Wireless Management Interface): The main management interface for controller operations and communications; shares its subnet with the RMI and may serve as a source address for certain types of traffic such as AAA packets.

Analogy: Like a city’s public headquarters, used for both regular operations and official correspondence.
RMI (Redundancy Management Interface): A dedicated network interface that serves as a secondary communication path between controllers for exchanging resource health information, detecting dual-active conditions, and monitoring gateway reachability; shares the same subnet as the Wireless Management Interface (WMI).

Analogy: Like an emergency side road connecting two city halls, used for urgent official communication.
HA (High Availability): A deployment setup where controllers operate as an active-standby pair to ensure uninterrupted wireless services; relies on RP and RMI links for failover and role management.
ARP table: A database on a network device such as a switch that maintains mappings between IP addresses and MAC addresses; determines how to forward traffic within the local network.

(Analogy: Like a city map book held by delivery drivers in neighboring towns, showing them which mayor is at which city hall, so the right deliveries go to the right address.)
GARP (Gratuitous ARP): A type of ARP (Address Resolution Protocol) packet broadcast by a controller, typically after a switchover, to update the ARP tables in connected network switches with the correct IP-to-MAC address mappings.

(Analogy: Like sending out an urgent memo to all nearby towns, telling them who the new mayor is so they update their city maps immediately after a leadership change.)
ARP cache timeout: The duration for which an entry in the ARP table is considered valid before it must be refreshed; reducing this value helps the network recover quickly after role or address changes in the controllers.

(Analogy: Like setting a regular schedule for when all delivery drivers check for updates to the city map books, ensuring they quickly recognize changes in city leadership or addresses.)
SGACL (Security Group Access Control List): A policy configuration that determines which types of network traffic (e.g., ICMP, ARP) are permitted between specific interfaces or devices, such as the RMI addresses of controllers.

(Analogy: Like special city rules that decide which types of emergency vehicles are allowed to travel the emergency road between city halls.)
ICMP (Internet Control Message Protocol): A network protocol used for sending error messages and operational information between network devices; essential for controllers to monitor each other’s status over the RMI.

(Analogy: Like sending quick bike couriers to report on the status of the roads or to alert if there’s trouble between cities.)
AAA (Authentication, Authorization, and Accounting): A framework for controlling user access to network resources and tracking user activity; controllers may send AAA-related packets from either the WMI IP or the RMI IP, so the AAA server must recognize both as valid.

(Analogy: Like having a security checkpoint that logs who enters or exits city buildings, whether they come from Main Street (WMI) or the emergency road (RMI).)
SGT (Security Group Tag): An identification label assigned to network devices for policy enforcement with Cisco TrustSec; mapping is applied for both RMI and WMI addresses when device SGTs are used.

Analogy: Like giving every city vehicle a badge, so officials can enforce special rules for each group whether they use Main Street or the emergency road.
Cisco TrustSec: A security architecture that uses SGTs to enforce network segmentation and access control policies; not supported on the RMI interface.

Analogy: Like a city’s security zone system—effective on main city roads, but not supported on the emergency side road.

Limitations for RMI

Cisco TrustSec is not supported on the RMI.

Best practices for RMI

Ensure that the SGACL is defined appropriately to allow ICMP and ARP traffic between the active and standby RMI addresses when device SGT is used, since the IP-SGT mapping applies to both the RMI and WMI addresses.
Configure the AAA server to recognize both the WMI IP and the RMI IP as valid source addresses, because AAA packets from the controller may originate from either.

Important: gateway monitoring interval and detection time

When gateway reachability is enabled, both the active and standby controllers check gateway status through the RMI interface.
It takes approximately the configured gateway monitoring interval to detect when a controller has lost gateway reachability.
The default gateway monitoring interval is eight seconds, so the minimum detection time is about eight seconds unless you configure a different value.

Recommendation: set ARP cache timeout to ensure fast HA recovery:

When both the RP and RMI links are down, the HA setup breaks and both controllers become active, causing an IP conflict in the network. The HA setup is restored once the RP link is up. Depending on the external switch, its ARP table may correctly update to the new active controller or remain stale if the switch ignores GARP packets, potentially prolonging the conflict.

We recommend setting the ARP cache timeout to a low value. This practice enables faster recovery from multiple fault scenarios.

You should choose a timeout value that does not negatively affect network traffic. For example, 30 minutes is a suitable interval.

Analogy

Think of redundancy management interfaces (RMI) as an emergency backup road that connects two cities (the active and standby controllers). The main highway (the redundancy port, RP) handles most of the day-to-day traffic and coordination. If the main highway is blocked or damaged, the emergency road (RMI) ensures that vital information—such as each city's health, status, and road conditions—can still be exchanged quickly.

Just as emergency vehicles and communication must be allowed to travel the backup road (analogous to allowing ICMP and ARP traffic via SGACL), the RMI helps both cities detect if both try to take charge at the same time (dual-active condition) and exchange important information about the area's main gateway (gateway status). If both the highway and the emergency road are inaccessible, each city might assume it’s in charge, resulting in confusion (an IP conflict). The ARP table is like city maps in other towns (switches) that may not immediately recognize which city is currently in charge after both reconnect—setting these maps to update frequently (low ARP cache timeout) allows for faster recovery from major outages.

Controller operations with Redundant Management Interface

A controller operation with redundant management interface is a high-availability configuration that

assigns the management IP address as the primary address on the active controller
uses the secondary IPv4 address on the management VLAN as the RMI IP address for the active controller, and
configures the RMI IP address as the primary IP address on the standby controller.

IP address assignment in controller operations

The active controller assigns IP addresses as follows:

The primary address is the management IP address.
The secondary IPv4 address on the management VLAN is the RMI (Redundant Management Interface) IP address for the active controller.

The standby controller manages IP addresses in a high-availability setup as follows:

It does not have the wireless management IP configured.
The RMI IP address is configured as the primary IP address on the standby controller.
When the standby controller becomes active, the management IP address becomes the primary IP address, and the RMI IP address becomes the secondary IP address.
If the interface on the active controller is administratively down, the same state is reflected on the standby controller.

Note

Do not configure the secondary IPv4 address explicitly. RMI automatically configures a single secondary IPv4 address under the RMI.

Dual stack configurations on management vlans with RMI

A dual stack configuration is a network interface setup that

allows both IPv4 and IPv6 addresses to be configured on the wireless management interface,
permits monitoring only of the gateway that matches the configured RMI address family (IPv4 or IPv6), and
restricts the visibility of the alternate family’s management address on the standby controller.

Expanded explanation

Dual stack refers to the fact that the wireless management interface can be configured with IPv4 and IPv6 addresses. If an RMI IPv4 address is configured along with an IPv4 management IP address, you can additionally configure an IPv6 management address on the wireless management interface. This IPv6 management IP address will not be visible on the standby controller.
If an RMI IPv6 address is configured along with an IPv6 management IP address, you can additionally configure an IPv4 management address on the wireless management interface. This IPv4 management IP address will not be visible on the standby controller.
Therefore, you can monitor only the IPv6 gateway when the RMI IPv6 address is configured, or only the IPv4 gateway when the RMI IPv4 address is configured.

Note

The RMI feature supports the RMI IPv4 or IPv6 addresses.

RMI-based high-availability pairings

A RMI-based high-availability pair is a controller deployment configuration that

uses Remote Machine Interface (RMI) to synchronize two controllers,
provides redundancy by designating active and standby roles, and
ensures failover and persistent state during controller reloads or outages.

RMI-based high-availability pairing scenarios and device support

You should consider RMI-based high-availability pairs in the following scenarios:

Fresh installation: Configure high availability during the initial setup of controllers.
Already paired controllers: Adjust or reconfigure pairing for controllers that are already part of a high-availability pair.
Upgrade scenario: Maintain or update the pair relationship during software or hardware upgrades.
Downgrade scenario: Ensure pairing remains stable and functional during downgrades.

Dynamic high-availability (HA) pairing requires both the active and standby controllers to reload. In practice, on the Cisco Catalyst 9800-L, 9800-40, and 9800-80 Wireless Controllers, dynamic pairing occurs when one controller reloads and becomes the standby member of the pair.

Note

Unique chassis numbers must be configured for each controller before forming an HA pair, as these numbers identify the controllers within the pair.

HA pairing without previous configuration

A high-availability (HA) pairing without previous configuration is a deployment scenario for wireless controllers that

initiates the HA setup on devices without existing ROMMON variables for RP (Route Processor) IP addresses
allows selection between the soon-to-be-deprecated privileged EXEC mode RP-based commands and the newer RMI IP-based mechanisms, and
derives RP IPs from RMI IPs after forming the HA pair, with restrictions on method transitions.

Command usage and method selection

When HA pairing is performed for the first time (without previous setup), devices do not have ROMMON variables for RP IP addresses.

After RMI-based HA pairing on a brand-new system:

RP IPs are derived from RMI IPs and used in HA pairing.
Privileged EXEC mode RP-based CLIs method of clearing and forming an HA pair is not allowed.
To view the ROMMON variables, use the show romvars command.

Method selection considerations:

You can still choose from the existing privileged EXEC mode RP-based commands or the RMI IP-based mechanisms. However, the privileged EXEC mode RP-based commands are deprecated.
If you use Cisco Catalyst Center, you can choose the privileged EXEC mode RP-based CLI mechanism till the Cisco Catalyst Center migrates to support the RMI.
If you choose privileged EXEC RP-based CLI mechanism, the RP IPs are configured the same way as in the 16.12 release.

Use the RMI IP-based mechanism for fresh installations, even though both RP-based and RMI methods may initially be available.

Software version requirements:

The RMI migration is supported from Cisco Catalyst Center, 2.3.3.x release version.
RMI-based High Availability requires Cisco IOS XE release version 17.3 or above.

Cisco Catalyst Center interoperability:

If you use Cisco Catalyst Center, you can choose the privileged EXEC mode RP-based CLI mechanism till the Cisco Catalyst Center migrates to support the RMI.
The RMI migration is supported from Cisco Catalyst Center, 2.3.3.x release version.

Devices are not reachable.
Non-Cisco Catalyst 9800 Series Wireless Controllers are in use.
Controller is running Cisco IOS XE 17.3 or below
High Availability is not configured.
High Availability RMI is already configured.
Attempting upgrade to an already failed High Availability paired controller.

Paired controllers

A paired controller is a high availability (HA) infrastructure configuration that

links two controllers to operate jointly for redundancy and failover,
allows seamless migration from traditional EXEC mode RP-based commands to RMI-based HA pairing, and
ensures controller identity and connectivity are maintained even when core pairing mechanisms are updated or reloaded.

Expanded explanation

When controllers are already in an HA pair, they continue to use existing EXEC mode RP-based commands unless Remote Management Interface (RMI) is enabled. Enabling RMI migrates the system to use RMI-derived HA pairing, overwriting any existing RP IPs with those derived from the RMI configuration. The HA pair remains stable immediately after this change, but the controllers only adopt the new IPs following their next reload.

RMI requires controllers to be reloaded for the changes to take effect. Once both controllers restart, they reestablish the HA pair using the new RMI-derived RP IPs. After pairing through RMI, EXEC mode RP-based commands are blocked, preventing configuration conflicts.

Examples

Two controllers configured as a high availability pair, where enabling RMI changes the way their active-standby relationship is managed and what IPs are used for internal communication.
An active and standby controller pair that continues functioning during migration from legacy RP-IP pairing to RMI, without disruption until reload.

Counter-examples

Two standalone controllers operating independently without HA pairing cannot be considered paired controllers.
A controller pair where RMI is never configured and all management remains through EXEC mode RP-based commands does not benefit from RMI-derived features.

Analogy

Imagine a paired controller setup as two co-pilots flying an airplane together (the airplane represents your network environment). Traditionally, they use walkie-talkies (EXEC mode RP-based commands) to coordinate their flying activities. If you upgrade their communication system to headsets (RMI-based pairing), the co-pilots continue flying the plane using walkie-talkies until they both put on the new headsets (after a "reload" or restart).

From that point onward, all their coordination happens via the more reliable and advanced headsets. The co-pilots' ability to work together—their partnership—remains unbroken throughout; it is only how they communicate and identify each other's messages that changes, and only becomes effective after both are using the new headsets.

Upgrade from Cisco IOS XE 16.1.x to a later release

When upgrading a system, you have these options:

Migrate while retaining the existing RP IP configuration: In this scenario, the current RP IP configuration remains unchanged, and future modifications will utilize EXEC mode RP-based commands.
Migrate after clearing the HA configuration: Here, you have the choice to use either the traditional EXEC mode RP-based commands or adopt the new RMI-based RP configuration. If the previous configuration is preserved, RMI will update the RP IPs with those derived from the RMI IPs.

Downgrade scenario

Important

The downgrade scenario given below is not applicable for Cisco IOS XE 17.1.x.

In a downgrade scenario, only EXEC mode RP-based commands are available. The downgrade process may follow one of these paths:

If the upgraded system used the RMI-based RP configuration.
If the upgraded system continued to use the EXEC mode RP-based commands.

In the above cases, the downgraded system uses the EXEC mode RP-based commands to modify the configuration. However, the downgraded system will continue to use the new derived RP IPs.

In both of these cases, the system will revert to EXEC mode RP-based commands for configuration alterations, yet will still utilize the newly derived RP IPs.

Note

When you downgrade the Cisco Catalyst 9800 Series Wireless Controller to any version below Cisco IOS XE 17.1 and if the mDNS gateway is enabled on the WLAN/RLAN/GLAN interfaces, the mdns-sd-interface gateway goes down after the downgrade.

To enable the mDNS gateway on the WLAN/RLAN/GLAN interfaces in Cisco IOS XE 16.12 and earlier versions, use these commands:

wlan test 1 test

mdns-sd gateway

To enable the mDNS gateway on the WLAN/RLAN/GLAN interfaces from version Cisco IOS XE 17.1 onwards, use these command:

mdns-sd-interface gateway

Configure redundancy management interface (GUI)

Enable redundancy management for Cisco Catalyst 9800 Series Wireless Controllers using the graphical user interface (GUI).

Use this task to configure the redundancy management interface (RMI) and set up either RMI+RP or RP redundancy pairing on Cisco Catalyst 9800 Series Wireless Controllers. Configuring redundancy improves system availability and failover capabilities.

Before you begin

Ensure that Wireless Management Interface (WMI) is available before configuring RMI + RP using the GUI.

Follow these steps to configure redundancy management interface using GUI:

Procedure

Step 1

In the Administration > Device > Redundancy window, perform the following:

Set the Redundancy Configuration toggle button to Enabled to activate redundancy configuration.
In the Redundancy Pairing Type field, select RMI+RP to perform RMI+RP redundancy pairing as follows:
- In the RMI IP for Chassis 1 field, enter the RMI IP address for chassis 1.
- In the RMI IP for Chassis 2 field, enter the RMI IP address for chassis 2.
- From the HA Interface drop-down list, choose one of the HA interfaces.
  
  You can select the HA interface only for Cisco Catalyst 9800 Series Wireless Controllers.
- Set the Management Gateway Failover toggle button to Enabled to activate management gateway failover.
- In the Gateway Failure Interval field, enter an appropriate value. The valid range is 6–12 seconds (default 8 seconds).
In the Redundancy Pairing Type field, select RP to perform RP redundancy pairing as follows:
- In the Local IP field, enter an IP address for the local chassis.
- In the Netmask field, enter the subnet mask assigned to all wireless clients.
- From the HA Interface drop-down list, choose one of the HA interfaces.
  
  You can select the HA interface only for Cisco Catalyst 9800 Series Wireless Controllers.
- In the Remote IP field, enter an IP address for the remote chassis.
In the Keep Alive Timer field, enter an appropriate timer value (1–10 ×100 milliseconds).
In the Keep Alive Retries field, enter an appropriate retry value (3–10 seconds).
In the Active Chassis Priority field, enter a value.

Step 2

Click Apply and reload controllers.

The redundancy management interface is configured, and redundancy pairing is established based on your chosen method. The controller is now set up for improved high availability and failover.

Configure redundancy management interface (CLI)

Configure a Redundancy Management Interface (RMI) on Cisco Catalyst 9800 controllers using CLI commands to support high availability (HA) between two devices.

Use this task when you want to set up high availability and redundancy between two Catalyst 9800 series controllers. The RMI coordinates HA communication and failover, ensuring service continuity in case of device failure.

Before you begin

Ensure both controllers are cabled and powered on.
Verify you have administrator access to both devices via CLI.
Gather the following information:
- Chassis number (1 or 2 for each controller)
- Desired chassis priority for HA (if overriding default)
- A dedicated GigabitEthernet interface for HA communication (required for 9800-CL controllers)
- Management VLAN and corresponding IP addresses for each chassis

Procedure

Step 1	(Optional) Configure the priority of the specified device. Example: `Device# chassis chassis-num priority chassis-priority` Example: `Device# chassis 1 priority 1` From Cisco IOS XE Gibraltar 16.12.x onwards, device reload is not required for the chassis priority to become effective. chassis-num—Enter the chassis number. The range is from 1 to 2. chassis-priority—Enter the chassis priority. The range is from 1 to 2. The default value is 1. When both the devices boot up at the same time, the device with higher priority becomes active, and the other one becomes standby. If both the devices are configured with the same priority value, the one with the smaller MAC address acts as active and its peer acts as standby.
Step 2	Create an HA interface for your controller. Example: `Device# chassis redundancy ha-interface GigabitEthernet interface-number` Example: `Device# chassis redundancy ha-interface GigabitEthernet 3` interface-number: GigabitEthernet interface number. The range is from 1 to 32. This step is applicable only for Cisco Catalyst 9800-CL Series Wireless Controllers. The chosen interface is used as the dedicated interface for HA communication between the 2 controllers.
Step 3	Enter global configuration mode. Example: `Device# configure terminal`
Step 4	Configure Redundancy Management Interface. Example: `Device(config)# redun-management interface vlan vlan-interface-number chassis chassis-number address ip-address chassis chassis-number address ip-address` Example: `Device(config)# redun-management interface Vlan 200 chassis 1 address 9.10.90.147 chassis 2 address 9.10.90.149` vlan-interface-number: VLAN interface number. The valid range is from 1 to 4094. Here, the vlan-interface-number is the same VLAN as the Management VLAN. That is, both must be on the same subnet. chassis-number: Chassis number. The valid range is from 1 to 2. ip-address: Redundancy Management Interface IP address. 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. To disable the HA pair, use the no redun-management interface vlan chassis command.
Step 5	Return to privileged EXEC mode. Example: `Device(config)# end`
Step 6	Save the configuration. Example: `Device# write memory`
Step 7	Reload the controllers. Example: `Device# reload` When the RMI configuration is done, you must reload the controllers for the configuration to take effect. For Cisco Catalyst 9800-CL Wireless Controller VM, both the active and standby controllers reload automatically. In the case of hardware platforms, you should reload the active controller manually, as only standby the controller reloads automatically.

The redundancy management interface is configured. After reload, an HA pair is established between the two controllers, enabling redundancy and failover support.

Auto-upgrade feature

The Auto-Upgrade feature is a wireless controller capability that

enables the standby controller to upgrade with the software image of the active controller
allows both controllers to form an HA pair, and
supports the active controller in INSTALL mode.

Auto-upgrade feature requirements

The Auto-Upgrade feature has the following requirements:

This feature supports the active controller in INSTALL mode.
This feature supports Cisco Catalyst 9800 Series Wireless Controller software versions 17.5.1 and later.
This feature is triggered in the standby controller only when the active image is in committed state.

Auto-upgrade use cases

Auto-upgrade use cases are scenarios that

handle software version mismatches during upgrades by copying packages between redundancy ports
support HA pair deployments where controllers may have different versions, and
manage SMU installations when standby controllers come online after being offline.

Auto-upgrade functionality details

The following are the use cases and functionalities supported by the Auto-Upgrade feature:

Handling software version mismatch: During an upgrade, if one of the redundancy port is upgraded to a newer version, and the other one is not upgraded at the same time, the active port tries to copy its packages to the other port using the Auto-Upgrade feature. You can enable Auto-Upgrade in this situation using configuration or by manually running the software auto-upgrade enable privileged EXEC command.

The auto-upgrade configuration is enabled by default.

Note

Auto-upgrade upgrades the mismatched redundancy port only when both the active redundancy port and the mismatched redundancy port are in INSTALL mode.

HA pair: If one of the controller is not upgraded successfully, use Auto-Upgrade to upgrade the controller on the newly deployed HA pair, which can each be a different version.
SMUs (APSP, APDP, and so on): If the SMUs that are successfully installed on the active controller when the standby controller was offline. In this scenario, when the standby controller comes up online, the Auto-Upgrade copies this SMU to the standby controller and installs it.

Configuration workflow

Configure auto-upgrade (CLI)

Enable the Auto-Upgrade feature to automatically upgrade software when new versions become available.

The Auto-Upgrade feature is enabled by default but can be disabled. When disabled, manual upgrades must be performed using the install autoupgrade command.

Procedure

Step 1

Enter global configuration mode.

Example:

Device# configure terminal

Step 2

Enable the Auto-Upgrade feature.

Example:

Device(config)# software auto-upgrade enable

This feature is enabled by default.

If you disable this feature using the no form of this command, you need to manually auto upgrade using the install autoupgrade command in privileged EXEC mode.

Step 3

Return to privileged EXEC mode.

Example:

Device(config)# end

Auto-upgrade is now enabled and will automatically upgrade software when new versions are available.

Cisco Catalyst 9800 Series Wireless Controller Software Configuration Guide, Cisco IOS XE 17.5.x

Bias-Free Language

Results

Chapter: High Availability

High Availability

High Availability

Feature history for High Availability

Additional reference information

Prerequisites for High Availability

External interfaces and IPs

HA interfaces

High Availability restrictions

Best practices for RP port configuration

Configure High Availability (CLI)

Before you begin

Procedure

Example:

Example:

Example:

Example:

Example:

Disable High Availability

Copy a WebAuth tar bundle to the standby controller (GUI)

Procedure

System and network fault handling

Handling recovery mechanism

Active-to-Active recovery

Standby-to-Standby recovery

Verify high availability configurations

Verify AP or client SSO statistics

Verify high availability

Configure a switchover

Procedure

Example:

Redundancy management interfaces

Gateway monitoring

Key aspects

Airport's air traffic control system

Configure gateway monitoring interval (CLI)

Before you begin

Procedure

Example:

Example:

Example:

Configure gateway monitoring (CLI)

Procedure

Example:

Example:

Example:

What to do next

Gateway Reachability Detection

Gateway reachability detection

Gateway reachability detection behavior

Requirement: proper configuration of default gateway

Configure system redundancy workflow

Summary

Workflow

Migrate to RMI IPv6

Before you begin

Procedure

Standby monitoring

Requirements and configuration

Monitoring the Health of Standby Parameters Using SNMP

Standby monitoring using standby RMI IP

Supported mibs and monitoring capabilities

Standby monitoring using the active controller

CISCO-LWAPP-HA-MIB

CISCO-PROCESS-MIB

ENTITY-MIB

Standby IOS linux syslogs

Standby syslog behavior

Standby controller health monitoring using programmatic interfaces

Standby controller health monitoring (CLI)

Port state monitoring

CPU or memory monitoring

Gateway-monitoring configuration verification

RMI IPv4 configuration verification

RMI IPv6 configuration verification

Redundancy management interfaces

Limitations for RMI