Absolutely, Sophie. CAPWAP, or Control and Provisioning of Wireless Access Points, is an interoperable protocol that allows a central Wireless LAN Controller to manage a group of access points. It’s a standard detailed in RFC 5415 and is based on the Lightweight Access Point Protocol (LWAPP).

Certainly, Sophie. CAPWAP, or Control and Provisioning of Wireless Access Points, is primarily designed to facilitate centralized control and management of wireless networks. It is the protocol used between Access Points and Wireless Lan Controllers for both control and data traffic. Let me explain the functionalities and the working mechanisms:

Functionalities of CAPWAP:

1. Centralized Control and Management: It centralizes authentication and policy enforcement, which is crucial for maintaining the integrity and security of a wireless network.
2. Protocol Processing: CAPWAP shifts higher-level protocol processing away from the individual access points (APs) to the controller. This helps in efficient management of the network and reduces the processing load on APs.
3. Interoperability: It’s designed to be extensible and can work with various types of APs.

 

Working Mechanism:

• Discovery Phase: Initially, CAPWAP enables wireless APs to find a controller. The APs send out discovery request messages, to which controllers reply with discovery responses.
• Secure Connection Establishment: After discovery, a secure connection is established using Datagram Transport Layer Security (DTLS). This connection is used for the exchange of control and data messages between the AP and the controller.
• Join Phase: In the Join phase the AP sends a Join Request to the WLC and the WLC sends back a Join Response.
• Data Transport: CAPWAP uses two UDP ports – 5246 for the control channel and 5247 for the data channel. The data channel is used to encapsulate and transport the client’s 802.11 frames.
• Modes of Operation: CAPWAP supports two modes – Split MAC and Local MAC. In Split MAC mode, all Layer 2 wireless data and management frames are exchanged between the controller and AP, while in Local MAC mode, data frames are locally bridged or tunneled.

Exactly. Each step in the CAPWAP session establishment is designed to ensure secure, efficient, and correct integration of APs into the wireless network, aligning them with the WLC’s configurations and security protocols.

Absolutely, Sophie. The CAPWAP session establishment is a structured process that ensures secure and efficient communication between Access Points (APs) and the Wireless LAN Controller (WLC).

1. IP Address Requirement: Initially, the AP must have an IP address. Without it, the AP cannot start the CAPWAP session establishment process.

2. Discovery Request: The AP begins by sending a Discovery Request. This is part of the WLC Discovery Methods, where the AP looks for a suitable controller to connect to.

3. Discovery Response: In response, the WLC sends a Discovery Response, acknowledging the AP’s request.

4. DTLS Session Establishment: Next, a Datagram Transport Layer Security (DTLS) session is established. This step is crucial as it encrypts all subsequent communications, ensuring secure data transmission.

5. Join Request: Following the DTLS session, the AP sends a Join Request to the WLC.

6. Join Response: The WLC then sends back a Join Response, accepting the AP’s request to join the network.

7. Image Check: The AP performs an image check to ensure its firmware is up to date. If the AP’s image version differs from the WLC’s, it downloads the necessary image from the WLC and reboots to load it. If the versions are the same, it proceeds to the next step.

8. Configuration Status Request and Response: The AP sends a Configuration Status Request, and the WLC replies with a Configuration Status Response.

9. Transition to RUN State: Finally, the AP enters the RUN state, where it becomes fully operational within the network.

Maintaining the CAPWAP Tunnel:

• During the RUN state, the CAPWAP tunnel is maintained through Keepalives, which are exchanged to sustain the data tunnel.
• Additionally, the AP sends Echo Requests to the WLC to maintain the CAPWAP control tunnel. The WLC must respond with Echo Responses to these requests.

Take a look at the whiteboard and analyze the CAPWAP Session establishment:

Exactly. Each step in the CAPWAP session establishment is designed to ensure secure, efficient, and correct integration of APs into the wireless network, aligning them with the WLC’s configurations and security protocols.

Certainly, Sophie. The DTLS (Datagram Transport Layer Security) session establishment in CAPWAP is crucial for secure communication between Access Points (APs) and the Wireless LAN Controller (WLC).

1. AP sends a Client Hello message to initiate the session.
2. WLC responds with a HelloVerifyRequest message containing a cookie for validation.
3. AP sends another ClientHello message with the cookie received from the WLC.
4. WLC then sends several messages in this order: ServerHello, Certificate, Server Key Exchange, Certificate Request, and ServerHelloDone.
5. AP then sends its packets in the following order: Certificate, ClientKeyExchange, Certificate Verify, and ChangeCipherSpec.
6. WLC responds to the AP’s ChangeCipherSpec with its own ChangedCipherSpec.
7. After this last message from the WLC, the secure tunnel is established, and all subsequent traffic is encrypted.

This process ensures that all communications over CAPWAP are secure and protected from potential threats.

Indeed, Sophie. Security in network communication, especially in wireless networks, is paramount, and DTLS plays a key role in ensuring that.

Good question, Sophie. The answer is Yes and no or it depends. Yes, if you only have a few APs, and no if you have a lot of them.  APs are programmed to automatically discover WLCs using the following steps:

1. DHCP Option 43: The DHCP server provides the IPv4 address of the WLC by using Option 43. It’s useful in large deployments where APs and WLCs are at different sites.
2. DHCP Option 52: Similar to Option 43, but for IPv6 addresses.
3. DNS Discovery: APs query ‘CISCO-CAPWAP-CONTROLLER.localdomain’ in DNS. It’s useful when WLCs are at the same site as APs.
4. Layer 3 Broadcast: APs broadcast a message, and any WLC on the same subnet can respond.
5. Static Configuration: You can statically configure a WLC in the AP using the CLI.
6. Mobility Discovery: If an AP was previously connected to a WLC in a mobility group, it remembers other WLCs in that group.

Great question, Sophie. If an AP send a Discovery Request and it receives back multiple Discovery Responses, from different controller, than, in that case there will be an election:

WLC Election:

• After discovery, the AP selects a WLC to join based on pre-configured priorities: Primary, Secondary, and Tertiary controllers. If none are pre-configured, the AP will select and join the WLC that responded and it is the least-loaded based on AP capacity.

Exactly. The network’s design dictates the most appropriate discovery and election method for efficient and reliable connectivity.

Alright, Sophie, let’s talk about the CAPWAP State Machine. This is a crucial framework that governs how Access Points (APs) interact with Wireless LAN Controllers (WLCs) during their lifecycle. It consists of various states and transitions that guide the APs from boot-up to normal operation. Since we already covered most of this topic in the CAPWAP Session Creation section, you will have no problems in understanding this.

Of course, Sophie. The first state is the ‘Discovery State,’ where APs try to find available WLCs using methods like DHCP, DNS, and broadcast messages, or previously known WLCs, as we already discussed. Once discovered, they will setup the DTLS session, remember? They than move to the ‘Join State,’ where they send a ‘Join Request’ to a selected WLC. The WLC responds with a ‘Join Response.

After the Join state, the AP will compare its image to the selected WLC image. If this is different, than the AP will invoke a script called upgrade.sh to download the image from the WLC. After the image is downloaded and verified, the upgrade.sh script will install  the image on the non-active partition and the AP will reload. Keep in mind that the AP has an active and a non active partition and before it reboots it will swap the partition it boots from to the one were the new image is installed.

Than we have the ‘Configuration State,’ where the AP gets its configuration from the WLC. Once configured, it enters the ‘Run State,’ where it actively communicates with the WLC. During normal operation in this state, the CAPWAP tunnel is maintained.”

Take a look at the below diagram to better understand the CAPWAP State Machine:

 

Good to hear that, because it’s a fundamental process in managing wireless networks. If you have more questions, feel free to ask!

Of course, Sophie. To configure the static WLC election we have two options:

1. Via GUI, but in order for this to work, the AP must first dynamically discover a WLC and from the WLC’S GUI we can statically set the Primary, Secondary and Tertiary Controllers.
2. Via CLI, connected to the AP via Telnet/SSH or the Console port.

 

Static WLC Election via GUI on IOS XE WLC:

Let’s start with the 1st option. Consider that an AP has booted and dynamically discovers a controller which it joins. After you open the WLC’S GUI by accessing the management IP of the controller via a web browser, follow these steps:

On the left side of the screen, in the menu, click on Configuration

1. In the Wireless section, click on Access Points
2. Select that access point for which you want to configured the static WLC election.
3. Once the AP page opens, click on High Availability tab.
4. Configure the name and the Management IP of the Controllers. 
5. Click on “Update and Apply to Device

Take a look a the below screenshot to visualize the process:

As a side note, you might have noticed the “AP failover priority” in the “High Availability” tab. Each AP can be configure with one of the 4 priorities(Low, Medium, High and Critical). These priorities are used in case the primary controller fails and multiple APs try to join a backup controller. Maybe the backup controller doesn’t have enough licenses/capacity. In this case the controller will drop lower priority APs in order to accommodate higher priority APs. 

 

Static WLC Election via CLI on AP:

Sure, Sophie! Let’s start with the GUI option on AireOS WLC:

Static WLC Election via GUI on IOS XE WLC:

After you open the WLC’S GUI by accessing the management IP of the controller via a web browser, follow these steps:

1. Click on the Wireless tab from the top menu.
2. Here, you will se a list of access points. Select that access point for which you want to configured the static WLC election.
3. The AP settings/configuration page will open. Click on High Availability tab.
4. Configure the name and the Management IP of the Primary, Secondary and Tertiary Controllers. 
5. Click on Apply.

Take a look a the below screenshot to visualize the process:

As a side note, the “AP failover priority” in the “High Availability” tab has the exact same purpose as in IOS XE. 

 

Static WLC Election via CLI on the WLC:

AireOS WLCs can configure static WLC election for the APs it manages via the CLI as well. Login to the WLC via Telnet/SSH or Console Port and issue the below commands, were you specify the name of the controller(e.g. Location1-WLC1), than you specify the AP name(e.g. AP0000.AAAA.BBBB) and finally the IP of the controller(e.g. 10.1.255.100). :

 

Static WLC Election via CLI on the AP:

Now let’s move on to the CLI configuration. In order to configure the static WLC election via CLI you will need to connect to the AP via Telnet/SSH or the Console port. Once connected issue the following commands: