High Availability SSO Deployment
Guide for Cisco Catalyst 9800
Series Wireless Controllers, Cisco
IOS XE Bengaluru 17.6
First Published: July 31, 2021
Last Updated: November 12, 2021

Cisco Systems, Inc.

www.cisco.com

1High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Introduction

Table of Contents
Introduction ....................................................................................................................... 5
Overview ........................................................................................................................... 5
Feature Description and Functional Behavior ..................................................................... 5
Platforms Supported .......................................................................................................... 6
SSO Pre-requisites .............................................................................................................. 6
SSO on Cisco Catalyst C9800-40-K9 and C9800-80-K9 Wireless Controllers ......................... 6
Physical Connectivity for C9800-L, C9800-40 and C9800-80 Wireless Controller HA SSO ...... 7
Connecting C9800-L Wireless Controllers using RJ-45 RP Port for SSO ............................. 7
Connecting C9800-40 and 9800-80 Wireless Controllers using RJ-45 RP Port for SSO ...... 8Connecting C9800-40 and 9800-80 Wireless Controllers using SFP Gigabit RP Port for SSO...................................................................................................................................... 8Connecting a C9800 wireless controller HA pair to upstream switches............................ 8
Option 1: Single VSS switch (or stack/VSL pair/modular switch) with RP back-to-back ... 9
Option 2: Single VSS switch (or stack/VSL pair/modular switch) with RP via upstream ... 9
Option 3: Dual Distributed switches with HSRP ............................................................ 10
Connecting a C9800 wireless controller HA pair to upstream switches with Release 17.1
and above........................................................................................................................ 10
SSO on Cisco Catalyst C9800-CL running on ESXi, KVM, Hyper-V ....................................... 11
Configuring High Availability SSO using GUI..................................................................... 11
Configuring High Availability SSO using CLI ...................................................................... 12
Mobility MAC................................................................................................................... 13
Active and Standby Election Process ................................................................................ 14
State Transition for HA SSO Pair formation ...................................................................... 14
Monitoring the HA Pair .................................................................................................... 16
Monitoring HA Pair from CLI ......................................................................................... 19
Verifying Redundancy States ........................................................................................... 19
Accessing standby wireless controller console .................................................................. 21
Switchover Functionality .................................................................................................. 22
Process Failure Switchover ........................................................................................... 22Power-fail Switchover .................................................................................................. 22
Manual Switchover ...................................................................................................... 22
Failover Process ............................................................................................................... 232

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Introduction

Active wireless controller ............................................................................................. 23
Standby wireless controller .......................................................................................... 23
Verifying AP and Client SSO State Sync ............................................................................ 24
SSO Failover Time Metrics ................................................................................................ 24
Redundancy Management Interface ................................................................................ 24
Redundancy Management Interface Configuration using WebUI .................................. 25
Programmatic configuration of RMI IPs ........................................................................ 25
Dual Stack support with RMI IPv4................................................................................. 26
Dual Stack Support with RMI IPv6 ................................................................................ 26
Peer Timeout Configuration ......................................................................................... 26
Redundancy Management Interface Configuration using CLI ........................................ 27
Verifying RMI and RP configuration .............................................................................. 28
RMI and RP pairing combinations ................................................................................. 28

Upgrade and HA Pairing with no previous HA config .................................................................................. 28
Upgrade already Paired controllers ............................................................................................................. 29
Downgrade .................................................................................................................................................. 29

Default Gateway Check.................................................................................................... 30
Configuring Gateway Failure Detection Interval............................................................... 31
Default Gateway Check WebUI Configuration .............................................................. 33
Default Gateway Check CLI Configuration ..................................................................... 33
System and Network Fault Handling ................................................................................ 34
HA Unpairing Behavior .................................................................................................... 38
LACP, PAGP support in SSO Pair ....................................................................................... 40
Supported LACP, PAGP topologies ................................................................................ 40
Multi-chassis Link Aggregation group .............................................................................. 40
Supported Multi-chassis LAG topologies....................................................................... 41
Supported Platforms: ................................................................................................... 41
Supported LAG Port Grouping .......................................................................................... 42
Sample LAG Configuration for HA SSO pair connecting to a VSS Pair with Split Links ........ 42

On the wireless Controller ........................................................................................................................... 42
On the VSS ................................................................................................................................................... 46

RMA process for a controller in an HA setup .................................................................... 49
N+1 with SSO Hybrid deployment .................................................................................... 50
Standby Monitoring using RMI ........................................................................................ 50

Standby Monitoring CLIs.............................................................................................................................. 503

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Introduction

Standby Monitoring Programmatic Interfaces .............................................................. 52
Steps to monitor the standby controller using SSH to RMI IPv4 .................................... 53
Command for Standby Monitoring using RESTCONF ..................................................... 54
Standby Monitoring in release 17.5 .............................................................................. 54
Interface Status of Standby controller through Active using SNMP ............................... 63

4

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Introduction

Introduction
High availability has been a requirement on wireless controllers to minimize downtime in live networks. This
document provides information on the theory of operation and configuration for the Catalyst 9800 WirelessController as it pertains to supporting stateful switchover of access points and clients (AP and Client SSO).
Catalyst 9800 Wireless Controller is the next generation wireless controller that can run on multiple
platforms with different scalability goals from low to high scale. AP and Client SSO is supported on thephysical appliances and the virtual cloud platforms of the Catalyst 9800 Wireless Controller, namely
C9800-L, C9800-40, C9800-80 and C9800-CL. The underlying SSO functionality is the same on all
platforms with some differences in the setup process.

Overview
The High availability SSO capability on wireless controller allows the access point to establish a CAPWAP
tunnel with the Active wireless controller and the Active wireless controller to share a mirror copy of the AP
and client database with the Standby wireless controller. The APs do not go into the Discovery state andclients do not disconnect when the Active wireless controller fails and the Standby wireless controller takes
over the network as the Active wireless controller. There is only one CAPWAP tunnel maintained at a time
between the APs and the wireless controller that is in an Active state.
Release 16.10 supports full access point and Client Stateful Switch Over. Client SSO is supported forclients which have already completed the authentication and DHCP phase and have started passing traffic.
With Client SSO, a client's information is synced to the Standby wireless controller when the client
associates to the wireless controller or the client’s parameters change. Fully authenticated clients, i.e. theones in Run state, are synced to the Standby and thus, client re-association is avoided on switchover
making the failover seamless for the APs as well as for the clients, resulting in zero client service downtime
and zero SSID outage. The overall goal for the addition of AP and client SSO support to the Catalyst 9800
Wireless controller is to reduce major downtime in wireless networks due to failure conditions that may
occur due to box failover, network failover or power outage on the primary site.

Feature Description and Functional Behavior
All the control plane activities are centralized and synchronized between the active and standby units. The
Active Controller centrally manages all the control and management communication. The network control
data traffic is transparently switched from the standby unit to the active unit for centralized processing.
Bulk and Incremental configuration is synced between the two controllers at run-time and both controllers
share the same IP address on the management interface. The CAPWAP state of the Access Points that are
in Run State is also synched from the active wireless controller to the Hot-Standby wireless controller
allowing the Access Points to be state-fully switched over when the Active wireless controller fails. The
APs do not go to the Discovery state when Active wireless controller fails, and Standby wireless controller
takes over as the Active wireless controller to serve the network.
The two units form a peer connection through a dedicated RP port (this can be a physical copper or fiberport) or a virtual interface for the VM. The Active/Standby election happens at boot time and it’s either
based on the highest priority (priority range is <1-2>) or the lowest MAC if the priority is the same. Bydefault the C9800 has a priority of 1. Once the HA pair is formed, all the configuration and AP and client
databases are synched between Active and standby. Any configuration is done on the Active is
automatically synch to the Standby. The standby is continuously monitoring the Active via keepalives overthe RP link. If the Active becomes unavailable, the standby assumes the role of Active. It does that bysending a Gratuitous ARP message advertising to the network that it now owns that wireless management
IP address. All the configurations and databases are already in synch, so the standby can take over without
service disruption5

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Platforms Supported
There is no pre-empt functionality with SSO meaning that when the previous Active wireless controller
resumes operation, it will not take back the role as an Active wireless controller but will negotiate its statewith the current Active wireless controller and transition to Hot-Standby state.

Platforms Supported■ Cisco Catalyst C9800-40 Wireless Controller■ Cisco Catalyst C9800-80 Wireless Controller■ Cisco Catalyst C9800-CL Wireless Controller■ Cisco Catalyst C9800-L Wireless Controller

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

SSO on Cisco Catalyst C9800-40-K9 and C9800-80-K9 WirelessControllers
The Cisco C9800-40-K9 wireless controller is an extensible and high performing wireless controller, which
can scale up to 2000 access points and 32000 clients. The controller has four 10G data ports and athroughput of 40G.

1

RP— RJ-45 1G redundancy Ethernet port.

2

Gigabit SFP RP port

The Cisco C9800-80-K9 Wireless Controller is a 100G wireless controller that occupies two rack unit
space and supports a pluggable Module slot, and eight built-in 10GE/1GE interfaces.

6High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Physical Connectivity for C9800-L, C9800-40 and C9800-80 Wireless Controller HA SSO
1

RP— RJ-45 1G redundancy Ethernet port.

2

Gigabit SFP RP port

Both C9800-40-K9 and C9800-80-K9 Wireless controllers have two RP Ports as shown in the figures
above:■ RJ-45 Ethernet Redundancy port
■ SFP Gigabit Redundancy PortIf both the Redundancy Ports are connected:■ SFP Gigabit Ethernet port takes precedence if they are connected at same time.
■ HA between RJ-45 and SFP Gigabit RP ports is not supported.
■ Only Cisco supported SFPs (GLC-LH-SMD and GLC-SX-MMD) are supported for RP port
■ 10G SFP-10G-SR is not supported on the RP port.
■ When HA link is up via RJ-45, SFPs on HA port should not be inserted even if there is no link between
them. As it is a physical level detection, this would cause the HA to go down as precedence is given to SFP

Physical Connectivity for C9800-L, C9800-40 and C9800-80 WirelessController HA SSO
The HA Pair always has one active controller and one standby controller. If the active controller becomes
unavailable, the standby assumes the role of the active. The Active wireless controller creates and updates
all the wireless information and constantly synchronizes that information with the standby controller. If theactive wireless controller fails, the standby wireless controller assumes the role of the active wirelesscontroller and continues to the keep the HA Pair operational. Access Points and clients continue to remain
connected during an active-to-standby switchover.

Connecting C9800-L Wireless Controllers using RJ-45 RP Port for SSO

7

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Physical Connectivity for C9800-L, C9800-40 and C9800-80 Wireless Controller HA SSO

Connecting C9800-40 and 9800-80 Wireless Controllers using RJ-45 RP Port for
SSO

Connecting C9800-40 and 9800-80 Wireless Controllers using SFP Gigabit RP
Port for SSO

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

SSO pair connected to upstream VSS pair with split links and RP connected back to back.

2.

SSO pair connected to upstream VSS pair with RP connected via the upstream set of switches
in order to detect gateway down scenario.

3.

SSO pair connected to upstream HSRP active and standby and RP connected via upstream setof switches in order to detect gateway down scenario.

8

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Physical Connectivity for C9800-L, C9800-40 and C9800-80 Wireless Controller HA SSO

Option 1: Single VSS switch (or stack/VSL pair/modular switch) with RP backto-backSingle L2 port-channel on each box and enable dot1q to carry multiple VLANs. Spread the uplinks of the
HA pair across the VSS pair and connect the RP back to back (no L2 network in between). Make sure thatswitch can scale in terms of ARP and MAC table entries.
This is a recommended topology.
Note: In HA SSO topology only LAG with mode ON is supported.

Option 2: Single VSS switch (or stack/VSL pair/modular switch) with RP via
upstream

9

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Connecting a C9800 wireless controller HA pair to upstream switches with Release 17.1 and above
With this topology a single L2 port-channel is created on each box. Enable dot1q to carry multiple VLANs
and connect the standby in the same manner. Make sure that switch can scale in terms of ARP and MAC
table entries
IMPORTANT: In this topology the links are not spread across the VSS stack. Connect RP port to the same
VSS/stack member as the uplinks and not back to backNote: In HA SSO topology only LAG with mode ON is supported.

Option 3: Dual Distributed switches with HSRP

With this topology a single L2 port-channel is created on each box. Enable dot1q to carry multiple VLANs
and connect the standby in the same manner. Make sure that switch can scale in terms of ARP and MAC
table entries.
IMPORTANT: Connect RP port to the same distribution switch as the uplinks and not back to backNote: In HA SSO topology only LAG with mode ON is supported prior to release 17.1. With 17.1, we
additionally support LACP and PAGP. See the LACP, PAGP support in SSO Pair section for more details

Connecting a C9800 wireless controller HA pair to upstream switcheswith Release 17.1 and above
With the option of RMI and default gateway check feature available in release 17.1, the following topologies
are now supported and recommended:1.

SSO pair connected to upstream VSS pair with split links and RP connected back to back.

2.

SSO pair connected to upstream VSS pair and RP connected back to back.

3.

SSO pair connected to upstream HSRP active and standby and RP connected back to back.

10

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
SSO on Cisco Catalyst C9800-CL running on ESXi, KVM, Hyper-V

Note: It is recommended to configure portfast trunk in uplink switches for faster convergence using CLI"spanning-tree port type edge trunk" or "spanning-tree portfast trunk"

SSO on Cisco Catalyst C9800-CL running on ESXi, KVM, Hyper-V
The Virtual Catalyst 9800 Wireless controller can be deployed as an HA Pair in a single or dual server
setup.

The figure on the left shows Redundant port connected on the same server.
The figure on the right shows Redundant port L2 connected to a separate server.
The same interface number (for example Gig3) must be used to form the HA pair on 9800-CL. The scale oftemplates must also match. We support SSO across 9800-CL on HyperV, VMware ESXi and KVM.

Configuring High Availability SSO using GUI
Device redundancy can be configured from the Administration > Device > Redundancy pageOn the Active controller, the priority is set to a higher value than the standby controller. The wirelesscontroller with the higher priority value is selected as the active during the active-standby election process.
The Remote IP is the IP address of the standby controller’s redundancy port IP.

11

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Configuring High Availability SSO using CLI

Note: This page has changed starting release 17.1 to include an option to configure the HA pair using RMI.
Please refer to the Redundancy Management Interface section to see the updated screens forconfiguration.
On the standby controller, the remote IP is set to the Active controller’s redundancy port IP

1) Both IP address for the Local and Remote IP must be in the same subnet.
2) It is suggested to use the 169.254.X.X/16 subnet. The last two octets can be derived from last twooctets of the management interface.
3) Avoid using 10.10.10.x/24 subnet for the RP port due to defect in 9800 WLC.

Clear Redundancy config clears the SSO configuration and returns the controller to standalone mode.
Note: It is recommended to configure HA using the Redundancy Management Interface (RMI) starting
Release 17.1. To see configuration using RMI please see the Redundancy Management Interface section.

Configuring High Availability SSO using CLI■ On Virtual Catalyst 9800 Wireless controller, enable High Availability SSO using the following commandon each of the two virtual Catalyst 9800 Wireless controller instances12High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Mobility MAC
chassis redundancy ha-interface <RP interface> local-ip <local IP> <local IP subnet>
remote-ip <remote IP>

e.g.
On Virtual Catalyst 9800 Wireless controller instance-1:
ip

chassis redundancy ha-interface Gig 3 local-ip 172.23.174.85 /24 remote172.23.174.86

On Virtual Catalyst 9800 Wireless controller instance-2:
ipchassis redundancy ha-interface Gig 3 local-ip 172.23.174.86 /24 remote172.23.174.85■ On C9800-40 and C9800-80 wireless controller, enable High Availability SSO using the following
command on each of the two wireless controller units
ip

chassis redundancy ha-interface local-ip <local IP> <local IP subnet> remote<remote IP>

Reload both wireless controllers by executing the command reload from the CLI
Note: It is recommended to configure HA using the Redundancy Management Interface (RMI) starting
Release 17.1. To see configuration using RMI please see the Redundancy Management Interface section.

Mobility MAC
The wireless mobility MAC is the MAC address used for mobility communication. In an SSO scenario,
ensure that you explicitly configure the wireless mobility MAC address; otherwise, the mobility tunnel will
go down after SSO. The mobility MAC address for the SSO pair can be configured either:●
Before forming the SSO pair on each standalone controller. This is recommended before software
release 16.12.3.
●

On the active controller once the SSO pair is formed.

To configure the mobility MAC address, you can use the GUI:

Once you’ve entered the address, click Apply.
Note: The MAC address on the GUI is automatically derived from the wireless management interface, but
you can use any other valid MAC address.
In the CLI, use the following command:
C9800#wireless mobility mac-address <MAC>

13

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Active and Standby Election Process

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

The wireless controller that is currently the active wireless controller.

2.

The wireless controller with the highest priority value.
Note: We recommend assigning the highest priority value to the wireless controller C9800 you
prefer to be the active controller. This ensures that the controller is re-elected as active
controller if a re-election occurs.
Setting the Switch Priority Value
chassis chassis -number priority new-priority-number

Chassis-number Specifies the chassis number and the new priority for the chassis. The
chassis number range is 1 to 2. Please note that the chassis renumbering command will
require a reboot.
The priority value range is <1-2>. Stack Priority 2 will be Primary while Priority 1 will bestandby.

Examplewireless controller#chassis 1 priority 2

You can display the current priority value by using the show chassis user EXEC command.
The new priority value takes effect immediately but does not affect the current Active
Controller. The new priority value helps determine which controller is elected as the new
Active Controller when the current active wireless controller or HA redundant pair reloads.
3.

The wireless controller with the shortest start-up time.

4.

The wireless controller with the lowest MAC Address.

The HA LED on the chassis can be used to identify the current Active Controller.

State Transition for HA SSO Pair formation
1.

Active wireless controller in Non Redundant mode

14

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
State Transition for HA SSO Pair formation

2.

Standby Insertion for HA Pairing

3.

HA Sync in Progress

15

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Monitoring the HA Pair

4.

Terminal State for SSO

Note: Breaking the HA Pair : The HA configuration can be disabled by using the chassis clear command
followed by a reload

Monitoring the HA Pair
Both Active and Standby System can be monitored from the Management UI of the Active wirelesscontroller. This includes information about CPU and memory utilization as well and advanced CPU andmemory views.

16

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6

Navigate to Monitoring > System > Redundancy on the controller Web UI. The Redundancy States page isdisplayed:

Parameter

Description

Shows the state of the active CPU controller module. Values are as
follows:
ActiveStandby HOT
My State

Disable17

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6

Displays the state of the peer (or standby) CPU controller module.
Values are as follows:Standby HOT
Peer State

DisableDisplays the current state of the redundancy peer. Values are as
follows:
Simplex— Single CPU controller module.

Mode

Duplex— Two CPU controller modules.

Unit ID

Displays the unit ID of the CPU controller module.

Redundancy Mode
(Operational)

Displays the current operational redundancy mode supported on theunit.

Redundancy Mode
(Configured)

Displays the current configured redundancy mode supported on theunit.
Displays the current functioning redundancy state of the unit. Values
are as follows:
SSO

Redundancy State

Not Redundant

Manual Swact

Displays whether manual switchovers have been enabled.

Communications

Displays whether communications are up or down between the twocontrollers.

The same page displays Switchover history. The description for the following parameters are displayed in
the table below:
Parameter

Description

Index

Displays the index number of the redundant unit.

Previous Active

Displays the controller that was active prior to switchover.

18

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Verifying Redundancy States

Current Active

Displays the controller that is currently active.

Switch Over Time

Displays the system time when the switchover occurred.

Switch Over Reason

Displays the cause of the switchover.

Monitoring HA Pair from CLI
The command show chassis displays summary information about the HA Pair, including the MAC address, role, switch priority, and current state of each wireless controller in the redundant HA pair. By default, the Local MAC Address of the HA Pair is the MAC address of the first elected Active Controller.

The show chassis command points to the current C9800 wireless controller on the console using the(*) symbol against the chassis number as shown above.

Verifying Redundancy States■ The command show redundancy can be used to monitor the state of the two units
wireless controller#show redundancy ?
applicationbox 2 box application informationclients
Redundancy Facility (RF) client list
config-sync
Show Redundancy Config Sync status
counters
Redundancy Facility (RF) operational countersdomainSpecify the RF domain
history
Redundancy Facility (RF) history
idb-sync-history Redundancy Facility (RF) IDB sync history
linecard-group
Line card redundancy group informationrii
Display the redundancy interface identifier for Box to Box
statesRedundancy Facility (RF) statesswitchover
Redundancy Facility (RF) switchover
trace
Redundancy Facility (RF) trace|
Output modifiers
<cr>
<cr>

■ The command show redundancy displays the redundant system and the current processor information.
The redundant system information includes the system uptime, standby failures, switchover reason,
hardware mode, and configured and operating redundancy mode. The current processor information
displayed includes the image version, active location, software state, BOOT variable, configuration registervalue, and uptime in the current state, and so on. The Peer Processor information is only available from theActive Controller.

19

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Verifying Redundancy States■ The command show redundancy states displays all the redundancy states of the active and standby
controllers.

20High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Accessing standby wireless controller console■ Manual Switchover Action (Manual Swact) i.e. the command redundancy force-switchover cannot be
executed on the Standby wireless controller and is enabled only on the Active Controller.
■ Switchover History can be viewed using the following command

Accessing standby wireless controller console
The active controller can be accessed through a console connection, Telnet, an SSH, or a Web Browser byusing the Management IP address. To use the console on the standby wireless controller, executethe following commands from the active Catalyst 9800 Wireless controller
conf tredundancy
main-cpu
standby console enable

The prompt on the Standby console is appended with “-stby” to reflect the Standby wireless controller
console as shown below.

Note: The show chassis command points to the current C9800 wireless controller on the console using the (*) symbol against the chassis number as shown above. In this case it is the console of the standby
Unit.

21

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Switchover Functionality

Switchover Functionality
Process Failure Switchover
This type of switch over occurs when any of the key processes running on the Active unit fails or crashes.
Upon such a failure, the Active unit reloads and the hot Standby takes over and becomes the new Active
unit. When the failed system boots up, it will transition to Hot-Standby state. If the Standby unit is not yet in
Hot Standby State, both units are reloaded and there will be no SSO. A process failure on the standby (hotor not) will cause it to reload.

Power-fail Switchover
This switchover from the Active to Standby unit is caused due to power failure of the current Active unit.
The current Standby unit becomes the new Active unit and when the failed system boots up, it willtransition to Hot-Standby state.

Manual Switchover
This is a user initiated forced switchover between the Active and Standby unit. The current Standby unit
becomes the new Active unit and when the failed system boots up, it will transition to Hot-Standby state.
To perform a manual switchover, execute the redundancy force-switchover command. This command
initiates a graceful switchover from the active to the standby controller. The active controller reloads andthe standby takes over as the New Active controller.

22

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Failover Process

Failover Process
Active wireless controllerStandby wireless controller
An Access Point and client Stateful Switch Over (SSO) implies that all the Access Point and client sessions
are switched over state-fully and continue to operate in a network with no loss of sessions, providing
improved network availability and reducing service downtime.
Once a redundancy pair is formed, HA is enabled, which means that Access Points and clients continue toremain connected during an active-to-standby switchover.

23

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Verifying AP and Client SSO State Sync

Verifying AP and Client SSO State Sync
On successful switchover of the standby wireless controller as active, all access points and clientsconnected to the previously active wireless controller must remain connected to the new Active controller.
This can be verified by executing the commands:■ show ap uptime : Verifies that the uptime of the access point after the switchover is not reset.
■ show wireless client summary: Displays the clients connected to the new Active controller.

SSO Failover Time Metrics
Metrics

Time

Failure Detection

In the order of 500-1000ms

Redundancy Management Interface
With a single RP link between the SSO pair, if the heartbeat on RP fails, there is no way find out if the failure
is limited to the link or if the other controller has failed. Redundancy Port (RP link) that handles state sync
traffic between the active and the standby is a single point of failure.
Release 17.1 introduces the Redundancy Management Interface (RMI) as a secondary link between theactive and the standby controllers. This release also introduces the support for default gateway check
which is done using the redundancy management interface.
Release 17.4 introduces IPv6 Support for RMI interfaces. One management IPv6 address and one RMI IPv6
address is supported on the wireless management interface. Either RMI IPv4 or RMI IPv6 is supported andthere is no simultaneous support for RMI IPv4 and RMI IPv6. The format of the CLI is same for IPv6 exceptthat the IPv4 address is replaced with IPv6 address.

24

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Redundancy Management Interface

Redundancy Management Interface Configuration using WebUI■ RMI IP for chassis 1 and 2 is same across both active and standby controllers■ RP IP configuration for chassis 1 and 2 auto-generated as 169.254.x.x where x.x. is from the RMI IP■

The netmask for RMI is picked up from the netmask configured on the Wireless Management VLAN.

■WebUI has RMI IPv6 support in Release 17.4

Programmatic configuration of RMI IPs
On the Active controller:
Secondary address on the management VLAN is the RMI for the active. The primary address on theactive is the management IP. It is possible to have multiple “secondary” addresses on the interface asshown below. For the purpose of RMI, only one secondary IP will be defined. The secondary IP shall be
configured programmatically.
There is no concept of “secondary” address in case of IPv6. The wireless management IP and the RMI
IP will appear as 2 distinct IPs in case of IPv6.

For eg, if the following CLI is configured: redun-management interface Vlan52 chassis 1 address
2020:0:0:1::211 chassis 2 address 2020:0:0:1::212
The active controller will be configured as follows:25

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Redundancy Management Interface
interface Vlan52
ip address 10.100.0.1 255.252.0.0
ipv6 address 2020:0:0:1::1/64
ipv6 address 2020:0:0:1::211/64
ipv6 enable
ipv6 nd na gleanno mop enabled
no mop sysidend

On the Standby controller:
It cannot have the management IP as the address is claimed by the active. Therefore, on the standby
controller, the RMI IP shall be configured as the primary address programmatically. When the standby
becomes active, the management IP needs to be programmed as primary and the RMI IP as secondary.
The “secondary” IP concept is relevant for IPv4 only.

interface Vlan52
no ip address
ipv6 address 2020:0:0:1::212/64
ipv6 enable
ipv6 nd na gleanno mop enabled
no mop sysid
end

Dual Stack support with RMI IPv4
When RMI IPv4 is configured, it is possible to an IPv6 IP configured on the wireless management interface.
This address shall be explicitly configured. With RMI enabled, the IPv6 address configured shall be
programmatically removed in the standby and configured back when the standby transitions to active. The
address shall be removed when the controller is in active-recovery mode. This would avoid Duplicate
Address Detection.

Dual Stack Support with RMI IPv6
This case arises in release 17.4. In 17.4, the wireless management IP can be IPv6 with an RMI IPv6
configured. In addition, the wireless management interface can have an IPv4 IP configured. When thestandby RMI interface is brought UP, the IPv6 and IPv4 management IPs will be unconfigured and IPv6 RMI
configured. Upon transition from standby to active, the management IPs shall be restored.

Peer Timeout Configuration■ Active and standby chassis send keepalives messages to each other to ensure both still available. Peertimeout is used to determine peer chassis is lost if it does not receive any keep alive message from peer
chassis in the configured peer timeout.
■ Default timeout is 100ms but is configurable up to 1000 ms. The keepalive retries are 5 by default but canbe configured all the way to 10.
■ CLI commands:

26

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Redundancy Management Interface
WLC#chassis redundancy keep-alive timer ?
<1-10> Chassis peer keep-alive time interval in multiple of 100 ms (enter 1
for default)
WLC#chassis redundancy keep-alive retries ?
<5-10> Chassis peer keep-alive retries before claiming peer is down (enter 5
for default)

For backward compatibility, RP based SSO configuration will also be supported, but keep in mind that thiswill not support default gateway check and hence is not preferred.

Redundancy Management Interface Configuration using CLI
Until 17.1, only RP-based SSO configuration was supported, i.e., chassis redundancy ha-interface <RPinterface> local-ip <local IP> <local IP subnet> remote-ip <remote IP>.
17.1 and beyond, the user can use either RMI+RP or RP-based configuration. Once an HA pair is formed
using RMI+RP configuration, the exec CLI for RP-based method of clearing and forming the HA pair shallnot be allowed.
Note: Chassis re-number needs to be configured while bringing up HA with RMI from scratch using RMI in
17.x release.
The chassis redundancy ha-interface GigabitEthernet interface-number command needs to be definedin Cisco Catalyst 9800-CL Cloud Wireless Controller before pairing the controllers. This step is applicable
only for Cisco Catalyst 9800-CL Series Wireless Controllers. The chosen interface is used as the dedicatedinterface for HA communication between the 2 controllers.
By default, chassis number is 1. IP addresses of RP ports are derived from RMI. If the chassis number is thesame on both controllers, local RP port IP derivation will be same and discovery will fail. This will result in
Active-Active case.
To avoid this scenario, execute the following CLI:
WLC#chassis 1 renumber ?
<1-2> Renumber local chassis id assignment
WLC(config)# redun-management interface <VLAN> chassis 1 address <RMI IP of chassis 1>
chassis 2 address <RMI IP of chassis 2>

Configuration example:

27

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Redundancy Management Interface
On WLC 1:
WLC(config)# redun-management interface Vlan112 chassis 1 address 172.20.226.148 chassis 2
address 172.20.226.149

On WLC 2: (Same CLI)
WLC(config)# redun-management interface Vlan112 chassis 1 address 172.20.226.148 chassis 2
address 172.20.226.149

Chassis numbers identify the individual controllers and must be configured before configuring the RMI IPs.
It is mandatory to execute the same CLI on both controllers before forming the pair. The RMI IP
configuration triggers HA pairing and forms the SSO pair.

Verifying RMI and RP configuration
WLC-9800#show chassis rmi
Sep 20 21:26:13.024: %SYS-5-CONFIG_I: Configured from console by console
Chassis/Stack Mac Address : 00a3.8e23.8760 - Local Mac Address
Mac persistency wait time: Indefinite
Local Redundancy Port Type: Twisted Pair
H/W
Current
Chassis#Role
Mac Address
Priority Version StateIP
RMI-IP-----------------------------------------------------------------------------------1
Standby 00a3.8e23.8760
2
V02
Ready 169.254.226.149 172.20.226.149*2
Active00a3.8e23.8900
1
V02
Ready 169.254.226.148 172.20.226.148

WLC-9800#show romvar
ROMMON variables:
SWITCH_NUMBER = 1
LICENSE_BOOT_LEVEL =…
RANDOM_NUM = 842430634
SWITCH_PRIORITY = 1
RMI_INTERFACE_NAME = Vlan112
RMI_CHASSIS_LOCAL_IP = 172.20.226.148
RMI_CHASSIS_REMOTE_IP = 172.20.226.149
CHASSIS_HA_LOCAL_IP = 169.254.226.148
CHASSIS_HA_REMOTE_IP = 169.254.226.149
CHASSIS_HA_LOCAL_MASK = 255.255.255.0

The following shows the scenario where the RP IP is derived from RMI IPv6 address:
D3-5-Dao#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 StateIP
RMI-IP-------------------------------------------------------------------------------------------------------*1
Active706d.1536.23c0
1
V02
Ready
169.254.254.17
2020:0:0:1::211
2
Standby 00a3.8e23.a540
1
V02
Ready
169.254.254.18
2020:0:0:1::212

