C9800 Deployment Models: Physical, Virtual, Cloud, and Embedded

C9800 Deployment Models: Physical, Virtual, Cloud, and Embedded

The Catalyst 9800 wireless LAN controller is fundamentally a flexible platform. You have choices. Depending on your organization's infrastructure, compliance requirements, and operational preferences, you can deploy the C9800 as a dedicated physical appliance, a virtual machine in your data center, a managed service in the public cloud, or even embedded directly within a Catalyst switch. This article walks you through each deployment model so you can understand the trade-offs and select the approach that fits your environment.

Why Deployment Flexibility Matters

Unlike older wireless controllers that were locked into specific hardware form factors, the C9800 separates the controller software from the underlying infrastructure. This means your wireless management experience remains consistent across different deployment models, while operational complexity, capital expenditure, and ongoing maintenance vary significantly. Whether you're a small branch office or a global enterprise, there's a C9800 deployment model designed for your needs.

C9800 Physical Appliance

The physical appliance deployment is the traditional approach: you purchase a dedicated hardware box, install it in your data center or campus network, and manage all aspects of the system yourself. For organizations that want direct control and a single point of management, this model remains popular.

Physical Appliance Models and Specifications

Cisco offers three primary physical appliance SKUs, each targeting different scale requirements:

Each model runs Cisco's IOS XE operating system and provides the same feature set and configuration model. The difference is scale and performance. If you double the performance license on the C9800-L, the throughput scales proportionally, allowing you to grow capacity without changing hardware.

Physical Appliance Installation and Bootstrap

When you unbox a C9800, your first task is basic bootstrap configuration. The appliance arrives with minimal configuration and needs an IP address, hostname, and management access before you can begin configuring wireless services. There are two primary methods to bootstrap the device:

1. Manual console configuration: Connect to the console port (RJ-45 or USB serial) and enter the IOS XE CLI setup wizard. This is straightforward but requires physical access or out-of-band access to the console.
2. Plug and Play (PnP) with Cisco DNA Center: If you configure the upstream network properly, the C9800 can discover and connect to a Cisco DNA Center instance, which then handles the bootstrap process automatically. This is the modern approach and significantly reduces deployment time.

For PnP to work, your C9800 must be able to reach the Cisco DNA Center (or PnP Connect service in the cloud). There are three discovery methods:

• DHCP option 43: Your DHCP server provides the IP address of the PnP server via option 43. This is the most reliable method if you control your DHCP infrastructure.
• DNS discovery: The device resolves the DNS entry pnpserver.localdomain to find the PnP server. Useful if you have DNS in place but want to avoid DHCP changes.
• Plug and Play Connect service: If the device cannot find a local PnP server via DHCP or DNS, it attempts to reach the cloud-based Cisco PnP Connect service using the DEVICEHELPER.cisco.com FQDN. This provides a failsafe bootstrap path.

Once the C9800 is claimed in the PnP workflow, it receives its configuration from Cisco DNA Center or your chosen provisioning system, joins a WLC tag, and becomes operational. The entire process—from unboxing to managing access points—can take just a few clicks.

Physical Appliance Network Requirements

The C9800 physical appliance connects to your network via multiple interfaces. The service port (SP) is a dedicated out-of-band management interface, separate from data plane traffic. This is important: if your upstream network is congested or down, you can still access the appliance via the SP port.

The device also provides 1G/10G front-panel ports for management and wireless traffic. These are typically connected to your upstream switch using EtherChannel or Link Aggregation Group (LAG) configuration for redundancy and throughput. LACP ACTIVE mode is required on the upstream switch; the C9800 will automatically create a single port-channel on uplink port 1 and add remaining links as part of the PnP process.

Initial Setup Process

Before your C9800 is operational and accepting access points, you need minimal configuration:

• Hostname and user login credentials with privilege level 15
• IP address and route to reach the upstream network
• Wireless management interface (WMI) configuration
• NTP and time zone settings (critical for wireless security)
• Country code within a regulatory domain (required for AP radio operation)
• Initial WLAN and policy tags (optional at this stage, can be added later)

If you're using the CLI setup wizard, you're prompted step by step. If you skip the wizard, you can complete configuration via the web GUI or CLI later. Once basic configuration is done, access points can discover the C9800 via CAPWAP broadcast and join the controller.

C9800 Virtual Appliance (C9800-CL)

The C9800-CL is a virtual machine image designed for private cloud deployments. Instead of purchasing dedicated hardware, you deploy the C9800-CL on your choice of hypervisor—VMware ESXi, KVM, Hyper-V, or Cisco NFVIS—and run the wireless controller as a VM on your existing infrastructure.

Hypervisor Support and Deployment Platforms

The C9800-CL supports multiple virtualization platforms, allowing you to choose based on your existing datacenter investments:

The single OVF (Open Virtualization Format) template works across all hypervisors, so you download one image and deploy it multiple times without re-packaging.

C9800-CL Scale and Performance Profiles

