Configuring a Wireless LAN Controller (WLC) — Getting Started
Enterprise wireless networks do not run on standalone access points. Each AP independently managing its own SSID, channels, and clients creates an uncoordinated sprawl — channel interference between neighbours, inconsistent security policies, no roaming handoff, and no centralised visibility. The Wireless LAN Controller (WLC) solves all of this: a single hardware or virtual appliance that centrally manages tens to thousands of Lightweight Access Points (LAPs), coordinating radio frequency, enforcing uniform security policy, and providing seamless client roaming across the entire wireless network.
The WLC–LAP architecture is built on the CAPWAP (Control and Provisioning of Wireless Access Points) protocol. Every LAP boots without local configuration — it discovers the WLC via CAPWAP, downloads its complete configuration, and operates entirely under WLC control. The WLC handles all 802.11 management frames and forwards client data either through the CAPWAP tunnel (centrally switched) or directly from the AP (locally switched — FlexConnect). This lab covers the initial WLC setup: running the startup wizard, defining the mandatory interfaces, and registering the first access point.
The WLC connects to the network as a trunk on a Cisco Catalyst switch. Review Trunk Port Configuration and VLAN Creation and Management before starting — the WLC management VLAN and AP VLAN must exist on the switch. For the DHCP server that provides IP addresses to LAPs during discovery, see DHCP Server Configuration. For NTP synchronisation required for WLC certificates and logging, see NTP Configuration.
1. WLC Architecture — Core Concepts
Autonomous AP vs Split-MAC Architecture
For background on why centralised control is preferred over standalone APs, see Lightweight vs Autonomous APs.
| Feature | Autonomous AP (Standalone) | Lightweight AP + WLC (Split-MAC) |
|---|---|---|
| Configuration | Each AP configured independently via CLI or GUI | All APs configured centrally on the WLC — APs have no local config |
| 802.11 management | AP handles all management frames locally (beacons, probes, auth, assoc) | Split: AP handles real-time frames (beacons, ACKs); WLC handles auth and assoc processing |
| Client data path | Switched locally at the AP | Tunnelled to WLC via CAPWAP (central switching) or locally at AP (FlexConnect) |
| Roaming | Client re-authenticates at each AP — visible interruption | WLC manages client state — seamless Layer 2 and Layer 3 roaming |
| RF management | Manually configured per AP | WLC RRM (Radio Resource Management) automatically adjusts channels and power |
| Scale | Practical up to ~10 APs before management burden becomes excessive | Single WLC manages 6 to 6000+ APs depending on model |
CAPWAP — How APs Join the WLC
CAPWAP (RFC 5415) uses two UDP tunnels between each LAP and the WLC:
| Tunnel | UDP Port | Purpose | Encrypted? |
|---|---|---|---|
| CAPWAP Control | UDP/5246 | AP configuration, firmware downloads, state machine, radio management commands | Yes — DTLS encrypted by default |
| CAPWAP Data | UDP/5247 | Client traffic tunnelled from AP to WLC (centrally switched mode) | Optional — disabled by default for performance |
LAP Discovery Process — How an AP Finds the WLC
WLC Interface Types
| Interface | Purpose | Required? | Notes |
|---|---|---|---|
| Management | WLC GUI/CLI management, AP CAPWAP control traffic, inter-controller communication | Yes — mandatory | Only one management interface per WLC — must have a routable IP |
| Virtual | DHCP relay, web authentication portal, Layer 3 mobility anchor | Yes — mandatory | Uses a non-routable fictitious IP (e.g., 192.0.2.1) — never advertised in routing |
| Service Port | Out-of-band management on a dedicated physical port | No — optional | Not connected to the data network — direct PC connection for recovery |
| Dynamic | Client VLAN interface — one per WLAN/SSID/VLAN mapping | No — per WLAN | Created for each SSID-to-VLAN mapping (e.g., Corp SSID → VLAN 20) |
| AP Manager | Older WLC models: separate interface for AP CAPWAP traffic | No — legacy | Modern WLC versions (7.x+) use the management interface for CAPWAP — AP Manager is deprecated |
2. Lab Topology & Scenario
A Cisco 3504 WLC connects to NetsTuts_SW1 via a trunk port. Three VLANs are used: VLAN 10 for WLC management, VLAN 20 for AP connectivity (CAPWAP traffic), and VLAN 30 for wireless client traffic. A lightweight AP (Cisco 2802i) is connected to an access port on SW1 in VLAN 20. The DHCP server provides IPs to the AP with DHCP Option 43 pointing to the WLC management IP:
| Component | IP / VLAN | Role |
|---|---|---|
| WLC Management Interface | 192.168.10.50 / VLAN 10 | Web GUI, SSH, CAPWAP control plane, AP join |
| WLC Virtual Interface | 192.0.2.1 (fictitious) | Web auth portal, DHCP relay, mobility anchor |
| LAP (2802i) | 192.168.20.10 / VLAN 20 | Wireless access point — joins WLC via CAPWAP |
| DHCP Server | 192.168.10.200 | Assigns IPs to APs with Option 43 pointing to 192.168.10.50 |
3. Step 1 — Prepare the Switch
Before powering on the WLC, configure the switch trunk port and access port for the AP. The WLC port must be a trunk carrying all three VLANs. The AP port is an access port in the AP management VLAN:
NetsTuts_SW1>en NetsTuts_SW1#conf t Enter configuration commands, one per line. End with CNTL/Z. ! ── Create required VLANs ──────────────────────────────── NetsTuts_SW1(config)#vlan 10 NetsTuts_SW1(config-vlan)#name MGMT NetsTuts_SW1(config-vlan)#exit NetsTuts_SW1(config)#vlan 20 NetsTuts_SW1(config-vlan)#name AP-MGMT NetsTuts_SW1(config-vlan)#exit NetsTuts_SW1(config)#vlan 30 NetsTuts_SW1(config-vlan)#name WIRELESS-CLIENTS NetsTuts_SW1(config-vlan)#exit ! ── WLC uplink: 802.1Q trunk carrying all WLC VLANs ────── NetsTuts_SW1(config)#interface GigabitEthernet1/0/48 NetsTuts_SW1(config-if)#description WLC-3504-uplink NetsTuts_SW1(config-if)#switchport mode trunk NetsTuts_SW1(config-if)#switchport trunk allowed vlan 10,20,30 NetsTuts_SW1(config-if)#spanning-tree portfast trunk NetsTuts_SW1(config-if)#exit ! ── AP access port: VLAN 20 (AP management) ────────────── NetsTuts_SW1(config)#interface GigabitEthernet1/0/2 NetsTuts_SW1(config-if)#description Cisco-2802i-AP NetsTuts_SW1(config-if)#switchport mode access NetsTuts_SW1(config-if)#switchport access vlan 20 NetsTuts_SW1(config-if)#spanning-tree portfast NetsTuts_SW1(config-if)#exit NetsTuts_SW1(config)#end NetsTuts_SW1#wr
spanning-tree portfast trunk on the WLC uplink prevents
the 30-second STP listening/learning delay — critical for
the WLC to come online quickly and avoid timeout issues during
initial setup. spanning-tree portfast on the AP port
ensures the AP gets network access immediately on power-up, allowing
it to complete DHCP and CAPWAP discovery within the normal boot
timeout. Without PortFast on AP ports, the AP may time out its
CAPWAP discovery while waiting for STP to converge. See
PortFast & BPDU Guard
for full PortFast configuration guidance.
4. Step 2 — WLC Startup Wizard (Console)
A factory-reset WLC launches the startup wizard automatically on the console port (9600 8N1). The wizard collects the minimum configuration needed to bring the WLC online. The following shows the complete wizard interaction with explanations at each prompt:
Welcome to the Cisco Wizard Configuration Tool Use the '-' character to backup. Would you like to terminate autoinstall? [yes]: yes System Name [Cisco_xx:yy:zz] (31 characters max): NetsTuts-WLC Enter Administrative User Name (24 characters max): admin Enter Administrative Password (3 to 24 characters): NetsTuts@2026 Re-enter Administrative Password : NetsTuts@2026 Management Interface IP Address: 192.168.10.50 Management Interface Netmask: 255.255.255.0 Management Interface Default Router: 192.168.10.1 Management Interface VLAN Identifier (0 = untagged): 10 Management Interface Port Num [1 to 8]: 1 Management Interface DHCP Server IP Address: 192.168.10.200 Virtual Gateway IP Address: 192.0.2.1 Multicast IP Address: 239.0.0.1 Mobility/RF Group Name: NetsTuts-RF Network Name (SSID): NetsTuts-Corp Configure DHCP Bridging Mode [yes][NO]: NO Allow Static IP Addresses [YES][no]: YES Configure a RADIUS Server? [YES][no]: no Warning! The default WLAN security policy requires a RADIUS server. Please make sure that a RADIUS server is specified after the configuration is complete. (This can be done through the WLC GUI or CLI.) Enter Country Code list (enter 'help' for a list of countries) [US]: US Enable 802.11b Network [YES][no]: YES Enable 802.11a Network [YES][no]: YES Enable 802.11g Network [YES][no]: YES Enable Auto-RF [YES][no]: YES Configuration saved! Resetting system with new configuration...
Each wizard prompt configures a critical component. The
System Name identifies the WLC in network management
tools. The Management Interface IP (192.168.10.50)
is the address used to reach the WLC GUI and where APs will send
CAPWAP Join Requests. VLAN 10 tags management traffic
on the trunk. The Virtual Gateway IP (192.0.2.1) must
be a non-routable address that is never used anywhere else in the
network — it is an internal WLC address for web authentication
redirects and DHCP relay, not reachable from outside the WLC. The
Mobility/RF Group Name identifies the group for
inter-controller roaming. The wizard creates an initial SSID
(NetsTuts-Corp) which will be refined in later steps.
Virtual Gateway IP — Why 192.0.2.1?
| Requirement | Explanation |
|---|---|
| Must be non-routable | The virtual IP must not exist in the routing table or be reachable from any real host. If it is reachable, clients may route to it unexpectedly, breaking web authentication |
| Must be unique across all WLCs | In a mobility group, all WLCs use the same virtual IP — consistency is required. Different virtual IPs break Layer 3 roaming |
| Common convention | RFC 5737 designates 192.0.2.0/24 as documentation/example addresses — never routed on the internet. Using 192.0.2.1 is a widely adopted convention for the WLC virtual interface. Some deployments use 1.1.1.1 if it is not a real address in the environment |
5. Step 3 — Log In to WLC GUI and Verify Interfaces
After the wizard completes and the WLC reboots, access the GUI from a PC on VLAN 10. The WLC GUI uses HTTPS by default on port 443:
The CONTROLLER → Interfaces page is the primary interface
verification screen. Both the management and virtual interfaces must
show as configured and operational. If the management interface is
missing or shows the wrong VLAN, the WLC cannot communicate with
APs on the network. Note that the WLC GUI uses a self-signed
certificate by default — accept the browser security warning
for initial access. In production, install a signed certificate
from your CA.
Create the Dynamic Interface for Wireless Clients
The dynamic interface (corp-clients) maps WLAN
traffic to VLAN 30 — wireless clients in the Corp SSID receive
addresses from the 192.168.30.0/24 subnet via the DHCP server at
192.168.10.200. One dynamic interface per WLAN/VLAN mapping is
required. The IP address on the dynamic interface acts as the
default gateway for that client subnet when the WLC is performing
inter-VLAN routing. The VLAN 30 tag must be allowed on the trunk
between the WLC and the switch — already configured in Step 1.
6. Step 4 — Connecting the First Lightweight Access Point
DHCP Option 43 on the DHCP Server
The most reliable AP discovery method is DHCP Option 43 — the WLC's management IP is embedded in the DHCP Offer sent to the AP. Configure this on the DHCP server (or on the IOS DHCP pool if using the router as server):
! ── On IOS DHCP server for AP subnet (192.168.20.0/24) ── NetsTuts_R1(config)#ip dhcp pool AP-POOL NetsTuts_R1(dhcp-config)#network 192.168.20.0 255.255.255.0 NetsTuts_R1(dhcp-config)#default-router 192.168.20.1 NetsTuts_R1(dhcp-config)#dns-server 8.8.8.8 ! ── Option 43: WLC management IP in TLV format ─────────── ! ── Type=f1(241), Length=04 (4 bytes), Value=WLC IP ────── NetsTuts_R1(dhcp-config)#option 43 ascii f1:04:c0:a8:0a:32 ! ── c0:a8:0a:32 = 192.168.10.50 in hex ────────────────── NetsTuts_R1(dhcp-config)#exit
DHCP Option 43 carries the WLC IP address in a vendor-specific TLV
(Type-Length-Value) format. The Cisco LAP expects the sub-option
type 0xF1 (241 decimal) with the WLC IP in 4-byte hex.
192.168.10.50 in hex is: 192=c0, 168=a8, 10=0a, 50=32.
The length field 04 means 4 bytes (one IPv4 address). Multiple WLC
IPs can be specified by increasing the length and appending more
hex octets — e.g., two WLCs:
option 43 ascii
f1:08:[IP1-hex]:[IP2-hex]. If using a Windows DHCP server,
Option 43 is configured as a binary value through the DHCP console
or PowerShell.
Verifying AP Join on WLC GUI
A newly joined AP shows Status: Joined and
Mode: Local (centrally switched) in the All APs
list. Clicking the AP name reveals the full detail view.
CAPWAP Path confirms the tunnel endpoints —
the AP's IP (192.168.20.10) and the WLC management IP (192.168.10.50).
Software Ver confirms the AP firmware version
downloaded from the WLC. Certificate: MIC means the
AP authenticated using its factory-installed certificate. If the AP
shows Discovering or Associating
instead of Joined, the CAPWAP join is in progress
or failing — see the troubleshooting section.
AP Join Verification via WLC CLI
! ── SSH to WLC management IP ───────────────────────────── admin@adminPC:~$ ssh [email protected] (NetsTuts-WLC) > show ap summary Number of APs.................................... 1 AP Name Slots AP Model Ethernet MAC IP Address Port Country Priority ───────────────── ───── ────────── ───────────── ────────────── ──── ─────── ──────── AP2802i 2 AIR-2802I a0:e0:af:xx:yy 192.168.20.10 1 US 1 (NetsTuts-WLC) > show ap join stats summary all Number of APs.................................... 1 Base Mac Ethernet Mac AP Name IP Address Status ─────────────── ─────────────── ───────── ────────────── ──────────────── a0:e0:af:xx:yy a0:e0:af:xx:yy AP2802i 192.168.20.10 Joined
show ap summary on the WLC CLI lists all registered APs
with their model, MAC address, IP, port (which WLC physical port
the AP's traffic arrives on), and priority. show ap join stats
summary all shows the join state for every AP that has
attempted to contact this WLC — including APs still in
discovery or those that failed. The status Joined
confirms successful CAPWAP registration. If the AP is stuck in
Discovering, check DHCP Option 43 and IP
connectivity between the AP subnet and WLC management interface.
7. Step 5 — Configure the Initial WLAN (SSID)
The startup wizard created a placeholder SSID. Configure a proper WLAN through the GUI: WLANs → Create New → [Go]:
The WLAN configuration maps the SSID to the dynamic interface
(corp-clients) which places wireless clients on VLAN 30.
WPA2 + AES + PSK is the minimum acceptable security
for a basic WLAN — see Wi-Fi Security
for a full breakdown of WPA2/WPA3 security options. For enterprise
environments, replace PSK with 802.1X authentication backed by a
RADIUS server. The WLAN ID (1) is used in WLC CLI commands to
reference this WLAN. After applying, the SSID becomes active on
all joined APs immediately — clients can now see and connect
to NetsTuts-Corp.
8. Verification
show interface summary (WLC CLI)
(NetsTuts-WLC) > show interface summary Number of Interfaces.......................... 3 Interface Name Port Vlan Id IP Address Type Ap Mgr Guest ───────────────────────────────────────────────────────────────────────────────────── corp-clients 1 30 192.168.30.1 Dynamic No No management 1 10 192.168.10.50 Static Yes No virtual N/A N/A 192.0.2.1 Static No No
All three required interfaces are present and active. The
management interface shows Ap Mgr: Yes
— confirming this interface handles AP CAPWAP control traffic.
The corp-clients dynamic interface maps to VLAN 30.
The virtual interface shows no VLAN ID — it is
not tagged on the trunk but used internally by the WLC for web auth
and DHCP relay. If any interface is missing here, return to
CONTROLLER → Interfaces in the GUI to create it.
show wlan summary (WLC CLI)
(NetsTuts-WLC) > show wlan summary Number of WLANs.................................. 1 WLAN ID WLAN Profile Name / SSID Status Interface Name ─────── ───────────────────────────────────── ──────── ─────────────── 1 Corp-WLAN / NetsTuts-Corp Enabled corp-clients
show ap config general AP2802i (WLC CLI)
(NetsTuts-WLC) > show ap config general AP2802i Cisco AP Name.................................... AP2802i Cisco AP Identifier.............................. 1 Country code..................................... US Regulatory Domain allowed by Country............ 802.11bg:-A 802.11a:-A AP Country code.................................. US AP Regulatory Domain............................. -A Switch Port Number............................... 1 CAPWAP Path MTU.................................. 1485 Telnet State..................................... Disabled SSH State........................................ Enabled Cisco AP Location................................ default location Cisco AP Group Name.............................. default-group Primary Cisco Switch Name........................ NetsTuts-WLC Primary Cisco Switch IP Address.................. 192.168.10.50
The AP configuration detail confirms critical fields: the AP's
Primary Cisco Switch IP (192.168.10.50) is the
WLC management IP — the AP will always attempt to rejoin this
WLC first after a reboot. CAPWAP Path MTU: 1485 is
the standard MTU accounting for CAPWAP tunnel overhead (1500 - 28
bytes CAPWAP header = 1472, with additional headers the practical
value is 1485). SSH State: Enabled confirms the AP
can be accessed directly via SSH for diagnostic purposes.
debug capwap ap error (AP CLI or WLC)
! ── On WLC: trace AP join issues ───────────────────────── (NetsTuts-WLC) > debug capwap ap error ! ── Sample output during successful join ───────────────── *Mar 5 09:30:11.123: CAPWAP: AP a0:e0:af:xx:yy sent Discovery Request *Mar 5 09:30:11.456: CAPWAP: Sending Discovery Response to 192.168.20.10 *Mar 5 09:30:12.234: CAPWAP: AP a0:e0:af:xx:yy sent Join Request *Mar 5 09:30:12.567: CAPWAP: DTLS handshake complete with 192.168.20.10 *Mar 5 09:30:13.001: CAPWAP: AP a0:e0:af:xx:yy Join successful *Mar 5 09:30:13.500: CAPWAP: Configuration download to AP2802i complete (NetsTuts-WLC) > no debug capwap ap error
Verification Command Summary
| Command / Location | What It Shows | Primary Use |
|---|---|---|
show ap summary (WLC CLI) |
All joined APs with model, MAC, IP, port, country | Confirm how many APs have joined and their current state |
show ap join stats summary all (WLC CLI) |
Join status per AP MAC — Joined, Discovering, or failed | Diagnose APs that are failing to join — shows discovery attempts |
show interface summary (WLC CLI) |
All WLC interfaces, VLANs, IPs, and AP manager status | Verify management, virtual, and dynamic interfaces are all present and configured |
show wlan summary (WLC CLI) |
All configured WLANs with status and interface mapping | Confirm WLANs are enabled and mapped to the correct dynamic interface |
| WIRELESS → Access Points (WLC GUI) | Visual AP list with join status, mode, and IP address | Quick visual confirmation that APs are joined and operational |
show ip dhcp binding (router/server) |
DHCP leases assigned — confirms AP received an IP via DHCP Option 43 pool | Verify the AP got an IP address as the first step in CAPWAP discovery |
9. Troubleshooting WLC and LAP Issues
| Problem | Symptom | Cause | Fix |
|---|---|---|---|
| AP stuck in Discovering state | show ap join stats summary all shows the AP in Discovering indefinitely — never reaches Joined |
AP cannot reach the WLC management IP. Common causes: AP did not receive DHCP Option 43, wrong WLC IP in Option 43, trunk VLAN mismatch between switch and WLC, or routing issue between AP subnet and WLC management VLAN | Check AP DHCP lease: show ip dhcp binding on the DHCP server. Verify Option 43 hex value matches WLC IP. Check that VLAN 20 is allowed on the trunk between switch and WLC. Ping the WLC management IP from a host on VLAN 20. Enable debug capwap ap error on the WLC. |
| AP joins but shows Wrong Country Code | AP joins successfully but is in a restricted mode with limited channels and power | The AP's configured country code does not match the WLC's country code — the AP was previously configured for a different region | On WLC GUI: WIRELESS → Access Points → [AP Name] → Advanced tab → Country Code. Alternatively on WLC CLI: config ap country [country-code] [AP-name]. The AP may need to reboot to apply the new country code. |
| WLC GUI not accessible after wizard | Cannot reach https://192.168.10.50 from admin PC | Admin PC not on VLAN 10, management VLAN not allowed on trunk, or wrong IP entered in wizard. Also check: browser blocking self-signed certificate, HTTP vs HTTPS | Verify admin PC IP is on 192.168.10.0/24 subnet. Check VLAN 10 is allowed on trunk: show interfaces trunk on SW1. Reconnect to WLC console and verify management interface IP with show interface management. Use HTTPS (not HTTP) — WLC redirects HTTP to HTTPS. |
| AP joins but clients cannot get DHCP | Client associates to SSID but gets "No IP address" or 169.254.x.x APIPA address | Dynamic interface (corp-clients) is mapped to the wrong VLAN, VLAN 30 is not allowed on the WLC-switch trunk, or the DHCP server does not have a pool for 192.168.30.0/24 | Verify dynamic interface VLAN: WLC GUI → CONTROLLER → Interfaces → corp-clients → confirm VLAN ID is 30. Verify VLAN 30 on trunk: show interfaces trunk. Check DHCP server for a 192.168.30.0/24 pool. |
| AP drops and re-joins repeatedly | AP shows as Joined then Discovering cycling in the AP list every few minutes | CAPWAP keepalive failures — caused by network congestion on the CAPWAP path, MTU issues (fragmented CAPWAP packets dropped), or an upstream device (firewall/ACL) blocking UDP/5246 | Check for ACLs or firewalls blocking UDP/5246 between AP subnet and WLC management. Reduce CAPWAP MTU on WLC: config ap capwap mtu 1250. Check for packet loss on the AP-to-WLC path with ping from the WLC to the AP IP. |
| Virtual interface IP conflict | Web authentication redirects fail, DHCP relay behaves erratically, or routing loops observed | The virtual interface IP (e.g., 192.0.2.1) is actually routable in the network — a real host or router interface uses the same IP, creating a routing conflict | Change the virtual interface to a truly non-routable IP. Confirm no device in the network uses 192.0.2.1. On WLC GUI: CONTROLLER → Interfaces → virtual → change IP to a unique non-routable address. All WLCs in the mobility group must use the same virtual IP. |
Key Points & Exam Tips
- The WLC–LAP architecture uses CAPWAP (UDP/5246 for control, UDP/5247 for data). LAPs have no local configuration — they download everything from the WLC via the CAPWAP control tunnel after joining.
- LAP discovery order: (1) DHCP Option 43 (most reliable), (2) DNS lookup for
CISCO-CAPWAP-CONTROLLER.domain, (3) subnet broadcast, (4) previously known WLC in AP flash. Configure Option 43 for predictable production deployments. - The WLC has three mandatory interface types: management (WLC administration and CAPWAP control), virtual (web auth, DHCP relay — must use a non-routable IP), and one or more dynamic interfaces (one per SSID-to-VLAN mapping).
- The virtual interface IP must be non-routable, unique in the network, and identical across all WLCs in the same mobility group. Using RFC 5737 addresses (192.0.2.0/24) is the widely adopted convention.
- The switch port connecting to the WLC must be a trunk carrying all VLANs used by the WLC (management VLAN, AP VLAN, and all client VLANs). Access ports are not used for WLC uplinks. Configure
spanning-tree portfast trunkon the WLC uplink. - AP ports on the switch should be access ports in the AP management VLAN with
spanning-tree portfast— this prevents STP delay from causing CAPWAP discovery timeouts during AP boot. - Intra-zone traffic between same-zone interfaces is always permitted in ZBF. Similarly, traffic within the same VLAN between wireless clients is controlled by the P2P Blocking option on the WLAN.
show ap summaryandshow ap join stats summary allare the primary CLI verification commands for AP registration status. The GUI WIRELESS → Access Points page provides the same information visually.- After joining, the AP downloads the WLC firmware and may reboot to upgrade — Status: Downloading in the AP list is normal during the firmware update phase. The AP comes back as Joined after the upgrade reboot.
- On the CCNA exam: know the CAPWAP UDP ports (5246/5247), the four LAP discovery methods, the three mandatory WLC interface types, why the virtual IP must be non-routable, and the split-MAC architecture (what the AP handles locally vs what the WLC handles centrally).
Next Steps: The WLC is running and the first AP
has joined. To configure multiple SSIDs for different user groups
(guest, corporate, IoT) with separate VLANs, expand the dynamic
interfaces and WLAN configurations using the same GUI workflow —
see WLC SSID VLAN Mapping
for detailed WLAN-to-VLAN configuration.
For diagnosing client association failures, DHCP issues, and RF
problems on a running WLC, see
Troubleshooting Wireless Connectivity.
For the underlying VLAN and trunk infrastructure supporting the WLC,
revisit Trunk Port
Configuration and
VLAN Creation and
Management. For NTP synchronisation ensuring WLC certificate
validity and accurate logging timestamps, see
NTP Configuration.
TEST WHAT YOU LEARNED
A lightweight AP has been powered on and connected to the network but remains in the Discovering state indefinitely. It received an IP address via DHCP but DHCP Option 43 was not configured. Which LAP discovery method will it attempt next, and what must be configured for it to succeed?
Correct answer is C. The LAP CAPWAP discovery process follows a defined sequence. After failing to receive a WLC IP from DHCP Option 43, the AP proceeds to DNS discovery. It performs a DNS A-record lookup for the hostname
CISCO-CAPWAP-CONTROLLER appended with the domain suffix provided in the DHCP Offer. For this method to succeed, the DNS server must have a record mapping this hostname to the WLC management IP (192.168.10.50 in our lab). If DNS also fails, the AP then attempts a subnet broadcast on UDP/5246, which only works if the WLC management interface is on the same subnet. Finally, if the AP has previously joined a WLC, it uses the IP stored in its flash memory. In production, DHCP Option 43 is the most reliable method because it works across subnets and does not require DNS configuration.What is the WLC virtual interface used for, and why must its IP address never be reachable from anywhere in the network?
Correct answer is A. The virtual interface serves three critical internal WLC functions. For web authentication: when a client needs to be redirected to a login portal, the WLC uses the virtual IP as the redirect destination. For DHCP relay: the virtual IP is used as the relay agent source address when proxying DHCP requests from wireless clients to the DHCP server. For Layer 3 mobility: the virtual IP is used as the anchor point for client mobility between WLCs. The non-routability requirement exists because the WLC uses this IP for internal packet manipulation — if any network device has a route to this IP pointing somewhere other than the WLC itself, these functions break unpredictably. RFC 5737 addresses (192.0.2.0/24) are the standard choice because they are designated as documentation-only addresses and are never routed on any production network.
In the split-MAC architecture, which 802.11 functions are handled by the lightweight AP locally, and which are handled by the WLC?
Correct answer is D. The "split-MAC" name describes this division of 802.11 MAC layer responsibility. The AP must handle time-critical operations locally because they have strict 802.11 timing requirements — an acknowledgement (ACK) for a received frame must be sent within 10 microseconds. Sending that ACK to the WLC and waiting for a response would take milliseconds (impossible to meet the timing). So real-time operations (beacons, ACKs, probe responses, PHY operations) stay at the AP. Non-real-time operations (authentication, key management, association state, roaming handoffs, SSID policy) are handled centrally by the WLC, giving administrators a single management point. In Local mode, client data is also tunnelled through CAPWAP to the WLC, which then forwards it to the wired network — the AP never touches the VLAN directly.
An AP is connected to a switch access port in VLAN 20. The WLC management interface is on VLAN 10 (192.168.10.50). The AP gets a DHCP address on 192.168.20.10 with Option 43 pointing to 192.168.10.50. The AP remains in Discovering. Routing between VLAN 20 and VLAN 10 is confirmed working. What else should be checked?
Correct answer is B. This is a classic inter-VLAN WLC deployment scenario. Routing between VLANs 20 and 10 works (confirmed by the question) — IP connectivity exists. However, CAPWAP specifically uses UDP ports 5246 and 5247. If any security device in the path (IOS ACL, Zone-Based Firewall, hardware firewall) is blocking UDP traffic on these ports, CAPWAP discovery packets are silently dropped even though regular ICMP ping works fine. The AP can receive Option 43, attempt to send CAPWAP Discovery Requests to 192.168.10.50:5246, and get no response — appearing stuck in Discovering. The fix is to ensure UDP/5246 and UDP/5247 are permitted between the AP subnet (192.168.20.0/24) and the WLC management IP (192.168.10.50).
Why must the switch port connecting to the WLC be configured as a trunk, not an access port?
Correct answer is D. The WLC is a multi-VLAN device — it terminates traffic from multiple VLANs on a single physical port. The management interface is on VLAN 10, APs may reside on VLAN 20, and wireless clients from different SSIDs are mapped to VLAN 30, VLAN 40, etc. All of this traffic needs to flow through the single physical port connecting the WLC to the switch. 802.1Q trunking preserves the VLAN ID in each Ethernet frame, allowing the WLC to differentiate traffic belonging to different interfaces. If the port were an access port, only one VLAN would be supported and all VLAN-tagged frames would be dropped — the WLC would only work with a single management VLAN and no client VLANs.
What is the difference between a WLC management interface and a dynamic interface, and how many of each can exist?
Correct answer is A. The management interface is a singleton — exactly one per WLC, configured during the setup wizard. It provides: the WLC's primary reachable IP for administration (GUI, SSH, SNMP), the CAPWAP termination point for all AP join requests and control traffic, the source IP for WLC-to-WLC mobility communication, and the management VLAN tag. Dynamic interfaces are created manually by the administrator for each SSID/VLAN combination: one for Corp WLAN on VLAN 30, another for Guest WLAN on VLAN 40, etc. The number of dynamic interfaces is limited by the WLC model (typically 512 on enterprise WLCs). Each dynamic interface acts as the default gateway IP for its corresponding client subnet and maps the WLAN to the correct VLAN tag on the trunk.
show ap join stats summary all on the WLC shows an AP with status "Image Data Download" for several minutes. Is this normal and what is happening?
Correct answer is C. One of the most important WLC features is automated AP firmware management. When an AP joins the WLC for the first time (or after a WLC software upgrade), the WLC compares the AP's firmware version with the image it has on file. If they differ, the WLC automatically pushes the correct firmware to the AP via the CAPWAP control tunnel. The "Image Data Download" status indicates this firmware transfer is in progress — a completely normal and expected event, particularly when deploying new APs or after upgrading the WLC software. The download can take several minutes depending on the image size and network speed. After the download completes, the AP reboots, applies the new firmware, and rejoins the WLC — appearing as "Joined" in the AP list. Interrupting power during this phase can corrupt the AP image.
A wireless client associates to the SSID but receives a 169.254.x.x APIPA address instead of a valid IP from the 192.168.30.0/24 range. The DHCP server has a pool for that subnet. What is the most likely WLC configuration issue?
Correct answer is B. APIPA (169.254.x.x) means the client sent DHCP Discover requests and received no DHCP Offer in response. The client is associated (wireless connectivity exists) but is not getting a valid IP. In a centrally switched WLC deployment, the client's DHCP traffic is tunnelled through CAPWAP to the WLC, which then forwards it on the VLAN specified by the dynamic interface. The most common causes: (1) The WLAN is mapped to the wrong dynamic interface (e.g., mapped to management instead of corp-clients), so DHCP requests arrive on VLAN 10 where no pool for 192.168.30.0/24 exists. (2) The dynamic interface has the wrong VLAN ID (not 30). (3) VLAN 30 is not allowed on the WLC-switch trunk, so the tagged frames are dropped before reaching the DHCP server. Verify in sequence: WLAN interface mapping → dynamic interface VLAN → trunk allowed VLANs → DHCP pool.
Why must spanning-tree portfast be configured on the switch port facing the lightweight AP, and what happens without it?
Correct answer is D. Spanning Tree Protocol's role is to prevent switching loops by blocking redundant paths. When a new device connects to a port, STP runs the port through Blocking → Listening (15 sec, no traffic) → Learning (15 sec, no traffic) → Forwarding. This 30-second delay is acceptable for most devices but problematic for LAPs. A Cisco LAP has a defined CAPWAP discovery timeout — if it cannot complete DHCP and CAPWAP discovery within this window, it may give up and fall back to autonomous mode or enter a reset loop. PortFast (or Rapid PVST + edge ports) bypasses the Listening and Learning states, immediately putting the port in Forwarding the moment the LAP connects. This is essential for reliable AP deployment. Note: PortFast should only be used on ports facing end hosts — never on ports connected to other switches, as it bypasses loop detection for that port.
In what scenario would you configure a zone-pair from OUTSIDE to self in ZBF on the same router also running as a WLC CAPWAP gateway, and what risk does omitting it introduce?
Correct answer is C. This question tests the integration of two topics from the course. The ZBF self zone, when left without any zone-pair policy, defaults to permitting all traffic to the router's own processes. However, once you create a zone-pair involving the self zone (e.g., for SSH hardening as covered in the ZBF lab), the self zone policy becomes restrictive. If you only add
match protocol ssh and class-default drop, then CAPWAP packets (UDP/5246, UDP/5247) arriving at the router are dropped by class-default. In a scenario where the router routes between the AP VLAN and the WLC management VLAN, and also has ZBF self-zone policies, you must ensure UDP/5246 and UDP/5247 are in the permitted class map or are handled by a transit zone-pair (not self). The practical lesson: whenever adding self-zone restrictions, audit all router-destined protocol traffic (OSPF, NTP, SNMP, CAPWAP, RADIUS) and explicitly permit each needed one.Related Topics & Step-by-Step Tutorials
Related concepts and next steps:
- Wireless LAN Controller (WLC) – Overview — WLC architecture — CAPWAP, SSID, dynamic interfaces
- Access Points (APs) & Wireless LAN Controllers (WLCs) — lightweight APs and WLC control
- Lightweight vs Autonomous Access Points — CAPWAP — local mode vs FlexConnect
- Creating SSIDs and Mapping to VLANs on a Cisco WLC
- Autonomous Access Point Configuration via CLI
- FlexConnect AP Configuration
- Guest WLAN with Web Authentication (WebAuth)
- Wireless RF Channel & Power Planning