RMI and RP pairing combinations
Upgrade and HA Pairing with no previous HA config
The user shall be presented with an option to choose the existing mechanism (exec RP-based CLIs) or the
RMI IP based mechanism.

28

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Redundancy Management Interface
If the user chooses the exec CLI based method, the RP IPs shall be configured as it happens till 16.12.
When the RMI configuration is done, it shall:
Generate the RP IPs with IPs derived from the RMI IPs and will also be used for setting RMI IPs and pair theControllers (while pairing only standby reloads in hardware platforms. Both active and standby reload incase of 9800-CL VM). Exec RP-based CLIs are blocked in this case.
Option 1: RMI Based Configuration (Preferred)
1.

Upgrade to 17.1 and connect the RPs

2.

Configure RMI+RP

3.

RP IPs are derived from the RMI IPs

4.

RP-based exec commands are blocked

5.

ROMMON RP and RMI variables are set

Option 2: RP Based Configuration
1.

Upgrade to 17.1 and connect RPs

2.

Configure RP via GUI/CLI

3.

RP-based configuration sets the local and remote IP

4.

ROMMON RP Variables are set to the local and remote IP

Upgrade already Paired controllers
If the controllers are already in an HA pair, the existing exec RP CLIs can be continued to be used.
Those who would like to migrate to the RMI based HA pairing (preferred) can enable RMI.
This will overwrite the RP IPs with RMI derived IPs. The HA pair will not be immediately disturbed, but thecontrollers will pick up the new IP when they reload next.
RMI feature mandates a reload for the feature to take effect.
When the controllers reload, they would come up as a pair with the new RMI-derived-RP-IPs. Exec RPbased CLIs will be blocked

Downgrade
If RMI based configuration was used, after downgrade the system will fall back to the RP-based
configuration

29

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Default Gateway Check

If RP based configuration was used, after downgrade the system will continue to use RP-based
configuration

Default Gateway Check
Default Gateway check is done by periodically sending Internet Control Message Protocol (ICMP) ping to
the gateway. Both the active and the standby controllers use the RMI IP as the source IP. These messages
are sent at 1 second interval. If there are 8 consecutive failures in reaching the gateway, the controller will
declare the gateway as non-reachable.
After 4 ICMP Echo requests fail to get ICMP Echo responses, ARP requests are attempted. If there is no
response for 8 seconds (4 ICMP Echo Requests followed by 4 ARP Requests), the gateway is assumed to
be non-reachable.
IPv6 default gateway detection is supported starting release 17.4. Instead of ICMP and ARP in IPv4, IPv6
shall use ICMP to detect gateway failure.

30

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6

The Catalyst 9800 Wireless controller has two recovery states to prevent an active-active scenario.
Recovery mode logically means a state where the controller does not have all “resources” available toprovide the service. Currently, RP, RMI and Gateway are the resources. Ports will be in admin down inrecovery mode, so no traffic goes through.
■ Standby-Recovery: If Gateway goes down, standby goes to standby-recovery mode. Standby means, its
state is up to date with the active. But since it does not have the other resource (Gateway) it goes toStandby-Recovery. The standby shall not be in a position to take over the active functionality when it is instandby-recovery mode. Standby-Recovery will go back to Standby without a reload, once it detects that
the Gateway reachability is restored.
■ Active-Recovery is when the RP goes down. Active-Recovery does not have its internal state in sync with
the Active. Active-Recovery will reload when the RP link comes up so that it can come up as Standby withbulk sync.
Switchover history will show switchover reason as Gateway down in the event of a switchover triggered asa result of the gateway going down.

Configuring Gateway Failure Detection Interval
The gateway failure detection interval is configurable starting release 17.4 using the following CLI:
WLC(config)#management gateway-failover interval <6 - 12>
The default is 8.
This parameter can be configured through YANG, SNMP and WebUI as well. The configuration parameter isapplicable for IPv6 gateway monitoring also.

31

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Configuring Gateway Failure Detection Interval

Sample json for NETCONF/YANG support

32

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Configuring Gateway Failure Detection Interval

Default Gateway Check WebUI Configuration
The default gateway check option can be configured under Administration > Device > Redundancy >Management Gateway Failover

Default Gateway Check CLI Configuration
The following CLIs need to be configured for the gateway check functionality to be enabled and to specify
the default gateway IP used by this feature
WLC-9800(config)#management gateway-failover enable
WLC-9800#ip default-gateway <IP>

To verify if gateway check is enabled, use the CLI show redundancy state
WLC-9800#show redundancy states
my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Primary
Unit ID = 2
Redundancy Mode (Operational) = sso
Redundancy Mode (Configured) = sso
Redundancy State= sso…
Gateway Monitoring = EnabledWith 17.2, usage of “ip default-gateway <IP>” shall be removed . Gateway IP will be picked up from thestatic IP routes configured. The HA infrastructure will choose the static route IP that matches the RMI
network. If there are multiple static routes configured, the route configured for the broadest network scope
shall be selected. It is possible to configure multiple gateways for the same network scope. If there are
multiple gateways for the same network, broadest mask and least gateway IP is chosen. The gateway IP
shall be reevaluated, if necessary, when config update to static routes happens.
The above mechanism of selecting the gateway IP from the set of static routes is applicable to IPv6 inRelease 17.4.

33

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
System and Network Fault Handling
Note:•Physical port down scenario takes 8 seconds to be detected as it is detected via GW check mechanism
prior to release 17.3.2. Starting release 17.3.2, if the port state goes down all actions associated withgateway going down will be triggered. A new reason code will be used to indicate SSO due to detection of
port going down. “Active RMI Port Down” shall be used in place of “Active GW Lost”.

•Physical port status is synced from the active to standby controller in release 17.1. This has been fixed inrelease 17.2 and the active and standby controllers maintain their own port status.

System and Network Fault HandlingIf the standby controller crashes, it shall reboot and come up as standby. Bulk sync will follow and thestandby will become hot. If the active controller crashes, the standby becomes active. The new active shallassume the role of master and try to detect a dual active.
These matrices provide a clear picture of what condition the WLC Switchover will trigger:
System Issues
Trigger

RP Link Status

Peer Reachability
through RMI

Switchover

ResultCritical Process crash

Up

Reachable

Yes

Switchover happens

Forced switchover

Up

Reachable

Yes

Switchover happens

Critical Process crash

Up

Unreachable

Yes

Switchover happens

Forced switchover

Up

Unreachable

Yes

Switchover happens

Critical Process crash

Down

ReachableNo

No action, one
controller will be inrecovery mode
already.

Forced switchover

Down

Reachable

N/A

No action, one
controller will be inrecovery mode
already.

Critical Process crash

Down

Unreachable

No

Double fault – asmentioned in Network
Error handling

Forced switchover

Down

Unreachable

N/A

Double fault – asmentioned in Network
Error handling34

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6

RP LinkPeerreachability
through RMI

Gateway From
ActiveGateway fromStandbySwitchover

ResultUp

Up

Reachable

ReachableNo

No actionNo

No Action.
Standby is notready for SSO in
this state as it
does not havegatewayreachability. The
standby shall beshown to be instandbyrecovery mode.
If the RP goes
down, standby(in recoverymode) shallbecome active.

Yes

Gatewayreachability
message isexchanged overthe RMI + RP
links. Active shallreboot so thatstandbybecomes active.

Up

Up

Up

Up

Up

Up

Reachable

Unreachable

Unreachable

Unreachable

Reachable

Unreachable

35

No

With this, when
the active SVI
goes down, so
will the standby
SVI. Aswitchover isthen triggered. If
the new active
discovers its
gateway to bereachable, thesystem shallstabilize in
Active - Standby
Recovery.

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6

Otherwise,
switchovers will
happen in aping-pongfashion.

Up

Up

Up

Up

Down

Down

Down

Down

Reachable

Reachable

Unreachable

Unreachable

Reachable

Unreachable

Reachable

Unreachable

36

No

No Action

NoStandby is notready for SSO in
this state as it
does not havegatewayreachability.
Standby will go
to recovery
mode as LMP
messages areexchanged overthe RP link also.

Yes

Gatewayreachability
message isexchanged overRP link also.
Active shallreboot so thatstandbybecomes active.

No

With this, when
the active SVI
goes down, so
will the standby
SVI. Aswitchover isthen triggered. If
the new active
discovers its
gateway to bereachable, thesystem shallstabilise in
Active - Standby
Recovery.
Otherwise,

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6

switchovers will
happen in aping-pongfashion.

Down

Up

Reachable

Reachable

Yes

Standby will
become activewith (old) active
going to activerecovery. Config
mode is disabled
in activerecovery mode.
All interfaces willbe ADMIN
DOWN with thewirelessmanagement
interface having
RMI IP. The
controller in
Active Recovery
will reload tobecome standby
when the RP link
comes UP.

Down

Up

Reachable

Unreachable

Yes

Same as above

Down

Up

Unreachable

Reachable

Yes

Same as above

Down

Up

Unreachable

Unreachable

Yes

Same as above

Down

Down

Reachable

Reachable

37

Yes

Double fault –this may result ina network
conflict as there
will be 2 active
controllers.

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
HA Unpairing Behavior
Standbybecomes active.
Old active also
exists. Role
negotiation has
to happen oncethe connectivity
is restored andkeep the activethat came up
last

Down

Down

Reachable

Unreachable

Yes

Same as above

Down

Down

Unreachable

Reachable

Yes

Same as Above

Down

Down

Unreachable

Unreachable

Yes

Same as Above

HA Unpairing Behavior
In release 16.10 and 16.11, when disjoining an HA pair by issuing the command 'clear chassis
redundancy’, the standby controller reboots and comes up with exactly the same configuration as theactive controller, causing duplicate IP address error leading to the following messages:
WLC#sh log | i DUP
Mar 21 21:53:46.307 CET: %IP-4-DUPADDR: Duplicate address 120.0.0.1 on Vlan120, sourced by
d4c9.3ccc.f98b
Mar 21 21:54:16.947 CET: %IP-4-DUPADDR: Duplicate address 172.18.50.60 on
GigabitEthernet0, sourced by d4c9.3ccc.f981

The solution implemented in 16.12 and 17.1 is that after HA unpairing, the standby controller startup config
and HA config will be cleared and standby will go to Day 0.
Before the command is executed, the user is prompted with the following warning on the active controller:

38

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
HA Unpairing Behavior

The same is seen on the CLI as well.
WLC#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 nolonger standby

