Catalyst 9800-CL in CML: What You Can and Can't Actually Lab

If you have tried to build a wireless lab in Cisco Modeling Labs, you have probably hit the same wall everyone hits: you drop a Catalyst 9800-CL on the canvas, configure it perfectly, and show ap summary stubbornly reports zero access points forever. Nothing is wrong with your configuration. The platform simply cannot do what you are asking.

This article documents exactly what a 9800-CL can and cannot do inside CML, with real output captured from a controller running IOS XE 17.18.2. Every command result below came off an actual lab controller, including the failures. If you are planning study time around a virtual wireless lab, read this first so you spend it on the things that actually work.

For the broader configuration and design material, start at the Cisco wireless cluster guide.

The Short Version

The Console Will Not Talk to You on First Boot

This is the first thing that stops people, and it looks like a broken image rather than expected behaviour. You start the node, watch the serial console, and the output dies partway through boot:

Both links down, not waiting for other chassis
Chassis number is 1

After that, silence. Nothing else ever appears on the serial console, and any automation you point at it (PyATS, Netmiko, an MCP connector) fails with a bare timeout rather than an authentication error, which sends you hunting for credentials problems that do not exist.

Cisco documents the cause: the 9800-CL uses the VNC console initially, and "even with the command platform console serial in the bootstrap configuration (which is included in the default node definition), the first boot will only output the full data and accept CLI input on the VNC console. Once the 9800-CL has booted and saved its day-0 configuration, you can restart the node. On subsequent boots, the node will use the serial console."

The practical fix, if you want a scriptable controller, is to stop the node, wipe it, inject a day-0 configuration that includes both the console directive and your credentials, and start it again:

hostname WLC1
!
platform console serial
!
username admin privilege 15 secret Cisco@123
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 login local
 privilege level 15
 transport input ssh

After the wipe the node factory-resets itself once before applying the config:

Chassis 1 reloading, reason - Reload command
%PMAN-5-EXITACTION: R0/0: pvp: Process manager is exiting: process exit with reload chassis code
%IOSXEBOOT-4-FACTORY_RESET: (rp/0): This was not selected via cli. Rebooting/Shutting Down like normal

Budget roughly twelve minutes from wipe to a usable prompt. From the second boot onward the serial console works normally and automation attaches cleanly:

WLC1#show version | include Cisco IOS Software|uptime is
Cisco IOS Software [IOSXE], C9800-CL Software (C9800-CL-K9_IOSXE), Version 17.18.2, RELEASE SOFTWARE (fc3)
WLC1 uptime is 13 minutes

No Access Point Will Ever Join

This is the limitation that matters most, and the one people burn the most hours on. Cisco states it directly in the 9800-CL platform notes: "While CML does not offer images for access points (APs) or wireless clients, the 9800-CL can be used to manage physical access points via bridge external connectivity. Even without physical APs, you can use the 9800-CL to learn about wireless LAN configuration, creating RF profiles, etc."

There is no virtual lightweight AP in CML. There never has been.

The CML 2.10 wireless nodes do not change this

CML 2.10 added beta Wi-Fi simulation with two new node types, wireless-ap and wireless-client, and it is easy to assume these are the missing piece. They are not. Their node definition is an Ubuntu 24.04 cloud-init virtual machine, and the AP role is provided by hostapd:

write_files:
  - path: /home/cisco/hostapd.conf
    content: |
      interface=wlan0
      driver=nl80211
      ssid=openap
      channel=6
      auth_algs=1
      wpa=0

That is a standalone Linux software access point. It speaks 802.11 to a wireless-client node running wpa_supplicant, which is genuinely useful for demonstrating association, beacons, and the WPA handshake. It has no CAPWAP implementation and no concept of a controller, so it cannot register to a Catalyst WLC.

The result is permanent, no matter how correct your DHCP option 43 is:

WLC1#show ap summary
Number of APs: 0

WLC1#show wireless stats ap join summary
Number of APs: 0
Base MAC        Ethernet MAC    AP Name       IP Address    Status      Last Failure Phase    Last Disconnect Reason
-----------------------------------------------------------------------------------------------------------------

Note what is not in that second output: there is no failure phase and no disconnect reason, because no join was ever attempted. If you were troubleshooting a real AP that could not join, you would see entries here with a failure phase. An empty table is the signature of an AP that never spoke CAPWAP at all.

The DHCP side works perfectly, which adds to the confusion. The AP node takes a lease from the lab DHCP server without complaint:

EDGE-RTR1#show ip dhcp binding
IP address      Client-ID/              Lease expiration        Type       State      Interface
10.10.10.22     ff32.39f9.b500.0200.    Jul 20 2026 04:43 AM    Automatic  Selecting  Ethernet0/0.10

If you need genuine AP join and client output, your options are a physical access point bridged into the lab through an external connector, or real hardware. There is no software path.

The Default Node Size Blocks Local Mode

Even once you attach a physical AP, the default node sizing constrains what deployment model you can run. Cisco puts it this way: "The 9800-CL node definition uses 2 vCPUs and 6 GB of RAM by default, which puts it in Ultra-Low Profile. This profile does not support local mode AP deployments (i.e., you cannot have AP traffic tunneled over CAPWAP to the controller). If you increase the resource allocation of your CAT 9800-CL node to 4 vCPUs to 8 GB of memory, it will then support local mode deployments. In all modes, you can do FlexConnect deployments."

You can confirm which profile you are in from the controller itself. A maximum DRAM figure just under 6 GB means Ultra-Low:

WLC1#show platform resources
**State Acronym: H - Healthy, W - Warning, C - Critical
Resource                 Usage                 Max             Warning         Critical        State
----------------------------------------------------------------------------------------------------
RP0 (ok, active)                                                                               H
 Control Processor       54.11%                100%            80%             90%             H
  DRAM                   2133MB(36%)           5879MB          88%             93%             H

The practical consequence: if you are labbing FlexConnect versus local mode, FlexConnect is available to you on any node size, and local mode requires bumping the node to 4 vCPU and 8 GB first. Plan your host memory accordingly, because a 9800-CL at 8 GB alongside a few IOL nodes adds up quickly.

High Availability Configures Cleanly and Does Nothing

This one is genuinely dangerous for study purposes, because the CLI gives you no indication that anything is wrong. Every SSO and N+1 command is accepted. The configuration appears in the running config. Verification commands return plausible-looking output. But redundancy never becomes operational.

Cisco's note is unambiguous: "high availability (HA) features of the physical Catalyst 9800 controllers are not supported by the 9800-CL node. The configuration options for HA are present, but they do not work."

Here is the proof from a live controller. Read the two mode lines together:

WLC1#show redundancy states
       my state = 13 -ACTIVE
     peer state = 1  -DISABLED
           Mode = Simplex
           Unit = Primary
        Unit ID = 1

Redundancy Mode (Operational) = Non-redundant
Redundancy Mode (Configured)  = sso
Redundancy State              = Non Redundant
    Manual Swact = disabled (system is simplex (no peer unit))
 Communications = Down      Reason: Simplex mode

   client count = 130
   client_notification_TMR = 30000 milliseconds
Gateway Monitoring = Enabled
Gateway monitoring interval  = 8 secs

Configured says sso. Operational says Non-redundant. That gap is the entire story. The chassis view confirms a single unit with no peer address:

WLC1#show chassis
Chassis/Stack Mac Address : 0001.0202.aabb - Local Mac Address
                                             H/W   Current
Chassis#   Role    Mac Address     Priority Version  State                 IP
-------------------------------------------------------------------------------------
*1       Active   0001.0202.aabb     1      V02     Ready                0.0.0.0

If you are preparing for an exam or a production cutover, practise the SSO configuration syntax here by all means, but do not expect to observe a switchover. The failover behaviour, RMI health signalling, and client session preservation all need real hardware.

What You Can Actually Lab

None of this makes a virtual 9800 useless. The entire control and configuration plane is real, and that is where most of the learning curve lives. In a single session on this controller we exercised all of the following with genuine output:

• The full tag and profile model: WLAN profiles, policy profiles, policy tags, site tags, and RF tags
• WLAN security across WPA2-PSK, WPA3-SAE, and WPA3 Enhanced Open (OWE)
• Wireless management interface assignment and country and regulatory domain configuration
• Mobility group settings, DTLS cipher lists, and mobility domain identifiers
• Radio network defaults for 2.4 GHz, 5 GHz, and 6 GHz
• RF profile creation and the 802.11 network enable and disable workflow
• AAA and RADIUS server configuration syntax
• The web UI, which is fully functional at https://<controller-ip>

What you cannot lab is anything downstream of an AP joining: AP join troubleshooting, client onboarding, roaming, RRM in action, rogue detection, and RF troubleshooting all need radios.

Three Gotchas Worth Knowing Before You Start

Country code configuration is order-dependent

Setting the country while the radio networks are up is rejected outright:

WLC1(config)#ap country US
% 802.11bg/802.11a  Network must be disabled

You have to shut both bands, set the country, and re-enable them. Each step prompts for confirmation:

ap dot11 24ghz shutdown
ap dot11 5ghz shutdown
ap country US
no ap dot11 24ghz shutdown
no ap dot11 5ghz shutdown

Adaptive FT silently blocks WPA3 and OWE

This one is not in most guides. A WPA3-SAE or Enhanced Open WLAN will refuse to come up while adaptive fast transition is enabled, and the error only appears when you try to enable the WLAN:

WLC1(config-wlan)#no shutdown
% node-(1):dbm:wireless:FT adaptive is not allowed with SAE/SAE-EXT-KEY AKM in WPA3 only WLAN

WLC1(config-wlan)#no shutdown
% node-(1):dbm:wireless:FT must be disabled in OWE WLAN

The fix is a single line, no security ft adaptive, but you will not find it by reading the WLAN configuration back.

Removing WPA2 turns off PMF behind your back

When you strip WPA2 from a WLAN on the way to a WPA3-only configuration, protected management frames are disabled as a side effect, and the controller tells you only once:

WLC1(config-wlan)#no security wpa wpa2
PMF is now disabled.

Since WPA3 requires PMF, you must re-apply security pmf mandatory afterward or the WLAN will not come up. Related reading: Catalyst 9800 wireless security configuration.

Bonus: the 6 GHz Band Tells You Exactly What It Wants

One genuinely pleasant surprise is how explicit the controller is about 6 GHz requirements. On a WPA2-PSK WLAN, the 6 GHz band reports itself down along with the reason:

Operational State of Radio Bands
    2.4GHz                                     : UP
    5GHz                                       : UP
    6GHz                                       : DOWN (Required config: Enable WPA3 & dot11ax)

Configure WPA3-SAE with PMF required on the same controller and the band comes up:

WLC1#show wlan id 2 | include Operational State|Security-6GHz|SAE|PMF Support
Operational State of Radio Bands               : All Bands Operational
    Security-2.4GHz/5GHz
         SAE PWE Method                             : Hash to Element, Hunting and Pecking(H2E-HNP)
         PMF Support                                : Required
     Security-6GHz
         SAE PWE Method                             : Hash to Element(H2E)
         PMF Support                                : Required

Note the SAE password element method differs by band. The 6 GHz band is Hash to Element only, while 2.4 and 5 GHz permit H2E with Hunting and Pecking for backward compatibility. That detail matters when you are debugging why a client associates on 5 GHz but not 6 GHz. More on this in the Wi-Fi 6 and 6E guide.

One More Trap: the External Connector

If you attach an external connector to your wireless management VLAN in the hope of bridging a physical AP later, be careful about leaving it up before that AP exists. In this lab the connector bridged the management VLAN straight onto the physical home network, and the access switch learned twenty-eight foreign MAC addresses on a single port:

ACCESS-SW1#show mac address-table vlan 10
  10    000c.295b.368b    DYNAMIC     Et0/1
  10    187f.888c.9209    DYNAMIC     Et0/1
  10    1cb3.c902.f42f    DYNAMIC     Et0/1
  ... (28 total on Et0/1)
  10    5254.00f1.2139    DYNAMIC     Et0/2
Total Mac Addresses for this criterion: 32

Worse, the upstream router on that network was also offering DHCP, so lab clients were racing two DHCP servers and leases were landing unpredictably. Shut the connector until you genuinely need it.

Key Takeaways

• The 9800-CL in CML is a control-plane lab. Configuration, syntax, tags, profiles, and security modes are all real and worth your time.
• No access point can join a 9800-CL in CML because no virtual AP image exists. The CML 2.10 wireless-ap node is a Linux hostapd device and does not speak CAPWAP.
• Expect the serial console to be dead on first boot. Save a day-0 configuration and restart, and it behaves from then on.
• The default 2 vCPU and 6 GB sizing is Ultra-Low profile and cannot do local mode. FlexConnect works everywhere. Local mode needs 4 vCPU and 8 GB.
• High availability configuration is accepted but never becomes operational. Check Redundancy Mode (Operational), not the configured value.
• If you need AP join, client, roaming, or RRM output, plan for a physical AP bridged in through an external connector.

For the full cluster covering configuration, security, design, and troubleshooting, see the Cisco wireless guide.

References

• Cisco Modeling Labs: Catalyst 9800-CL platform notes
• Cisco Modeling Labs 2.10 release notes