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 6.0.170.0 code)
4. DHCP Option 43 returned from the DHCP server
5. DNS lookup for "CISCO-CAPWAP-CONTROLLER.localdomain"
Broadcast
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 255.255.255.255 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.
Local NVRAM
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
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
mwarName
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 10.127.78.5
Configured Switch 2 Addr 10.108.50.20
Note – mwarName entries are the controller preference settings (primary, secondary, tertiary). Configured Switch entries are the learned mobility group members.
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
mwarName
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 10.127.78.5
Configured Switch 2 Addr 10.108.50.20
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
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
OTAP
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
show network summary
Note - OTAP was removed from the wireless controller feature set in code version 6.0.170.0 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:
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
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 pool-name
network ip-address netmask
default-router ip-address
dns-server ip-address … ip-address
domain-name domain
lease days hours
ip dhcp pool pool-name
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 192.168.1.1 255.255.255.0
ip dhcp excluded-address 192.168.1.1 192.168.1.10
ip dhcp pool lwapp
network 192.168.1.0 255.255.255.0
default-router 192.168.1.1
dns-server 192.168.1.2
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 = 10.108.50.20 (0x0a6c3214) and 10.108.50.18 (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.
DNS
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
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....................................... 10.108.51.54
IP NetMask....................................... 255.255.254.0
Gateway IP Addr.................................. 10.108.50.1
Domain........................................... ccietest.com
Name Server...................................... 10.10.10.25
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 255.255.255.255.
%DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0 assigned DHCP address 192.168.1.20, mask 255.255.255.0, hostname AP0018.7361.e702
Translating "CISCO-LWAPP-CONTROLLER.test.lab"...domain server (10.97.40.216)
%LWAPP-3-CLIENTEVENTLOG: Performing DNS resolution for CISCO-LWAPP-CONTROLLER
%LWAPP-3-CLIENTERRORLOG: DNS Name Lookup: could not resolve CISCO-LWAPP-CONTROLLER
%LWAPP-3-CLIENTEVENTLOG: Controller address 10.108.50.20 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.
