1.2 Enterprise Wireless Architecture Evolution & Hands-On Lab Setup

1.2 Enterprise Wireless Architecture Evolution & Hands-On Lab Setup

Catalyst 9800 controllers run Cisco IOS XE and use the same broad configuration, programmability, telemetry, and operational conventions found across modern Catalyst platforms. That does not make IOS XE “open source”; the precise description is a modular, programmable network operating system built on a Linux kernel with Cisco control and data-plane components.

AireOS and Catalyst 9800: important differences

Legacy AireOS used controller-specific concepts such as dynamic interfaces and AP-manager behavior. Catalyst 9800 integrates wireless into IOS XE and organizes most wireless service configuration through tags and profiles. Operators gain model-driven telemetry, YANG-based NETCONF and RESTCONF, familiar IOS XE CLI behavior, install-mode software lifecycle features, and platform-dependent high availability.

Do not map old names mechanically. On Catalyst 9800, the Wireless Management Interface (WMI) is the Layer 3 interface selected for CAPWAP communication with APs. On a physical controller it is commonly an SVI, but the supported interface type depends on platform and deployment. Public-cloud C9800-CL designs, for example, use Layer 3 interfaces rather than assuming an 802.1Q SVI. The optional GigabitEthernet0 management port is isolated in the Mgmt-intf VRF and is intended for device administration. APs do not use that service interface as their CAPWAP endpoint.

Choose the virtual-controller profile before building

C9800-CL resource requirements are not a single universal minimum. Cisco publishes multiple templates. An ultra-low profile can use 2 vCPUs, 6 GB RAM, and 16 GB disk, but it has significant feature and traffic restrictions. In Cisco Modeling Labs, the commonly used small profile for a functional local-mode lab uses 4 vCPUs, 8 GB RAM, and 16 GB disk; local-mode AP data tunneling is not supported by the ultra-low CML profile. Larger profiles add CPU and memory for higher AP/client scale and throughput.

Therefore, state the intended profile and workload:

EVE-NG and other emulators do not change the appliance’s supported sizing rules. A VM that happens to boot below a supported profile is not evidence of a supported deployment.

Build a simple routed lab

A useful topology has four logical functions:

1. An administrative network to reach HTTPS/SSH and, if used, the Mgmt-intf interface.
2. A WMI Layer 3 network reachable from the AP management subnet.
3. An AP management subnet with DHCP, default gateway, DNS if using CISCO-CAPWAP-CONTROLLER discovery, and NTP reachability.
4. One or more client VLANs carried to the controller or locally switched by FlexConnect, depending on the exercise.

On a virtual controller, map virtual NICs according to the Cisco deployment guide for the chosen hypervisor. On a physical appliance, an SVI is a common WMI design:

interface Vlan10
 description WIRELESS-MANAGEMENT
 ip address 10.10.10.10 255.255.255.0
 no shutdown
!
wireless management interface Vlan10

That example demonstrates the role; it is not a rule that every WMI must be an SVI. Keep the controller’s default route and any required return routes explicit. CAPWAP control uses UDP 5246, and CAPWAP data normally uses UDP 5247. Firewalls, NAT, or a path MTU problem can allow discovery yet break join or tunneled traffic.

Discovery and trust dependencies

An AP can discover a controller from previously stored priming information, DHCP Option 43, DNS, local broadcast where applicable, Plug and Play, or other supported mechanisms. Discovery only identifies candidates. The AP then chooses a controller and proceeds through DTLS establishment, join, configuration, and run states.

Time matters because the AP and controller validate certificate lifetimes during the secure join. Configure NTP early and verify time on both sides. However, a DTLS failure is not proof of an NTP problem; packet loss, MTU, certificate state, unsupported code/AP combinations, or policy can produce similar symptoms. Troubleshoot in order: address/gateway, discovery response, bidirectional UDP, controller selection, DTLS evidence, join response, image/version compatibility, and final configuration.

A repeatable validation sequence

• Confirm the VM matches a documented resource profile and all intended NICs are present.
• Confirm the WMI selection and IP routing from the AP subnet in both directions.
• Confirm DHCP, DNS or Option 43 only if the design relies on them.
• Confirm NTP and current system time.
• Capture or debug CAPWAP only after basic reachability is proven.
• Verify the AP reaches RUN state, receives the intended policy/site/RF tags, and advertises the expected WLAN.
• For local-mode traffic, validate client VLAN reachability through the controller data path; for FlexConnect local switching, validate the AP switchport trunk and VLAN mapping.

A lab is valuable when it exposes these dependencies clearly. Treat emulator-specific shortcuts, unsupported resource allocations, and legacy AireOS terminology as lab artifacts—not production facts.