WLAN Architectures — Autonomous, Centralized (WLC), Cloud, Embedded

Mental model

Wi-Fi started simple: one AP, configured locally, broadcasting an SSID. For a small office with 1–3 APs, that’s still fine — the autonomous AP model.

The problem: you can’t scale autonomy. With 200 APs across an enterprise campus you can’t SSH into each one to push a config change. Roaming between APs gets weird (each AP decides independently when to release a client). Tracking clients across the network is impossible. APs doing independent radio management step on each other’s channel assignments.

The fix: split the AP’s duties. Time-sensitive radio work (encryption, beacon timing, MAC ACK) stays on the AP — it has to, because microsecond responses matter. Everything else (config, policy, RADIUS auth, RF management, roaming decisions, location services) moves to a central WLC (Wireless LAN Controller). The lightweight AP becomes a radio with brains relocated to the WLC.

This is split-MAC architecture. It’s been the standard for enterprise Wi-Fi since ~2008.

Four WLAN architectures — what to use when

Architecture	Where control lives	Sweet spot	Trade-offs
Autonomous AP	Inside each AP	≤ 3-5 APs, no controller budget	No roaming optimization, manual config per AP, no central RF tuning
Centralized (WLC)	Dedicated WLC appliance	Single-campus enterprise, 5–1000+ APs	Hairpin traffic through WLC (unless FlexConnect); WLC is a critical dependency
Cloud-managed	Vendor’s cloud (Meraki, Cisco Spaces, Mist)	Multi-site, distributed orgs, MSP-friendly	Recurring subscription, internet-dependent control plane
Embedded WLC	Running on an access switch (e.g., Catalyst 9300 with EWC)	Small-to-mid campus (≤100 APs), no separate WLC budget	Switch CPU shared between switching + WLC duties

CCNA scope: Autonomous + Centralized in depth. Cloud-managed + Embedded at the recognition level.

Autonomous AP — standalone

Each AP holds its own config. SSID definitions, security keys, VLAN mappings all live in the AP’s startup config. To change something, you log into the AP. To deploy 50 APs, you configure 50 APs.

Pros:

• No WLC cost.
• No WLC = no single point of failure.
• Survives WAN outages (no controller dependency).

Cons:

• No coordinated roaming between APs.
• No central RF channel/power management.
• Manual config replication is error-prone.
• No client tracking or location services.
• Each AP a separate management surface.

In 2026 use cases: home offices, micro-branches (1-3 APs), labs, kiosks. Anywhere a real enterprise WLAN is overkill.

Centralized — Lightweight AP + WLC

The default for enterprise. Every AP is “lightweight” — runs only the time-critical radio code. Config lives on the WLC. CAPWAP tunnel between AP and WLC carries control + data.

Pros:

• One management surface for hundreds/thousands of APs.
• Coordinated roaming (handoff < 50ms with 802.11r).
• RRM (Radio Resource Management) auto-tunes channels + power across APs.
• Central policy (per-SSID, per-VLAN, per-user).
• Client visibility (one query lists every client).
• Easy upgrades (WLC pushes firmware to all APs).

Cons:

• WLC failure = AP service degrades (depends on mode — see “AP modes” below).
• Client traffic may hairpin through WLC, adding latency + bandwidth tax.
• Requires WLC purchase and licensing.
• Network paths must reach the WLC.

Cloud-managed — Meraki / Cisco Spaces / Mist

The control plane lives in the vendor’s cloud, not your network. APs reach out to the cloud over the internet for config and management. Client data still flows locally (does NOT hairpin to the cloud).

Pros:

• Manage thousands of APs across hundreds of sites from one cloud GUI.
• Zero-touch deployment (ship the AP to a branch; it phones home).
• AI/ML features (Mist Marvis, Meraki Insight) — anomaly detection, root-cause hints.
• No on-prem WLC to maintain.

Cons:

• Recurring subscription cost.
• Internet outage = no management (data plane still works locally for existing APs).
• Vendor lock-in — Meraki APs only work with Meraki cloud.
• Less granular control vs traditional WLC.

Use case: distributed retail, hospitality, K-12 schools, MSPs, anywhere “central WLC at HQ” doesn’t fit the topology.

