What Is the Cisco Catalyst 9800? Platform Overview and Models Compared

If you're evaluating the Cisco Catalyst 9800 or just starting to work with one, the first question you need answered is simple: what exactly is it, and which model do you actually need? The answer involves more than a spec sheet. The C9800 represents a fundamentally different approach to wireless LAN controllers — one built on Cisco IOS-XE rather than the legacy AireOS platform that powered Cisco's wireless controllers for over 15 years. Understanding what that means, and how the different platform options map to different deployment scenarios, is the foundation for everything else in this series.

Why the C9800 Exists

Cisco introduced the AireOS-based WLC in 2005. It served the enterprise well — scaling through 802.11n, 802.11ac Wave 1, and Wave 2 — but it was a closed, monolithic operating system. A crash in any major process could take down the entire controller. Configuration was only possible through the CLI or GUI, with no programmatic interface. AireOS couldn't integrate into the CI/CD toolchains that network teams were increasingly expected to use, and it couldn't stream operational telemetry at the rate that modern assurance platforms need.

The C9800 was built to solve all of this. By running on Cisco IOS-XE — the same operating system that powers Catalyst switches and ISR/ASR routers — the wireless controller gained a multiprocess architecture, native NETCONF/RESTCONF support, YANG data models, model-driven streaming telemetry, and In-Service Software Upgrade (ISSU) capability. It also gained a consistent CLI that network engineers already know from routing and switching. According to Arena, Crippa, Darchis, and Katgeri in Understanding and Troubleshooting Cisco Catalyst 9800 Series Wireless Controllers (Cisco Press, 2023), the platform was built from the ground up according to four pillars: high availability, security, flexibility, and an open and programmable framework.

The 15 years of wireless innovations from AireOS weren't abandoned — the RF excellence, the RRM algorithms, the client tracking, and the wireless assurance capabilities were all carried forward and augmented with the advantages of a modern, scalable operating system.

IOS-XE: What It Actually Means for a Wireless Controller

The most important architectural difference between the C9800 and AireOS is IOS-XE's multiprocess model. On AireOS, a single process failure could crash the entire controller. On the C9800, every major wireless function runs as an isolated Linux process with its own memory and fault domain:

The C9800-40 runs five WNCd processes; the C9800-80 runs eight. The number of WNCd processes directly determines the maximum AP and client capacity — more processes allow the controller to distribute session management load and scale to higher AP counts.

Beyond resiliency, IOS-XE brings the programmability that AireOS never had. Every configuration element on the C9800 is accessible via NETCONF (TCP port 830) and RESTCONF (HTTP/HTTPS), backed by YANG data models. This isn't a bolt-on API layer — the YANG models are the native configuration interface, and the CLI is generated from them. Whatever you can configure via CLI, you can configure via NETCONF or RESTCONF with the same consistency guarantees. This is what enables integration with Ansible, Terraform, Cisco DNA Center, and custom automation pipelines.

IOS-XE also brings two troubleshooting capabilities that are genuinely transformative for wireless engineers: conditional debugs (debug a single client or AP by MAC address without generating a firehose of output for every device on the network) and radioactive tracing (trace the entire lifecycle of a client through every software layer from the moment it associates, readable in real time or downloaded as a log). Both of these are covered in the troubleshooting articles later in this series.

CAPWAP and the Split-MAC Architecture

The C9800 uses CAPWAP (Control and Provisioning of Wireless Access Points), an IETF standard protocol (RFC 5415), to communicate with its access points. CAPWAP builds two tunnels between each AP and the controller: a control channel (UDP 5246) for management traffic and a data channel (UDP 5247) for client data (in Local Mode). Both channels use DTLS encryption — all Cisco APs and appliance controllers ship with a Manufacturer Installed Certificate (MIC) used to establish the DTLS tunnel.

The split-MAC architecture divides 802.11 MAC layer responsibilities between the AP and the controller:

The AP handles real-time 802.11 functions because the latency of round-tripping every frame to the controller would be impractical. The controller handles authentication, policy enforcement, and data forwarding because centralizing these functions simplifies security enforcement, enables consistent QoS, and makes Layer 3 client roaming possible (the client's MAC and IP presence is "behind" the controller from the wired network's perspective, limiting MAC move events on the upstream switches).