The virtual appliance comes in multiple scale profiles, all available in a single deployment package. At installation time, you select the profile that matches your needs:

This flexibility means you can right-size the VM to your actual requirements. A branch office might use a Small profile; a regional data center might use Medium or Large. If your needs grow, you can reconfigure the VM (or deploy a second controller) to add capacity.

C9800-CL Key Advantages

Deploying C9800-CL offers distinct operational benefits compared to physical hardware:

• Hardware independence: The controller runs on any x86 infrastructure you already own. No need to purchase dedicated appliances.
• Flexibility and mobility: Move the C9800-CL VM between physical servers without changing configuration. If you need to evacuate a host for maintenance, live-migrate the VM to another host.
• Resource sharing: The hypervisor allocates compute and memory resources dynamically. If your wireless controller is idle, those resources can be used by other workloads.
• Feature parity with physical: The C9800-CL supports all the same deployment modes (centralized, FlexConnect, SD-Access) and features as the physical appliance, from StateFul Switchover (SSO) to In-Service Software Upgrade (ISSU).

Virtual Network Interface Configuration

By default, the C9800-CL boots with three network interfaces. Understanding their purpose is important for correct network design:

The most common mistake is connecting all interfaces to a single vSwitch and VLAN. This creates loops and prevents the wireless management interface from reaching access points. Best practice is to map each interface to a separate vSwitch or VLAN with appropriate routing and segmentation.

VMware Security Settings and MAC Address Handling

If you're deploying on VMware ESXi, pay attention to vSwitch security settings. By default, VMware prevents MAC addresses other than the vNIC's assigned MAC from transmitting traffic. For C9800-CL to operate correctly, you must enable "Promiscuous mode" and "Forged transmits" on the port group or vSwitch where the C9800-CL interfaces connect.

Here's why: the C9800-CL operates as a wireless controller managing multiple access points. Each AP has its own MAC address. The controller must be able to send and receive packets with source/destination MACs that differ from the vNIC's own MAC. Without these security settings enabled, traffic from the controller to APs will be dropped by the hypervisor.

Example ESXi configuration:
Port group: "Wireless-Mgmt"
- Promiscuous mode: Accept
- Forged transmits: Accept
- MAC address changes: Accept (optional, but recommended)

Bootstrapping C9800-CL with PnP

The C9800-CL can also use Plug and Play for automated provisioning. When you deploy the OVF with default configurations, the VM boots and attempts to discover a PnP server. If you have Cisco DNA Center and proper network connectivity, PnP can configure the C9800-CL automatically—just claim it in the DNA Center dashboard, and the rest happens without manual CLI entry.

C9800 in the Public Cloud

For organizations seeking to avoid on-premises infrastructure entirely, Cisco offers C9800-CL as a managed service on public cloud platforms. The three major cloud service models are supported:

Cloud Service Models and Responsibility

Understanding who manages what is critical when deploying in the public cloud. Here's the typical division:

For the Catalyst 9800, Cisco recommends an IaaS approach. You deploy the C9800-CL VM on the cloud provider's infrastructure (AWS, Google Cloud, Microsoft Azure), and you manage the controller configuration and wireless network. The cloud provider manages compute, storage, and networking hardware. This gives you control of your wireless system while offloading infrastructure burden.

C9800-CL in Public Cloud: Deployment Modes

Two primary deployment architectures are supported for C9800-CL in the public cloud:

Managed VPN Deployment Mode

In this mode, you establish a VPN tunnel from your on-premises network (where the access points are located) to the cloud provider's infrastructure (where the C9800-CL runs). The APs communicate with the controller over this secure tunnel.

This approach is typical for:

• Branch offices with remote access points
• Scenarios where you want to centralize wireless management in the cloud but keep AP traffic segmented from the cloud infrastructure
• Hybrid deployments where some infrastructure is on-premises and some is in the cloud

The VPN tunnel can be established via an AWS Direct Connect connection, an Azure ExpressRoute, or a standard IPSec VPN. A route table on the cloud provider's side directs AP traffic destined for the cloud toward the C9800-CL instance.

Example architecture:

On-Premises:
Access Points (Multiple sites)
|
| (VPN tunnel)
|
AWS (Region us-east-1):
VPC 10.0.0.0/8
C9800-CL (10.0.1.0/24 subnet)
Route Table:
Destination Target
10.0.0.0/8 Local
0.0.0.0/0 AWS-GW
Upstream to internet if needed

C9800-CL with Public IP Deployment Mode

Alternatively, the C9800-CL can be exposed with a public IP address, allowing access points to connect directly from the internet. This is supported starting with IOS XE release 17.3.2.

This mode requires careful security planning. Since access points are on-premises and the controller is in the public cloud, you must authenticate and authorize which APs are allowed to join. Cisco supports filtering by IP subnet, AP MAC address, and AP serial number. On the C9800-CL, you configure AAA policies to enforce these restrictions.

Example C9800-CL AAA configuration for public IP deployment:

Configuration > Security > AAA > AAA Advanced

Authorize APs against MAC Address:
Enable [checkbox]

Authorize APs against Serial Number:
Enable [checkbox]

Important considerations for public IP deployment:

• FlexConnect only: On-premises APs must operate in FlexConnect mode (local switching). This allows traffic to switch locally if the cloud controller becomes unreachable.
• Latency sensitivity: If your APs are far from the cloud region (e.g., Asia-Pacific APs connecting to a US cloud controller), you may experience latency-related issues with roaming and real-time handoffs. Minimize this by deploying controllers close to your AP locations.
• No Layer 2 broadcast domain: The C9800-CL in the public cloud operates with only Layer 3 connectivity. This means no VLAN-level broadcast, no sniffer mode, and no HyperLocation or Multicast features across the WMI interface.
• Cisco DNA Center is not supported: DNA Center cannot be deployed behind a NAT router and cannot manage a device that is. If your C9800-CL is in the public cloud with a public IP and your APs are on-premises behind a NAT, DNA Center cannot be used for management. You configure the C9800-CL directly.

Agility and Scalability Advantages

The public cloud deployment model offers distinct advantages for specific use cases:

• Instant scale: You can spawn a C9800-CL instance in minutes. If you need to test a new feature or support a temporary event with many wireless users, launch a controller, run the test, and tear it down. No hardware procurement cycle.
• Elasticity: If client load exceeds a single C9800-CL's capacity, you can add a second controller in parallel. Cloud providers allow you to scale up and down on demand.
• Global footprint: Public cloud providers have data centers across the globe. Deploy C9800-CL instances in regions close to your users for lower latency and better compliance with data residency policies.
• Operational expenditure (OpEx) model: Pay-as-you-go instead of capital expenditure. Your wireless controller costs scale with actual usage.

Embedded Wireless Controller on Catalyst Access Points and Switches

For small deployments where a dedicated wireless controller is impractical, Cisco offers an embedded wireless controller (EWC) function. This allows a Catalyst 9100 access point or Catalyst 9000 switch to serve as a local wireless controller for nearby APs.

Embedded Wireless Controller Architecture

The Embedded Wireless Controller is a service embedded in Catalyst access points. Instead of a separate controller managing APs, one AP can become the controller and manage other APs in the same site.

Key characteristics:

• Runs Cisco IOS XE Embedded Wireless Controller (EWC-AP)
• All Catalyst 9100 access points can run in master mode where the wireless controller functions run
• Catalyst 9100 access points can also operate in client serving mode managed by the master
• Cisco Aironi 802.11ac Wave 2 access points can operate in client serving mode under an EWC-AP master
• Catalyst 9000 switches can host the embedded controller on a Catalyst 9000 switch in software-defined access (SDA) deployments

When to Use Embedded Wireless Controller

EWC is ideal for specific scenarios:

EWC-AP Features and Limitations

The embedded controller provides most of the wireless management capabilities you'd expect from a full C9800:

• Runs Cisco IOS XE
• Supports advanced enterprise features: WPA3, 802.1X, fast roaming, aWIPS, Umbrella integration, SMU, ClearAir, Flexible Radio Assignment (FRA)
• Supports mobile app or WebUI management
• Can be managed via Cisco DNA Center
• Enables migration to full controller if your site grows beyond 100 APs

The trade-off is scale. A Catalyst 9100 AP running as EWC-AP master can manage up to 100 managed APs and 2,000 wireless clients. If you exceed those limits, you need to migrate to a dedicated C9800 controller or C9800-CL.

Key Takeaways

The Catalyst 9800 gives you flexibility across four distinct deployment models, each with different trade-offs:

• Physical appliance (C9800-80/40/L): Choose this if you want direct control, no virtualization overhead, and guaranteed performance. Best for large enterprises with dedicated IT infrastructure teams. Scale from 250 APs (C9800-L) to 6,000 APs (C9800-80).
• Virtual appliance (C9800-CL on-premises): Choose this if you already have a private cloud (VMware, KVM, Hyper-V) and want to maximize your infrastructure investments. Same features as physical but with flexibility to move between hosts and share resources with other workloads.
• Public cloud (C9800-CL in AWS/Azure/GCP): Choose this if you want to avoid on-premises infrastructure and prefer operational expenditure over capital. Ideal for agile environments, temporary deployments, or organizations wanting to quickly scale wireless capacity without hardware procurement.
• Embedded controller (EWC-AP on Catalyst 9100): Choose this for small sites (under 100 APs) where a dedicated controller is unnecessary overhead. Simplifies deployment and reduces total cost of ownership for distributed small branch locations.

Whichever model you choose, the wireless configuration, management workflow, and feature set remain consistent. Your access points see the same WLC tags, policies, and authentication methods regardless of whether the controller is a 6RU physical appliance in your data center, a VM on your ESXi cluster, a cloud instance in AWS, or embedded in a 9100 AP on your branch network. This consistency is the real power of the C9800 platform.