Embedded WLC — controller on a switch

A WLC instance running directly on a Catalyst 9300 / 9500 access switch (using Catalyst 9800-CL Embedded Wireless Controller). The switch performs its normal duties plus runs the WLC code.

Pros:

• No separate WLC hardware.
• Tight integration with the wired network.
• Lower TCO for mid-size sites.

Cons:

• Switch CPU shared between switching + WLC.
• Lower AP capacity than a dedicated WLC (typically up to 200 APs vs 6,000 on a 9800-80).
• Tighter coupling: switch maintenance affects wireless control plane.

Use case: smaller campuses with ≤ 100 APs that already use Catalyst 9000-series access switches.

Split-MAC architecture — what runs where

In a centralized WLC deployment, the AP and WLC each own different responsibilities:

Function	AP	WLC
802.11 frame encryption (WPA2/3)	✓
Beacon transmission	✓
Probe response	✓
MAC ACK (sub-millisecond)	✓
Decryption of incoming frames	✓
Authentication (802.1X / PSK 4-way handshake)		✓
AAA / RADIUS proxy		✓
Roaming coordination		✓
RF channel + power management (RRM)		✓
Client tracking + location services		✓
Config push to APs		✓
QoS policy + per-WLAN rate limits		✓
Captive portal / web auth		✓
Rogue AP detection	Both	✓ (correlates)
Mesh / point-to-point links	✓	(coordinated)

The split line is “must respond in microseconds = AP” versus “can respond in milliseconds = WLC.”

CAPWAP — the AP↔WLC tunnel

CAPWAP (Control And Provisioning of Wireless APs, RFC 5415) is the protocol that connects each lightweight AP to its WLC.

Two channels:

Channel	UDP port	Purpose	Encrypted?
Control	5246	Config, policy, RF management, AP status	Yes (DTLS always)
Data	5247	Client traffic encapsulated to/from WLC	Optional (DTLS)

Key insight: client traffic is tunneled from AP to WLC before being released on the wired network (in Local mode). Implications:

• AP and WLC don’t need to be on the same VLAN or subnet.
• Client traffic crosses the WAN if the WLC is at HQ — bandwidth tax.
• WLC sees and can policy every client packet.
• Adds latency proportional to AP-to-WLC distance.

AP Modes — Local vs FlexConnect vs others

The WLC tells the AP how to operate:

Mode	Behavior	Use
Local	Default. Client traffic tunneled to WLC.	Campus where WLC and APs are nearby.
FlexConnect	Client traffic switched locally at AP (data plane); control plane still to WLC.	Branch offices with slow / metered WAN to WLC.
Sniffer	AP forwards every captured 802.11 frame to a Wireshark host.	Troubleshooting roaming, association, auth.
Monitor	No client service. AP just scans the air.	Dedicated RF / rogue detection / location anchor.
Rogue Detector	Listens for unauthorized APs.	Compliance environments.
Bridge / Mesh	Wireless backhaul. AP acts as RAP or MAP.	Outdoor, warehouse, port/yard, P2P building links.
SE-Connect	Streams spectrum data to Spectrum Expert.	Hunt non-Wi-Fi interference.

Full detail in AP Operating Modes.

FlexConnect deep dive — the most CCNA-relevant non-Local mode

FlexConnect (formerly H-REAP) was built for branches with a centralized WLC at HQ. The trade-off:

• Control plane to WLC over WAN — minimal traffic.
• Data plane switched locally at the AP — no hairpinning of every Wi-Fi packet across the WAN.
• AP can stay operational (in “Standalone” state) during WAN outages, authenticating clients using cached creds.

When to use FlexConnect: any branch with slow WAN where you don’t want every client packet hairpinning to HQ.

WLC discovery — how a lightweight AP finds its controller

A factory-fresh AP has no config — just enough firmware to discover a WLC. Discovery order:

1. Static IP — if the AP was previously joined, the WLC IP is cached in flash.
2. Layer-2 broadcast — broadcast on the local subnet (rarely works in 2026 since AP and WLC are usually on different subnets).
3. DHCP Option 43 — the DHCP server hands out the WLC IP(s) alongside the AP’s normal DHCP lease.
4. DNS — the AP queries DNS for CISCO-CAPWAP-CONTROLLER.<your-domain> (using DNS suffix from DHCP).
5. Manual — set on AP console.

