CAPWAP Controller Discovery Process

Posted on by Admin

Related Post

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 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

 

  • 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.

 

  • 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

 

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

 

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:

 

 

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 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

 

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.