15.1 Cisco Catalyst Center (DNA Center) Assurance & AI Network Analytics
Key Takeaways
- Cisco Catalyst Center operates on a microservices-based architecture managed by Cisco Maglev and Kubernetes; production High Availability (HA) mandates a 3-node physical cluster to maintain quorum and prevent split-brain conditions via Raft consensus.
- Model-Driven Telemetry (MDT) replaces legacy SNMP polling with a high-speed, push-based streaming architecture over gRPC, NETCONF, or RESTCONF using YANG data models, supporting both cadence-based periodic streaming and event-driven on-change subscriptions.
- Network Health Scores are calculated on a 1-to-10 scale across three unified domains: Device Health (CPU, memory, link errors, AP status), Client Health (SNR, RSSI, onboarding latency, roaming quality), and Application Health (packet loss, latency, jitter, CleanAir RF AQI).
- The Client 360 view provides a time-travel scrubber (up to 14/30 days) that tracks the deterministic four-step onboarding lifecycle: 802.11 Association, 802.1X/AAA Authentication, DHCP DORA address assignment, and DNS query resolution.
- AI Network Analytics leverages cloud-hosted machine learning to construct dynamic, time-of-day baselines that eliminate false positives, detect wanderlust/sticky clients, perform peer comparison benchmarking, and trigger Intelligent Packet Capture (iCAP) on APs upon anomaly detection.
Last updated: August 2026
15.1 Cisco Catalyst Center (DNA Center) Assurance & AI Network Analytics
Core Blueprint Focus: Cisco 350-401 ENCOR v1.2 topic 4.5 -- which v1.2 rewrote to read "describe how Cisco Catalyst Center (formerly Cisco DNA Center) is used to apply network configuration, monitoring, and management using traditional and AI-powered workflows" -- requires network engineers to diagnose enterprise campus and wireless network performance using Cisco Catalyst Center (formerly Cisco DNA Center). Candidates must master controller clustering, streaming telemetry ingestion (MDT vs. SNMP/Syslog/NetFlow/RADIUS), the 1-to-10 Health Score computation engine, Client 360 and Device 360 diagnostic time-travel, the Machine Reasoning Engine (MRE), AI-driven dynamic baselining, and Access Point Intelligent Packet Capture (iCAP).
In modern intent-based networking (IBN), traditional reactive monitoring—polling SNMP Object Identifiers (OIDs) every 5 to 15 minutes and sifting through disconnected syslog servers—fails to capture transient micro-bursts, RF interference spikes, or intermittent client onboarding failures. Cisco Catalyst Center Assurance transforms network operations into a closed-loop, proactive validation system by streaming continuous real-time telemetry from switches, routers, wireless LAN controllers (WLCs), and access points (APs) into a centralized analytics and machine learning pipeline.
+---------------------------------------------------------------------------------------------------+
| CISCO CATALYST CENTER ASSURANCE ARCHITECTURE |
+---------------------------------------------------------------------------------------------------+
| |
| [ NORTHBOUND INTERFACES ] |
| - REST APIs (HTTPS / JSON) - Webhook Event Notifications - ITSM (ServiceNow CMDB/Incidents) |
| |
| ================================== CISCO CATALYST CENTER ====================================== |
| | [ MICROSERVICES CORE ] (Cisco Maglev Orchestration / Kubernetes Pods / Hardened Linux) | |
| | +---------------------------+ +----------------------------+ +-----------------------------+ | |
| | | Time-Series TSDB (Influx) | | Search & Logs (Elastic) | | Distributed DB (Cassandra) | | |
| | +---------------------------+ +----------------------------+ +-----------------------------+ | |
| | +---------------------------+ +----------------------------+ +-----------------------------+ | |
| | | Machine Reasoning Engine | | Health Score Engine (1-10) | | AI Network Analytics Engine | | |
| | | (TAC Knowledge Graph) | | (Device, Client, App) | | (Cloud ML / Dynamic Baseline| | |
| | +---------------------------+ +----------------------------+ +-----------------------------+ | |
| ================================================================================================ |
| |
| [ SOUTHBOUND TELEMETRY INGESTION PIPELINES ] |
| - Streaming Telemetry (MDT / gRPC / NETCONF / YANG) - Syslog (RFC 5424 / Port 514) |
| - Flexible NetFlow (FNF) / Application Visibility - SNMPv2c / SNMPv3 Traps & Informs |
| - RADIUS Accounting (RFC 2866 Session Tracking) - AP Intelligent Packet Capture (iCAP) |
| |
| ================================ CAMPUS NETWORK INFRASTRUCTURE ================================= |
| | [ Catalyst 9300/9400/9500/9600 ] [ Catalyst 9800 WLCs ] [ Catalyst 9100 Wi-Fi APs ] | |
| | [ Catalyst 8000 / ISR 4000 WAN ] [ Cisco ISE (AAA/PxGrid) ] [ Wired / Wireless Clients ] | |
+---------------------------------------------------------------------------------------------------+
1. Catalyst Center Architecture, Clustering & Interface Topologies
Cisco Catalyst Center is deployed as a dedicated hardware appliance or a virtual appliance (Catalyst Center VA on VMware ESXi / AWS) powered by Cisco Maglev, a container orchestration platform built on hardened Linux and Kubernetes.
Appliance Form Factors & Capacity Scaling
| Hardware Platform | CPU & Architecture | Memory (RAM) | Managed Device Scale | Concurrent Client Scale |
|---|---|---|---|---|
| 33-Core (DN2-HW-APL-S) | 1x Intel Xeon (33 Cores) | 128 GB | Up to 1,000 devices | Up to 10,000 clients |
| 44-Core (DN2-HW-APL) | 2x Intel Xeon (44 Cores) | 256 GB | Up to 2,000 devices | Up to 25,000 clients |
| 56-Core (DN2-HW-APL-L) | 2x Intel Xeon (56 Cores) | 384 GB | Up to 4,000 devices | Up to 40,000 clients |
| 112-Core (DN2-HW-APL-XL) | 4x Intel Xeon (112 Cores) | 768 GB | Up to 10,000 devices | Up to 100,000 clients |
| Virtual Appliance (VA) | ESXi 7.0/8.0 / AWS AMI | 128–256 GB | Up to 1,000–2,000 devices | Up to 25,000 clients |
High Availability (HA) 3-Node Cluster Architecture
For mission-critical production environments, Catalyst Center supports High Availability (HA) clustering:
- Strict 3-Node Cluster Mandate: Production HA requires exactly three physical nodes. An odd number of nodes is mandatory to achieve distributed quorum and execute Raft consensus within the internal database and microservices layers (
etcd, Cassandra, GlusterFS). - No 2-Node Support: A 2-node cluster is explicitly unsupported because the loss of one node causes a split-brain condition where neither node can form a majority quorum ($N/2 + 1 = 2/2 + 1 = 2$).
- N+1 Node Resilience: A 3-node cluster tolerates the loss of a single node with zero service interruption. If one node fails, the remaining two nodes maintain a valid quorum ($3/2 + 1 = 2$).
+---------------------------------------------------------------------------------------------------+
| CATALYST CENTER 3-NODE CLUSTER INTERFACES |
+---------------------------------------------------------------------------------------------------+
| |
| +------------------------+ +------------------------+ +------------------------+ |
| | Catalyst Center Node 1 | | Catalyst Center Node 2 | | Catalyst Center Node 3 | |
| +------------------------+ +------------------------+ +------------------------+ |
| | | | | | | | | | | | | |
| | | | +==============+====+=====+=====+==============+====+=====+=====+ (Jumbo) |
| | | | ================== CLUSTER INTERFACE SUBNET ==================== MTU 9000 |
| | | | (Dedicated Inter-Node L2/L3 Link; Latency < 10ms RTT; 10 Gbps) |
| | | | |
| | | +---------------------------------------------------------------------> OOB Mgmt |
| | | CIMC / IPMI INTERFACE (Out-of-Band Hardware Control, KVM, Power) (1 Gbps) |
| | | |
| | +---------------------------------------------------------------------------> Campus Net |
| | ENTERPRISE INTERFACE (Southbound Device Control & Telemetry) (10/25 Gbps)|
| | |
| +--------------------------------------------------------------------------------> Cloud / WAN|
| INTERNET / CLOUD INTERFACE (AI Analytics, Licensing, Updates) (1/10 Gbps) |
+---------------------------------------------------------------------------------------------------+
Physical Network Interface Roles
Each Catalyst Center physical node utilizes four distinct network interfaces:
- Enterprise Interface (
eth0/enp1s0f0): Carries all southbound control, provisioning, and telemetry traffic between Catalyst Center and managed campus switches, routers, WLCs, and APs. Also serves northbound REST API clients and web GUI administrators. - Cluster Interface (
eth1/enp1s0f1): Dedicated, isolated interface for high-speed inter-node communication, database replication, and container synchronization. Must be connected to a dedicated Layer 2 broadcast domain or low-latency Layer 3 subnet. Maximum round-trip latency must be < 10 ms RTT, and MTU 9000 (jumbo frames) is strongly recommended. - Management / CIMC Interface: Cisco Integrated Management Controller port for out-of-band server hardware management, remote KVM console access, BIOS configuration, and power cycling.
- Internet / Cloud Interface: Dedicated egress interface to securely communicate with Cisco Cloud services (Cisco AI Network Analytics, Talos threat intelligence, Cisco Smart Software Licensing, and PnP Connect) over HTTPS (TCP port 443).
Loading diagram...
2. Telemetry Ingestion & Protocols: MDT vs. Legacy Models
Catalyst Center Assurance synthesizes multi-dimensional telemetry streams to build its real-time understanding of network operations.
+---------------------------------------------------------------------------------------------------+
| TELEMETRY PROTOCOL INGESTION MATRIX |
+---------------------------------------------------------------------------------------------------+
| Telemetry Source | Ingestion Protocol | Transport / Port | Key Metrics Ingested |
| :---------------------- | :------------------- | :------------------ | :------------------------- |
| **Model-Driven Tel.** | gRPC / NETCONF | TCP 25103 | CPU, Memory, Link Drops, |
| **(Streaming MDT)** | (YANG Data Models) | (device dial-out/TLS)| Interface Counters, BFD |
| **Syslog** | RFC 5424 / RFC 3164 | UDP 514 / TLS 6514 | Link Flaps, OSPF Events, |
| | Structured Logging | | Crash Dumps, Stack Changes |
| **SNMP Traps / Informs**| SNMPv2c / SNMPv3 | UDP 162 | Legacy LinkState, Power, |
| | MIB-II Traps | | Environmental Alarms |
| **NetFlow / FNF / AVC** | IPFIX / NetFlow v9 | UDP 6007 | 5-tuple, NBAR2 App ID, |
| | Flow Records | | Latency, Jitter, Packet Loss|
| **RADIUS Accounting** | RFC 2866 | UDP 1813 | Client MAC, IP, Auth State, |
| | Accounting Records | | Session Time, Roam Events |
| **Intelligent PCAP** | iCAP Protocol | TLS / Streaming PCAP| Full 802.11 / Dot1X / DHCP |
| **(iCAP on APs)** | AP Encapsulation | to Controller | Control & Management Frames|
+---------------------------------------------------------------------------------------------------+
Model-Driven Telemetry (MDT): Push vs. Pull Paradigm
Legacy network management relies on the Pull Model (SNMP polling). The management server periodically sends SNMP GET requests for specific OIDs. This model suffers from severe architectural limitations:
- High CPU overhead on routers/switches during large OID tree walks.
- Inability to detect micro-bursts, transient drops, or intermittent link flapping occurring between polling cycles (e.g., 5-minute blind spots).
- Polling jitter and inconsistent timestamping across distributed devices.
Model-Driven Telemetry (MDT) replaces SNMP with a Push Model:
- The network device continuously packages operational data structured according to standardized YANG models (Cisco Native, OpenConfig, or IETF) and streams it directly to Catalyst Center.
- Telemetry is generated directly at the internal subsystem layer in hardware ASICs or software kernel tables, dramatically reducing CPU consumption.
- Supports high-frequency, sub-second streaming intervals.
+---------------------------------------------------------------------------------------------------+
| DIAL-IN VS. DIAL-OUT TELEMETRY SESSIONS |
+---------------------------------------------------------------------------------------------------+
| |
| DIAL-IN (Collector-Initiated): |
| +-------------------------+ gRPC / NETCONF Session +-------------------+ |
| | Catalyst Center | ---------------------------------------------> | Cisco IOS-XE Node | |
| | (Telemetry Collector) | <============================================= | (TCP Port 57500) | |
| +-------------------------+ Streaming YANG Telemetry Data +-------------------+ |
| - Catalyst Center initiates outbound TCP session to device. |
| - Subscription dynamic: Terminated when TCP session closes. |
| |
| DIAL-OUT (Device-Initiated): |
| +-------------------------+ gRPC / TLS Connection +-------------------+ |
| | Catalyst Center | <--------------------------------------------- | Cisco IOS-XE Node | |
| | (TCP Port 25103) | <============================================= | (MDT Client) | |
| +-------------------------+ Streaming YANG Telemetry Data +-------------------+ |
| - Device initiates outbound session to Catalyst Center collector IP. |
| - Subscription persistent: Survives device reloads and controller restarts. |
| - Highly firewall-friendly (permits egress outbound from access devices). |
+---------------------------------------------------------------------------------------------------+
Telemetry Subscription Types
- Periodic (Cadence-Based) Subscriptions: The device pushes telemetry data at regular, configured intervals (e.g., every 500 ms, 5 seconds, or 60 seconds). Used for continuously changing counters like interface byte counts, CPU load, and memory usage.
- On-Change (Event-Driven) Subscriptions: The device pushes telemetry updates only when a state transition or threshold event occurs (e.g., an interface changes from
uptodown, a BGP neighbor drops, or a CDP neighbor appears). Minimizes network bandwidth while providing instant event notification.
Loading diagram...
3. Network Health Score Calculation (1 to 10 Scale)
Catalyst Center synthesizes ingested telemetry into a standardized, holistic Health Score ranging from 1 to 10 across three primary operational domains: Device Health, Client Health, and Application Health.
+---------------------------------------------------------------------------------------------------+
| HEALTH SCORE RATING SYSTEM & THRESHOLDS |
+---------------------------------------------------------------------------------------------------+
| Score Range | Health Status | UI Indicator | Operational Meaning |
| :------------ | :------------ | :----------- | :------------------------------------------------- |
| **8 – 10** | **Good** | **Green** | Healthy performance; all KPIs within normal bounds.|
| **4 – 7** | **Fair** | **Orange** | Degraded performance; potential user impact. |
| **1 – 3** | **Poor** | **Red** | Critical failure or severe threshold violation. |
| **No Data** | **Unknown** | **Grey** | Device unreachable or telemetry not provisioned. |
+---------------------------------------------------------------------------------------------------+
+---------------------------------------------------------------------------------------------------+
| MULTI-DOMAIN HEALTH SCORE KPI BREAKDOWN |
+---------------------------------------------------------------------------------------------------+
| |
| [ 1. DEVICE HEALTH ] (Score: 1 - 10) |
| * Switches / Routers: |
| - CPU Utilization (>90% Poor, 70-90% Fair, <70% Good) |
| - Memory Utilization (>90% Poor, 75-90% Fair, <75% Good) |
| - Link Error / Discard Rates (CRC, input/output drops >0.5% drops score) |
| - Interface Flapping & Link Availability |
| - Environmental KPIs: Temperature, Fan modules, Dual Power Supply redundancy |
| - Switch Stack Health (StackWise ring continuity, missing stack member) |
| * Access Points (APs): |
| - AP Reachability & CAPWAP Tunnel Stability |
| - Radio Utilization per Band (2.4 GHz, 5 GHz, 6 GHz >70% Poor) |
| - Channel Interference & Noise Floor |
| - Crash / Reboot History & Memory Leaks |
| * Wireless LAN Controllers (WLCs): |
| - AP Join Ratio (Joined APs vs Configured APs) |
| - Mobility Tunnel Status & Inter-WLC Keepalives |
| |
| [ 2. CLIENT HEALTH ] (Score: 1 - 10) |
| * Wired Endpoints: |
| - Port Speed & Duplex Mismatch negotiation |
| - Port Drops / Packet Discards |
| - 802.1X / MAB Authentication Latency and Failures |
| - DHCP IP Address Assignment Latency and Lease Success |
| * Wireless Endpoints: |
| - Received Signal Strength Indicator (RSSI): Good > -65 dBm, Fair -65 to -75 dBm, Poor <-75 |
| - Signal-to-Noise Ratio (SNR): Good > 25 dB, Fair 10 to 25 dB, Poor < 10 dB |
| - Client Onboarding Time: Good < 2s, Fair 2 to 5s, Poor > 5s |
| - Roaming Performance: Roam latency < 100ms, 802.11r/k/v fast transition |
| - Over-the-Air Packet Retransmission Rate (>20% Retries drops score) |
| - Current PHY Data Rate vs Minimum Capability |
| |
| [ 3. APPLICATION HEALTH ] (Score: 1 - 10) |
| * Qualitative Experience Scoring (Cisco AVC / NBAR2 Application Visibility): |
| - Packet Loss Rate (%): Real-time audio/video loss >1% degrades to Poor |
| - Network Latency / Round-Trip Time (RTT in ms): Critical SaaS / VoIP thresholds |
| - Inter-Packet Delay Variation (Jitter in ms): VoIP jitter >30ms degrades score |
| - Bandwidth Consumption & Queue Drops (QoS DSCP Queue Starvation) |
| - Cisco CleanAir RF Air Quality Index (AQI 0-100 scale; non-Wi-Fi interferers) |
+---------------------------------------------------------------------------------------------------+
4. Client 360 & Device 360 Diagnostic Views
The Client 360 and Device 360 interfaces provide deep, multi-layered investigative dashboards that correlate real-time telemetry, topology graphs, and historical events for any specific client MAC address or device IP.
The Time-Travel / Historical Scrubber
A cornerstone feature of Catalyst Center Assurance is the Time-Travel Scrubber (accessible at the top of 360 pages). It allows engineers to rewind network state up to 14 days (or 30 days with extended storage) in increments as fine as 1 minute:
- Reconstructs the exact state of RF interference, channel utilization, AP neighbor graphs, and port counters at the precise second a user experienced an outage.
- Eliminates the need to reproduce intermittent issues live.
Loading diagram...
The 4-Step Client Onboarding Journey
When troubleshooting client connectivity, Client 360 breaks down the onboarding lifecycle into four deterministic steps, measuring the exact latency and status of each:
+---------------------------------------------------------------------------------------------------+
| THE 4-STEP ONBOARDING DIAGNOSTIC LIFECYCLE |
+---------------------------------------------------------------------------------------------------+
| Step 1: ASSOCIATION |
| - Client exchanges 802.11 Probe Requests, 802.11 Open Authentication, and Association Requests. |
| - Failure Indicators: AP Max Client Capacity reached, unsupported 802.11 PHY rates, RSSI < -80. |
| |
| Step 2: AUTHENTICATION |
| - 802.1X / EAP-TLS / PEAP / MAB transaction between Client, AP/WLC (Authenticator), and Cisco ISE.|
| - Failure Indicators: RADIUS timeout, EAP-TLS certificate validation failure, wrong PSK password. |
| |
| Step 3: DHCP |
| - 4-way DORA transaction (Discover, Offer, Request, ACK) with the enterprise DHCP server. |
| - Failure Indicators: Scope exhaustion, DHCP server latency >2000ms, IP helper-address missing. |
| |
| Step 4: DNS & GATEWAY REACHABILITY |
| - Client resolves domain names via DNS and verifies default gateway reachability via ARP/ICMP. |
| - Failure Indicators: DNS query drops, NXDOMAIN, default gateway ARP resolution timeout. |
+---------------------------------------------------------------------------------------------------+
5. Issue Resolution Workflows & Machine Reasoning Engine (MRE)
Catalyst Center Assurance aggregates millions of raw telemetry data points into actionable Issues categorized by severity: P1 (Critical), P2 (High), P3 (Medium), and P4 (Low).
+---------------------------------------------------------------------------------------------------+
| MACHINE REASONING ENGINE (MRE) WORKFLOW |
+---------------------------------------------------------------------------------------------------+
| |
| [ INGESTED ANOMALY ] ---> Telemetry detects 15 wireless clients failing 802.1X in Building 4 |
| | |
| v |
| [ MRE TAC KNOWLEDGE GRAPH ] Automated Root-Cause Analysis (RCA) Engine |
| - Step 1: Queries Cisco ISE via pxGrid to inspect RADIUS logs (Result: EAP-TLS Cert Expired). |
| - Step 2: Executes parallel diagnostic command graphs on Catalyst 9800 WLC. |
| - Step 3: Verifies NTP synchronization between WLC and AAA server. |
| - Step 4: Correlates client certificate expiration timestamps against CA CRL database. |
| | |
| v |
| [ GUIDED REMEDIATION / RUNBOOK ] |
| - Root Cause: Root CA Certificate chain expired on client devices enrolled in BYOD profile. |
| - Suggested Actions: |
| 1. Renew intermediate Enterprise Sub-CA certificate in Cisco ISE Trust Store. |
| 2. Push updated Wi-Fi profile payload via MDM (Mobile Device Manager). |
| 3. Single-Click Runbook: Re-authenticate dropped sessions after certificate renewal. |
+---------------------------------------------------------------------------------------------------+
Machine Reasoning Engine (MRE) vs. Static Alerting
- Static Alerting: A traditional Network Management System (NMS) creates a separate alert for every failed ping, resulting in an overwhelming "alert storm" of hundreds of redundant emails.
- Machine Reasoning Engine (MRE): Encapsulates the diagnostic knowledge and decision trees of senior Cisco TAC escalation engineers. MRE automatically gathers diagnostic outputs across multiple switches, routers, and firewalls in parallel, eliminates symptoms, pinpointing the single underlying root cause.
6. AI Network Analytics & Intelligent Packet Capture (iCAP)
AI Network Analytics: Cloud-Powered Machine Learning
Cisco Catalyst Center integrates with Cisco AI Network Analytics, a cloud-hosted machine learning platform running in Cisco Cloud Services. Anonymized network telemetry is securely transmitted outbound over TLS 1.3 (TCP port 443).
+---------------------------------------------------------------------------------------------------+
| STATIC THRESHOLDS VS. AI MACHINE LEARNING BASELINING |
+---------------------------------------------------------------------------------------------------+
| Attribute | Static Threshold Monitoring | AI ML Dynamic Baselining |
| :--------------------- | :------------------------------ | :------------------------------------- |
| **Threshold Model** | Fixed value (e.g., CPU > 80%) | Time-of-day & Day-of-week curve |
| **Peak Hour Behavior** | Triggers false alarms during | Recognizes expected Monday morning |
| | anticipated peak usage | traffic surges as normal baseline |
| **Off-Hour Behavior** | Misses subtle 40% CPU spikes at | Instantly flags abnormal 40% CPU spike |
| | 2:00 AM on Sunday morning | at 2:00 AM as a statistical anomaly |
| **Customization** | Manual configuration per device | Self-learning, continuous adaptation |
| **Peer Comparison** | None | Benchmarks against vertical peers |
+---------------------------------------------------------------------------------------------------+
+---------------------------------------------------------------------------------------------------+
| AI NETWORK ANALYTICS CAPABILITIES |
+---------------------------------------------------------------------------------------------------+
| 1. Dynamic Baselining & Anomaly Detection: |
| Constructs hour-by-hour Gaussian baseline probability distributions for every SSID, AP, and |
| building. Anomalies are triggered only when KPI deviations breach statistical confidence bands.|
| |
| 2. Peer Comparison & Benchmarking: |
| Compares your enterprise Wi-Fi onboarding latency, roam times, and throughput against |
| anonymized industry peers (e.g., Higher Education, Healthcare, Financial Enterprise). |
| |
| 3. Wanderlust / Sticky Client Identification: |
| Identifies mobile client endpoints that fail to roam to closer APs, remaining stuck on distant |
| APs with degraded SNR (<10 dB), isolating client NIC driver bugs from AP RF coverage gaps. |
+---------------------------------------------------------------------------------------------------+
Intelligent Packet Capture (iCAP) on Catalyst 9100 APs
Traditional Wi-Fi packet analysis requires dispatching a technician with a specialized laptop sniffer to sit on-site and wait for an intermittent failure to reoccur. Intelligent Packet Capture (iCAP) embeds hardware-assisted packet capture directly into Cisco Catalyst 9100 Series APs.
+---------------------------------------------------------------------------------------------------+
| INTELLIGENT PACKET CAPTURE (iCAP) MODES |
+---------------------------------------------------------------------------------------------------+
| Capture Mode | Trigger Mechanism | Captured Content & Use Case |
| :---------------------- | :-------------------------- | :---------------------------------------- |
| **Anomaly-Triggered** | Automatic / Event-Driven | Captures pre-event and post-event packet |
| **(Reactive iCAP)** | (Triggered by 802.1X/DHCP | buffers the exact instant an onboarding |
| | failure or roaming drop) | failure occurs; zero user intervention. |
| **Scheduled / Proactive**| Manual Start by Admin | Full over-the-air capture on specified |
| **(On-Demand iCAP)** | for specific AP / Client | channels/SSIDs for live RF deep-dives. |
| **Control & Mgmt Only** | Default privacy mode | Captures 802.11 Beacon, Probe, Auth, Assoc|
| | (Filters data payloads) | EAPOL, DHCP, DNS; strips user payloads. |
| **Full Payload PCAP** | Deep application debug | Captures entire Layer 2–Layer 7 frame; |
| | (Requires admin override) | inspects application data payloads. |
+---------------------------------------------------------------------------------------------------+
- Captured packets are streamed directly from the AP over an encrypted tunnel to Catalyst Center.
- Engineers can analyze frames using the built-in web packet decoder directly within the Client 360 GUI or download a
.pcapfile for Wireshark analysis.
Test Your Knowledge
A network engineer wants to configure real-time telemetry streaming from several Cisco Catalyst 9300 switches to Cisco Catalyst Center. The switches are situated behind an enterprise firewall that permits outbound connections initiated from the internal access layer but blocks all unsolicited inbound connection attempts initiated from the central network management zone. Which Model-Driven Telemetry (MDT) architecture and transport mechanism satisfies this requirement?
A
B
C
D
Test Your Knowledge
An enterprise wireless user reports intermittent connectivity problems when moving between conference rooms. A network administrator opens Cisco Catalyst Center and reviews the Client 360 dashboard for the user's laptop. The 4-step onboarding timeline reveals that Step 1 (Association) completed in 18 ms, Step 2 (Authentication) succeeded via 802.1X in 42 ms, but Step 3 (DHCP) transitioned to Poor with a 12-second timeout before failing. What is the most likely root cause indicated by this diagnostic breakdown?
A
B
C
D
Test Your Knowledge
A network operations team notices that traditional static monitoring tools generate numerous false-positive alerts every Monday morning between 9:00 AM and 10:00 AM as thousands of employees arrive and connect to campus Wi-Fi, exceeding static CPU and association thresholds. Conversely, static monitoring failed to alert when a critical distribution switch experienced an anomalous 45% CPU spike at 3:00 AM on Sunday. How does Cisco Catalyst Center AI Network Analytics solve both operational challenges?
A
B
C
D
Test Your Knowledge
A wireless network administrator is troubleshooting an elusive, intermittent 802.1X authentication failure affecting executive laptops in a remote branch office. The administrator cannot travel to the branch to capture over-the-air packets with a physical Wireshark sniffer. Which Cisco Catalyst Center Assurance feature allows the administrator to automatically capture and analyze the exact 802.11 and EAPOL packet frames the moment the failure occurs?
A
B
C
D