Enterprise default: DHCP Option 43 or DNS. DNS is often easier to maintain (one record vs hex-encoded option 43).

DHCP Option 43 syntax (Cisco IOS DHCP server)

R1(config)# ip dhcp pool AP-VLAN
R1(dhcp-config)# network 10.20.30.0 255.255.255.0
R1(dhcp-config)# default-router 10.20.30.1
R1(dhcp-config)# option 43 hex f104.0a01.0102        ! WLC IP = 10.1.1.2

The hex format encodes WLC IPs:

• f1 = sub-option type 0xF1 (WLC IP list)
• 04 = length 4 bytes
• 0a01.0102 = 10.1.1.2 in hex (10 = 0x0a, 1 = 0x01, etc.)

Multiple WLC IPs concatenate: f108.0a01.0102.0a01.0103 for two WLCs.

DNS approach

Create an A record CISCO-CAPWAP-CONTROLLER.example.com → <WLC IP>. APs that receive DHCP with DNS suffix example.com will query for this name automatically. Multiple A records for HA.

Once discovered — the CAPWAP join sequence

1. AP sends Discovery Request (broadcast / unicast).
2. WLC responds with Discovery Response.
3. AP selects WLC (if multiple respond — based on priority + load).
4. AP sends CAPWAP Join Request.
5. WLC validates AP (cert check, model whitelist).
6. WLC responds with Join Response.
7. AP downloads firmware (if version mismatch).
8. AP downloads config (SSIDs, security, VLAN maps).
9. AP transitions to Run state.
10. AP starts broadcasting SSIDs and serving clients.

Verify the sequence on the AP console:

AP# show capwap client mn
AP# show capwap detail

WLC redundancy — keeping wireless alive when the WLC fails

A single WLC is a single point of failure. Three common redundancy patterns:

N+1 redundancy (oldest)

Multiple primary WLCs + one backup. Each AP has a primary, secondary, and tertiary WLC in its config. If the primary fails, APs join the secondary. Slow failover (re-join the secondary = ~30 seconds).

HA SSO (High Availability with Stateful Switchover)

Two WLCs configured as a single logical pair. Active + Standby. The Standby mirrors the Active’s state in real time. When the Active fails, Standby takes over instantly (sub-second), and APs don’t even know — they keep their CAPWAP tunnel to the same “WLC IP” (a shared management IP).

Modern Catalyst 9800 default. The right answer for enterprise.

Stretched / DC redundancy

Multiple WLC pairs across data centers. APs select the nearest reachable WLC via priorities. Used for global enterprises.

Mobility groups — coordinated roaming across WLCs

When APs are spread across multiple WLCs (e.g., separate WLCs per building), roaming across WLCs needs coordination.

Mobility Group — a set of WLCs that share client context. When a client roams from WLC-A’s AP to WLC-B’s AP, WLC-A and WLC-B exchange the client’s state so the handoff is seamless.

WLC-A(config)# wireless mobility group name CAMPUS-MOBILITY
WLC-A(config)# wireless mobility group member ip 10.0.0.2 public-ip 10.0.0.2

Without mobility groups: cross-WLC roaming = full re-auth, including 802.1X — slow, voice calls drop.

Configuration patterns (Catalyst 9800 WLC)

! Define a WLAN
WLC(config)# wlan Corp-Wifi 1 Corp-Wifi
WLC(config-wlan)# security wpa wpa3
WLC(config-wlan)# security wpa wpa3 ciphers gcmp256
WLC(config-wlan)# security dot1x authentication-list ISE-AUTH
WLC(config-wlan)# client vlan 10
WLC(config-wlan)# no shutdown

! Define a policy profile (what to do with clients on this WLAN)
WLC(config)# wireless profile policy Corp-Policy
WLC(config-wireless-policy)# vlan 10
WLC(config-wireless-policy)# no shutdown

! Tag — bind WLAN + policy to APs
WLC(config)# wireless tag policy Corp-Tag
WLC(config-policy-tag)# wlan Corp-Wifi policy Corp-Policy

! Apply to APs
WLC(config)# ap aaaa.bbbb.cccc policy-tag Corp-Tag

Modern Catalyst 9800 uses tags (Policy, Site, RF) to apply config to APs in groups. Older AireOS WLCs used the AP-group concept.

Verification (Catalyst 9800)

WLC# show ap summary
WLC# show ap join stats summary
WLC# show wireless client summary
WLC# show wireless wlan summary
WLC# show wireless tag policy summary
WLC# show wireless mobility summary
WLC# show capwap session
WLC# show ap config general AP-LOBBY

show ap summary = all APs joined + their state. show wireless client summary = all clients + AP + SSID + signal.

The 6-step WLAN architecture debug

When clients aren’t connecting on a centralized WLAN:

1. Is the AP joined to the WLC? show ap summary — state should be Registered (joined). If not joined, fix CAPWAP path (Option 43, DNS, firewall blocking UDP 5246/5247).

2. Is the WLAN broadcasting? show wireless wlan summary. State should be Enabled and broadcast set. SSID visible from a phone Wi-Fi scanner.

3. Can the client associate? show wireless client mac-address <mac> detail. State should reach Run. If stuck at Authentication, RADIUS/802.1X issue.

4. VLAN + DHCP? Client got an IP? Trace the CAPWAP data plane: WLC decapsulates and forwards on the configured VLAN. ip helper-address on that VLAN’s SVI?

5. Mode-specific issues? If FlexConnect, verify trunk on the AP’s local switch port. If Local, verify WLC has IP path to the client’s VLAN.

6. HA / failover state? show redundancy on the WLC HA pair. Active should be Active; Standby should be Hot Standby.

Worked scenarios

---

Scenario 1. A new branch has 8 lightweight APs but the WLC is at HQ over a 50 Mbps WAN. Which AP mode minimizes WAN load?

Answer: FlexConnect. Client data is switched locally at the AP (uses the local VLAN trunk on the AP’s switch port); only control plane traffic to the WLC goes over the WAN.

---

Scenario 2. An AP boots but doesn’t appear on the WLC. show ap summary shows nothing. Top three checks?

Answer:

1. CAPWAP ports — UDP 5246/5247 open from AP subnet to WLC?
2. WLC discovery — DHCP Option 43 or DNS CISCO-CAPWAP-CONTROLLER.<domain> configured?
3. AP firmware — major version mismatch with WLC prevents join. Match versions.

---

Scenario 3. Why might an enterprise prefer Embedded WLC over a dedicated 9800?

Answer: Mid-size site, ≤ 100 APs, already using Catalyst 9300 access switches. Embedded WLC avoids a separate hardware purchase + licensing while reusing existing switch CPU. Trade-off is lower AP scale and shared switch CPU.

---

Scenario 4. Cloud-managed (Meraki) loses internet connectivity for 4 hours. What happens to existing Wi-Fi clients?

Answer: Existing clients stay connected and continue to pass traffic (data plane is local, not cloud-dependent). New management changes can’t be pushed during the outage. Some advanced features (cloud-based analytics, certain policy types) may be unavailable. Network functions for end users mostly unaffected.

---

Scenario 5. Two WLCs are deployed in HA SSO. The Active fails. What does an AP experience?

Answer: Sub-second failover. The AP keeps its CAPWAP tunnel to the same logical management IP (now answered by the formerly-Standby WLC). Clients don’t drop. SSO maintains the AP’s state through the failover.

---

Scenario 6. A client roams from an AP on WLC-A to an AP on WLC-B. The roam is slow and the user hears a voice call hiccup. What’s missing?

Answer: Either (a) mobility group between WLC-A and WLC-B isn’t configured — they don’t share client context, so cross-WLC roams require full re-auth, or (b) 802.11r (FT) isn’t enabled on the WLAN. Both should be configured for voice deployments.

---

Scenario 7. A new building’s APs join a remote WLC over WAN. Latency is 50ms one-way. Why might users see slow Wi-Fi performance?

Answer: In Local mode, every Wi-Fi packet hairpins through the WLC — adding 100ms round-trip to every packet. Apps that are latency-sensitive (voice, video, interactive) degrade. Solution: convert these APs to FlexConnect mode so data switches locally.

Common mistakes

