CAPWAP State Machine in the Cisco Unified Wireless Implementation: Discovery State

The Unified Wireless Network architecture assumes centralized management of all access points (TD) from a single interface - a wireless network controller, to which access points must pre-register.

Understanding the CAPWAP State Machine (state transition sequence) when interacting with an access point and a controller is very helpful in quickly troubleshooting a wireless network. The CAPWAP State Machine is described in the RFC 5415 standard (CAPWAP Protocol Specification). This article details the states of Discovery in a Cisco Unified Wireless implementation. In subsequent articles, the Join, Failover, and Fallback states in the Cisco Unified Wireless implementation will be described.

CAPWAP Discovery Phase IPv4 on Cisco Wireless AireOS

Registering an access point to a specific controller consists of the following steps:

1. Discovery Phase (detection phase);
   
   • The access point sends a CAPWAP Discovery Request to all known controllers;
   • Each controller that receives a CAPWAP Discovery Request responds with a CAPWAP Discovery Response message;
2. Join Phase
   
   • Based on the data collected in the CAPWAP Discovery Response packets, the access point selects which controller to connect to and sends it a CAPWAP Join request
   • The controller checks the access point and sends a CAPWAP Join response
   • The access point is checking the controller.

CAPWAP discovery request is sent to the IP address of the Management interface of the controller.
In order for the access point to determine where to send the CAPWAP discovery request, several tools are provided, but to start the search mechanisms, the access point needs to obtain an IP address. This can be done via DHCP or set it manually. Then the search mechanisms start working. The access point sends a CAPWAP discovery request to all controllers that it succeeded in detecting and forms a list of controllers from which it already selects which specific controller to connect to (send a CAPWAP Join Request).

1. The TD sends a third-level broadcast request (layer 3 local broadcast to address 255.255.255.255;
2. TD looks to the local list of controllers stored on NVRAM;
3. AP when requesting a DHCP address looks in DHCP Option 43 in the DHCP offer message;
4. The access point tries to resolve DNS names CISCO-CAPWAP-CONTROLLER.local-domain or CISCO-LWAPP-CONTROLLER.local-domain

Work mechanisms CAPWAP Discovery Phase IPv4

You can view the current TD settings through the console using the command:

show capwap client config 

If any changes were made on the access point, you can restore the original configuration by deleting the private-config and IP address settings.

 clear capwap private-config clear capwap ap ip address clear capwap ap ip default-gateway 

In the current tests, the clear capwap private-config command was always enough, but in the book Deploying and Troubleshooting Cisco Wireless LAN Controllers, the author recommends that the TD just forget all known controllers to use the erase / all nvram command: for which, in turn, you need to activate debugging / troubleshooting mode with the debug capwap console cli command.

 debug capwap console cli erase /all nvram: 

Next, restart the access point.

 reload 

After the reboot, you can make sure (if the DHCP service is not started) that until the access point has received an IP address, it cannot start the Discovery Phase:

 %CAPWAP-3-ERRORLOG: Not sending discovery request AP does not have an Ip !! 

 %CAPWAP-3-DHCP_RENEW: Could not discover WLC using DHCP IP. Renewing DHCP IP. 

In order to start Discovery Phase, the access point needs to issue an address via DHCP or set statically via the console using the commands:

 capwap ap ip address ip mask capwap ap ip default-gateway ip 

1) Layer 3 local broadcast

The access point sends a broadcast Discovery request to the address 255.255.255.255 on the UPD port 5246. Discovery request is processed by the Management interface of the controller. If the Management interface of the controller and the TD interface are in the same VLAN, then the controller will process this request and send a Discovery response.

After the access point receives an address, it activates all possible search mechanisms and as a result receives a Discovery response due to the Discovery request broadcast.

 delphi %DHCP-6-ADDRESS_ASSIGN: Interface BVI1 assigned DHCP address 10.0.191.7, mask 255.255.255.0, hostname AP001b.d542.1d2c AP001b.d542.1d2c# Translating "CISCO-CAPWAP-CONTROLLER"...domain server (255.255.255.255) AP001b.d542.1d2c# *Dec 28 02:26:04.306: %CAPWAP-3-ERRORLOG: Did not get log server settings from DHCP. Translating "CISCO-LWAPP-CONTROLLER"...domain server (255.255.255.255) *Dec 28 02:26:13.307: %CAPWAP-3-ERRORLOG: Could Not resolve CISCO-CAPWAP-CONTROLLER *Dec 28 02:26:22.308: %CAPWAP-3-ERRORLOG: Could Not resolve CISCO-LWAPP-CONTROLLER *Dec 28 02:26:32.309: %CAPWAP-3-ERRORLOG: Go join a capwap controller *Mar 16 10:18:26.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent peer_ip: 10.0.191.4 peer_port: 5246 *Mar 16 10:18:28.500: %CAPWAP-5-DTLSREQSUCC: DTLS connection created sucessfully peer_ip: 10.0.191.4 peer_port: 5246 *Mar 16 10:18:28.502: %CAPWAP-5-SENDJOIN: sending Join Request to 10.0.191.4 