On the standby controller, the following messages indicate that the configuration is being cleared:
WLC-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*Apr 3 23:42:26.466: Calling HA configs clear on standby*Apr 3 23:42:26.466: Clearing HA configurations*Apr 3 23:42:27.499: Successfully sent Set chassis mode msg for chassis 2.chasfs file
updatedNote: To unpair the SSO pair when using RMI based config, use the “no” version of the RMI configuration
followed command by reload:
WLC(config)# no redun-management interface <VLAN> chassis 1 address <RMI IP of chassis 1>
chassis 2 address <RMI IP of chassis 2>39

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
LACP, PAGP support in SSO Pair

LACP, PAGP support in SSO Pair
LACP protocol (IEEE 802.3ad) aggregates physical Ethernet interfaces by exchanging the Link Aggregation
Control Protocol Data Units (LACPDUs) between two devices.
LACP, PAGP support is needed on SSO pair in order to have the ability to detect and monitor thelink/connectivity failures on the standby controller and to have seamless transfer of client data traffic uponswitchover (SSO). Prior to 17.1 only LAG mode ON was supported in SSO mode. With 17.1 both LACP
(active and passive) and PAGP will be supported in SSO mode.
This feature is supported on Cisco Catalyst 9800-L, Cisco Catalyst 9800-40and Cisco Catalyst 9800-80(including module ports).

Supported LACP, PAGP topologies
The following topologies are supported with SSO and LACP/PAGP

The following are not supported with LACP, PAGP topologies:■ Auto-LAG is not supported.
■ C9800-CL and EWC on AP is not supported.
■ L3 port-channel is not supported.

Multi-chassis Link Aggregation group
Starting with Release 17.2.1, Multi-chassis Link Aggregation Group is supported on a standalone as well as
HA Pair of controllers. Multi-chassis LAG provides the capability to connect multiple uplinks fromcontroller to separate uplink switches.
This enables flexibility in connecting controller(s) to switch infrastructure and VLAN-based traffic splitting
when connected to a multi-switch topology, for e.g., to isolate Guest traffic on completely different
switch/network from Enterprise traffic. Each LAG must be connected to a single switch and different VLANs
must be assigned to different LAGs.

40

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
LACP, PAGP support in SSO Pair

Note: It is the user’s configuration responsibility not to create a loop.

Supported Multi-chassis LAG topologies•

Multi-chassis LAG is supported with LAG mode ON and dynamic LAG (LACP and PAGP)•

Multi-chassis LAG is supported with a standalone controller as well as an HA pair as depicted below.

Note: Controller with multiple LAGs can be connected to a single switch, However, different VLANs must beconnected to different LAGs

Supported Platforms:
Multi-chassis LAG is supported on the following platforms:•

Catalyst 9800-L Wireless Controllers•

Catalyst 9800-40 Wireless Controllers•

Catalyst 9800-80 Wireless Controllers

41

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Sample LAG Configuration for HA SSO pair connecting to a VSS Pair with Split Links

Supported LAG Port Grouping
Best practice is to have ports of same type and speed in the port channel•

9800-L-C with 2.5G/1G and 10G/mGig ports in different port channels•

9800-L-F with 2.5G/1G and 10G/1G Fiber ports in different port channels

On the 9800-80 ports on Bay 0 and Bay 1 (modular slots) cannot be combined into the same port channelgroup. Best practice is to have ports of same slot in the port channel.

Sample LAG Configuration for HA SSO pair connecting to a VSS Pairwith Split Links
On the wireless Controller
ACTIVE WLC:

WLC#sh etherchannel summary
Flags: D - down

P - bundled in port-channel

I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3

S - Layer2

U - in use

f - failed to allocate aggregator

M - not in use, minimum links not metu - unsuitable for bundlingw - waiting to be aggregated42High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Sample LAG Configuration for HA SSO pair connecting to a VSS Pair with Split Linksd - default port

A - formed by Auto LAG

Number of channel-groups in use: 1
Number of aggregators:

1

Group Port-channel Protocol

Ports------+-------------+-----------+----------------------------------------------2

Po2(SU)

LACP

Te0/0/0(P)Te0/0/3(P)WLC#sh run int po2
Building configuration...

Current configuration : 54 bytes!
interface Port-channel2
switchport mode trunkend

WLC#sh run int te0/0/0
Building configuration...

Current configuration : 114 bytes!
interface TenGigabitEthernet0/0/0
switchport mode trunk
no negotiation autochannel-group 2 mode activeend

43

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Sample LAG Configuration for HA SSO pair connecting to a VSS Pair with Split Links
WLC#sh run int te0/0/3
Building configuration...

Current configuration : 114 bytes!
interface TenGigabitEthernet0/0/3
switchport mode trunk
no negotiation autochannel-group 2 mode active
end

STANDBY WLC:

WLC-stby#sh etherchannel summary
Flags: D - down

P - bundled in port-channel

I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3

S - Layer2

U - in use

f - failed to allocate aggregator

M - not in use, minimum links not metu - unsuitable for bundlingw - waiting to be aggregatedd - default port

A - formed by Auto LAG

Number of channel-groups in use: 1
Number of aggregators:

Group Port-channel Protocol

1

Ports

44

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Sample LAG Configuration for HA SSO pair connecting to a VSS Pair with Split Links------+-------------+-----------+----------------------------------------------2

Po2(SU)

LACP

Te0/0/0(P)Te0/0/3(P)WLC-stby#sh run int po2
Building configuration...

Current configuration : 54 bytes!
interface Port-channel2
switchport mode trunkend

WLC-stby#sh run int te0/0/0
Building configuration...

Current configuration : 114 bytes!
interface TenGigabitEthernet0/0/0
switchport mode trunk
no negotiation autochannel-group 2 mode activeend

WLC-stby#sh run int te0/0/3
Building configuration...

Current configuration : 114 bytes!
interface TenGigabitEthernet0/0/3
switchport mode trunk
no negotiation autochannel-group 2 mode active

45

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Sample LAG Configuration for HA SSO pair connecting to a VSS Pair with Split Links
end

WLC-stby#

On the VSS
Router#sh etherchannel summary
Flags: D - down

P - bundled in port-channel

I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3

S - Layer2

U - in use

N - not in use, no aggregationf - failed to allocate aggregator

M - not in use, no aggregation due to minimum links not met
m - not in use, port not aggregated due to minimum links not metu - unsuitable for bundlingd - default portw - waiting to be aggregatedNumber of channel-groups in use: 9
Number of aggregators:

9Group Port-channel Protocol

Ports------+-------------+-----------+----------------------------------------------6

Po6(RD)-10

Po10(RU)-

Te1/5/4(P)20

Po20(RU)-

Te2/5/4(P)30

Po30(SU)

LACP

40

Po40(SD)-

Gi1/4/1(P)Gi2/4/1(P)46High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Sample LAG Configuration for HA SSO pair connecting to a VSS Pair with Split Links
60

Po60(SU)

LACP

Gi1/4/3(P)Gi2/4/4(P)61

Po61(SU)

LACP

Gi1/4/4(P)Gi2/4/3(P)833

Po833(SU)-Te1/1/1(P)Te1/1/2(P)865

Po865(SU)-Te2/1/1(P)Te2/1/2(P)Router#sh run int po60
Building configuration...

Current configuration : 67 bytes!
interface Port-channel60
switchport
switchport mode trunkend

Router#sh run int po61
Building configuration...

Current configuration : 67 bytes!
interface Port-channel61
switchport
switchport mode trunkend

Router#sh run int gi1/4/3
Building configuration...

47

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Sample LAG Configuration for HA SSO pair connecting to a VSS Pair with Split Links
Current configuration : 103 bytes!
interface GigabitEthernet1/4/3
switchport
switchport mode trunk
channel-group 60 mode active
end

Router#sh run int gi2/4/4
Building configuration...

Current configuration : 103 bytes!
interface GigabitEthernet2/4/4
switchport
switchport mode trunk
channel-group 60 mode active
end

Router#sh run int Gi1/4/4
Building configuration...

Current configuration : 103 bytes!
interface GigabitEthernet1/4/4
switchport
switchport mode trunk
channel-group 61 mode activeend

48High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
RMA process for a controller in an HA setup
Router#sh run int Gi2/4/3
Building configuration...

Current configuration : 103 bytes!
interface GigabitEthernet2/4/3
switchport
switchport mode trunk
channel-group 61 mode activeend

RMA process for a controller in an HA setup
1. Disconnect and remove the standby controller from the HA pair to RMA the box.
2. Prepare the new 9800 standby with the same configuration as the previous controller. Thismeans the same software version, licensing level, wireless management interface, login credentials, and SSO configuration including RMI.
3. Be sure to set the chassis priority to 1 so that it has a lower priority than the current active
controller. Verify that a higher priority of 2 is set on the current active controller to makesure that the current active remains the active.
4. Save the configuration and power off the new standby controller
5. Physically connect the cables on new standby which includes the uplink ports and redundancy port (RP).
6. Power on the new standby controller. The new 9800 controller will pair up as standby withthe current active controller.

49

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
N+1 with SSO Hybrid deployment

N+1 with SSO Hybrid deployment

A hybrid topology of SSO redundant pair and N+1 primary, secondary and tertiary model is supported asshown above. The secondary controller at the DR site can be a Catalyst C9800-L, C9800-40 C9800-80 or
C9800-CL Wireless controller. Access points failing back from Catalyst 9800 Wireless controller to CUWN
controllers will re-download the code before joining the CUWN wireless controller and vice versa.

Standby Monitoring using RMI
This feature enables monitoring the health of the system on standby controller in an HA pair using programmatic interfaces (NETCONF/YANG, RESTCONF) and CLIs without going through the active controller.
This includes monitoring parameters such as CPU, memory, interface status, PSU (Power Supply Unit) failure, fan failure and temperature. This feature is supported on the Cisco Catalyst 9800-CL Private cloud,9800-L, 9800-40, and 9800-80 wireless controller.
Using the RMI interface, the user can:•Connect to the IOS SSH server on port 22 to execute a select set of show CLIs.

•

Connect to the NETCONF SSH server on port 830 and use programmatic interfaces to access
NETCONF/YANG.

•

Connect on the HTTPS port 443 and use programmatic interfaces using RESTCONF.

The user credentials can be configured locally for Local Authentication and External AAA server using RADIUS. SSH authentication shall be through user name and password. The standby controller does not run
the PKI infrastructure to be able to handle certificate based authentication. External AAA servers shall bereachable through the default route which can be statically configured on the standby controller.
Syslog is supported on the standby controller as console logs.
Standby Monitoring using RMI IPv6 is supported starting release 17.4

Standby Monitoring CLIs

50

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Standby Monitoring using RMI•

