6.1 Catalyst 9800 Controller Initialization & High Availability SSO

Key Takeaways

  • Day 0 setup can use the WebUI wizard or CLI. The optional GigabitEthernet0 management port is isolated in the Mgmt-intf VRF, while CAPWAP terminates on the Layer 3 Wireless Management Interface, commonly an SVI on physical appliances but platform- and deployment-dependent.
  • Smart Licensing Using Policy (SLUP) in Cisco IOS-XE 17.3.2+ replaces legacy evaluation modes and upfront registration tokens with an un-enforced compliance model based on Resource Utilization Measurement (RUM) reports submitted directly to CSSM, via CSLU, or through offline air-gapped uploads.
  • A secure bootstrap configures device identity, administrative AAA, the applicable country codes, trustworthy time, and cryptographic keys/certificates as required by the chosen management and AP-join design; not every item is an unconditional prerequisite to every initialization path.
  • HA SSO pairs compatible, identically provisioned controllers in Active/Standby-Hot roles and synchronizes state over supported redundancy links. Switchover is designed to preserve AP and client state, but interruption and recovery time depend on the platform, release, failure mode, network, and clients.
  • Redundancy Management Interface health checking helps distinguish a peer failure from a redundancy-link failure and mitigate dual-active conditions. Exact interface, reachability, and keepalive requirements must follow the platform and release HA guide.
Last updated: September 2026

6.1 Catalyst 9800 Controller Initialization & High Availability SSO

Core Blueprint Focus: Domain 4.0 (Wireless Network Operation) represents 20% of the Cisco WLCOR 350-101 examination. Achieving engineering mastery begins with understanding the operational bootstrap of the Cisco Catalyst 9800 Series Wireless LAN Controller (WLC) running Cisco IOS-XE, configuring modern Smart Licensing Using Policy (SLUP), and engineering enterprise-grade High Availability Stateful Switchover (HA SSO) clustering. A failure in foundational interface separation, licensing compliance, or redundancy arbitration compromises the entire enterprise wireless infrastructure.


1. Day 0 Controller Initialization & Interface Architecture

When commissioning a physical Catalyst 9800 appliance (9800-L, 9800-40, 9800-80) or virtual appliance (9800-CL), network engineers must establish foundational management reachability, cryptographic identity, and interface segmentation.

Day 0 WebUI Provisioning Wizard vs. Deterministic CLI Bootstrap

Upon initial power-on without a valid startup configuration (startup-config), the Catalyst 9800 provides two initialization vectors:

  1. Day 0 WebUI Setup Wizard:
    • The controller boots into a temporary setup utility. If connected to an access switch port with a running DHCP server, or accessed via its service port default IP (192.168.1.1), the controller presents an intuitive web-based initialization wizard.
    • While convenient for rapid branch rollouts or proof-of-concept labs, the WebUI wizard abstracts critical parameters—such as explicit Virtual Routing and Forwarding (VRF) separation, granular cryptographic key lengths, and fine-grained AAA authentication models.
  2. Manual CLI Bootstrap:
    • For enterprise campus deployments, experienced engineers bypass the automated configuration dialog (Would you like to enter the initial configuration dialog? [yes/no]: no) to execute a deterministic CLI bootstrap.
    • This ensures strict adherence to corporate security baselines, correct VRF boundary enforcement, deterministic routing metrics, and granular parameter tuning.
+-----------------------------------------------------------------------------------------+
|                               CATALYST 9800 ROUTING ARCHITECTURE                       |
|                                                                                         |
|  +-------------------------------------+   +-----------------------------------------+  |
|  |      VRF: Mgmt-intf (Isolated)      |   |          GLOBAL ROUTING TABLE           |  |
|  |                                     |   |                                         |  |
|  |   GigabitEthernet 0 (Physical Port) |   |   GigabitEthernet 1 (802.1Q Trunk Port) |  |
|  |   - Out-of-Band (OOB) Management    |   |   - SVI Vlan 10: Wireless Mgmt (WMI)    |  |
|  |   - SSH, HTTPS, NETCONF, RESTCONF   |   |     * CAPWAP Termination (UDP 5246/5247)|  |
|  |   - Isolated from Wireless Planes   |   |   - SVI Vlan 20: Client Data VLANs      |  |
|  +-------------------------------------+   +-----------------------------------------+  |
+-----------------------------------------------------------------------------------------+

Interface Architecture: Out-of-Band Management vs. Wireless Management Interface (WMI)

Catalyst 9800 deployments distinguish the optional out-of-band administrative path from the in-band wireless infrastructure path:

  • Out-of-Band (OOB) Management Interface (GigabitEthernet 0):
    • Dedicated physical RJ-45 port isolated into the predefined Mgmt-intf VRF.
    • Used strictly for administrative management plane traffic: Secure Shell (SSH), HTTPS WebUI console, SNMP polling, syslog export, and model-driven telemetry (NETCONF on port 830, RESTCONF on port 443).
    • Critical Architectural Rule: The GigabitEthernet 0 interface cannot terminate CAPWAP tunnels from Access Points. Traffic arriving on this port is completely isolated from the wireless control and data planes. This architecture ensures administrators maintain console and management reachability even during campus broadcast storms or distributed denial-of-service (DDoS) events directed at wireless client VLANs.
  • Wireless Management Interface (WMI):
    • A Layer 3 interface selected for wireless management. It is commonly an SVI on a physical appliance, while supported interface forms vary by platform and deployment.
    • Must be explicitly declared as the controller's wireless anchor using the global configuration command: wireless management interface Vlan10.
    • Serves as the destination IP address for all Access Point discovery, DTLS session handshakes, and CAPWAP tunnel termination (UDP 5246 for Control, UDP 5247 for Data).
    • Handles inter-controller mobility tunneling and Cisco Catalyst Center (formerly DNA Center) telemetry streaming.

Foundational System Parameters & Security Prerequisites

Before production AP join or HA deployment, establish the system parameters required by the selected management, certificate, regulatory, and redundancy design:

  1. Cryptographic Identity & SSH: Configure supported keys and certificates for the intended SSH and PKI design. The following example creates an RSA key, but certificate type, size, trustpoint, and lifecycle should follow the current security policy and release documentation:
    hostname C9800-CORE-01
    ip domain name cisco.local
    crypto key generate rsa modulus 2048
    
  2. AAA Security & Role-Based Access Control:
    aaa new-model
    aaa authentication login default local
    aaa authorization exec default local
    username admin privilege 15 secret CiscoWLAN#2026!
    
  3. Network Time Protocol (NTP) Synchronization: NTP synchronization is not merely a logging best practice; it is a mandatory prerequisite for AP join. Cisco APs authenticate controllers using X.509 certificates (Manufacturing Installed Certificates [MIC] or Self-Signed Certificates [SSC]). If the controller's clock is outside the certificate's validity window (Not Before / Not After), the cryptographic DTLS handshake terminates instantly with a fatal error.
    ntp server 10.10.10.5 prefer
    clock timezone UTC 0 0
    
  4. Regulatory Domain & Country Codes: The regulatory country code dictates channel availability, Dynamic Frequency Selection (DFS) radar scanning requirements, and maximum Equivalent Isotropically Radiated Power (EIRP) limits. APs cannot enable their 2.4 GHz, 5 GHz, or 6 GHz radios until a matching country code is applied on the controller:
    ap dot11 5ghz country US
    ap dot11 24ghz country US
    ap dot11 6ghz country US
    

2. Licensing Architecture: Smart Licensing Using Policy (SLUP)

Beginning in Cisco IOS-XE 17.3.2, Cisco introduced Smart Licensing Using Policy (SLUP) across all Catalyst 9800 platforms. SLUP fundamentally alters how software entitlements are tracked, shifting from an enforcement-based model to a compliance-and-reporting model.

Evolution from Legacy Smart Licensing to SLUP

Under legacy Cisco Smart Licensing, controllers required upfront registration tokens generated from Cisco Smart Software Manager (CSSM). Controllers maintained a continuous connection to CSSM; if synchronization failed for over 90 days, the controller transitioned into an "Out-of-Compliance" authorization state, displaying persistent nag banners and restricting operational features.

Under Smart Licensing Using Policy (SLUP):

  • No Upfront Registration Tokens: The controller boots directly into an operational state without requiring an initial token or evaluation license countdown.
  • Un-enforced Operational Model: Features are never crippled or blocked due to licensing connectivity failures. Devices function normally regardless of whether they have communicated with CSSM.
  • Policy-Driven Reporting: Entitlement consumption is tracked locally in the form of signed Resource Utilization Measurement (RUM) records. RUM reports record the number of active Access Points and tier levels consumed over time.
  • Reporting Policies: Defined by Cisco or organizational policy. For standard enterprise accounts, policy typically requires reporting usage at least once every 365 days, or within 90 days following a significant change in consumed license counts.

License Tiers and Packaging

Catalyst 9800 licensing follows Cisco's standard DNA software subscription architecture, requiring two complementary components per connected Access Point:

  1. Network License (Perpetual / Base Hardware Entitlement):
    • Network Essentials: Base wireless features, standard 802.11 operations, local and FlexConnect switching, basic QoS, and static routing.
    • Network Advantage: Advanced high availability (HA SSO), advanced telemetry, Flexible Radio Assignment (FRA), Cisco CleanAir spectrum intelligence, and advanced segmentation.
  2. Cisco DNA Software License (Term Subscription - 3, 5, or 7 Years):
    • Cisco DNA Essentials: Basic Catalyst Center integration, basic health monitoring, software image management (SWIM).
    • Cisco DNA Advantage / Premier: Advanced AI Network Analytics, AI-Enhanced Radio Resource Management (AI-RRM), Cisco Spaces IoT services, Encrypted Traffic Analytics (ETA), and automated Software Maintenance Updates (SMU).
AttributeNetwork EssentialsNetwork AdvantageCisco DNA EssentialsCisco DNA Advantage
License TypePerpetualPerpetualSubscription (3/5/7 yr)Subscription (3/5/7 yr)
HA SSO ClusteringSupportedSupportedSupportedSupported
Catalyst Center AssuranceBasic HealthBasic HealthBaseline MonitoringFull AI-Assurance / 360 Analytics
Radio Resource MgmtStandard RRMAdvanced FRA / CleanAirStandard RRMAI-Enhanced Cloud RRM
Fabric Wireless (SDA)Not SupportedSupportedNot SupportedSupported

SLUP Reporting Topologies and Deployment Models

Depending on security policies and internet reachability, enterprise controllers submit RUM reports through one of four topologies:

+-----------------------------------------------------------------------------------------+
|                               SLUP CONNECTIVITY TOPOLOGIES                              |
|                                                                                         |
|  1. DIRECT CONNECT (HTTPS)                                                              |
|     [ Catalyst 9800 ] ----------------- HTTPS (Smart Transport) ----------------> [CSSM]|
|                                                                                         |
|  2. CSLU ON-PREMISES COLLECTOR                                                          |
|     [ Catalyst 9800 ] ---- REST / Pull ----> [ Cisco Smart License Utility ] ---> [CSSM]|
|                                                                                         |
|  3. CISCO CATALYST CENTER PROXY                                                         |
|     [ Catalyst 9800 ] ----------------- Managed Inventory ---------------------> [C1000]|
|                                                                                   |     |
|                                                                                 [CSSM]  |
|                                                                                         |
|  4. OFFLINE / AIR-GAPPED (FILE TRANSFER)                                                |
|     [ Catalyst 9800 ] === Export RUM ===> [ Admin PC ] === Manual Web ===> [CSSM Cloud] |
|     [ Catalyst 9800 ] <== Import ACK <=== [ Admin PC ] <== Download ACK == [CSSM Cloud] |
+-----------------------------------------------------------------------------------------+
  1. Connected Directly to CSSM:
    • The controller communicates directly with https://smartreceiver.cisco.com over HTTPS (port 443) using Smart Transport. RUM reports are automatically pushed on a schedule.
  2. Connected via Cisco Smart License Utility (CSLU):
    • An on-premises lightweight Windows or Linux utility collects RUM reports from network devices via REST API or push notifications, aggregates records, and uploads them to CSSM.
  3. Connected via Cisco Catalyst Center:
    • Catalyst Center acts as the centralized on-prem licensing aggregator for all managed Catalyst 9800 controllers and switches, synchronizing RUM usage directly with CSSM.
  4. Offline / Air-Gapped Mode (Disconnected Networks):
    • In highly secure environments (financial datacenters, defense, classified networks) with zero outbound internet access:
      • The administrator exports a RUM report file from the controller CLI or WebUI: license smart save usage all file bootflash:rum-report.tar.gz.
      • The file is transferred to an internet-connected workstation and manually uploaded to the Cisco Smart Software Manager portal.
      • CSSM generates an Acknowledgment (ACK) file.
      • The administrator transfers the ACK file back to the controller's bootflash and imports it: license smart import bootflash:ack-file.tar.gz.
      • This clears pending RUM logs on the controller and resets the policy reporting interval.

SLUP CLI Configuration and Verification

! --- Configure Smart Transport for Direct Cloud Reporting ---
license smart transport smart
license smart url default

! --- Trigger Immediate Synchronization of RUM Reports ---
license smart sync all

! --- Verification Commands ---
show license status
show license summary
show license usage

3. High Availability Stateful Switchover (HA SSO) Architecture

In mission-critical enterprise environments, controller downtime halts campus operations. Cisco Catalyst 9800 provides High Availability Stateful Switchover (HA SSO), an active/standby 1:1 redundancy architecture intended to preserve synchronized state and reduce disruption during supported failure and maintenance events.

+-----------------------------------------------------------------------------------------+
|                                 HA SSO 1:1 REDUNDANCY MODEL                             |
|                                                                                         |
|       +----------------------------+            +----------------------------+          |
|       |  CHASSIS 1: ACTIVE (Pri 2) |            |  CHASSIS 2: STANDBY (Pri 1)|          |
|       |  - Active Control Plane    |            |  - Standby-Hot Daemon State|          |
|       |  - Active Data Plane       |            |  - Inactive Forwarding     |          |
|       +--------------+-------------+            +--------------+-------------+          |
|                      |                                         |                        |
|                      | [RP] Dedicated Redundancy Port Link [RP]|                        |
|                      |=========================================|                        |
|                      |     Redundancy state synchronization    |                        |
|                      |                                         |                        |
|                      | [KA] Out-of-Band Keepalive Link (Gi0)[KA|                        |
|                      | - - - - - - - - - - - - - - - - - - - - |                        |
|                      |       Dual-Active / Split-Brain Check   |                        |
|                      |                                         |                        |
|       +--------------+-----------------------------------------+-------------+          |
|       |                                                                      |          |
|       |                SHARED VIRTUAL IP (VIP) & VIRTUAL MAC                 |          |
|       |                    Wireless Management: 10.10.10.10                  |          |
|       |                                                                      |          |
|       +----------------------------------------------------------------------+          |
+-----------------------------------------------------------------------------------------+

Architectural Fundamentals of HA SSO

An HA SSO pair operates as a single logical controller to the rest of the enterprise network:

  • Hardware & Software Parity: Both appliances must be identical hardware models (e.g., two 9800-40s or two 9800-80s) or identical virtual deployment scale profiles (e.g., two 9800-CL Medium profiles). Both units must run the exact same Cisco IOS-XE software maintenance release.
  • Role Designation (Active vs. Standby-Hot):
    • Active Controller: Manages the active control plane, runs RRM algorithms, interacts with external RADIUS servers (Cisco ISE), maintains active CAPWAP control tunnels, and processes data plane packet forwarding.
    • Standby-Hot Controller: Fully booted into a synchronized state. It mirrors the active controller's database in real time. It does not process control protocols or forward client traffic while in standby mode, but its memory structures are fully primed to take over instantaneously.
  • Shared Network Identity: Both chassis share a single Virtual IP (VIP) address assigned to the WMI and a single Virtual MAC address. Downstream distribution switches, upstream core routers, Access Points, and wireless clients communicate with one logical entity. Upon switchover, the standby controller assumes the VIP and Virtual MAC, broadcasting gratuitous ARPs (GARPs) to update adjacent switch MAC address tables.

The Redundancy Port (RP) and State Checkpointing

The two controllers are interconnected via their dedicated physical Redundancy Ports (RP):

  • On physical appliances (9800-40, 9800-80), the RP is a dedicated 10GE or 1GE port. On the 9800-L, dedicated RJ-45/SFP redundancy ports are provided. On the 9800-CL, a dedicated virtual network interface card (vNIC 3) is mapped to an isolated virtual switch port group.
  • The RP link carries the platform’s redundancy control and state-synchronization traffic.
  • Checkpointed Session States: The active controller continuously replicates runtime state across the RP:
    • AP CAPWAP State Machine: All DTLS keys, sequence numbers, and keepalive timers.
    • Client Authentication Contexts: 802.1X Pairwise Master Keys (PMK), fast roam FT keys, DHCP/IP bindings, and authorization ACLs.
    • Configuration Sync: Any configuration change executed on the active controller is automatically committed to the standby controller's memory and startup configuration.

Synchronized state allows many AP and client sessions to survive a supported switchover, but an engineer must validate the specific platform, release, topology, failure mode, and client behavior. HA SSO reduces disruption; it does not create a universal sub-500-ms or zero-packet-loss guarantee.

Chassis Renumbering and Priority Settings

To ensure deterministic role selection (preventing the secondary controller from preempting an existing operational active controller during reloads), engineers assign explicit chassis numbers and priorities:

  • Chassis Priority: Values range from 1 to 2. A higher priority wins the active election. Setting Chassis 1 to Priority 2 and Chassis 2 to Priority 1 ensures Chassis 1 assumes the active role when both boot simultaneously.

4. Dual-Active Detection (DAD) & Redundancy Management Interface (RMI)

High availability systems must be resilient not only against primary unit failure, but also against communication partition failures that could lead to catastrophic dual-active scenarios.

The Split-Brain Dilemma

A split-brain condition occurs if the physical Redundancy Port link fails or is accidentally disconnected while both controllers remain fully operational:

  • Without defensive mechanisms, the Standby controller would assume the Active is dead and declare itself Active.
  • Both controllers would simultaneously broadcast gratuitous ARPs claiming the identical Virtual IP and Virtual MAC address.
  • This duplicate IP/MAC conflict causes severe MAC flapping on campus switches, blackholing AP CAPWAP traffic and collapsing enterprise wireless service.

Redundancy Management Interface (RMI) HA SSO Architecture

In modern Cisco IOS-XE releases, Cisco recommends deploying HA SSO using the Redundancy Management Interface (RMI) architecture. RMI introduces in-band health monitoring that operates alongside the dedicated out-of-band Redundancy Port:

+-----------------------------------------------------------------------------------------+
|                        RMI HA SSO INTERFACE & IP ADDRESS SCHEME                         |
|                                                                                         |
|  VLAN 10: Wireless Management Network (Subnet: 10.10.10.0/24, Gateway: 10.10.10.1)      |
|                                                                                         |
|  - Shared Wireless Management Virtual IP (VIP): 10.10.10.10                             |
|  - Chassis 1 Local RMI IP:                      10.10.10.11                             |
|  - Chassis 2 Local RMI IP:                      10.10.10.12                             |
|                                                                                         |
|  Dual-Active Arbitration Logic:                                                         |
|  1. RP Link Lost -> Standby sends ICMP/UDP heartbeats to Active via RMI IP (10.10.10.11)|
|  2. Active responds on RMI -> Standby recognizes RP fault; STANDBY SUPPRESSES TAKEOVER |
|  3. Standby pings Default Gateway (10.10.10.1) -> Verifies own uplink integrity         |
+-----------------------------------------------------------------------------------------+
  1. IP Address Triad: On the Wireless Management Interface SVI (e.g., VLAN 10), three distinct IP addresses are configured:
    • Virtual IP (VIP): The shared operational IP (10.10.10.10) that APs use for CAPWAP tunnels.
    • Chassis 1 Local RMI IP: A dedicated static IP (10.10.10.11) bound to Chassis 1.
    • Chassis 2 Local RMI IP: A dedicated static IP (10.10.10.12) bound to Chassis 2.
  2. In-Band Health Monitoring: In addition to millisecond heartbeats across the dedicated physical RP link, the controllers continuously exchange health probes across the campus distribution switch trunk using their local RMI IP addresses.
  3. Dual-Active Arbitration Flow:
    • If the dedicated RP cable is cut, the Standby controller detects heartbeat loss on the RP.
    • Before asserting Active authority, the Standby immediately queries Chassis 1 over the RMI interface (10.10.10.11).
    • Because Chassis 1 is still powered on and operational, it answers the RMI query. The Standby controller recognizes that the RP link is partitioned, suppresses failover, and enters Recovery Mode while raising a critical syslog alarm.
    • If neither the RP nor the RMI receives a response, the Standby pings the configured default gateway (10.10.10.1). If gateway reachability is verified, the Standby assumes the Active role, confident that the primary chassis has suffered a complete catastrophic hardware or power failure.

Secondary Keepalive (KA) Interface

As an additional defensive layer, administrators can bind the out-of-band management port (GigabitEthernet 0 in Mgmt-intf VRF) as a secondary keepalive port. This provides three independent physical paths for heartbeat arbitration: RP, RMI, and KA.


5. Maintenance Procedures: In-Service Software Upgrade (ISSU)

Traditional wireless controller upgrades require scheduling campus-wide maintenance windows and dropping client connectivity. Catalyst 9800 HA SSO supports In-Service Software Upgrade (ISSU), enabling hitless OS upgrades:

+-----------------------------------------------------------------------------------------+
|                                ISSU THREE-PHASE WORKFLOW                                |
|                                                                                         |
|  [Phase 1: Standby Upgrade] --> [Phase 2: Stateful Switchover] --> [Phase 3: Active Upgrade]   |
|  - Target IOS-XE image         - Graceful failover to         - Original active chassis |
|    copied to standby            newly upgraded standby          reloads with new image  |
|  - Standby reloads with new    - Clients & APs remain         - Reconnects as Standby-  |
|    code while Active runs       completely uninterrupted        Hot; upgrade committed  |
+-----------------------------------------------------------------------------------------+

During an ISSU procedure:

  1. The new Cisco IOS-XE .bin package is loaded onto both chassis.
  2. The system upgrades the Standby controller first. The Standby reloads running the new code release and rejoins the HA cluster in a backward-compatible standby state.
  3. A controlled, stateful switchover is executed. The newly upgraded Standby becomes the Active controller without dropping AP CAPWAP tunnels or client sessions.
  4. The former Active controller reloads, boots into the new software release, and assumes the Standby-Hot role.
  5. The engineer commits the upgrade (install commit), finalizing the hitless software lifecycle.

6. End-to-End HA SSO Configuration & Verification CLI

The following configuration demonstrates configuring an HA SSO pair with dedicated Redundancy Port (RP), Redundancy Management Interface (RMI), and secondary Keepalive (KA):

! =========================================================================
! STEP 1: INITIAL CHASSIS 1 BOOTSTRAP (ON CONTROLLER 1)
! =========================================================================
C9800-01# chassis 1 renumber 1
C9800-01# chassis 1 priority 2

C9800-01# configure terminal
! Configure Out-of-Band Management (Secondary Keepalive)
interface GigabitEthernet0
 vrf forwarding Mgmt-intf
 ip address 192.168.1.11 255.255.255.0
 no shutdown
exit

! Configure Wireless Management SVI with Virtual IP
interface Vlan10
 description WMI_CAPWAP_TERMINATION
 ip address 10.10.10.10 255.255.255.0
 no shutdown
exit
wireless management interface Vlan10

! Configure Redundancy Management Interface (RMI) and SSO Mode
redundancy
 mode sso
exit

! Configure Chassis RMI and Local IP Mapping
chassis 1 address 10.10.10.11
chassis 2 address 10.10.10.12
chassis 1 keepalive-interface GigabitEthernet0
end
write memory

! =========================================================================
! STEP 2: INITIAL CHASSIS 2 BOOTSTRAP (ON CONTROLLER 2)
! =========================================================================
C9800-02# chassis 1 renumber 2
C9800-02# chassis 2 priority 1

C9800-02# configure terminal
interface GigabitEthernet0
 vrf forwarding Mgmt-intf
 ip address 192.168.1.12 255.255.255.0
 no shutdown
exit

interface Vlan10
 ip address 10.10.10.10 255.255.255.0
 no shutdown
exit
wireless management interface Vlan10

redundancy
 mode sso
exit

chassis 1 address 10.10.10.11
chassis 2 address 10.10.10.12
chassis 2 keepalive-interface GigabitEthernet0
end
write memory

! Reload Chassis 2 to initiate clustering across connected RP cable
C9800-02# reload

! =========================================================================
! STEP 3: CLUSTER VERIFICATION COMMANDS (ON ACTIVE CONTROLLER)
! =========================================================================
! Verify cluster operating mode and unit states
C9800-01# show redundancy
! Output highlights:
!   Operating Redundancy Mode = sso
!   Current Software State = ACTIVE (Unit 1), STANDBY HOT (Unit 2)

C9800-01# show redundancy states
! Output highlights:
!   My state = 13 -ACTIVE
!   Peer state = 8 -STANDBY HOT

C9800-01# show chassis
! Displays chassis priority, role, and MAC addresses

C9800-01# show chassis rmi
! Verifies RMI IP addresses, gateway reachability, and DAD state
Loading diagram...
Catalyst 9800 HA SSO Multi-Tier Link Architecture
Test Your Knowledge

An enterprise wireless engineer is pairing two physical Cisco Catalyst 9800-40 controllers into a High Availability Stateful Switchover (HA SSO) cluster. Which combination of hardware, software, and physical interconnect conditions is mandatory before the controllers can successfully negotiate an Active/Standby-Hot operational state?

A
B
C
D
Test Your Knowledge

A defense contractor deploys a Cisco Catalyst 9800-CL virtual controller in a classified, air-gapped facility with zero inbound or outbound internet reachability. The network team must maintain licensing compliance under Smart Licensing Using Policy (SLUP). Which operational procedure accurately describes how license reporting is accomplished in this disconnected environment?

A
B
C
D
Test Your Knowledge

In a Catalyst 9800 HA SSO deployment utilizing the Redundancy Management Interface (RMI), a technician accidentally cuts the primary cable connecting the dedicated Redundancy Ports (RP) between Chassis 1 (Active) and Chassis 2 (Standby-Hot). What prevents Chassis 2 from erroneously declaring Chassis 1 dead and triggering a catastrophic split-brain dual-active scenario?

A
B
C
D
Test Your Knowledge

A newly deployed Cisco Catalyst 9800-L controller fails to join any lightweight Access Points during commissioning. When reviewing the console logs, the engineer notices that the APs discover the controller and initiate communication on UDP port 5246, but the DTLS handshake consistently aborts with the message '%DTLS-3-HANDSHAKE_FAILURE: certificate verify failed'. Physical reachability and routing are verified. What is the most probable system-level cause of this failure?

A
B
C
D