Lightweight vs Autonomous Access Points – Architecture, CAPWAP & WLC

1. The Core Problem: Managing Wireless at Scale

When Wi-Fi was first deployed in enterprises, each access point operated as a fully independent device — just like a standalone router. Every AP had its own configuration, its own security settings, and its own firmware. For one or two APs this was manageable. For fifty, two hundred, or a thousand APs spread across a campus, it became operationally impossible.

The solution was to separate the intelligence from the radio hardware. This gave rise to two architectures that CCNA candidates must fully understand: Autonomous APs (each AP is self-contained) and Lightweight APs (each AP is controlled by a central Wireless LAN Controller).

  Autonomous architecture (per-AP management):
  ┌──────────┐  ┌──────────┐  ┌──────────┐
  │  AP1     │  │  AP2     │  │  AP3     │
  │ full     │  │ full     │  │ full     │
  │ config   │  │ config   │  │ config   │
  └──────────┘  └──────────┘  └──────────┘
  Admin must SSH/console into every AP separately for any change

  Lightweight (controller-based) architecture:
  ┌──────────────────────────────────┐
  │      Wireless LAN Controller     │
  │  (all config, security, SSID,    │
  │   firmware — ONE place)          │
  └─────┬────────┬────────┬──────────┘
        │CAPWAP  │CAPWAP  │CAPWAP
  ┌─────┴──┐ ┌───┴──┐ ┌───┴──┐
  │  AP1   │ │  AP2 │ │  AP3 │
  │ radio  │ │radio │ │radio │
  │ only   │ │only  │ │only  │
  └────────┘ └──────┘ └──────┘
  Single change on WLC propagates to all 3 APs instantly

2. Autonomous AP — Architecture and Operation

An Autonomous AP (also called a standalone AP) is a fully self-contained wireless device that handles every function locally: radio management, SSID broadcasting, client authentication, encryption, bridging, and even basic routing in some models. It requires no external controller to operate.

  Autonomous AP — all functions local:

  ┌────────────────────────────────────────┐
  │          Autonomous AP                 │
  │  ┌─────────────┐  ┌─────────────────┐  │
  │  │  Radio /    │  │  Control Plane  │  │
  │  │  PHY Layer  │  │  (SSID, Auth,   │  │
  │  │  (802.11)   │  │   Security,     │  │
  │  └─────────────┘  │   QoS, Roaming) │  │
  │                   └─────────────────┘  │
  │  ┌──────────────────────────────────┐  │
  │  │  Data Plane (bridges Wi-Fi to    │  │
  │  │  wired LAN locally)              │  │
  │  └──────────────────────────────────┘  │
  │  Config via: CLI / Web GUI / SNMP      │
  └────────────────────────────────────────┘
       │
  Ethernet to switch (trunk or access port)

Autonomous AP Characteristics

Property	Detail
Configuration	Per-device — CLI (IOS), web GUI, or SNMP. Each AP configured individually.
Control plane	Local — AP makes all forwarding and security decisions independently
Data plane	Local — client traffic bridged from 802.11 to wired Ethernet on the AP itself
Firmware updates	Manual per AP — must connect to each AP individually via TFTP or web GUI
SSID/security changes	Must be applied to every AP individually — time-consuming in large deployments
Roaming	Basic layer 2 roaming only — client re-authenticates when moving between APs; sessions may drop
Controller required	None — operates completely independently
Best for	1–5 APs; small offices; remote sites without WAN connectivity to controller; temporary deployments

Autonomous AP IOS Configuration Example

hostname AP-Lobby
!
! Configure radio interface for 2.4 GHz
interface Dot11Radio0
 ssid CompanyWiFi
   authentication open
   authentication key-management wpa version 2
   wpa-psk ascii 0 MySecurePassw0rd
 !
 channel 6
 power local max
 no shutdown
!
! Configure wired interface (get IP via DHCP)
interface FastEthernet0
 ip address dhcp
 no shutdown
!
! Enable web-based management
ip http server
!
end
write memory

3. Lightweight AP — Architecture and the Split-MAC Design

A Lightweight AP (LAP) delegates most of its intelligence to a central Wireless LAN Controller (WLC). The AP handles only time-sensitive real-time functions; everything else is handled by the WLC. This division of responsibility is called the split-MAC architecture.

Split-MAC: What the AP Handles vs What the WLC Handles