To see power supply, fan and temperature status, the below CLI can be used on physical appliances. This output will be empty for virtual platforms.
Show environment
9800-stby#show environment summary
Number of Critical alarms:
Number of Major alarms:
Number of Minor alarms:

0
0
0

Slot
Sensorjor,Critical,Shutdown)---------- ----------------------------P0
Vin
P0
Iin
P0
Vout
P0
Iout
P0
Temp1
)(Celsius)
P0
Temp2)(Celsius)
P0
Temp3)(Celsius)
P1
Vin
P1
Iin
P1
Vout
P1
Iout
P1
Temp1
)(Celsius)
P1
Temp2)(Celsius)
P1
Temp3)(Celsius)
R0
VRRX1: VX1
R0
VRRX1: VX2
R0
VRRX1: VX3
R0
VRRX1: VX5
R0
VRRX1: VP1
R0
VRRX1: VP2
R0
VRRX1: VP3
R0
VRRX1: VP4
R0
VRRX1: VH
R0
VRRX2: VX1
R0
VRRX2: VX4
R0
VRRX2: VX5
R0
VRRX2: VP1
R0
VRRX2: VP3
R0
VRRX2: VP4
R0
VRRX2: VH
R0
VRRX3: VX1
R0
VRRX3: VX2
R0
VRRX3: VX4
R0
VRRX3: VX5
R0
VRRX3: VP1
R0
VRRX3: VP2
R0
VRRX3: VP3
R0
VRRX3: VP4
R0
VRRX3: VH
R0
Temp: RCRX IN)(Celsius)
R0
Temp: RCRX OUT)(Celsius)
R0
Temp: Yoda)(Celsius)
R0
Temp: XEPhy(110,120,130,140)(Celsius)

Current State

Reading--------------- ------------

Threshold(Minor,Ma-----------------------

NormalNormalNormalNormalNormal

218
1
12
20
31

V AC
A
V DC
A
Celsius

na
na
na
na
(na ,na ,na ,naNormal42

Celsius(na ,na ,na ,naNormal43

Celsius(na ,na ,na ,naNormalNormalNormalNormalNormal

0
0
0
1
28

V AC
A
V DC
A
Celsius

na
na
na
na
(na ,na ,na ,naNormal29

Celsius(na ,na ,na ,naNormal0

Celsius(na ,na ,na ,naNormalNormalNormalNormalNormalNormalNormalNormalNormalNormalNormalNormalNormalNormalNormalNormalNormalNormalNormalNormalNormalNormalNormalNormalNormalNormal751 mV
6937 mV
1217 mV
1222 mV
1705 mV
2489 mV
1300 mV
5070 mV
11993mV
853 mV1016 mV
1019 mV
3325 mV
1826 mV
1050 mV
11987mV
994 mV
1002 mV
750 mV751 mV
2477 mV
1197 mV
1517 mV
1514 mV
11987mV
26
Celsius

na
na
na
na
na
na
na
na
na
na
na
na
na
na
na
na
na
na
na
na
na
na
na
na
na
(52 ,57 ,62 ,73

Normal41

Celsius(62 ,67 ,72 ,80

Normal47

Celsius(71 ,76 ,81 ,90

Normal49

Celsius51

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Standby Monitoring using RMI
R0)(Celsius)
R0
sius)

•

Temp: CPU Die

Normal47

Celsius(61 ,66 ,71 ,80

Temp: FC FANSFan Speed 40%

26

Celsius(36 ,44 ,0

To get interface status on Standby controller, the below CLI can be used:show ip interface brief
Eg.
9800-stby#show ip int brief
Interface
IP-Address
GigabitEthernet1
unassigned
GigabitEthernet0
unassigned
Capwap1
unassigned
Capwap2
unassigned
Capwap3
unassigned
Capwap4
unassigned
Capwap5
unassigned
Capwap6
unassigned
Capwap7
unassigned
Capwap8
unassigned
Capwap9
unassigned
Capwap10
unassigned
Vlan1
unassigned
Vlan56
unassigned
Vlan111111.1.1.85
1.

)(Cel-

OK? Method Status
Protocol
YES unset down
down
YES NVRAM administratively down down
YES unset upup
YES unset upup
YES unset upup
YES unset upup
YES unset upup
YES unset upup
YES unset upup
YES unset upup
YES unset upup
YES unset upup
YES NVRAM down
down
YES unset down
down
YES NVRAM upup

To see IOS task CPU on the standby, the CLI show processes can be used

9800-stby#show processes ?
<1-2147483647> IOS(d) Process Number
cpuShow CPU usage per IOS(d) process
heapcheck
Show IOS(d) scheduler heapcheck configuration
historyShow ordered IOS(d) process history
memoryShow memory usage per IOS(d) process
platform
Show information per IOS-XE process
timercheckShow IOS(d) processes configured for timercheck|
Output modifiers
<cr>
<cr>

Standby Monitoring Programmatic Interfaces
The CPU, memory and interface status on standby controller can be monitored programmatic interfaces.
Here is the list of operational models required for this purpose:•

Cisco-IOS-XE-device-hardware-oper.yang: This has serial number for all FRUs in the device,including chassis. It also has information about all hardware in the system.

•

Cisco-IOS-XE-process-cpu-oper.yang: This has CPU utilization averages over intervals of past 1
min, 5 min, 5 seconds, and also per process CPU stats for IOS tasks.

•

Cisco-IOS-XE-platform-software-oper.yang: This gives Average CPU utilization of 5-second
interval and allocated memory for the processes.

2.

Cisco-IOS-XE-process-memory-oper.yang: This gives per process memory utilization.

52

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Standby Monitoring using RMI•

Cisco-IOS-XE-interfaces-oper.yang: This has interface operational data including state andstats. It has a lot of other operational data about interfaces also.

Steps to monitor the standby controller using SSH to RMI IPv4
1.

Enable SSH on the active controller. In order to do that, it is required to generate rsa key

9800(config)#crypto key generate rsa% You already have RSA keys defined named ak_vewlc_small.cisco.com.
% Do you really want to replace them? [yes/no]: yes
Choose the size of the key modulus in the range of 2048 to 4096 for your
General Purpose Keys. Choosing a key modulus greater than 512 may takea few minutes.
How many bits in the modulus [2048]: 2048
% Generating 2048 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 0 seconds)
9800(config)#
Configure Local AAA or External AAA (RADIUS) with local AAA fallback as shown below.
line vty 0 4
password Cisco
authorization exec DEVICE_ADMIN
login authentication DEVICE_ADMIN
length 0transport input sshline vty 5 15
password Cisco
authorization exec DEVICE_ADMIN
login authentication DEVICE_ADMIN
transport input telnet ssh
transport output telnet ssh
aaa authentication login DEVICE_ADMIN group AAA_GROUP_ISE1 local
aaa authorization exec DEVICE_ADMIN group AAA_GROUP_ISE1 local
aaa group server radius AAA_GROUP_ISE1
server name ISE1
radius server ISE1
address ipv4 <RMI IP> auth-port 1812 acct-port 1813
key <key>

Note: TACACS is not supported for standby. Make sure “LOCAL” is added in the method list. So user will
be authenticated locally for standby.
aaa authentication login VTY_authen_tacacs group tacacs_ise_group local
aaa authentication login VTY_authen_tacacs group tacacs_ise_group local

2. Make sure default route is configured for management VLAN.
ip route <Destination prefix> <Destination prefix mask> <Forwarding router's address>
3.

Login to the standby controller using the standby controller’s RMI IP address

ssh <username>@<RMI IP>
Password:

53

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Standby Monitoring using RMI
Note: To use Netconf-YANG SSH use the command:ssh <username>@<RMI IP> -p 830
Only the default port of 830 can be used for Netconf-YANG SSH

4.

Execute the commands show environment summary, show processes, show ip interface brief
to view the CPU, memory, interface status, PSU (Power Supply Unit) failure, fan failure and temperature.

Command for Standby Monitoring using RESTCONF
GET request:
curl --request GET --url https://<Standby RMI IP>:443/restconf/data/Cisco-IOS-XEnative:native/hostname --header 'accept: application/yang-data+json' --header'cache-control: no-cache' --header 'content-type: application/yang-data+json' -k -uusername:passwordeg.
$curl --request GET --url https://<Standby RMI IP>:443/restconf/data/Cisco-IOS-XEnative:native/hostname --header 'accept: application/yang-data+json' --header'cache-control: no-cache' --header 'content-type: application/yang-data+json' -k -uusername:password{"Cisco-IOS-XE-native:hostname": "Catalyst 9800 HA2"}
PUT request is not supported for the standby and will return an access-denied error.

Standby Monitoring in release 17.5
The following enhancements are part of this release
1. Monitoring directly on the standby controller
2. Monitoring for Standby parameters from the active controller
We will look at both of these in detail in the following sections
Monitoring directly on the standby controller
1. Support for IF-MIB - This MIB is used to monitor Interface statistics
HA-stby#snmp get-bulk v2c <ip address> public n 0 m 1000 oid ifMIB
SNMP Response: reqid 1, errstat 0, erridx 0
ifName.1 = Gi1
ifName.2 = Gi0
54

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Standby Monitoring using RMI

ifName.3 = Vo0
ifName.4 = Nu0
ifName.5 = Vl1
ifName.6 = Vl84
ifName.7 = Vl111
ifName.8 = Vl184
umang_ha-stby#$lk v2c <ip address> public n 0 m 1000 oid ifAdminStatus
SNMP Response: reqid 2, errstat 0, erridx 0
ifAdminStatus.1 = 1
ifAdminStatus.2 = 2
ifAdminStatus.3 = 1
ifAdminStatus.4 = 1
ifAdminStatus.5 = 2
ifAdminStatus.6 = 1
ifAdminStatus.7 = 1
ifAdminStatus.8 = 1
ifOperStatus.1 = 2
ifOperStatus.2 = 2
ifOperStatus.3 = 1
ifOperStatus.4 = 2
ifOperStatus.5 = 2
ifOperStatus.6 = 2
ifOperStatus.7 = 2
ifOperStatus.8 = 1
Note: Please note that traps from the standby are not supported.

2. Support to list all the sensors using show env all on the standby chassis.
a) Load image on an HA system.
b) Run show env all on the standby after active and standby are up and running.
HA-stby#sh env all
Sensor List: Environmental Monitoring
Sensor Location State Reading
Temp: BRDTEMP1 R0 Normal 35 Celsius
Temp: BRDTEMP2 R0 Normal 33 Celsius
Temp: CPU Die R0 Normal 45 Celsius

3. Standby Syslog to external serverStandby is able to send syslogs to external syslog server independently whenever user logs in
via ios SSH or NETCONFa) Bring up an HA Pairb) configure external logging server(config)#logging host <ip>c) In logging server check if we are able to recieve syslogs from standby IP whenever user login in to standby via ssh or netconf SSH
55

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Standby Monitoring using RMI

Netconf:
Sep 28 10:52:43.263: %DMI-5-AUTH_PASSED: Chassis 2 R0/0: dmiauthd: User
'asomesul' authenticated successfully from 64.104.149.222:58970 and was authorized for netconf over ssh. External groups: PRIV15
IOS SSH:
Sep 28 10:56:02.163: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user:
asomesul] [Source: 9.4.16.172] [localport: 22] at 10:56:02 UTC Mon Sep 28 2020
Sep 28 10:56:04.183: %SYS-6-LOGOUT: User asomesul has exited tty session
1(9.4.16.172)

56

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Standby Monitoring using RMI

Monitoring for Standby parameters from the active controller
1. Support for CISCO-PROCESS-MIB - This MIB is used to monitor CPU and process statistics.This is for
CPU/Memory information

In the sample output below, index 5 is chassis 1 and index 6 is chassis 2#$lk v2c <ip address> public n 0 m 1000 oid cpmProcessEntry.2
SNMP Response: reqid 16, errstat 0, erridx 0
cpmProcessEntry.2.5.2890 = linux_iosd-imag
cpmProcessEntry.2.5.10111 = vman
cpmProcessEntry.2.5.11712 = lman
cpmProcessEntry.2.5.13447 = cmand
cpmProcessEntry.2.5.17443 = cli_agent
cpmProcessEntry.2.5.21398 = psd
cpmProcessEntry.2.5.22986 = smand
cpmProcessEntry.2.5.23265 = fman_fp_image
cpmProcessEntry.2.5.23936 = repm
cpmProcessEntry.2.5.24412 = plogd
cpmProcessEntry.2.5.25914 = cman_fp
cpmProcessEntry.2.5.26655 = hman
cpmProcessEntry.2.5.26981 = fman_rp
cpmProcessEntry.2.5.27625 = dbm
cpmProcessEntry.2.6.10140 = vman
cpmProcessEntry.2.6.11662 = lman
cpmProcessEntry.2.6.13007 = cmand
cpmProcessEntry.2.6.21071 = fman_fp_image
cpmProcessEntry.2.6.23341 = psd
cpmProcessEntry.2.6.23731 = cman_fp
cpmProcessEntry.2.6.25148 = repm
cpmProcessEntry.2.6.25424 = plogd
cpmProcessEntry.2.6.26475 = hman
cpmProcessEntry.2.6.26796 = fman_rp
cpmProcessEntry.2.6.27369 = dbm
cpmProcessEntry.2.6.27660 = cli_agent
cpmProcessEntry.2.6.28153 = linux_iosd-imag
cpmProcessEntry.2.6.30537 = smand
cpmProcessEntry.4.5.2890 = 1
cpmProcessEntry.4.5.10111 = 1
cpmProcessEntry.4.5.11712 = 3
cpmProcessEntry.4.5.13447 = 0
cpmProcessEntry.4.5.17443 = 1
cpmProcessEntry.4.5.21398 = 2
cpmProcessEntry.4.5.22986 = 2
cpmProcessEntry.4.5.23265 = 2
cpmProcessEntry.4.5.23936 = 0
cpmProcessEntry.4.5.24412 = 3
cpmProcessEntry.4.5.25914 = 0
cpmProcessEntry.4.5.26655 = 3
cpmProcessEntry.4.5.26981 = 1
cpmProcessEntry.4.5.27625 = 3
cpmProcessEntry.4.6.10140 = 2
57

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Standby Monitoring using RMI

cpmProcessEntry.4.6.11662 = 2
cpmProcessEntry.4.6.13007 = 2
cpmProcessEntry.4.6.21071 = 3
cpmProcessEntry.4.6.23341 = 3
cpmProcessEntry.4.6.23731 = 2
cpmProcessEntry.4.6.25148 = 3
cpmProcessEntry.4.6.25424 = 1
cpmProcessEntry.4.6.26475 = 1

2. Support for CISCO-LWAPP-HA-MIB – This MIB is used to monitor the HA parameters related to SSO
Supported fields:
9800-HA#$lk v2c 1.1.1.1 public n 0 m 1000 oid ciscoLwappHaMIBSNMP Response: reqid 62, errstat 0, erridx 0cLMcHaPortName.0 = GigabitEthernet2
cLMcHaPortLocIpAddrType.0 = 1
cLMcHaPortLocIp.0 = A9 FE B8 4E
cLMcHaPortMask.0 = FF FF FF 00
cLMcHaPortRemoteIpAddrType.0 = 1
cLMcHaPortRemIp.0 = A9 FE B8 4F
cLMcHaKeepAliveTimeOut.0 = 100
cLMcHaChassisPriority.0 = 1
cLMcHaClearConfig.0 = 2
cLMcHaKeepAliveRetryCount.0 = 5
cLMcRmiConfigAction.0 = 1
cLMcRmiInterface.0 = Vlan184
cLMcRmiChassisANum.0 = 1
cLMcRmiChassisAIpAddrType.0 = 1
cLMcRmiChassisAIp.0 = 09 07 B8 4E
cLMcRmiChassisBNum.0 = 2
cLMcRmiChassisBIpAddrType.0 = 1
cLMcRmiChassisBIp.0 = 09 07 B8 4F
cLMcRmiGatewayFailover.0 = 1
cLMcRmiGatewayFailoverInterval.0 = 8
3. Support for cLHaPeerHotStandbyEvent - This object represents that the peer has turned hotstandby.
a)
b)
c)
d)
e)