In FlexConnect mode, some of these controller functions are pushed back to the AP — specifically, client data traffic is switched locally at the AP rather than tunneled to the controller. This is covered in detail in C9800 FlexConnect Configuration.

Platform Models Compared

The C9800 comes in seven distinct platform options spanning hardware appliances, virtual machines, and embedded controllers. The critical differentiator between hardware appliances and virtual appliances is the dataplane: hardware appliances use Cisco's Quantum Flow Processor (QFP) ASIC for hardware-accelerated packet forwarding, while virtual appliances handle the dataplane in software (2–3 Gbps fixed maximum, extendable with SR-IOV NICs).

C9800-40 and C9800-80: The Enterprise Workhorses

The C9800-40 and C9800-80 are the standard choice for medium-to-large campus deployments that use centralized (Local Mode) switching. Both appliances use the Cisco Quantum Flow Processor (QFP) — a 64-core programmable packet processing ASIC with four hardware threads per core, priority queues, and feature arrays that allow ACLs, AVC (Application Visibility and Control), NetFlow, and QoS to be implemented directly in the packet processing pipeline at hardware speed.

The throughput numbers published for both controllers (40 Gbps and 80 Gbps respectively) assume 1500-byte packets measured in one direction. In practice, you will almost never hit the throughput ceiling before you hit the AP or client count ceiling — wireless is a shared medium, clients send in bursts, and the maximum AP/client limit is typically reached first. The throughput ceiling matters primarily in high-density deployments where a large number of clients are doing simultaneous bulk transfers (think dense auditoriums with active video streaming).

Key differences between the two models:

Both appliances include a hardware crypto chip for DTLS encryption/decryption acceleration — at 40–80 Gbps throughput, the CPU alone cannot handle decryption of all CAPWAP data traffic. Both also support Encrypted Traffic Analytics (ETA) via integration with Cisco Stealthwatch (Secure Network Analytics), streaming detailed NetFlow statistics about encrypted traffic flows so that threats can be identified without decrypting the payload.

The service port (named GigabitEthernet0 in IOS-XE) is hard-coded into the mgmt-intf VRF and wired directly to the appliance CPU. It is separate from the data plane — use it for out-of-band management access, not for AP CAPWAP traffic.

C9800-L: The Compact Controller

The C9800-L targets small-to-medium deployments. It's physically compact (you can fit two in a 1RU rack space, though leave room above each for thermal dissipation). The C9800-L does not use a QFP chipset — instead it uses dedicated x86 CPU cores for its dataplane, which caps its maximum forwarding throughput at 5 Gbps (or 10 Gbps with the optional Performance License).

Two hardware variants exist: the C9800-L-C (four mGig copper RJ45 ports at 1 or 2.5 Gbps, plus two additional ports up to 10 Gbps) and the C9800-L-F (the two additional ports are SFP+ supporting fiber at up to 10 Gbps). The C9800-L has no internal hard disk — only bootflash — so there's no local SSD partition for extended log storage the way the C9800-40/-80 have.

Despite the reduced hardware, the C9800-L supports the full feature set of the larger appliances. The same software capabilities — ISSU, SSO, FlexConnect, all security features, NETCONF/RESTCONF — are all there. The limits are purely capacity and throughput. The Performance License doubles both the AP ceiling (from 250 to 500) and the client ceiling (from 5,000 to 10,000), and unlocks the 10 Gbps forwarding rate.

Note: the C9800-L uses a different software image than the C9800-40 and C9800-80 (even though they all run IOS-XE). You cannot boot a C9800-40 image on a C9800-L.

C9800-CL: The Virtual Controller

The C9800-CL is software — a virtual appliance with no physical hardware. It runs on:

• Private cloud: VMware ESXi, KVM, Microsoft Hyper-V, or Cisco ENCS (Enterprise Network Compute System)
• Public cloud: Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP)

The architecture differs from the appliances only in its dataplane implementation: because the dataplane is virtualized, maximum throughput is fixed at approximately 2–3 Gbps. This can be roughly doubled by using SR-IOV (Single Root I/O Virtualization) compatible NIC cards and drivers, which allow more CPU cores to be dedicated to the dataplane task — separate "high throughput" VM images are available for SR-IOV deployments. Link Aggregation Group (LAG) is supported starting with IOS-XE 17.5 on SR-IOV images.

The C9800-CL scales to the same AP and client counts as the C9800-80 (up to 6,000 APs and 64,000 clients), achieved by scaling the VM footprint and adding more WNCd processes. From a feature standpoint, the C9800-CL supports the same feature set as the physical appliances, with two notable exceptions for public cloud deployments: public cloud deployments do not support central switching (no CAPWAP data plane termination on the controller), and features that depend on central switching (such as sniffer mode AP) are not available. Public cloud C9800-CL is FlexConnect-only by design.

Two important VMware ESXi requirements: enable promiscuous mode and forged transmits on the port group. Wireless client MACs appear as source addresses coming from behind the WLC switchport — if promiscuous mode is not enabled, the ESXi host won't know to forward unicast traffic destined to client MACs to the C9800-CL VM. This is a common gotcha that causes mysterious client connectivity failures in new virtualized deployments.

Embedded Wireless Controller (EWC)

The Embedded Wireless Controller runs the C9800 control plane directly on a Catalyst 9100 access point (EWC-AP) or a Catalyst 9000 series switch (EWC-SW). There's no separate controller hardware.

EWC-AP is designed for small standalone sites — under 100 APs, up to 2,000 clients, FlexConnect only. One AP in the group runs the controller function; the rest join it as lightweight APs. The C9800 software runs in a container on the Catalyst 9100's AP OS, which is why EWC-AP cannot use more than one SVI (the AP OS provides the dataplane and doesn't expose a full IOS-XE dataplane to the container).

EWC-SW runs the C9800 control plane on the switch CPU but relies on the switch's FED (Forwarding Engine Driver) dataplane — specifically the UADP (Unified Access Data Plane) ASIC in Catalyst 9000 switches. This is the preferred option for SD-Access (Software-Defined Access) fabric deployments where the switch is already the fabric edge node.

How to Manage the C9800

The C9800 supports four management paradigms, and in practice most organizations use a mix depending on whether they're doing Day 0 initial setup, Day 1 deployment, or Day N operations:

A few practical notes on the WebUI: it uses VTY lines to process HTTP requests. The default VTY line count (15) can be exhausted when multiple browser sessions are open simultaneously. Cisco recommends bumping this to 50:

C9800(config)# line vty 16 50

It's also best practice to disable HTTP (plain-text) access and force HTTPS:

C9800(config)# no ip http server
C9800(config)# ip http secure-server
C9800(config)# ip http secure-trustpoint <trustpoint-name>

To add the C9800 to Cisco DNA Center, you need to configure the Wireless Management Interface (WMI), enable NETCONF, and ensure privilege-15 AAA authentication is in place:

C9800(config)# netconf-yang
C9800(config)# aaa new-model
C9800(config)# aaa authorization exec default local

When adding the C9800 to Prime Infrastructure, be aware that PI will overwrite the aaa authentication login default and aaa authorization exec default methods to point to the local database. If you're using TACACS+, you'll lose CLI access after PI discovery unless you revert those AAA configurations back to your TACACS+ server group afterward.

Licensing: AIR + DNA, Essential vs. Advantage

The C9800 uses Cisco Smart Software Licensing. The controller itself requires no licenses to boot — but each access point that joins requires two licenses to be entitled to connect:

• AIR Network License — covers the AP itself (one per AP)
• AIR DNA License — covers DNA-level features including assurance, advanced security, and Cisco DNA Spaces integration (one per AP)

Both license types come in two tiers:

If there are insufficient Cisco DNA licenses to cover all connected APs, an out-of-compliance message is displayed. This is informational only — it does not block access points from joining or clients from connecting. Starting with IOS-XE release 17.3.2a, the C9800 uses Smart Licensing Using Policy (SLUP), an enhanced version of Smart Licensing that eliminates registration and key generation steps, makes compliance reporting flexible (direct connection to Cisco, through a proxy, or periodic manual reporting for air-gapped networks), and provides consistent licensing behavior across all IOS-XE platforms.

Where the C9800 Fits: The Next-Generation Wireless Stack

The C9800 doesn't operate in isolation — it's one layer in Cisco's next-generation wireless stack:

The Catalyst 9100 access points include the Cisco RF ASIC — a software-defined "radio on a module" embedded in models like the 9130, 9120, and 9124. The RF ASIC provides CleanAir spectrum analysis, Zero Wait Dynamic Frequency Selection (DFS) for immediate use of DFS channels without the standard 60-second radar detection penalty, Dual Filter DFS (reducing false radar detections by 99.9%), FastLocate for consistent client location updates, and Off-Channel RRM for zero client impact RF monitoring. These RF capabilities are carried forward from AireOS and augmented by the IOS-XE platform.