Function	Handled By	Why This Layer?
802.11 frame transmission/reception (PHY)	AP	Must happen in real time at the radio — latency to WLC would be too high
Beacons and probe responses	AP	Timing-critical — must respond within tight 802.11 intervals
ACK and MAC-layer retransmissions	AP	Sub-millisecond timing required — cannot wait for WLC
Association and re-association handling	WLC	Central coordination enables seamless inter-AP roaming
Authentication (802.1X, EAP, PSK)	WLC	Centralised policy enforcement; WLC communicates with RADIUS server. See: AAA Local vs RADIUS
SSID/WLAN configuration	WLC	Single point of policy — changes propagate to all APs instantly
QoS marking and enforcement	WLC	Consistent policy across all APs
RF management (channel, power)	WLC (RRM)	Cisco RRM (Radio Resource Management) optimises the entire RF environment globally — individual APs cannot see network-wide RF picture
Client mobility/roaming database	WLC	WLC maintains client state — enables layer 2 and layer 3 roaming
Firmware management	WLC	WLC pushes firmware to all APs during join or on demand

Why "lightweight"? The term reflects that the AP's software (its "weight" in terms of processing and code) has been dramatically reduced. All the heavyweight functions — authentication, policy, RF management, roaming — have been moved to the WLC. The AP runs only the minimal logic needed to operate its radios in real time.

4. CAPWAP — Control and Provisioning of Wireless Access Points

CAPWAP (RFC 5415) is the standardised tunnelling protocol that connects lightweight APs to their WLC. It replaced the earlier Cisco-proprietary LWAPP (Lightweight Access Point Protocol). CAPWAP creates two separate tunnels between each AP and the WLC: a control tunnel and a data tunnel.

  CAPWAP tunnels between AP and WLC:

  ┌──────────┐                              ┌──────────────┐
  │  AP      │                              │     WLC      │
  │          │══ CAPWAP Control (UDP 5246) ═│              │
  │          │   (encrypted with DTLS)      │              │
  │          │                              │              │
  │          │══ CAPWAP Data   (UDP 5247) ══│              │
  │          │   (optional DTLS)            │              │
  └──────────┘                              └──────────────┘

  Control tunnel: AP join, config push, firmware updates,
                  stats reporting, RF management commands
  Data tunnel:    Client 802.11 frames encapsulated in CAPWAP
                  and forwarded to WLC (central switching mode)

CAPWAP Key Facts

Property	Detail
Standard	RFC 5415 (2009) — open standard replacing Cisco's proprietary LWAPP
Transport	UDP over IPv4 (or IPv6)
Control channel	UDP port 5246 — always encrypted with DTLS (Datagram TLS). See: Common Port Numbers
Data channel	UDP port 5247 — DTLS encryption optional (disabled by default for performance; enable for higher security)
Encryption	DTLS (Datagram Transport Layer Security) — provides mutual authentication and encryption between AP and WLC
Layer 3 capable	AP and WLC can be on different subnets/VLANs — CAPWAP tunnels route across Layer 3 networks (unlike LWAPP which was Layer 2 only)
MTU consideration	CAPWAP adds overhead (~50 bytes). If path MTU is exactly 1500 bytes, CAPWAP-encapsulated frames may be fragmented — configure `ip mtu 1300` on AP Ethernet interface or adjust PMTUD

5. AP Join Process — How a Lightweight AP Finds and Joins a WLC