Bring up the HA pair
Reload the standby
From active: snmp get v2c <ip address> public oid cLHaPeerHotStandbyEvent.0
Active should return 0 as standby is not hot
After standby reloads and standby becomes HOT it must again changed to 1
After Reload of standby#snmp get v2c <ip address> public oid cLHaPeerHotStandbyEvent.0
SNMP Response: reqid 31, errstat 0, erridx 0
cLHaPeerHotStandbyEvent.0 = 058

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Standby Monitoring using RMI

After reload to STANDBY HOT#snmp get v2c <ip address> public oid cLHaPeerHotStandbyEvent.0
SNMP Response: reqid 33, errstat 0, erridx 0
cLHaPeerHotStandbyEvent.0 = 1

4. Support for cLHaBulkSyncCompleteEvent - This object represents the time when the bulk sync wascomplete.
a)
b)
c)
d)
e)

Bring up the HA pair
Reload standby.
From Active: snmp get <ip address> public oid cLHaBulkSyncCompleteEvent.0
Active should return 0 as standby is not hot
After standby reloads and standby becomes HOT bulk sync must again update
After Standby Reload#snmp get <ip address> public oid cLHaBulkSyncCompleteEvent.0
SNMP Response: reqid 30, errstat 0, erridx 0
cLHaBulkSyncCompleteEvent.0 = 0Standby to Standby HOT#snmp get v2c <ip address> public oid cLHaBulkSyncCompleteEvent.0
SNMP Response: reqid 32, errstat 0, erridx 0
cLHaBulkSyncCompleteEvent.0 = 1601288785

5. List active and standby sensors using show env command.
a) Load image on an HA system.
b) Run show env all on active after active and standby are up and running.
#sh env all
Sensor List: Environmental Monitoring
SensorLocationState
Reading
Temp: BRDTEMP1
R0
Normal39 Celsius
Temp: BRDTEMP2
R0
Normal36 Celsius
Temp: CPU Die
R0
Normal47 Celsius
Stby Temp: BRDTEMP1 R0
Normal36 Celsius
Stby Temp: BRDTEMP2 R0
Normal33 Celsius
Stby Temp: CPU Die
R0
Normal46 Celsius

6. List standby sensors using the ‘show env chassis <standby chassis num> r0’ command.
a) Load image on an HA system.

59

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Standby Monitoring using RMIb) Run show env chassis <standby chassis num> r0 on active after active and standby are up
and running. To see sensors on active controller from standby use the same command withthe chassis number of the active chassis.
#sh env cha 2 r0
Sensor List: Environmental Monitoring
Sensor Location State Reading
Stby Temp: BRDTEMP1 R0 Normal 35 Celsius
Stby Temp: BRDTEMP2 R0 Normal 33 Celsius
Stby Temp: CPU Die R0 Normal 45 Celsius

7. Fetch active and standby sensors using YANGa) Load image on an HA system.
b) Run NETCONF on the CISCO-IOS-XE-environmen-oper
Bellow is the xpath module use to get this information.

Module Cisco-IOS-XE-environment-oper
Revision
2019-05-01
Revision Info
Added semantic version
Description
This module contains a collection of YANG definitions
for monitoring Environment of a Network Element.
Copyright (c) 2016-2019 by Cisco Systems, Inc.
All rights reserved.
Organization
Cisco Systems, Inc.
Imports"cisco-semver"Namespacehttp://cisco.com/ns/yang/Cisco-IOS-XE-environment-oper
Prefix environment-ios-xe-oper
Namespace Prefixes
cisco-semver http://cisco.com/ns/yang/cisco-semver
environment-ios-xe-oper
http://cisco.com/ns/yang/Cisco-IOS-XE-environmentoper
ModtypemoduleOperations"get"Below is the output of yang for reference:
Table Record Index 0 = {[0] state = Normal[1] current_reading = 35
[2] sensor_units = SENSOR_UNIT_CELSIUS[3] low_critical_threshold = 60
[4] low_normal_threshold = -2147483647[5] high_normal_threshold = 53
[6] high_critical_threshold = 60
[7] sensor_name = SENSOR_TYPE_TEMPERATURE
60

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Standby Monitoring using RMI[8] name = Temp: BRDTEMP1[9] location = R0}
Table Record Index 1 = {[0] state = Normal[1] current_reading = 33
[2] sensor_units = SENSOR_UNIT_CELSIUS[3] low_critical_threshold = 64[4] low_normal_threshold = -2147483647[5] high_normal_threshold = 57
[6] high_critical_threshold = 64
[7] sensor_name = SENSOR_TYPE_TEMPERATURE[8] name = Temp: BRDTEMP2[9] location = R0}
Table Record Index 2 = {[0] state = Normal[1] current_reading = 45
[2] sensor_units = SENSOR_UNIT_CELSIUS[3] low_critical_threshold = 104[4] low_normal_threshold = -2147483647[5] high_normal_threshold = 93
[6] high_critical_threshold = 104[7] sensor_name = SENSOR_TYPE_TEMPERATURE[8] name = Temp: CPU Die[9] location = R0}
Table Record Index 3 = {[0] state = Normal[1] current_reading = 39
[2] sensor_units = SENSOR_UNIT_CELSIUS[3] low_critical_threshold = 60
[4] low_normal_threshold = -2147483647[5] high_normal_threshold = 53
[6] high_critical_threshold = 60
[7] sensor_name = SENSOR_TYPE_TEMPERATURE[8] name = Stby Temp: BRDTEMP1[9] location = R0}
Table Record Index 4 = {[0] state = Normal[1] current_reading = 36
[2] sensor_units = SENSOR_UNIT_CELSIUS[3] low_critical_threshold = 64[4] low_normal_threshold = -2147483647[5] high_normal_threshold = 57
[6] high_critical_threshold = 64
[7] sensor_name = SENSOR_TYPE_TEMPERATURE[8] name = Stby Temp: BRDTEMP2[9] location = R0}
61

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Standby Monitoring using RMI

