5.3 Cisco Catalyst 9800 Modular Configuration Architecture & Tag-Based Modeling

5.3 Cisco Catalyst 9800 Modular Configuration Architecture & Tag-Based Modeling

The Cisco Catalyst 9800 Series Wireless LAN Controller (WLC) represents a fundamental architectural departure from legacy Cisco AireOS controllers (such as the 2504, 5508, 5520, and 8540). While AireOS operated as a monolithic, single-threaded operating system, the Catalyst 9800 is built entirely on Cisco IOS-XE, aligning enterprise wireless infrastructure with the same robust, modular, and programmable software foundation that powers Cisco Catalyst 9000 Series enterprise campus switches and enterprise routers.

To manage wireless policy across thousands of access points without the administrative fragility of legacy AP Groups, the Catalyst 9800 introduces the Tag-Based Configuration Model—a modular framework separating wireless identity ("what"), physical topology ("where"), and radio behavior ("how").

1. Cisco IOS-XE Wireless Operating Architecture

The fundamental design principle of Cisco IOS-XE on the Catalyst 9800 is the strict operational decoupling of the Control Plane, the Data Plane, and the Management Plane.

+-----------------------------------------------------------------------------------------+
| Cisco IOS-XE Control Plane                                                              |
|                                                                                         |
|  +------------------+   +------------------+   +------------------+                     |
|  |   WNCd Core 0    |   |   WNCd Core 1    |   |   WNCd Core N    |   Multi-threaded        |
|  | (APs 1-500)      |   | (APs 501-1000)   |   | (APs 1001-1500)  |   Load-Balanced         |
|  +------------------+   +------------------+   +------------------+   Processes         |
|           \                      |                     /                                |
|            +---------------------+--------------------+                                 |
|                                  |                                                      |
|      [ Wireless Database / Shared Memory Infrastructure ]                               |
|      [ RRM / Mobility / Radio Management Services       ]                               |
+-----------------------------------------------------------------------------------------+
                                   |
+-----------------------------------------------------------------------------------------+
| Cisco Forwarding Plane (Data Plane)                                                     |
| Hardware: QuantumFlow Processor (QFP) on C9800-40 / C9800-80                            |
| Virtual: Data Plane Development Kit (DPDK) on C9800-CL Cloud Appliance                 |
+-----------------------------------------------------------------------------------------+

The Wireless Network Controller Daemon (WNCd)

In legacy AireOS, all wireless control plane events—including AP discovery, CAPWAP heartbeats, 802.1X/EAP authentications, and mobility handoffs—were processed by a central execution loop. Under heavy load (e.g. a morning "arrival wave" where 5,000 corporate laptops authenticate simultaneously), the controller CPU spiked, delaying client associations and causing CAPWAP timeouts.

In contrast, the Catalyst 9800 employs multiple independent instances of the Wireless Network Controller daemon (WNCd) running concurrently as isolated Linux processes:

• Multi-Core Distribution: Each WNCd instance is pinned to specific CPU cores. The controller distributes APs and client sessions across active WNCd instances using internal hashing algorithms (based on AP radio MAC address and Site Tag boundaries).
• Fault Isolation: If an abnormal packet causes a software exception in WNCd instance 2, only the APs and clients assigned to WNCd 2 are affected. The remaining WNCd instances continue servicing wireless traffic uninterrupted.
• Independent Forwarding Plane: Client CAPWAP data packets are forwarded in hardware by the Cisco QuantumFlow Processor (QFP) (on physical appliances like the 9800-40 and 9800-80) or accelerated by the Data Plane Development Kit (DPDK) (on the virtual 9800-CL appliance), completely isolating data throughput from control plane CPU utilization.

Zero-Downtime Maintenance & Software Resiliency

The modularity of IOS-XE enables four advanced software lifecycle management capabilities:

1. High Availability Stateful Switchover (HA SSO): Active and Standby controllers maintain sub-second synchronization of AP CAPWAP tunnels and client 802.11 association/security states across a dedicated Redundancy Port (RP). A failure of the active unit triggers stateful switchover; service impact and client behavior depend on the failure mode, release, platform, and client, so zero packet loss or zero reauthentication must not be assumed.
2. Software Maintenance Upgrade (SMU): An SMU is a point patch delivered as an RPM package that fixes a specific software defect or vulnerability without requiring a complete IOS-XE release reload. Hot patching (Cold = reload required, Hot = zero reload) patches the running WNCd process memory dynamically with zero downtime.
3. AP Service Pack (APSP): Delivers critical AP radio firmware fixes, CleanAir calibration updates, or over-the-air patches without modifying or reloading the controller's underlying IOS-XE operating system.
4. AP Device Pack (APDP): Allows enterprise administrators to introduce newly released Cisco AP hardware models (e.g., adding Wi-Fi 7 access points to an existing network) onto a running controller without requiring a major controller software upgrade.
5. In-Service Software Upgrade (ISSU): Supports staged controller upgrades across a compatible HA SSO pair to minimize disruption: the standby is upgraded first, a controlled switchover occurs, and the former active is upgraded. Client and AP continuity depends on platform, release path, feature compatibility, and documented caveats; it is not a universal zero-packet-loss guarantee.

2. The Tag-Based Configuration Paradigm

In AireOS, administrators relied on AP Groups and FlexConnect Groups. A single AP Group bundle merged WLAN-to-VLAN mappings, 802.11 radio parameters, and interface assignments. If a branch office required identical SSIDs to headquarters but needed local switching, engineers had to duplicate the entire AP Group structure, resulting in configuration sprawl.

The Catalyst 9800 eliminates this limitation by adopting the Tag-Based Model. Under this paradigm, configuration properties are abstracted into three independent Profiles, bound to three independent Tags, and assigned to Access Points:

+-----------------------------------------------------------------------------------------+
|                           THE CATALYST 9800 TAG TRIAD                                   |
+-----------------------------------------------------------------------------------------+
|  1. POLICY TAG                    2. SITE TAG                     3. RF TAG             |
|  "What and How"                   "Where and Mode"                "Radio Behavior"      |
|                                                                                         |
|  Maps:                            Maps:                           Maps:                 |
|  WLAN Profile                     AP Join Profile                 2.4 GHz RF Profile    |
|       +                                +                               +                |
|  Policy Profile                   Flex Profile                    5 GHz RF Profile      |
|                                   (Local Site Toggle: On/Off)          +                |
|                                                                   6 GHz RF Profile      |
+-----------------------------------------------------------------------------------------+
                                            |
                        Applied to Access Points via Precedence:
               [ Static Override ] > [ Rule/Regex ] > [ Location ] > [ Default ]
                                            |
                                            v
                                   +------------------+
                                   |   Access Point   |
                                   +------------------+

1. The Policy Tag ("What to Broadcast" & "How to Treat Traffic")

A Policy Tag dictates which wireless networks are broadcast by an AP and what security and QoS policies apply to client traffic. It binds two components:

• WLAN Profile ("What"): Defines the advertised network identity. Specifies the Service Set Identifier (SSID) string, WLAN ID, broadcast state (enabled/disabled), Layer 2 security suite (WPA2-Enterprise, WPA3-Personal SAE, WPA3-Enterprise 192-bit Suite B, Enhanced Open / OWE), and 802.11k/v/r fast roaming parameters.
• Policy Profile ("How"): Defines how client traffic is handled once connected to that WLAN:
  • Central Switching vs. Local Switching: Determines whether client data frames are encapsulated into CAPWAP data tunnels to the WLC (Central) or bridged directly into local switchport VLANs (Local).
  • Central Authentication vs. Local Authentication: Specifies whether 802.1X/RADIUS authentications are processed centrally through the WLC or locally by the AP.
  • VLAN Assignment: Statically maps a client VLAN ID/Name or enables AAA Override (allowing RADIUS/Cisco ISE to dynamically return Tunnel-Private-Group-ID attributes).
  • QoS & Session Parameters: Attaches QoS egress/ingress policies, Application Visibility and Control (AVC) profiles, session timeouts, idle timeouts, and IPv4/IPv6 ACLs.

A single Policy Tag can contain multiple WLAN Profile-to-Policy Profile bindings (e.g. binding Corp-WLAN to Corp-Policy with central switching, and Guest-WLAN to Guest-Policy with local switching).

2. The Site Tag ("Where the AP is Physically Located" & Operational Mode)

A Site Tag defines the physical deployment location of the AP and establishes its operational mode (Local vs. FlexConnect). It binds two components:

• AP Join Profile: Governs the global operational parameters of the physical AP hardware: CAPWAP discovery and echo timers, Ethernet port speeds, chassis LED behavior, TFTP/SFTP firmware download credentials, AP console port passwords, rogue AP detection/containment, and Cisco Spaces hyperlocation settings.
• Flex Profile: Governs branch-specific operational parameters when operating in FlexConnect mode: branch VLAN-to-SSID mappings, FlexConnect local Access Control Lists (ACLs), local EAP authentication servers, client split tunneling, and ARP caching.

The Critical Architectural Switch: [x] Enable Local Site

The Site Tag controls whether an AP operates in Centralized Local Mode or FlexConnect Mode through a single parameter:

• Enable Local Site = CHECKED (Enabled): The AP operates in Centralized Local Mode. The AP assumes high-speed LAN connectivity to the WLC and encapsulates all client traffic back to the WLC (unless specifically overridden). The Flex Profile binding within the Site Tag is ignored.
• Enable Local Site = UNCHECKED (Disabled): The AP converts into a FlexConnect AP. The AP activates its associated Flex Profile, downloads local VLAN mappings, and prepares for WAN survivability / Standalone mode.

Core Blueprint Fact: A single Site Tag also defines a CAPWAP Roaming Domain (up to 500 APs per Site Tag). APs sharing the same Site Tag are assigned to the same WNCd process, ensuring ultra-low latency, sub-10 millisecond Layer 2 intra-site roaming.

3. The RF Tag ("Radio Operational Settings")

An RF Tag dictates the low-level radio operational parameters across all supported physical frequency bands. It binds three separate profiles:

• 2.4 GHz RF Profile
• 5 GHz RF Profile
• 6 GHz RF Profile

Each RF Profile customizes the Radio Resource Management (RRM) algorithms for that specific frequency band:

• Dynamic Channel Assignment (DCA): Specifies which channels the AP radio is permitted to use (e.g. restricting 5 GHz DCA to non-DFS channels, or enabling 80 MHz channel bonding).
• Transmit Power Control (TPC): Defines minimum and maximum power thresholds (e.g. setting minimum TPC to $8\text{ dBm}$ and maximum to $14\text{ dBm}$ to prevent cell bleeding).
• Channel Widths: Selects between $20\text{ MHz}$, $40\text{ MHz}$, $80\text{ MHz}$, $160\text{ MHz}$, or $320\text{ MHz}$ operation.
• Data Rate Control: Enables, disables, or mandates specific 802.11 PHY data rates. For example, disabling legacy $1, 2, 5.5,$ and $11\text{ Mbps}$ rates on 2.4 GHz to eradicate legacy 802.11b overhead and enforce high-density cell sizing.
• High Density Experience (HDX): Configures Flexible Radio Assignment (FRA), Client Balancing, and CleanAir Pro interference mitigation.

3. Tag Assignment Precedence Hierarchy

When an access point discovers and joins a Cisco Catalyst 9800 WLC, the controller must evaluate which Policy Tag, Site Tag, and RF Tag to assign to that AP. Conflicts are resolved through a strict four-tier evaluation hierarchy:

+-----------------------------------------------------------------------------------------+
| 1. STATIC ASSIGNMENT (Highest Priority - Manual Override)                               |
| Applied directly to an individual AP via CLI or Web GUI. Overrides all other rules.    |
+-----------------------------------------------------------------------------------------+
                                             |
                                     If no static tag...
                                             v
+-----------------------------------------------------------------------------------------+
| 2. FILTER-BASED / RULE-BASED ASSIGNMENT (Priority Ranked)                               |
| Evaluates Tag Rules matching AP Name Regular Expressions (Regex) or AP Ethernet MAC.    |
+-----------------------------------------------------------------------------------------+
                                             |
                                     If no rule matches...
                                             v
+-----------------------------------------------------------------------------------------+
| 3. LOCATION-BASED ASSIGNMENT (Cisco Catalyst Center)                                    |
| Inherited dynamically from the AP's assigned floor/building in the site hierarchy.     |
+-----------------------------------------------------------------------------------------+
                                             |
                                     If no location tag...
                                             v
+-----------------------------------------------------------------------------------------+
| 4. DEFAULT TAGS (Lowest Priority - Global Fallback)                                     |
| AP automatically inherits: default-policy-tag, default-site-tag, default-rf-tag.        |
+-----------------------------------------------------------------------------------------+