When a lightweight AP boots for the first time (or after being reset), it must discover and join a WLC before it can serve any clients. This process follows a specific sequence.

  AP Join Process (6 steps):

  Step 1: AP boots → sends DHCP Discover
          DHCP server assigns IP, subnet mask, default gateway
          (Optional) DHCP Option 43 provides WLC IP addresses

  Step 2: WLC Discovery (multiple methods attempted in order):
          a) DHCP Option 43: WLC IPs embedded in DHCP reply
          b) DNS: AP resolves "CISCO-CAPWAP-CONTROLLER.local-domain"
          c) Layer 3 broadcast: AP broadcasts CAPWAP Discovery Request
          d) Mobility group: Previously known WLC IPs stored in AP
          e) Over-the-air provisioning (APoS)
          f) Static WLC IP configured on AP

  Step 3: AP sends CAPWAP Discovery Request to all discovered WLC IPs
          WLC responds with CAPWAP Discovery Response
          (includes WLC load, AP capacity, software version)

  Step 4: AP selects best WLC (load balancing) → sends CAPWAP Join Request
          WLC validates AP certificate (AP ships with factory-installed X.509 cert)
          WLC sends CAPWAP Join Response — DTLS session established

  Step 5: WLC pushes configuration to AP:
          - Firmware (if AP version doesn't match WLC) → AP reboots
          - SSIDs/WLANs, security policies, VLAN mappings
          - Channel and power settings
          - QoS parameters

  Step 6: AP sends CAPWAP Configuration Status → enters RUN state
          AP now serves clients
          Control channel keepalives sent every 30 seconds

WLC Discovery Methods

Method	How It Works	When to Use
DHCP Option 43	DHCP server includes WLC IP addresses in Option 43 field of DHCP reply — AP extracts WLC IPs and contacts them	Most common enterprise method — configure on DHCP server for each AP VLAN/subnet
DNS	AP performs DNS lookup for the hostname `CISCO-CAPWAP-CONTROLLER.<domain>` — DNS A record points to WLC	Useful when DHCP option 43 is not configured; requires DNS entry
Layer 3 Broadcast	AP sends broadcast CAPWAP Discovery Request on its local subnet — WLC on same subnet responds	AP and WLC on same Layer 2 segment — simple lab setups
Static Configuration	WLC IP manually entered on AP via CLI or web GUI	When other methods unavailable; initial lab setup; fallback method
Primed/Last WLC	AP remembers the WLC it last joined — attempts to rejoin after reboot	Automatic after first successful join — reduces discovery overhead on subsequent boots

6. Central Switching vs Local Switching (FlexConnect)

In a controller-based architecture, there is a fundamental choice about where client data traffic is processed after it leaves the AP — this is the switching mode decision.

Central Switching (Local Mode)

  Central switching (default — also called Local Mode):

  Wi-Fi Client ──▶ AP ──▶[CAPWAP data tunnel]──▶ WLC ──▶ Wired LAN
                         (all client traffic flows
                          through WLC before reaching LAN)

  Advantage: WLC inspects all traffic — full visibility and policy enforcement
  Disadvantage: WLC becomes traffic bottleneck; WAN latency if WLC is remote

All client data frames are encapsulated in CAPWAP and forwarded to the WLC
WLC decapsulates frames and forwards to the appropriate VLAN on the wired network
WLC applies QoS, security, and ACL policies to all traffic
If CAPWAP tunnel to WLC fails, AP cannot serve clients — all connectivity lost
Use case: Campus networks where WLC is local and low-latency

Local Switching (FlexConnect Mode)

  FlexConnect local switching:

  Wi-Fi Client ──▶ AP ──▶ Local LAN directly (data bypasses WLC)
                    │
                    └──▶[CAPWAP control tunnel]──▶ WLC
                         (management only — WLC controls AP)

  Advantage: Traffic stays local — works even if WAN to WLC fails
  Disadvantage: Less WLC visibility into client traffic

Client data is switched directly to the local LAN by the AP — does not traverse the WAN to the WLC
The CAPWAP control tunnel still runs over the WAN for management
In standalone mode (WLC unreachable): AP continues to serve existing clients using cached configuration — new clients with pre-configured SSIDs can still connect
Use case: Branch offices where client traffic should stay local and not backhaul over WAN; WAN failure resilience

Switching Mode Comparison

Feature	Central Switching (Local Mode)	Local Switching (FlexConnect)
Client data path	AP → WLC → wired LAN	AP → local wired LAN (direct)
WLC dependency for data	High — WLC failure = no client connectivity	Low — AP survives WLC failure in standalone mode
WAN bandwidth usage	High — all client traffic crosses WAN to WLC	Low — only management traffic crosses WAN
Policy visibility	Full — WLC sees and processes all client traffic	Partial — WLC only sees control messages
Typical deployment	Campus, data centre, large office near WLC	Remote branch offices connected via WAN

7. Seamless Roaming — The Key Advantage of Controller-Based APs

Roaming is the process of a Wi-Fi client moving from one AP's coverage area to another while maintaining its network session. The quality of this experience differs dramatically between autonomous and lightweight deployments.

Autonomous AP Roaming (Basic Layer 2)

  Client moves from AP1 to AP2 (both autonomous, same subnet):

  AP1 area ──────────────────── AP2 area
  [Client connected to AP1]
  Client signal drops → client sends 802.11 Probe Request
  AP2 responds → client sends Association Request to AP2
  AP2 forces full re-authentication (new 802.1X / PSK exchange)
  Client gets new association → may get new IP address
  Result: session disruption, TCP connections may drop

Lightweight AP Seamless Roaming

  Client moves from AP1 to AP2 (both lightweight, same WLC):

  ┌─────────────────────────────┐
  │           WLC               │
  │  Maintains client database: │
  │  Client: 00:AA:BB:CC:DD:EE  │
  │  IP: 192.168.10.50          │
  │  VLAN: 10, Auth: 802.1X     │
  │  Current AP: AP1 → AP2      │
  └──────┬────────────┬─────────┘
     CAPWAP         CAPWAP
  ┌──────┴──┐    ┌───┴──────┐
  │  AP1    │    │   AP2    │
  └─────────┘    └──────────┘

  When client moves to AP2:
  - AP2 notifies WLC via CAPWAP control tunnel
  - WLC updates its client database (AP1 → AP2)
  - Client's IP address, VLAN, QoS profile, and auth state PRESERVED
  - Client does NOT re-authenticate
  - Handoff completes in milliseconds
  - TCP sessions, VoIP calls, video streams continue uninterrupted

Roaming Types in Controller-Based Networks

Roaming Type	Condition	Client Experience
Layer 2 Intra-controller Roaming	Client moves between two APs on same WLC, same VLAN	Seamless — sub-50ms handoff; same IP; no re-auth
Layer 3 Intra-controller Roaming	Client moves between two APs on same WLC, different VLANs/subnets	Seamless — WLC tunnels traffic back to original VLAN using Mobility Anchor; client keeps original IP
Inter-controller Roaming	Client moves to AP on a different WLC (same mobility group)	Seamless — WLCs exchange client state via mobility tunnel; client keeps IP and auth state

8. Full Feature Comparison

Feature	Autonomous AP	Lightweight AP (with WLC)
Management	Per-device (CLI/web/SNMP)	Centralised — single WLC GUI or CLI
SSID/security changes	Manual on each AP	Pushed globally from WLC in seconds
Firmware updates	Manual per AP (TFTP)	Automatic — WLC downloads to AP at join or on demand
Roaming	Basic — re-authentication required; sessions may drop	Seamless — WLC preserves client state; no re-auth
Security (802.1X)	Limited — AP communicates with RADIUS independently	Full — WLC acts as 802.1X authenticator; RADIUS proxy. See: Wi-Fi Security
Guest portals (Web Auth)	Limited/vendor-specific	Full — WLC hosts captive portal; redirects to guest VLAN
RF management	Manual channel and power per AP	Automatic RRM — WLC adjusts channel/power across all APs
Scalability	1–5 APs practical	Hundreds to thousands of APs per WLC
WAN survivability	Always operational — no WAN dependency	FlexConnect mode: survives WLC outage; Local mode: depends on WLC
Initial cost	Lower — no controller hardware/licence	Higher — WLC hardware (or virtual) and AP licences
Operational cost (large scale)	High — admin time per AP multiplies	Low — single management point regardless of AP count
Protocol	None (standalone)	CAPWAP (UDP 5246/5247) with DTLS encryption

9. WLC Key Verification Commands

  ! ── View all APs joined to WLC ─────────────────────────────────────────
  (WLC) > show ap summary
  Number of APs: 12
  AP Name              Slots  AP Model    Ethernet MAC       Status
  AP-Floor1-NW         2      AIR-AP3802I 1c:6a:7a:aa:bb:cc  Registered
  AP-Floor1-NE         2      AIR-AP3802I 1c:6a:7a:dd:ee:ff  Registered
  ...

  ! ── AP join statistics and firmware version ─────────────────────────────
  (WLC) > show ap config general AP-Floor1-NW

  ! ── View configured WLANs ───────────────────────────────────────────────
  (WLC) > show wlan summary
  WLAN ID  Profile Name / SSID     Status    Security
  1        CorpWiFi / CorpWiFi     Enabled   WPA2-802.1X
  2        GuestWiFi / GuestWiFi   Enabled   WPA2-PSK

  ! ── View connected clients ──────────────────────────────────────────────
  (WLC) > show client summary
  (WLC) > show client detail <client-MAC>

  ! ── AP CAPWAP tunnel state ───────────────────────────────────────────────
  (WLC) > show ap join stats summary all

  ! ── RRM (automatic channel/power) status ────────────────────────────────
  (WLC) > show ap auto-rf 802.11b AP-Floor1-NW

  ! ── On the AP itself (lightweight mode) ─────────────────────────────────
  AP# show capwap client rcb
  AP# show capwap client config
  AP# show dot11 associations

10. Migrating an Autonomous AP to Lightweight Mode

Many Cisco AP models support converting between autonomous and lightweight firmware images. This is done by replacing the IOS image with the CAPWAP lightweight image.

  ! ── Step 1: Identify the correct lightweight image ──────────────────────
  ! Download from Cisco Software Centre — file ends in "k9w8" for lightweight
  ! Example: ap3g2-k9w8-tar.153-3.JF.tar

  ! ── Step 2: Place image on TFTP server (e.g., 192.168.1.5) ──────────────

  ! ── Step 3: Connect to AP via console or SSH ─────────────────────────────
  AP# enable

  ! ── Step 4: Transfer and install the lightweight image ───────────────────
  AP# archive download-sw /overwrite /force tftp://192.168.1.5/ap3g2-k9w8-tar.153-3.JF.tar
  Loading ap3g2-k9w8-tar.153-3.JF.tar from 192.168.1.5
  extracting info (273 bytes)
  Image info:
    Version Suffix: k9w8-.153-3.JF
    Image Name: ap3g2-k9w8-c153-3.JF
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  [image extracted, AP reboots automatically]

  ! ── Step 5: AP reboots in lightweight mode ───────────────────────────────
  ! AP will now discover and join the WLC via CAPWAP
  ! Verify on WLC: show ap summary (AP should appear as Registered)

  ! ── To convert BACK to autonomous ────────────────────────────────────────
  ! Download "k9w7" image (autonomous IOS) and repeat the archive command

Alternative — WLC-initiated conversion: From a Cisco WLC, if the AP has joined in lightweight mode and you want to convert it, the WLC can push the autonomous image:

config ap tftp-downgrade <tftp-ip>
              <filename> <ap-name>

11. Cloud-Managed APs — A Third Architecture

Beyond autonomous and controller-based, a third modern architecture exists: cloud-managed APs (e.g., Cisco Meraki, Ubiquiti UniFi cloud). These combine the benefits of centralised management with the elimination of on-premises WLC hardware.

Feature	Autonomous	Lightweight + WLC	Cloud-Managed
Management location	Local per AP	On-premises WLC	Cloud dashboard (internet)
Controller hardware	None	Required (physical or virtual)	None on-premises
Client data path	Local	Via WLC or local (FlexConnect)	Local (only management in cloud)
Internet dependency	None	None (WLC is local)	APs function locally but lose management visibility if internet fails
Scalability	Low	High (bounded by WLC licence)	Very high (cloud scales elastically)
CCNA relevance	Core concept	Core concept (CAPWAP/WLC)	Awareness only — not heavily tested

12. Deployment Scenarios — Choosing the Right Architecture

Scenario	Best Choice	Reasoning
Home office or 1–2 AP deployment	Autonomous	Controller overhead not justified; simple config adequate
Small branch office (3–10 APs), no IT staff on-site	Cloud-managed or FlexConnect lightweight	Central visibility without WLC on each site; FlexConnect survives WAN failure
Large campus (50–1000+ APs)	Lightweight + WLC	Central management essential; seamless roaming; RRM; 802.1X
High-density venue (stadium, conference centre)	Lightweight + WLC	RRM auto-adjusts for density; WLC load-balances clients; single management point
Remote branch, poor WAN to HQ	FlexConnect lightweight	Local data switching survives WAN outage; still centrally managed when WAN available
Temporary event or pop-up deployment	Autonomous	No controller infrastructure needed; self-contained; easy to deploy and remove

13. Troubleshooting — Autonomous vs Lightweight

Issue	Autonomous Approach	Lightweight Approach
Client cannot connect	Console/SSH to AP; check SSID config, VLAN, radio status (`show dot11 associations`)	WLC GUI/CLI: `show client summary`; check WLAN enabled, VLAN mapping, AP registration
AP not serving clients	Check AP config, radio up/down, IP addressing (`show interfaces`)	Check AP join state: `show ap join stats summary all`; verify CAPWAP reachability; check UDP 5246/5247 not blocked
AP won't join WLC	N/A — autonomous has no controller	Verify DHCP Option 43 or DNS entry; confirm AP has IP and can reach WLC; check WLC AP licence count; check AP image version matches WLC
Poor roaming experience	Expected — configure same SSID/security on all APs; 802.11r (Fast BSS Transition) if supported	Check mobility group configuration; verify intra-controller roaming via `show client detail`; check PMK caching
CAPWAP tunnel drops	N/A	Check WAN path stability; verify no NAT on CAPWAP ports; check AP keepalive timers; `debug capwap events enable`

14. Key Points & Exam Tips

Autonomous AP: Standalone, all functions local (control plane + data plane on the AP), configured per-device via CLI/web/SNMP. Best for small/simple/isolated deployments. No CAPWAP.
Lightweight AP: Split-MAC — time-sensitive radio functions stay on AP; everything else (auth, SSID, policy, roaming, RF management) on WLC. Communicates via CAPWAP. Best for scalable enterprise deployments.
CAPWAP: UDP 5246 (control — always DTLS-encrypted) and UDP 5247 (data — optional DTLS). Open standard (RFC 5415). Replaced proprietary Cisco LWAPP.
AP join process: DHCP → WLC Discovery → CAPWAP Join → firmware push → config push → RUN state. DHCP Option 43 is the most common WLC discovery method.
Split-MAC key rule: Real-time radio functions (beacons, ACKs, retransmissions) stay on AP. Management functions (association, auth, policy, roaming database) go to WLC.
Central switching (Local Mode): All client data tunnelled through WLC via CAPWAP. Full WLC visibility. WLC is in the data path.
FlexConnect (Local switching): Client data switched locally by AP. WAN failure survivable. Used for branch offices.
Seamless roaming: WLC maintains client state (IP, auth, VLAN) — client moves between APs without re-authentication. Sessions survive handoff.
Cisco APs can be converted between autonomous and lightweight by swapping firmware image ("k9w7" = autonomous, "k9w8" = lightweight).
DTLS encrypts the CAPWAP control channel — mutual authentication between AP and WLC using X.509 certificates (AP ships with factory certificate).

15. Lightweight vs Autonomous APs Quiz

1. A university has 400 access points deployed across its campus. The network team receives a security bulletin requiring a WPA3 migration. With an autonomous AP architecture, how many individual AP configurations must be updated, and what is the lightweight architecture advantage in this scenario?

A. 10 — only distribution-layer APs need updating; access APs inherit settings B. 1 — autonomous APs synchronise with each other automatically C. 400 autonomous APs must each be individually reconfigured — an enormous operational burden. With lightweight APs, the WPA3 policy change is made once on the WLC and pushed automatically to all 400 APs within seconds D. 0 — APs auto-detect security changes from clients

Correct answer is C. This scenario illustrates the core operational advantage of centralised management. With 400 autonomous APs, each one requires an individual configuration change — connecting via SSH or console, navigating to the SSID security settings, changing the encryption type, and saving. At even 5 minutes per AP, this is over 33 hours of work. With lightweight APs and a WLC, the administrator logs into a single WLC interface, changes the security policy on the WLAN profile, and clicks Apply. The WLC pushes the update to all 400 APs simultaneously via CAPWAP control tunnels. The entire operation completes in under a minute. This scalability difference is why any network with more than 5–10 APs should use a controller-based architecture.

2. A lightweight AP is booting for the first time on a subnet where the DHCP server is configured with Option 43 pointing to the WLC IP (10.10.10.1). The AP gets an IP but never joins the WLC. What is the most likely cause?

A. The AP firmware is autonomous — lightweight APs do not use DHCP B. UDP ports 5246 and 5247 are blocked by an ACL or firewall between the AP subnet and the WLC — CAPWAP cannot establish even though the AP has IP connectivity C. Option 43 only works for DNS discovery, not CAPWAP D. The WLC is on a different VLAN — CAPWAP requires Layer 2 adjacency

Correct answer is B. The AP successfully obtaining an IP address confirms DHCP and basic IP connectivity are working. Option 43 is correctly providing the WLC IP. The next step — establishing the CAPWAP tunnel — requires UDP port 5246 (CAPWAP control) to be open between the AP and WLC. If a firewall, ACL, or security group is blocking UDP 5246/5247, the AP sends CAPWAP Discovery Requests that never reach the WLC, and the WLC's responses never reach the AP. The AP times out and retries indefinitely but never joins. One of CAPWAP's key advantages over the legacy LWAPP is Layer 3 capability — the AP and WLC can be on completely different subnets as long as IP routing and the UDP ports are open. CAPWAP does not require Layer 2 adjacency (that was LWAPP's limitation).

3. In the split-MAC architecture, which functions must remain on the lightweight AP itself rather than being offloaded to the WLC, and why?

A. Authentication and SSID configuration — these must be local for fast client access B. Firmware management and policy enforcement — APs handle these because the WLC is too far away C. Roaming database and QoS — these require the AP's local radio knowledge D. Real-time radio functions: beacon transmission, probe responses, ACK frames, and MAC-layer retransmissions. These require sub-millisecond timing defined by the 802.11 standard — the WAN latency to the WLC would cause timing violations if these were centralised

Correct answer is D. The split-MAC design is driven by strict 802.11 timing requirements. For example: after receiving a data frame, an AP must send an ACK within a SIFS (Short Inter-Frame Space) interval of 16 µs (for 802.11g). The round-trip latency to a WLC — even on a fast LAN — is typically 1–10 ms: thousands of times too slow for ACK timing. Similarly, beacons must be transmitted at precisely timed intervals (every 100ms by default); probe responses must arrive within specific windows. All of these are "hard real-time" requirements. Everything else — client association management, authentication, policy, roaming state — are "soft" functions with latency tolerance of tens or hundreds of milliseconds, making them ideal candidates for centralisation at the WLC.

4. A branch office has 8 lightweight APs in FlexConnect local switching mode. The WAN link to the central WLC goes down. What happens to Wi-Fi clients currently connected, and what happens to new clients trying to connect?

A. Current clients remain connected — AP serves them using cached policies (standalone mode). New clients can connect to pre-configured SSIDs using cached configuration. Data traffic continues to switch locally. Only management visibility and WLC-dependent features (e.g., centralised RADIUS) are lost B. All clients are immediately disconnected — lightweight APs cannot function without the WLC C. APs reboot and convert to autonomous mode automatically D. Clients can still connect but data is buffered until the WAN recovers

Correct answer is A. FlexConnect's standalone mode is specifically designed for WAN failure resilience. When the CAPWAP control tunnel drops (WLC unreachable), FlexConnect APs enter standalone mode and continue to operate using the configuration last received from the WLC (cached locally). In local switching mode, client data traffic was already flowing directly from the AP to the local LAN without touching the WLC — so the data path is completely unaffected by WAN failure. Existing connected clients continue without interruption. New client connections are possible for SSIDs that are configured for FlexConnect standalone mode (PSK authentication continues to work; 802.1X may fail if RADIUS is at HQ). When the WAN recovers, APs automatically re-join the WLC and resynchronise. This is the key reason FlexConnect is mandated for branch office deployments.

5. A Wi-Fi user is on a video call and walks from one end of the building to the other, moving through coverage zones of 5 different lightweight APs all joined to the same WLC. The video call never drops. What mechanism enables this, and how does it differ from autonomous AP roaming?

A. The client re-authenticates to each AP but does so fast enough that the video doesn't notice B. The client's IP address changes at each AP but the video application reconnects automatically C. The WLC maintains a centralised client database with the client's IP, VLAN, auth state, and QoS profile. When the client roams to a new AP, the AP notifies the WLC via CAPWAP; the WLC updates its database and redirects traffic to the new AP — the client keeps its IP and stays authenticated. Handoff completes in milliseconds. With autonomous APs, each AP is independent — roaming requires re-authentication and often an IP change, which drops real-time sessions D. APs form a mesh and hand off the client's association directly to each other without the WLC

Correct answer is C. This is the defining advantage of controller-based Wi-Fi. The WLC acts as the single source of truth for all client state. When a client associates with AP1, the WLC records: MAC address, assigned IP, VLAN, authentication credentials (PMK from 802.1X), QoS profile, and current AP. When the client moves to AP2 and sends a re-association request, AP2 notifies the WLC via its CAPWAP control channel. The WLC updates the "current AP" field — all other client attributes remain identical. The WLC now forwards traffic destined for this client to AP2 instead of AP1. The handoff typically completes in under 50ms — imperceptible for video at standard frame rates. The client's IP address never changes, no TCP connections are reset, and no re-authentication occurs. With autonomous APs, each AP is an independent entity with no shared state — the client must fully re-associate and re-authenticate, which takes 200–2000ms and drops real-time sessions.

6. What is the difference between the CAPWAP control tunnel (UDP 5246) and the CAPWAP data tunnel (UDP 5247), and when might an engineer disable data tunnel DTLS encryption?

A. The control tunnel carries client data; the data tunnel carries management commands B. The control tunnel carries AP management messages (join, config, keepalives) — always DTLS-encrypted. The data tunnel carries client 802.11 frames (in central switching mode) — DTLS is optional and often disabled for performance, since client traffic is usually already protected by WPA2/WPA3 at the 802.11 layer C. Both tunnels are identical — the port numbers are just used for load balancing D. The data tunnel only exists in FlexConnect mode — in local mode there is only a control tunnel

Correct answer is B. The two CAPWAP channels serve completely different purposes. The control channel (UDP 5246) carries AP-WLC management traffic: the join request/response, configuration pushes, keepalive heartbeats, firmware transfer commands, RF management data, and statistics. This channel is always protected with DTLS because compromise of the management channel would allow an attacker to reconfigure APs or intercept authentication credentials. The data channel (UDP 5247) carries actual client Wi-Fi frames encapsulated in CAPWAP headers (central switching mode). DTLS encryption on the data channel is optional because: (1) client traffic is already encrypted by WPA2/WPA3 at the 802.11 layer — double-encrypting it adds CPU overhead with minimal additional security; (2) DTLS encryption on high-throughput data paths requires significant WLC CPU, potentially limiting scale. Many production deployments disable data DTLS for performance while keeping control DTLS mandatory.

7. An engineer is configuring DHCP Option 43 so that lightweight APs on the 10.20.0.0/24 subnet can discover the WLC at 172.16.1.100. The APs get DHCP addresses but still fail to discover the WLC. The engineer checks and confirms UDP 5246/5247 are open. What else should be verified?

A. Whether the APs support CAPWAP — older APs may only support LWAPP B. Whether DNS is configured — Option 43 requires DNS to resolve the WLC hostname C. Whether the APs are in FlexConnect mode — Option 43 only works in local mode D. Whether the DHCP Option 43 value is correctly formatted as a TLV (Type-Length-Value) with the WLC IP encoded in the correct vendor-specific format for Cisco APs (suboption 241, hex-encoded IP address)

Correct answer is D. DHCP Option 43 is a vendor-specific information field that must be formatted precisely for Cisco APs to parse the WLC IP correctly. Cisco APs expect Option 43 in a specific TLV (Type-Length-Value) format: type=0xf1 (241 decimal), length in bytes, then the WLC IP address(es) in dotted-decimal or hex. If the Option 43 value is entered as plain ASCII, as the wrong hex encoding, or without the correct suboption prefix, the AP receives the DHCP offer with Option 43 present but cannot interpret the WLC IP from it. The AP then falls back to other discovery methods (DNS, broadcast). Correctly formatted example for WLC at 172.16.1.100: f1:04:ac:10:01:64 (f1=suboption 241, 04=4 bytes length, ac:10:01:64=172.16.1.100 in hex). This formatting error is one of the most common CAPWAP lab misconfiguration issues.

8. A network engineer runs `show ap summary` on a Cisco WLC and sees an AP listed with status "Downloading." What is happening and what should the engineer expect next?

A. The WLC detected that the AP's firmware version does not match the WLC's expected AP image — the WLC is automatically pushing the correct firmware to the AP via CAPWAP. The AP will reboot after the download completes and rejoin the WLC with the correct firmware, at which point status changes to "Registered" B. The AP is downloading a configuration file from an external TFTP server — this is normal first-time setup C. The AP is actively serving clients and "Downloading" means it is processing data traffic D. The AP has a hardware fault and is unable to complete the join process

Correct answer is A. "Downloading" in the WLC AP status indicates automatic firmware upgrade. When an AP joins the WLC, one of the first things the WLC does is check whether the AP's running firmware version matches the image the WLC expects. If there's a mismatch, the WLC automatically initiates a firmware push: it sends the correct AP image over the CAPWAP control tunnel to the AP (via TFTP/FTP or CAPWAP data channel depending on WLC version). The AP writes the image to flash, then reboots. After rebooting with the new firmware, the AP rediscovers and rejoins the WLC (going through the full join process again), and its status changes to "Registered." This is one of the most valuable features of controller-based wireless — firmware consistency across the entire AP fleet is enforced automatically, with no manual AP-by-AP TFTP updates required.

9. An enterprise network currently has 15 autonomous APs. Management decides to migrate to a controller-based architecture with a Cisco WLC. Three of the APs are older models that do not support lightweight firmware. What options exist for these three APs?

A. All APs must be replaced — migration requires 100% lightweight APs B. The three APs can join the WLC but will operate in read-only mode C. The three older APs remain as autonomous (standalone) and continue to be managed individually — hybrid environments are valid where some APs are WLC-managed and others remain autonomous. The older APs are replaced as budget allows. D. The WLC can proxy management for autonomous APs without CAPWAP by using SNMP

Correct answer is C. Hybrid wireless environments are a real-world reality during phased migrations. The 12 compatible APs are converted to lightweight firmware and join the WLC — gaining centralised management, seamless roaming, RRM, and 802.1X. The 3 older incompatible APs continue to operate as autonomous devices, configured individually as before. This is a supported architecture: a WLC manages only lightweight APs; autonomous APs operate in parallel on the same physical network. The limitations: clients moving between WLC-managed APs and autonomous APs will experience the autonomous roaming behaviour (re-auth, potential session drop) on those handoffs. The standard migration path is to replace the autonomous APs with compatible models as part of a planned hardware refresh cycle. WLCs cannot manage or proxy autonomous APs via SNMP for wireless-specific functions.

10. Why does the CAPWAP protocol use DTLS (Datagram TLS) rather than standard TLS for encrypting the control channel between the AP and WLC?

A. DTLS is proprietary to Cisco — standard TLS is not supported on Cisco APs B. CAPWAP uses UDP, not TCP. Standard TLS requires TCP's reliable delivery and ordering guarantees. DTLS is the UDP-compatible version of TLS that provides the same encryption and authentication but handles packet loss and reordering within its own protocol, making it suitable for UDP-based tunnels C. DTLS provides stronger encryption than TLS — it uses 256-bit keys where TLS only uses 128-bit D. DTLS is faster than TLS because it skips the handshake phase entirely

Correct answer is B. This question tests understanding of why CAPWAP uses DTLS specifically. CAPWAP is built on UDP rather than TCP for performance reasons — UDP has lower overhead and is better suited for the control tunnel's mix of keepalives and bulk firmware transfers. Standard TLS (Transport Layer Security) was designed exclusively for TCP. It relies on TCP's guaranteed delivery, in-order delivery, and connection state management. Using TLS over UDP would break because TLS assumes all previously sent data has been received before processing new data. DTLS (Datagram TLS, RFC 6347) solves this by adding its own mechanisms for handling packet loss (retransmission), packet reordering (sequence numbers), and replay prevention — the same security properties as TLS but working correctly over connectionless UDP. CAPWAP specifies DTLS for the control channel to provide mutual authentication (AP and WLC authenticate each other with X.509 certificates) and encryption of management traffic.

← Back to Home