Table Record Index 5 = {[0] state = Normal[1] current_reading = 47
[2] sensor_units = SENSOR_UNIT_CELSIUS[3] low_critical_threshold = 104[4] low_normal_threshold = -2147483647[5] high_normal_threshold = 93
[6] high_critical_threshold = 104[7] sensor_name = SENSOR_TYPE_TEMPERATURE[8] name = Stby Temp: CPU Die[9] location = R0}

8. Get the active and standby power, fan and RP sensor information using snmpwalka) Load the Image on HA system.
b) Run the snmpwalk from any Linux machine once standby joined.
c) Run the CLI show inventory raw and check the sensors of standby and actived) Do snmpwalk on the entity mib and sensor mib check the power, fan and RP sensor arealigned with the values from the CLI output.
Below is the output of snmpwalk for reference
SNMPv2-SMI::mib-2.47.1.1.1.1.7.1 = STRING: "Multi Chassis System"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.2 = STRING: "Chassis 1"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.3 = STRING: "Chassis 1 Power Supply Bay 0"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.4 = STRING: "Chassis 1 Power Supply Module 0"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.5 = STRING: "Vin P0/0"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.6 = STRING: "Iin P0/1"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.7 = STRING: "Vout P0/2"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.8 = STRING: "Iout P0/3"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.9 = STRING: "Temp1 P0/4"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.10 = STRING: "Temp2 P0/5"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.11 = STRING: "Temp3 P0/6"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.14 = STRING: "Chassis 1 Power Supply 0"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.23 = STRING: "Chassis 1 Power Supply Bay 1"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.44 = STRING: "Chassis 1 Fan Tray"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.55 = STRING: "Chassis 1 Fan 2/0"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.56 = STRING: "Chassis 1 Fan 2/1"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.57 = STRING: "Chassis 1 Fan 2/2"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.58 = STRING: "Chassis 1 Fan 2/3"
62

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Standby Monitoring using RMI

SNMPv2-SMI::mib-2.47.1.1.1.1.7.500 = STRING: "Chassis 2"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.501 = STRING: "Chassis 2 Power Supply Bay 0"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.502 = STRING: "Chassis 2 Power Supply Module 0"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.503 = STRING: "Stby Vin P0/0"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.504 = STRING: "Stby Iin P0/1"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.505 = STRING: "Stby Vout P0/2"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.506 = STRING: "Stby Iout P0/3"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.507 = STRING: "Stby Temp1 P0/4"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.508 = STRING: "Stby Temp2 P0/5"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.509 = STRING: "Stby Temp3 P0/6"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.512 = STRING: "Chassis 2 Power Supply 0"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.521 = STRING: "Chassis 2 Power Supply Bay 1"

Interface Status of Standby controller through Active using SNMP
The following MIB objects are supported in 17.6 related to stby Interface Entries
in CISCO_LWAPP-HA-MIB:
•
•
•
•
•

stbyIfIndex
stbyIfName
stbyIfPhysAddress
stbyifOperStatus
stbyifAdminStatus

The Wireless Management interface, Redundancy Management Interface as wellas the Service Port (Device management Interface) can be used with SNMP on the
Active Controller.
MIB

MIB Object

Description

OID

CISCOLWAPPHA-MIB

stbyIfTable"A list of standby interface entries."

1.3.6.1.4.1.9.9.843.1.8.1

CISCOLWAPPHA-MIB

stbyIfEntry

An entry containing management
information applicable
to a particular interface

1.3.6.1.4.1.9.9.843.1.8.1.1

63

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Standby Monitoring using RMI
CISCOLWAPPHA-MIB

stbyifIndex"A unique value, greater than zero,for eachinterface. It is recommended thatvalues are assigned
contiguously starting from 1. The
value for eachinterface sub-layer must remain
constant at least fromone re-initialization of the entity's
networkmanagement system to the next reinitialization."

1.3.6.1.4.1.9.9.843.1.8.1.1.1

CISCOLWAPPHA-MIB

stbyifName"The textual name of the interface.
The value of thisobject should be the name of theinterface as assignedby the local device and should besuitable for use incommands entered at the device's`console'. Thismight be a text name, such as `le0' ora simple port
number, such as `1', depending on
the interface naming
syntax of the device. If several entries
in theifTable together represent a single
interface as namedby the device, then each will have thesame value of
ifName. Note that for an agent which
responds to SNMP
queries concerning an interface onsome other(proxied) device, then the value of
ifName for such aninterface is the proxied device's local
name for it.
If there is no local name, or thisobject is otherwise
not applicable, then this object
contains a zerolength string."

1.3.6.1.4.1.9.9.843.1.8.1.1.2

CISCOLWAPPHA-MIB

stbyifPhysAddress"The interface's address at its
protocol sub-layer.
For example, for an 802.x interface,
this object
normally contains a MAC address.
The interface's
media-specific MIB must define thebit and byteordering and the format of the valueof this object.

1.3.6.1.4.1.9.9.843.1.8.1.1.3

64

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Standby Monitoring using RMI
For interfaces which do not have suchan address(e.g., a serial line), this object should
contain an
octet string of zero length."
CISCOLWAPP-HAMIB

stbyifAdminStatus"The desired state of the interface.
The testing(3)state indicates that no operational
packets can bepassed. When a managed system
initializes, allinterfaces start with ifAdminStatus in
the down(2)state. As a result of either explicit
management
action or per configuration
information retained by
the managed system, ifAdminStatusis then changed toeither the up(1) or testing(3) states(or remains in
the down(2) state)."

1.3.6.1.4.1.9.9.843.1.8.1.1.4

This is based on the actual config of
the active(For eg if its administratively downthen it will be 2 else 1 for active andstandby)

CISCOLWAPPHA-MIB

stbyifOperStatus"The current operational state of theinterface. The
testing(3) state indicates that nooperational packets
can be passed. If ifAdminStatus isdown(2) thenifOperStatus should be down(2). If
ifAdminStatus ischanged to up(1) then ifOperStatus
should change toup(1) if the interface is ready totransmit andreceive network traffic; it shouldchange todormant(5) if the interface is waitingfor external
actions (such as a serial line waiting
for an incoming
connection); it should remain in thedown(2) state if
and only if there is a fault thatprevents it fromgoing to the up(1) state; it should
remain in the
notPresent(6) state if the interface

65

1.3.6.1.4.1.9.9.843.1.8.1.1.5

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Standby Monitoring using RMI
has missing(typically, hardware) components."
This is based on actual state of theinterfaceNote: Standby interface data related to MTU, Ifspeed, ifLastChange is not supported

The following is an example of the same:
WLC#snmp get-bulk v2c 111.1.1.215 public n 0 m 1000 oid stbyIfEntry
SNMP Response: reqid 1, errstat 0, erridx 0
stbyifIndex.1 = 1
stbyifIndex.2 = 2
stbyifIndex.3 = 3
stbyifIndex.4 = 4
stbyifIndex.5 = 5
stbyifIndex.6 = 6
stbyifIndex.7 = 7
stbyifIndex.8 = 8
stbyifIndex.9 = 9
stbyifIndex.10 = 10
stbyifName.1 = Gi1
stbyifName.2 = Gi0
stbyifName.3 = Vo0
stbyifName.4 = Nu0
stbyifName.5 = Vl1
stbyifName.6 = Lo0
stbyifName.7 = Vl111
stbyifName.8 = Vl333
stbyifName.9 = Vl444
stbyifName.10 = Vl555
stbyifPhysAddress.1 = 00 0C 29 23 DB 56
stbyifPhysAddress.2 = 00 00 00 00 00 00
stbyifPhysAddress.3 =stbyifPhysAddress.4 =stbyifPhysAddress.5 = 00 1E 7A 4C 89 FF
stbyifPhysAddress.6 =stbyifPhysAddress.7 = 00 1E 7A 4C 89 FF
stbyifPhysAddress.8 = 00 1E 7A 4C 89 FF
stbyifPhysAddress.9 = 00 1E 7A 4C 89 FF
66

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Standby Monitoring using RMI

stbyifPhysAddress.10 = 00 1E 7A 4C 89 FF
stbyifAdminStatus.1 = 1
stbyifAdminStatus.2 = 2
stbyifAdminStatus.3 = 1
stbyifAdminStatus.4 = 1
stbyifAdminStatus.5 = 1
stbyifAdminStatus.6 = 2
stbyifAdminStatus.7 = 1
stbyifAdminStatus.8 = 1
stbyifAdminStatus.9 = 1
stbyifAdminStatus.10 = 1
stbyifOperStatus.1 = 1
stbyifOperStatus.2 = 2
stbyifOperStatus.3 = 1
stbyifOperStatus.4 = 1
stbyifOperStatus.5 = 1
stbyifOperStatus.6 = 2
stbyifOperStatus.7 = 1
stbyifOperStatus.8 = 2
stbyifOperStatus.9 = 2
stbyifOperStatus.10 = 2

67

High Availability SSO Deployment Guide for Cisco Catalyst 9800 Series Wireless Controllers, Cisco IOS
XE Bengaluru 17.6
Standby Monitoring using RMI
Legal Information
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECTTO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THISMANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY
PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SETFORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATEDHEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITEDWARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the
University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating
system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE
SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERSDISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROMA COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL,CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR
LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF
CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be
actual addresses and phone numbers. Any examples, command display output, network topology
diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of
actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
All printed copies and duplicate soft copies are considered un-Controlled copies and the original on-line
version should be referred to for latest version.
Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the
Cisco website at www.cisco.com/go/offices.

Cisco Trademark
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S.
and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks.
Third-party trademarks mentioned are the property of their respective owners. The use of the word partner
does not imply a partnership relationship between Cisco and any other company. (1110R)

Cisco Copyright© 2020 Cisco Systems, Inc. All rights reserved.

68