Step-by-Step Assignment Precedence

1. Static Assignment (Highest Precedence): An administrator explicitly maps tags directly to an individual AP's hardware MAC address via the CLI (ap name <name> tag policy <tag>) or web GUI. Static tags are stored in persistent NVRAM and override all automated tagging rules.
2. Filter-Based / Rule-Based Assignment: The controller evaluates configured Tag Rules in numerical priority order. A Tag Rule uses a Regular Expression (Regex) to match the AP's hostname or checks the AP's Ethernet MAC address. For example, a regex rule matching ^BLDG-HQ-FL[0-9]+-AP.* dynamically assigns campus headquarters tags to all matching APs upon join.
3. Location-Based Assignment: When integrated with Cisco Catalyst Center, APs mapped to a specific physical building, floor, or outdoor zone automatically inherit the Policy, Site, and RF tags mapped to that site hierarchy container.
4. Default Tags (Global Fallback - Lowest Precedence): If an AP matches none of the above criteria, the Catalyst 9800 automatically applies the default system tags:
   • default-policy-tag: Broadcasts default WLANs with central switching.
   • default-site-tag: Configured with Enable Local Site checked (Centralized Local Mode) using default-ap-join-profile.
   • default-rf-tag: Binds default-rf-profile-24ghz, default-rf-profile-5ghz, and default-rf-profile-6ghz.

4. Production Cisco Catalyst 9800 CLI Configuration

The following end-to-end CLI workflow builds an enterprise wireless deployment utilizing the Tag-Based Model:

Step 1: Configure WLAN Profile and Policy Profile, then Bind in Policy Tag

! 1. Define the over-the-air WLAN Profile (SSID and Layer 2 Security)
wlan Corporate-WLAN 10 Corporate-Secure
 security wpa psk set-key ascii 0 CiscoSecretKey123!
 security wpa akm sae
 security wpa wpa3
 no shutdown

! 2. Define the Policy Profile (Traffic Handling, VLAN, Switching Mode)
wireless profile policy Corporate-Policy-Profile
 vlan 200
 central switching
 central authentication
 central dhcp
 qos profile platinum
 no shutdown

! 3. Bind WLAN Profile to Policy Profile inside a Policy Tag
wireless tag policy HQ-Policy-Tag
 wlan Corporate-WLAN policy Corporate-Policy-Profile

Step 2: Configure AP Join Profile and Flex Profile, then Bind in Site Tag

! 1. Define the AP Join Profile (Global Hardware and Management Settings)
wireless profile ap AP-Join-HQ-Standard
 capwap timer heart-beat-timeout 15
 capwap timer discovery-interval 10
 led state on
 mgmt user admin password 0 CiscoCampusAPPass!

! 2. Define the Site Tag (Setting Local Mode vs. FlexConnect Mode)
wireless tag site HQ-Site-Tag
 ap-profile AP-Join-HQ-Standard
 [no] ap-profile
 ! 'no site-tag local' sets FlexConnect mode; omitting or enabling it sets Local Mode:
 site-tag local

Step 3: Configure RF Profiles and Bind in RF Tag

! 1. Define custom 5 GHz RF Profile
wireless profile rf 5GHz-HighDensity-RF-Profile
 channel width 40
 tpc-min 8
 tpc-max 14
 rate 5ghz 6 basic
 rate 5ghz 9 supported
 rate 5ghz 12 supported
 rate 5ghz 24 supported
 no rate 5ghz 1
 no rate 5ghz 2

! 2. Bind RF Profiles into an RF Tag
wireless tag rf HQ-RF-Tag
 5ghz-rf-profile 5GHz-HighDensity-RF-Profile
 24ghz-rf-profile default-rf-profile-24ghz
 6ghz-rf-profile default-rf-profile-6ghz

Step 4: Configure Regex Tag Rule for Automated Assignment

! Define a filter rule matching AP hostname regex to dynamically apply the tags
wireless tag rule HQ-Floor1-Rule
 priority 1
 ap-name-regex ^HQ-FL01-AP[0-9]{2}$
 policy-tag HQ-Policy-Tag
 site-tag HQ-Site-Tag
 rf-tag HQ-RF-Tag

Step 5: Verification Commands

# show wireless tag policy summary
# show wireless tag site summary
# show wireless tag rf summary
# show ap name HQ-FL01-AP04 config general | include Tag