1. Trying to manually configure a lightweight AP via console. Only the WLC pushes config. If an AP isn’t joining, fix the discovery path — don’t try to console-config it.

2. Firewall blocking CAPWAP. UDP 5246/5247 closed = silent failure. AP just doesn’t appear on the WLC.

3. Forgetting that WLC reachability matters. A lightweight AP with no path to the WLC is useless. Plan WLC HA + redundant network paths.

4. One central WLC for global enterprise. Cross-continent CAPWAP control plane adds latency for every config change. Deploy regional WLCs or use cloud-managed for distributed orgs.

5. Mixing autonomous and lightweight modes. A given AP runs one mode. Converting requires firmware re-flash. Pick a strategy.

6. Hairpinning branch traffic to HQ WLC unnecessarily. Use FlexConnect mode at branches to switch traffic locally.

7. Skipping mobility groups across multi-WLC deployments. Cross-WLC roams become full re-auths. Slow. Configure mobility groups.

8. No WLC HA in production. Single WLC = single point of failure for all wireless. Always deploy HA SSO pair.

9. Using DHCP Option 43 without verifying the hex encoding. A wrong byte = AP can’t parse the WLC IP. DNS-based discovery is easier to verify.

10. Embedded WLC overload. Pushing 200 APs through a Catalyst 9300 EWC strains the switch CPU. Stay within rated scale (typically 100-200 APs).

11. Trying to manage Meraki + Catalyst from one pane. Different ecosystems. Catalyst Center bridges some of this gap but expect operational seams.

Lab to try tonight

Best path: use Cisco DevNet’s Always-On wireless sandbox or reservable Catalyst 9800 sandbox.

1. Reserve a 9800 + AP sandbox — Cisco DevNet Sandboxes → Wireless → Catalyst 9800.

2. Verify APs joined — show ap summary — confirm Registered state.

3. CAPWAP details — show capwap session on the WLC. Note UDP 5246 control + 5247 data.

4. Discovery inspection — show ap join stats summary shows how each AP found this WLC (Option 43, DNS, etc.).

5. Create a WLAN — WPA2-Personal SSID LAB-WIFI, map to VLAN 10. Verify it appears in show wireless wlan summary.

6. Connect a client — laptop / phone. Verify with show wireless client summary.

7. Mode change — switch one AP from Local to FlexConnect. Verify with show ap config general <AP>.

8. Mobility group — if the sandbox has two WLCs, configure mobility group between them. show wireless mobility summary.

9. HA SSO — if the sandbox includes an HA pair, fail the Active WLC (reload). Watch Standby take over. Verify APs stay registered.

10. Bonus — RRM observation. show ap dot11 5ghz summary to see RF coordination (channel, power assignments per AP).

Cheat strip

Concept	Plain English
Autonomous AP	Standalone, full config local. Small offices, ≤3-5 APs
Lightweight AP	Just the radio. Brain on WLC. Enterprise standard
Centralized WLC	Dedicated WLC appliance + lightweight APs
Cloud-managed	Meraki / Cisco Spaces / Mist — control plane in vendor cloud
Embedded WLC	WLC code running on a Catalyst 9300/9500 switch
Split-MAC	Time-critical functions on AP, mgmt on WLC
CAPWAP	Tunnel between LAP and WLC (UDP 5246 control / 5247 data)
DHCP Option 43	Hands WLC IP via DHCP — hex-encoded
CISCO-CAPWAP-CONTROLLER	DNS-based WLC discovery name
Local mode	Default. Data hairpinned to WLC.
FlexConnect	Data switched locally at AP. Branch use.
Monitor / Sniffer / Bridge / SE-Connect	Specialized AP modes
HA SSO	Stateful WLC failover. Sub-second. Modern default.
N+1 redundancy	Primary + backup WLC. Failover ~30s. Older model.
Mobility Group	Coordinated client context across multiple WLCs
9800 WLC	Cisco’s modern WLC platform (replaces older AireOS WLCs)
Tags (Policy / Site / RF)	9800’s grouping model for applying config to APs
show ap summary	Daily-driver — all APs + state
show wireless client summary	All clients + AP + SSID + signal
CCNA depth	Autonomous vs Centralized in depth · Cloud + Embedded recognize-level