Now we will try to place the access point in another VLAN, having previously reset its configuration. Connection does not occur.

 delphi *Dec 28 01:55:27.942: %DHCP-6-ADDRESS_ASSIGN: Interface BVI1 assigned DHCP address 10.0.192.3, mask 255.255.255.0, hostname AP001b.d542.1d2c Translating "CISCO-CAPWAP-CONTROLLER"...domain server (255.255.255.255) *Dec 28 01:55:32.817: %CAPWAP-3-ERRORLOG: Did not get log server settings from DHCP. Translating "CISCO-LWAPP-CONTROLLER"...domain server (255.255.255.255) *Dec 28 01:55:41.817: %CAPWAP-3-ERRORLOG: Could Not resolve CISCO-CAPWAP-CONTROLLER *Dec 28 01:55:50.818: %CAPWAP-3-ERRORLOG: Could Not resolve CISCO-LWAPP-CONTROLLER*Dec 28 01:56:36.324: %CAPWAP-3-DHCP_RENEW: Could not discover WLC using DHCP IP. Renewing DHCP IP. 

The broadcast request does not fall on the Management interface of the controller, since the access point is in a different VLAN.

In this case, you can forcibly redirect the broadcast request to the Management interface of the controller. To do this, it is necessary to activate the redirection of broadcast traffic on UDP port 5246 using the command

 forward-protocol udp 5246 

and prescribe on the third level interface

 ip helper-address [ ] 

In the switch configuration, it looks like this:

 CAT2(config)#ip forward-protocol udp 5246 CAT2(config)#int vlan 192 CAT2(config-if)#ip helper-address 10.0.191.4 

Then the broadcast request will also go to the controller and the point will connect to the controller.

2) Local NVRAM list

The access point looks at its own list of controllers, which is stored in NVRAM non-volatile memory. The following information is stored in NVRAM. Primary, Secondary and Tertiary controller, pre-configured on the access point. These settings can be set both on the access point itself through the CLI, and, if the access point is connected to the controller, through the controller (via the CLI or the web). The last connected controller and its mobility members are in the same group. There are some minor discrepancies in the documentation, which will be discussed below in the appropriate section.

Primary, Secondary and Tertiary controller

At the access point information about the controller can be set by two commands. One of them is capwap ap controller ip address.

 delphi AP001b.d542.1d2c#capwap ap controller ip address 10.0.191.4 *Dec 28 01:57:11.888: %CAPWAP-3-ERRORLOG: Go join a capwap controller 

The action of this command is displayed in two conclusions:

 delphi AP001b.d542.1d2c#sh capwap ip config LWAPP Static IP Configuration IP Address 10.0.192.102 IP netmask 255.255.255.0 Default Gateway 10.0.192.1 Primary Controller 10.0.191.3 

 delphi AP001b.d542.1d2c#sh capwap cli con ... mwarName mwarIPAddress 10.0.191.4 

That is, on the one hand, the controller writes it into the static IP configuration, on the other hand, it sets it as Primary. If tricky manipulations leave or in one place or another, it still connects to this controller.

Primary, Secondary or Tertiary on the access point can be set using the commands:

 capwap ap primary-base [wlc_sysname] [IP]; capwap ap secondary-base [wlc_sysname] [IP]; capwap ap tertiary-base [wlc_sysname] [IP]; delphi AP001b.d542.1d2c#capwap ap primary-base wlc2504 10.0.191.4 *Dec 28 01:57:44.901: %CAPWAP-3-ERRORLOG: Selected MWAR 'wlc2504'(index 0). *Dec 28 01:57:44.901: %CAPWAP-3-ERRORLOG: Go join a capwap controller AP001b.d542.1d2c#sh capwap client config .. mwarName wlc2504 mwarIPAddress 10.0.191.4 

It is not necessary to specify Primary, you can only specify Secondary:

 delphi AP001b.d542.1d2c#capwap ap secondary-base wlc2504 10.0.191.4 *Dec 28 01:57:04.097: %CAPWAP-3-ERRORLOG: Selected MWAR 'wlc2504'(index 1). *Dec 28 01:57:04.097: %CAPWAP-3-ERRORLOG: Go join a capwap controller 