Cisco DNA Spaces leverages the Wi-Fi and BLE infrastructure to provide location tracking, asset monitoring, and space analytics — turning the wireless network from a connectivity service into a business intelligence platform. From the C9800's perspective, DNA Spaces connectivity is established either through a direct connection or via the Cisco DNA Spaces Connector, a virtual appliance deployed on-premises that acts as a proxy.

Verifying the Platform: Key Show Commands

Once you have a C9800 up and running, a few commands let you quickly identify the platform, software version, and license status:

C9800# show version
Cisco IOS XE Software, Version 17.09.04a
Cisco IOS Software [Cupertino], Catalyst L3 Switch Software (CAT9K_IOSXE), Version 17.9.4a
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2023 by Cisco Systems, Inc.

Cisco Catalyst 9800-40 Wireless Controller
Processor board ID FCW2246G00R

cisco C9800-40-K9 (X86) processor with 16777216K/6147K bytes of memory.
8 Virtual Ethernet interfaces
4 Gigabit Ethernet interfaces
4 Ten Gigabit Ethernet interfaces
32768K bytes of non-volatile configuration memory.
245616752K bytes of physical memory.

...

Configuration register is 0x102

C9800# show license summary
Account Information:
  Smart Account: <your-smart-account>
  Virtual Account: Default

License Usage:
  License                 Entitlement Tag               Count Status
  -----------------------------------------------------------------------------
  network-advantage       (C9800-40-K9-DNA_NWK-ADV)      45  IN USE
  dna-advantage           (C9800-40-K9-DNA_DNA-ADV)       45  IN USE

C9800# show ap summary
Number of APs: 45

AP Name                            Slots  AP Model             Ethernet MAC    Radio MAC       Location                          Country  IP Address                                 State
----------------------------------------------------------------------------------------------------------------------------------------------------------
AP-Floor1-01                       3      C9130AXI-B           a4b2.39xx.xxxx  a4b2.39xx.xxxx  Floor 1                           US       10.10.1.101                                Registered
AP-Floor1-02                       3      C9130AXI-B           a4b2.39xx.xxxx  a4b2.39xx.xxxx  Floor 1                           US       10.10.1.102                                Registered

Choosing the Right Model

The decision framework is straightforward once you know your AP count, whether you need centralized or local switching, and whether you have existing virtualization infrastructure:

For SSO (Stateful Switchover) high availability, you pair two controllers of the same model — the active controller maintains state for all AP sessions and client sessions, and the standby takes over in subseconds on failure. This is covered in full in C9800 High Availability (SSO) Configuration Guide. For N+1 redundancy (a single backup controller serving multiple primary controllers), the C9800 supports AP-level failover via the AP Join Profile configuration.

Key Takeaways

The Cisco Catalyst 9800 is a wireless LAN controller platform built on Cisco IOS-XE, replacing the legacy AireOS platform with a multiprocess architecture, native programmatic interfaces, and hardware-accelerated data plane options. The seven platform options span from embedded controllers on access points and switches all the way to 6000-AP physical appliances, and the selection decision comes down to AP count, whether you need hardware-accelerated centralized switching, and your infrastructure preferences (physical, virtual, or cloud).

The QFP chipset is the defining hardware differentiator — present in the C9800-40 and C9800-80 appliances, it enables hardware-accelerated CAPWAP data plane termination at 40–80 Gbps. The C9800-L uses x86 CPU cores for its software dataplane; the C9800-CL uses virtualized NICs. Both are appropriate for FlexConnect deployments where APs do local switching and the controller handles only the control plane.

Every C9800 platform supports the full IOS-XE feature set for wireless — NETCONF/RESTCONF programmability, ISSU, SSO, conditional debugs, radioactive tracing, and the Tags/Profiles configuration model. The differences between platforms are capacity and dataplane implementation, not feature availability (with the exception of EWC-AP's single-SVI limitation and public cloud C9800-CL's central switching restriction).

The next article in this series covers the architecture in depth — the WNCd internals, the client state machine, and exactly how the dataplane works on each platform variant: C9800 Hardware and Software Architecture Explained.