Lesson 1 of 6

AIOps Maturity Model

Objective

In this lesson you will learn the AIOps maturity model — the four levels (reactive, proactive, predictive, autonomous), why each level matters in production wireless and wired networks, and how to perform the initial device-side prerequisites that allow an AIOps platform (Catalyst Center) to collect the telemetry and metadata required to move a network from reactive toward autonomous. In production, these steps are the foundation: without device telemetry and secure connectivity to your management/assurance system you cannot get baselines, anomaly detection, or automated remediation.

Real-world scenario: a campus with a Catalyst 9800 controller and multiple switches wants to enable AI Network Analytics and AI-Enhanced RRM in Catalyst Center. Before the cloud/center can analyze and act, each controller/switch must provide secure management interfaces (NETCONF/YANG, streaming telemetry, and a trusted certificate). This lesson shows the WHY and the device-side HOW for those prerequisites, and maps them to the AIOps maturity levels so you can understand what to expect from each stage.


Topology & Device Table

Network Topology Diagram

Key Concepts

Before you touch the CLI, understand these foundational ideas — both theory and production relevance:

  • Reactive vs Proactive vs Predictive vs Autonomous

    • Reactive: human-driven troubleshooting after an incident. In production, this is traditional NOC workflows — alerts are generated and engineers respond.
    • Proactive: system detects trends and raises warnings before major impact (e.g., rising retransmits). This matters in campuses to prevent mass disconnects during busy hours.
    • Predictive: models forecast future degradations (e.g., predicted mid-day congestion) so you can schedule changes or capacity increases.
    • Autonomous: the system not only predicts but also applies validated changes automatically (e.g., RRM parameter adjustments) — used in large deployments to scale operations.
    • Analogy: Think of these like driving modes — reactive is braking when you see the stop sign; proactive is slowing when you see a traffic jam ahead; predictive is rerouting before congestion forms; autonomous is an autopilot that navigates traffic for you.
  • Telemetry & Metadata are the fuel

    • AIOps systems require rich, continuous telemetry (streaming telemetry, YANG models, syslog, location data, NetFlow) to build baselines and detect anomalies. Without it, the system remains in reactive mode.
  • NETCONF/YANG for structured management

    • NETCONF with YANG models provides structured configuration and operational data. In practice, enabling NETCONF/YANG on controllers and switches lets Catalyst Center request/configure data reliably and run automated scripts.
  • Certificates and secure channels

    • The Catalyst Center appliance must trust devices and vice versa (HTTPS/MTLS/NETCONF). Installing a certificate on devices avoids man-in-the-middle risks and permits trust-based automation like pushing telemetry subscriptions.
  • Streaming telemetry vs. polling

    • Streaming telemetry pushes data continuously (lower latency, higher fidelity) compared to SNMP polling. For AI baselining and anomaly detection, streaming is essential because the models need fine-grained time-series data.

Step-by-step configuration

Each step below follows the pattern: what, commands, what happened, real-world note, and verify.

Step 1: Enable NETCONF-YANG on Catalyst9800-WLC

What we are doing: Enable the NETCONF-YANG agent on the Catalyst 9800 so that Catalyst Center can use structured, model-driven management to collect state and apply configurations programmatically. This is a core prerequisite for AIOps integrations and automated scripts.

configure terminal
netconf-yang
end

What just happened: The first command enters global configuration mode. netconf-yang enables the NETCONF server and YANG model support on the device, allowing authenticated management clients to open NETCONF sessions and retrieve YANG-modeled data. end exits configuration mode and commits the change to the running configuration.

Real-world note: In production you will typically perform this step during a maintenance window because enabling management interfaces may change access patterns and firewall rules.

Verify:

show netconf-yang status
NETCONF-YANG status
NETCONF Server: Enabled
YANG Datastores: running candidate
Open Sessions: 0
Supported Transports: SSH
Supported Capabilities:
  urn:ietf:params:xml:ns:netconf:base:1.0
  ietf-netconf-monitoring
  Cisco-IOS-XE-native