Primary, Secondary, Tertiary controllers can also be registered not only through the console of the access point, but also through the CLI or the web interface of the controller (if the point is already connected to some controller).

 (Cisco Controller) >config ap secondary-base wlc2 AP001b.d542.1d2c 10.0.191.5 delphi AP001b.d542.1d2c#sh capwap cli con .. mwarName wlc2 mwarIPAddress 10.0.191.5 

The last connected controller and its mobility members are in the same group.

As described above, there are small differences on this item. For example

• In the Configuration Guide, software version 8.0 is not written about this, only about Primary, Secondary or Tertiary controllers, as well as in Troubleshooting Technote
• if you look at another Troubleshooting Technote and the previously mentioned book "Deploying and Troubleshooting Cisco Wireless LAN Controllers", it says that NVRAM stores information about the last connected controller and its Mobilibty Members in the same group.
• in another document it is written that the access point forgets when rebooting all the information about mobilibty members, but remembers the last connected controller: "Remember that the AP forgets the mobility members across reboots."
  To begin with, with the help of tests, I tried to find out whether the access point forgets about all mobility members when it reboots.

Mobility members are displayed in the "Configured Switch X" construction of the show capwap client config output:

 delphi AP001b.d542.1d2c#sh capw cli con ... Configured Switch 1 Addr 10.0.191.4 Configured Switch 2 Addr 10.0.193.4 

Pre-access points were placed in an isolated VLAN and all Discovery mechanisms, except through NVRAM excluded (including Primary, Secondary and Tertiary). Tests were conducted on software 8.0.140.0 (15.3 (3) JA10).

The access point was connected to the controller 10.0.193.4, on which the controller 10.0.191.4 was registered in the same Mobilibty Group. When rebooting, the access point was connected to the controller 10.0.191.4 (the point was in a different VLAN and broadcast discovery could not work).

That is, in these tests, the information from the header was confirmed: the access point, at least in this version of the software, stores in NVRAM information about the mobility members of the same group and sends them discovery request.

The last controller to which the access point is connected, technically, is also the mobility member of the same group. During the tests, the access point saved the data about the last connected controller in the "Configured Switch 1" entry.

3) DHCP Option 43

The most commonly used method in installations is to transfer the controller's address in the 43rd option of the DHCP offer package, along with the IP address.

The controller address is written as follows (in hexadecimal form):

 f1[  * 4][IP  ()] 

For example, for controllers 10.0.191.4 and 10.0.191.5, option 43 looks like this:

 f1080a00bf040a00bf05 

For the switch, the syntax is:

 CAT2(dhcp-config)#option 43 hex f108.0a00.bf04.0a00.bf05 

Output from the access point:

 delphi *Dec 28 01:56:13.045: %DHCP-6-ADDRESS_ASSIGN: Interface BVI1 assigned DHCP address 10.0.192.2, mask 255.255.255.0, hostname AP001b.d542.1d2c *Dec 28 01:56:23.945: %CAPWAP-5-DHCP_OPTION_43: Controller address 10.0.191.4 obtained through DHCP *Dec 28 01:56:23.945: %CAPWAP-5-DHCP_OPTION_43: Controller address 10.0.191.5 obtained through DHCP *Dec 28 01:56:51.950: %CAPWAP-3-ERRORLOG: Go join a capwap controller 

If you configure only option 43, then in this case it will be returned to everyone, without exception, not only to access points.

If you want this option to be returned only to Cisco access points, then there is the possibility of checking the VCI (Vendor class identifier) ​​in DHCP discover. Each model of the access point transmits a specific VCI to DHCP discover. If you prescribe Option 60 on the DHCP server with the corresponding VCI, then option 43 will be issued only to those clients who send exactly the same VCI in the request.

The idea is to not pass the 43rd option to those who do not need it. But there is another point. If there are access points of two different series in the same pool, not all DHCP servers support the ability to specify multiple VCIs, this should be checked first.

4) DNS

The access point attempts to resolve DNS names CISCO-CAPWAP-CONTROLLER.local-domain or CISCO-LWAPP-CONTROLLER.local-domain.

To do this, on the access point (in the DHCP pool) you need to register a DNS server and domain. Configure the DNS server accordingly.

 CAT2(dhcp-config)#dns-server 10.0.191.8 CAT2(dhcp-config)#domain test.local 

After receiving the address, the controller can resolve the name and use the IP address in Discovery Phase.

 delphi Translating "CISCO-CAPWAP-CONTROLLER.test.local"...domain server (10.0.191.4) [OK] 

After searching for all controllers, sending them a Discovery request, receiving a Discovery response, a list of controllers is formed, on the basis of which it is decided which controller to try to connect to (send a Join Request).