CAPWAP Connection Maintenance

Continuing down our CAPWAP journey, once the access point has joined a controller, a mechanism is required to verify the correct code version is running on the AP, download the operational configuration, and maintain the connection especially during periods of idle WLAN activity. Collectively, I'll call this the CAPWAP connection maintenance process. Connection maintenance consists of 6 operational states for the access point, the first two of which have already been discussed regarding the controller discovery and join processes.

Connection Maintenance Operational States

1.      Discovery State is used when the AP is performing discovery to identify potential controllers on the network

2.      Join State is used when the AP is actively joining a WLC

3.      Image Data State is used if code version is out of sync with the WLC:

§  LWAPP Image Data Request(s) will be sent by the AP to request chunks of code

§  LWAPP Image Data Response(s) will be sent by the controller containing chunks of code

§  The AP will install new code, reboot, perform discovery, selection, and join a WLC

4.      Config State is used by WLC to provision the AP with the appropriate configuration

5.      RUN State is when the access point is ready to serve clients

6.      Reset State is used when the access point has been issued a command to reboot

Note - These operational states are performed behind the scenes and are not the same as the "Operational Status" field displayed in the WLC wireless access point list. That list defines the registered status of an AP with the controller (REG / DEREG).

Once the access point is in the RUN state, a heartbeat process between the AP and controller is initiated to identify the loss of connection so that the access point can attempt to failover to another controller.

LWAPP/CAPWAP Heartbeat Process:

1. LWAPP/CAPWAP Echo Request Sent
   When the access point's heartbeat timer expires, it sends an LWAPP Echo Request to the WLC. By default, the heartbeat timer is 30 seconds. It is administrator configurable in code version 5.0 and later.
   
   
2. Starts the 'NeighborDeadInterval' Timer
• The AP expects an LWAPP Echo Response from WLC before the timer expires.
• Once a response is received, the NeighborDeadInterval timer is reset and the Heartbeat Timer is restarted.
• If no response is received and the timer expires, the AP sends additional LWAPP Echo Requests up to 5 more times in 1 second intervals.
• If there is still no response received after 5 retries, the AP releases and renews its IP address, transitions back into the Discovery State, and attempts to discover a new controller.
  
  This behavior changed in code version 5.0; if the AP has a valid controller in its backup controller list, then it will immediately transition into the Join State and attempt to join the next controller in the list. The backup list is maintained by sending periodic LWAPP/CAPWAP discovery packets to each discovered controller (dictated by the AP Primary Discovery Timeout value).

The WLC also maintains a heartbeat timer, and expects an LWAPP/CAPWAP Echo Request packet from the AP before its timer expires. Once the WLC hearbeat timer expires, the AP connection is flushed from the controller's active AP list. If you have ever moved APs between primary, secondary, and tertiary controllers and noticed a small period of time that the previously connected controller still shows the AP as connected, it is due to this timer.


In versions 5.0 and later of WLC code, a fast heartbeat timer can be configured to detect failed controllers faster than 30 seconds. Separate timers can be specified for APs in local and H-REAP modes. The valid fast heartbeat interval is 1 – 10 seconds.

config advanced timers ap-fast-heartbeat { local | hreap | all } { enable | disable } interval
show advanced timers

From the AP, verification can be done using these commands:

show lwapp client ha
show lwapp client config

Tweaking the heartbeat timer allows quicker identification of failed controllers and faster failover necessary in a highly available environment. In my next post, I'll detail some additional measures that can be taken to implement a highly available wireless network.

Cheers,
Andrew