Step 2: Install Catalyst Center certificate on the device (establish trust)

What we are doing: Install or configure the certificate/trustpoint on the Catalyst 9800 so HTTPS/NETCONF sessions from Catalyst Center are trusted. Secure certification is necessary for encrypted management traffic and to allow the center to push automation.

configure terminal
crypto pki trustpoint CATALYST_CENTER_TRUST
 enrollment terminal
 exit
ip http secure-server
end

What just happened: crypto pki trustpoint CATALYST_CENTER_TRUST creates a trustpoint object to manage certificates. enrollment terminal prepares the device to accept certificate data (in production you would import the Catalyst Center CA-signed certificate here). ip http secure-server enables the HTTPS server on the device so the certificate will be used for secure REST/HTTPS and NETCONF-over-TLS sessions.

Real-world note: In production you will import the Catalyst Center certificate or CA chain (not shown here) into the trustpoint. Devices that lack proper certificates will still operate but will prevent secure automation and may cause certificate warnings.

Verify:

show crypto pki certificates verbose
Trustpoint: CATALYST_CENTER_TRUST
Certificate label: CATALYST_CENTER_TRUST_cert_1
Subject: CN=catalyst-center.lab.nhprep.com, O=NHPREP
Issuer: CN=Lab CA, O=NHPREP
Validity: notBefore: Apr 01 00:00:00 2026 GMT, notAfter: Apr 01 00:00:00 2028 GMT
Status: Valid
Key Usage: Digital Signature, Key Encipherment

Step 3: Configure and enable streaming telemetry (device-side subscription capability)

What we are doing: Configure the device so it can stream telemetry to Catalyst Center. Streaming telemetry provides the high-frequency time-series data AIOps requires to compute dynamic baselines and detect anomalies.

configure terminal
telemetry stream CATALYST_CENTER_STREAM
 source interface GigabitEthernet0/1
 destination 192.168.100.10 port 6500
 encoding encode-format self-describing-gpb
 end

What just happened: We created a telemetry stream named CATALYST_CENTER_STREAM. source interface defines the management interface used for the outbound stream. destination points the stream to the Catalyst Center appliance IP and port where the telemetry collector is listening. encoding selects a transport/encoding format suitable for the center. The device will now be able to push continuous telemetry data to the management appliance.

Real-world note: Encoding formats and transport ports must be coordinated with Catalyst Center. Streaming high-frequency telemetry has bandwidth and CPU implications; monitor device performance when enabling many streams.

Verify:

show telemetry stream CATALYST_CENTER_STREAM
Telemetry Stream: CATALYST_CENTER_STREAM
 Source Interface: GigabitEthernet0/1
 Destination: 192.168.100.10:6500
 Encoding: self-describing-gpb
 Status: Active
 Packets Sent: 12345
 Last Sent: 00:00:05 ago

Step 4: Assign the device to Catalyst Center inventory and enable AI Network Analytics (high-level action)

What we are doing: Register the device in Catalyst Center inventory, assign it to a site, and enable AI Network Analytics / Assurance so the center starts building baselines and issues. This is the step that transitions data into actionable insight.

! This action is performed on Catalyst Center (appliance). Command here is a representation of the center action.
configure terminal
enable ai-network-analytics
assign device Catalyst9800-WLC site Campus-Site-1
end

What just happened: Enabling ai-network-analytics tells the Catalyst Center to ingest telemetry and start generating baselines, anomalies, and issue detection for devices assigned to sites. Assigning the device to Campus-Site-1 scopes the analytics and ensures location-aware root-cause correlation.

Real-world note: In production the center will ingest telemetry, anonymize where required, and populate baselines. It may take hours for robust baselines to form depending on the environment and traffic patterns.

Verify:

show catalyst-center device status Catalyst9800-WLC
Device: Catalyst9800-WLC
Inventory State: Registered
Site: Campus-Site-1
AI Network Analytics: Enabled
Baselines: Building (approx 3h remaining)
Last telemetry received: 00:00:03 ago
Issues detected: 0

Step 5: Enable AI-Enhanced RRM (Assurance-driven optimization)

What we are doing: Enable AI-Enhanced RRM capability in the Catalyst Center so the center can suggest or apply RF parameter changes automatically for APs. This is an advanced step that moves you toward proactive/predictive/autonomous wireless optimization.

! This is a Catalyst Center operation (workflow selection)
configure terminal
enable ai-enhanced-rrm
set ai-rrm mode assurance-only
end

What just happened: enable ai-enhanced-rrm activates the AI RRM feature in the center. set ai-rrm mode assurance-only configures the workflow to Assurance-only mode (the center analyzes and suggests changes without provisioning the controller directly). Other modes may permit center-driven provisioning.

Real-world note: In production environments, many customers start with assurance-only to validate recommendations before enabling automated provisioning. This reduces risk while benefiting from AI baselines and recommendations.

Verify:

show catalyst-center ai-rrm status
AI-Enhanced RRM: Enabled
Mode: Assurance-Only
Controllers Monitored: Catalyst9800-WLC
APs Covered: 25
Last Recommendation: None
Busy Hours Data: Collecting

Verification Checklist

  • Check 1: NETCONF/YANG is enabled on the controller — use show netconf-yang status and confirm "NETCONF Server: Enabled".
  • Check 2: Certificate is installed and valid — show crypto pki certificates verbose should show a valid certificate with subject matching catalyst-center.lab.nhprep.com.
  • Check 3: Streaming telemetry is active — show telemetry stream CATALYST_CENTER_STREAM should show Status: Active and Last Sent within seconds.
  • Check 4: Catalyst Center shows the device registered and AI Network Analytics enabled — show catalyst-center device status Catalyst9800-WLC shows AI Network Analytics: Enabled and Baselines: Building.

Common Mistakes

SymptomCauseFix
Netconf sessions fail to connectNETCONF-YANG not enabled or SSH transport blockedEnsure netconf-yang was configured and verify SSH is allowed through any firewall between controller and center
Certificate import errorsWrong trustpoint or certificate formatRe-import certificate in PEM format into the configured trustpoint; ensure subject/issuer chains are correct
No telemetry data at Catalyst CenterTelemetry destination IP/port mismatch or ACL blockingVerify telemetry stream destination matches Catalyst Center IP and that firewall/ACL permits the port (e.g., 6500)
AI Baselines not formingShort data collection window; insufficient telemetryKeep AI Network Analytics enabled and ensure continuous telemetry for several hours; check telemetry packet counts on device

Key Takeaways

  • The AIOps maturity model moves from reactive → proactive → predictive → autonomous; the richer and more continuous your telemetry, the higher the model level you can achieve.
  • Device prerequisites (NETCONF/YANG, certificates, streaming telemetry) are essential: without them, Catalyst Center cannot reliably collect the data needed to build baselines and drive automation.
  • In production, enable telemetry carefully — it improves visibility and AI capability but has resource and security implications. Start in assurance-only modes before enabling automatic remediation.
  • Verification is critical: validate NETCONF/YANG, certificate validity, telemetry stream activity, and Catalyst Center device registration to ensure your network can progress from reactive to autonomous.

Tip: Treat this lesson as the "plumbing" step for AIOps. The real outcomes (issues, baselines, recommendations) appear in Catalyst Center after you complete these device-side prerequisites and allow time for data collection.


This completes Lesson 1: "AIOps Maturity Model". In Lesson 2 we will dive into "AI Baselines and Issue Detection" where we analyze what baselines look like, interpret dynamic baselines, and walk through an example anomaly and root-cause correlation.