CAPWAP Controller Discovery Process

In a controller-based architecture, CAPWAP access points are dependent on a wireless controller to provide the software image, configuration, and centralized control and optionally data forwarding functions. Therefore, it is necessary for the access point to find a list of available controllers with which it can associate.

The following layer 3 CAPWAP discovery options are supported:
1.       Broadcast on the local subnet
2.       Local NVRAM list of the previously joined controller, previous mobility group members, and administrator primed controller through the console port
3.       Over the Air Provisioning (OTAP) (subsequently removed in version code)
4.       DHCP Option 43 returned from the DHCP server
5.       DNS lookup for "CISCO-CAPWAP-CONTROLLER.localdomain"

The CAPWAP AP sends broadcast discovery requests on the local subnet. Controllers with management interfaces on the same subnet receive the discovery request and send a discovery reply back to the CAPWAP AP.

If no controllers are on the local subnet, broadcasts may be forwarded to the controller management interface by the local router using the Cisco “forward-protocol” and “ip helper-address” features. Use these commands to configure the router:

ip forward-protocol udp 12223
ip forward-protocol udp 5246
interface interface-name
     ip helper-address wlc-management-ip-address

When using the forward-protocol, the default gateway modifies the CAPWAP discovery packet that is broadcast on the local subnet by replacing the broadcast destination IP address with the WLC management IP address configured as an IP helper-address, then routes the packet to the controller. The downside to this approach is that the WLC will also receive all other forwarded protocols such as DHCP discovery packets. Also, other configured IP helpers will receive the CAPWAP discovery packets. Since this behavior is likely undesired, be sure to use the forward-protocol method only temporarily.

The local NVRAM of the access point stores a list of controllers, gathered from the following sources:

·         Primary, Secondary, and Tertiary controller preferences previously configured for the AP

If the access point was previously associated to a controller, the IP addresses of the primary, secondary, and tertiary controllers are stored in the access point’s non-volatile memory. This process of storing controller IP addresses on access points for later deployment is called priming the access point.

To verify locally stored controller preferences:

show ap config general ap_name

Primary Cisco Switch Name........................ WLC001
Primary Cisco Switch IP Address.................. Not Configured
Secondary Cisco Switch Name...................... WLC002
Secondary Cisco Switch IP Address................ Not Configured
Tertiary Cisco Switch Name....................... BACKUP-WLC
Tertiary Cisco Switch IP Address................. Not Configured

·         Mobility Group Members from the previous controller connection

The AP also maintains previously learned WLC IP addresses locally in NVRAM. The AP sends a unicast CAPWAP Discovery Request to each of these WLC IP addresses. These WLC IP addresses are learned by the AP from previously joined controllers. The stored WLC IP addresses include all of the WLCs in previously joined controller mobility groups.

To verify locally stored controllers learned through mobility groups, console into the access point and enter the following command:

show capwap client config

mwarName                CCIETEST
mwarName                backupwlc
numOfSlots              2
spamRebootOnAssert      1
spamStatTimer           180
randSeed                0x9640
transport               SPAM_TRANSPORT_L3(2)
transportCfg            SPAM_TRANSPORT_DEFAULT(0)
initialisation          SPAM_PRODUCTION_DISCOVERY(1)
ApMode                  Local
Discovery Timer         10 secs
Heart Beat Timer        30 secs
Led State Enabled       1
AP ILP Pre-Standard Switch Support Enabled
AP Power Injector Disabled
Infrastructure MFP validation Enabled
Configured Switch 1 Addr
Configured Switch 2 Addr

Note – mwarName entries are the controller preference settings (primary, secondary, tertiary). Configured Switch entries are the learned mobility group members.

·         Manually primed controller IP address through the console

Manual configuration can be used to “prime” the CAPWAP if network services for address assignment and WLC discovery do not exist. If the CAPWAP has previously joined a controller, or is currently joined to a controller, these commands will be disabled.

To stage an access point, use the commands:
capwap ap controller ip address wlc-mgmt-ip
show capwap ip config

If this feature is enabled on the controller, all associated access points transmit wireless RRM neighbor messages, and un-joined access points can receive the controller IP address from these messages. This feature is disabled by default and should only be enabled when necessary for AP deployment.

Note – OTAP does not work with default APs out of the box or upgraded using the Upgrade Tool because the radios are disabled from the manufacturer. 

Configure OTAP:
config network otap-mode { enable | disable }
show network summary

Note - OTAP was removed from the wireless controller feature set in code version due to a vulnerability.

DHCP Option 43
The IP address that should be configured as DHCP option 43 is the address of the controller Managament interface.

Cisco 1000 series access points use a string format for option 43.
Cisco Aironet access points use the type-length-value (TLV) format for option 43.

DHCP servers must be programmed to return the option based on the access point’s DHCP Vendor Class Identifier (VCI) string (DHCP option 60). The VCI strings for Cisco access points capable of operating in lightweight mode are listed in the following table:

The format of the Option 43 TLV block is:
     Type: 0xf1 (decimal 241)
     Length: Number of controller IP addresses * 4
     Value: List of WLC management interfaces

Configuration of option 43 will vary by DHCP server platform. Here is an example configuration using the built-in Cisco IOS DHCP server:

ip dhcp excluded-address start-ip end-ip
ip dhcp pool 
     network ip-address netmask
     default-router ip-address
dns-server ip-address … ip-address
     domain-name domain
     lease days hours
     option 60 ascii VCI string
     option 43 hex hex-value

An example of a finished IOS DHCP server configuration will look similar to this:

interface Vlan192
 ip address

ip dhcp excluded-address

ip dhcp pool lwapp
   domain-name test.lab
   lease 7
   option 60 ascii "Cisco AP c1240"
   option 43 hex f108.0a6c.3214.0a6c.3212

In this example, the hex value is obtained from these TLV values:

Type = 241 (0xf1)
Length = 2 IP addresses * 4 bytes each = 8 bytes (0x08)
Value = (0x0a6c3214) and (0x0a6c3212)

Note – Periods are added automatically to the hex value by Cisco IOS and should not be entered by the administrator when entering configuration commands.

The AP will attempt to resolve the DNS name “CISCO-CAPWAP-CONTROLLER.localdomain”. When the AP is able to resolve this name to one or more IP addresses, the AP sends a unicast CAPWAP Discovery Request to the resolved IP address(es). The DNS entries can be either an A (address) or CNAME (alias) records.

If the AP received a DHCP address, ensure the DHCP server is configured to return valid DNS servers and a valid domain name suffix to the AP.

If the AP is using a static IP address, configure the domain name and DNS name servers from the controller. WLC version 4.2 requires configuration from the CLI, whereas 6.0 and later allow configuration from the GUI. Once applied, the AP will disconnect and re-join the controller.

config ap static-IP { enable | disable } ap_name ip_address netmask gateway
config ap static-IP { add | delete } domain { all | ap_name domain_suffix
config ap static-IP { add | delete } nameserver { all | ap_name dns_server_ip_address

Verify the configuration of the AP:

(Cisco Controller) > show ap config general ccielwap

IP Address Configuration......................... Static IP assigned
IP Address.......................................
IP NetMask.......................................
Gateway IP Addr..................................
Name Server......................................

Verification of Method Used
To view the method used by an AP to discover the controller, view the console output of the AP as it searches, or issue the following command from a controller that receives the discovery request and search for IE 58 from the AP which indicates the discovery method used to resolve the controller IP address:

debug capwap packet enable

CAPWAP Discovery Packet IE 58 values:

0 = Broadcast
1 = Local NVRAM
2 = OTAP
3 = DHCP
4 = DNS

Example 1 – AP Console Log indicates DHCP discovery

*Mar  1 00:00:30.287: Logging LWAPP message to
%DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0 assigned DHCP address, mask, hostname AP0018.7361.e702
Translating "CISCO-LWAPP-CONTROLLER.test.lab"...domain server (
%LWAPP-3-CLIENTEVENTLOG: Controller address obtained through DHCP
%LWAPP-5-CHANGED: LWAPP changed state to JOIN
%LWAPP-5-CHANGED: LWAPP changed state to CFG
%LWAPP-5-CHANGED: LWAPP changed state to DOWN
%LWAPP-5-CHANGED: LWAPP changed state to UP
%LWAPP-3-CLIENTEVENTLOG: AP has joined controller CCIETEST

Example 2 – WLC LWAPP Packet Debug indicates DHCP discovery

(Cisco Controller) > debug lwapp packet enable

Mon Feb 22 09:55:32 2010: Start of Packet
Mon Feb 22 09:55:32 2010: Ethernet Source MAC (LRAD): 00:17:DF:96:9F:90
Mon Feb 22 09:55:32 2010: Msg Type       :
Mon Feb 22 09:55:32 2010:    DISCOVERY_REQUEST
Mon Feb 22 09:55:32 2010: Msg Length     :   31
Mon Feb 22 09:55:32 2010: Msg SeqNum     :   0
Mon Feb 22 09:55:32 2010:
IE            :   UNKNOWN IE 58
Mon Feb 22 09:55:32 2010: IE Length     :   1
Mon Feb 22 09:55:32 2010: Decode routine not available, Printing Hex Dump
Mon Feb 22 09:55:32 2010: 00000000: 03                                       Mon Feb 22 09:55:32 2010:

In my next post, I will describe the controller selection process used by the wireless access point to determine which controller to establish a connection to when multiple controllers have been discovered.

Prior to selecting a controller, the access point always performs discovery using the methods listed above. From the discovery responses the AP builds a list of candidate controllers and selects the optimal controller.