Access Point Communication Protocols

CAPWAP

Cisco lightweight access points use the IETF standard Control and Provisioning of Wireless Access Points Protocol (CAPWAP) to communicate with the controller and other lightweight access points on the network.

CAPWAP, which is based on LWAPP, is a standard, interoperable protocol that enables a controller to manage a collection of wireless access points. CAPWAP is implemented in controller for these reasons:

  • To provide an upgrade path from Cisco products that use LWAPP to next-generation Cisco products that use CAPWAP

  • To manage RFID readers and similar devices

  • To enable controllers to interoperate with third-party access points in the future

LWAPP-enabled access points can discover and join a CAPWAP controller, and conversion to a CAPWAP controller is seamless. For example, the controller discovery process and the firmware downloading process when using CAPWAP are the same as when using LWAPP. The one exception is for Layer 2 deployments, which are not supported by CAPWAP.

You can deploy CAPWAP controllers and LWAPP controllers on the same network. The CAPWAP-enabled software allows access points to join either a controller running CAPWAP or LWAPP. The only exceptions are that the Cisco Aironet 1040, 1140, 1260, 3500, and 3600 Series Access Points, which support only CAPWAP and join only controllers that run CAPWAP. For example, an 1130 series access point can join a controller running either CAPWAP or LWAPP where an1140 series access point can join only a controller that runs CAPWAP.

The following are some guidelines that you must follow for access point communication protocols:

  • If your firewall is currently configured to allow traffic only from access points using LWAPP, you must change the rules of the firewall to allow traffic from access points using CAPWAP.

  • Ensure that the CAPWAP UDP ports 5246 and 5247 (similar to the LWAPP UDP ports 12222 and 12223) are enabled and are not blocked by an intermediate device that could prevent an access point from joining the controller.

  • If access control lists (ACLs) are in the control path between the controller and its access points, you need to open new protocol ports to prevent access points from being stranded.

This section contains the following subsections:

Restrictions for Access Point Communication Protocols

  • Rate-limiting is applicable to all traffic destined to the CPU from either direction (wireless or wired). We recommend that you always run the controller with the default config advanced rate enable command in effect to rate limit traffic to the controller and protect against denial-of-service (DoS) attacks. You can use the config advanced rate disable command to stop rate-limiting of Internet Control Message Protocol (ICMP) echo responses for testing purposes. However, we recommend that you reapply the config advanced rate enable command after testing is complete.

  • Ensure that the controllers are configured with the correct date and time. If the date and time configured on the controller precedes the creation and installation date of certificates on the APs, the AP fails to join the controller.

  • The sender fragments the IPv6 UDP packets, which are then reassembled at the end device. APs do not support IPv6 reassembly and therefore IPv6 UDP packets are not recognized in the AP datapath.

    This issue does not impact IPv6 TCP because of TCP design. The MSS parameter is a part of the options in the TCP initial handshake that specifies the largest amount of data that a TCP speaker can receive in a single TCP segment. Each direction of TCP traffic uses its own MSS value because this is a receiver-specified value.

Data Encryption

Controllers enable you to encrypt CAPWAP control packets (and optionally, CAPWAP data packets) that are sent between the AP and the controller using Datagram Transport Layer Security (DTLS). DTLS is a standards-track Internet Engineering Task Force (IETF) protocol based on TLS. CAPWAP control packets are management packets exchanged between a controller and an access point while CAPWAP data packets encapsulate forwarded wireless frames. CAPWAP control and data packets are sent over separate UDP ports: 5246 (control) and 5247 (data). If an access point does not support DTLS data encryption, DTLS is enabled only for the control plane, and a DTLS session for the data plane is not established.

Table 1. DTLSv1.2 for CAPWAP Support Information

Release

Support Information

8.2

Not supported

8.3.11x.0 or a later release

Supported in controller and Cisco Wave 2 AP

Any release

Not supported in Cisco Wave 1 AP

The following are supported for web authentication and WebAdmin based on the configuration:

  • TLSv1.2.

  • TLSv1.0

  • SSLv3

  • SSLv2


Note

Controllers support only static configuration of gateway. Therefore, the ICMP redirect to change IP address of the gateway is not considered.


Cipher Suites Supported by APs

  • Cipher suites supported by Cisco Aironet 4800, 3800, 2800, 1800, and 1560 Series APs:

    • TLS_RSA_WITH_AES_128_CBC_SHA

    • TLS_RSA_WITH_AES_256_CBC_SHA

    • TLS_RSA_WITH_AES_256_CBC_SHA256

    • TLS_DHE_RSA_WITH_AES_128_CBC_SHA

    • TLS_DHE_RSA_WITH_AES_256_CBC_SHA

    • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

    • TLS_RSA_WITH_AES_128_GCM_SHA256

    • TLS_RSA_WITH_AES_256_GCM_SHA384

    • TLS_DH_RSA_WITH_AES_256_GCM_SHA384

    • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

    • TLS_DH_RSA_WITH_AES_128_GCM_SHA256

    • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

    • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

  • Cipher suites supported by Cisco Aironet 3700, 2700, 3600, 2600 Series, and 802 APs:

    • TLS_RSA_WITH_AES_128_CBC_SHA

    • TLS_RSA_WITH_AES_256_CBC_SHA

    • TLS_RSA_WITH_AES_256_CBC_SHA256

Restrictions on Data Encryption

  • Cisco 1130 and 1240 series access points support DTLS data encryption with software-based encryption.

  • The following access points support DTLS data encryption with hardware-based encryption: 1040, 1140, 1250, 1260, 1550, 1600, 1700, 2600, 2700, 3500, 3600, 3700, .

  • Cisco Aironet 1552 and 1522 outdoor APs support data DTLS.

  • DTLS data encryption is not supported on Cisco Aironet 700, 800, 1530 Series APs.

  • In Cisco Aironet 18xx Series APs, only software DTLS data encryption is supported with limited throughput performance. Hardware encryption is not supported.

  • DTLS data encryption is enabled automatically for OfficeExtend access points but disabled by default for all other access points. Most access points are deployed in a secure network within a company building, so data encryption is not necessary. In contrast, the traffic between an OfficeExtend access point and the controller travels through an unsecure public network, so data encryption is more important for these access points. When data encryption is enabled, traffic is encrypted at the access point before it is sent to the controller and at the controller before it is sent to the client.

  • Encryption limits throughput at both the controller and the access point, and maximum throughput is desired for most enterprise networks.

  • In a Cisco unified local wireless network environment, do not enable DTLS on the Cisco 1130 and 1240 access points, as it may result in severe throughput degradation and may render the APs unusable.

    See the OfficeExtend Access Points section for more information on OfficeExtend access points.

  • You can use the controller to enable or disable DTLS data encryption for a specific access point or for all APs.

  • Some AP models have hardware-based DTLS support, but some do not. The APs that do not have hardware-based DTLS support will have significantly reduced throughput if Data DTLS is enabled.

  • Central switching is not supported on Cisco vWLC and therefore Data DTLS is not supported on Cisco vWLC.

  • If your controller does not have a data DTLS license and if the access point associated with the controller has DTLS enabled, the data path will be unencrypted.

  • Non-Russian customers using Cisco 5508 Series Controller do not need data DTLS license. However all customers using Cisco 2504 WLCs, Cisco 8510 WLCS, Cisco WiSM2, and need a data DTLS license to turn on the Data DTLS feature.

Upgrading or Downgrading DTLS Images for Cisco 5508 WLC

Procedure


Step 1

The upgrade operation fails on the first attempt with a warning indicating that the upgrade to a licensed DTLS image is irreversible.

Note 

Do not reboot the controller after Step 1.

Step 2

On a subsequent attempt, the license is applied and the image is successfully updated.


Guidelines When Upgrading to or from a DTLS Image

  • You cannot install a regular image (nonlicensed data DTLS) once a licensed data DTLS image is installed.

  • You can upgrade from one licensed DTLS image to another licensed DTLS image.

  • You can upgrade from a regular image (DTLS) to a licensed DTLS image in a two step process.

  • You can use the show sysinfo command to verify the LDPE image, before and after the image upgrade.

Configuring Data Encryption (GUI)

Ensure that the base license is installed on the Cisco WLC. Once the license is installed, you can enable data encryption for the access points.

Procedure


Step 1

Choose Wireless > Access Points > All APs to open the All APs page.

Step 2

Click the name of the AP for which you want to enable data encryption.

Step 3

Choose the Advanced tab to open the All APs > Details for (Advanced) page.

Step 4

Check the Data Encryption check box to enable data encryption for this access point or unselect it to disable this feature. The default value is unselected.

Note 

Changing the data encryption mode requires the access points to rejoin the controller.

Step 5

Save the configuration.


Configuring Data Encryption (CLI)


Note

In images without a DTLS license, the config or show commands are not available.


To enable DTLS data encryption for access points on the controller using the controller CLI, follow these steps:

Procedure


Step 1

Enable or disable data encryption for all access points or a specific access point by entering this command:

config ap link-encryption {enable | disable} {all | Cisco_AP}

The default value is disabled.

Note 

Changing the data encryption mode requires the access points to rejoin the controller.

Step 2

When prompted to confirm that you want to disconnect the access point(s) and attached client(s), enter Y.

Step 3

Enter the save config command to save your configuration.

Step 4

See the encryption state of all access points or a specific access point by entering this command:

show ap link-encryption {all | Cisco_AP}

This command also shows authentication errors, which tracks the number of integrity check failures, and replay errors, which tracks the number of times that the access point receives the same packet.

Step 5

See a summary of all active DTLS connections by entering this command:

show dtls connections

Note 

If you experience any problems with DTLS data encryption, enter the debug dtls {all | event | trace | packet} {enable | disable} command to debug all DTLS messages, events, traces, or packets.

Step 6

Configure the DTLS version by entering this command:

config ap dtls-version {dtls1.0 | dtls1.2 | dtls_all}


Viewing CAPWAP Maximum Transmission Unit Information

See the maximum transmission unit (MTU) for the CAPWAP path on the controller by entering this command:

show ap config general Cisco_AP

The MTU specifies the maximum size of any packet (in bytes) in a transmission.

Information similar to the following appears:


Cisco AP Identifier.............................. 9
Cisco AP Name.................................... Maria-1250
Country code..................................... US  - United States
Regulatory Domain allowed by Country............. 802.11bg:-A     802.11a:-A
AP Country code.................................. US  - United States
AP Regulatory Domain............................. 802.11bg:-A    802.11a:-A
Switch Port Number .............................. 1
MAC Address...................................... 00:1f:ca:bd:bc:7c
IP Address Configuration......................... DHCP
IP Address....................................... 1.100.163.193
IP NetMask....................................... 255.255.255.0
CAPWAP Path MTU.................................. 1485

Debugging CAPWAP

Use these commands to obtain CAPWAP debug information:

  • debug capwap events {enable | disable} —Enables or disables debugging of CAPWAP events.

  • debug capwap errors {enable | disable} —Enables or disables debugging of CAPWAP errors.

  • debug capwap detail {enable | disable} —Enables or disables debugging of CAPWAP details.

  • debug capwap info {enable | disable} —Enables or disables debugging of CAPWAP information.

  • debug capwap packet {enable | disable} —Enables or disables debugging of CAPWAP packets.

  • debug capwap payload {enable | disable} —Enables or disables debugging of CAPWAP payloads.

  • debug capwap hexdump {enable | disable} —Enables or disables debugging of the CAPWAP hexadecimal dump.

  • debug capwap dtls-keepalive {enable | disable} —Enables or disables debugging of CAPWAP DTLS data keepalive packets.

Controller Discovery Process

In a CAPWAP environment, a lightweight access point discovers a controller by using CAPWAP discovery mechanisms and then sends the controller a CAPWAP join request. The controller sends the access point a CAPWAP join response allowing the access point to join the controller. When the access point joins the controller, the controller manages its configuration, firmware, control transactions, and data transactions.

The following are some guidelines for the controller discovery process:

  • If an access point is in the UP state and its IP address changes, the access point tears down the existing CAPWAP tunnel and rejoins the controller.

  • Access points must be discovered by a controller before they can become an active part of the network. The lightweight access points support the following controller discovery processes:

    • Layer 3 CAPWAP or LWAPP discovery—This feature can be enabled on different subnets from the access point and uses either IPv4 or IPv6 addresses and UDP packets rather the MAC addresses used by Layer 2 discovery.

    • CAPWAP Multicast Discovery—Broadcast does not exist in IPv6 address. Access point sends CAPWAP discovery message to all the controllers multicast address (FF01::18C). The controller receives the IPv6 discovery request from the AP only if it is in the same L2 segment and sends back the IPv6 discovery response.

    • Locally stored controller IPv4 or IPv6 address discovery—If the access point was previously associated to a controller, the IPv4 or IPv6 addresses of the primary, secondary, and tertiary controllers are stored in the access point’s nonvolatile memory. This process of storing controller IPv4 or IPv6 addresses on an access point for later deployment is called priming the access point.

    • DHCP server discovery using option 43—This feature uses DHCP option 43 to provide controller IPv4 addresses to the access points. Cisco switches support a DHCP server option that is typically used for this capability.


      Note

      You can configure up to three IP addresses in the hexadecimal string.


    • DHCP server discovery using option 52 —This feature uses DHCP option 52 to allow the AP to discover the IPv6 address of the controller to which it connects. As part of the DHCPv6 messages, the DHCP server provides the controllers management with an IPv6 address.

    • DNS discovery—The access point can discover controllers through your domain name server (DNS). You must configure your DNS to return controller IPv4 and IPv6 addresses in response to CISCO-LWAPP-CONTROLLER.localdomain or CISCO-CAPWAP-CONTROLLER.localdomain , where localdomain is the access point domain name.

      When an access point receives an IPv4/IPv6 address and DNSv4/DNSv6 information from a DHCPv4/DHCPv6 server, it contacts the DNS to resolve CISCO-LWAPP-CONTROLLER.localdomain or CISCO-CAPWAP-CONTROLLER.localdomain . When the DNS sends a list of controller IP addresses, which may include either IPv4 addresses or IPv6 addresses or both the addresses, the access point sends discovery requests to the controllers.

    • To configure the IP addresses that the controller sends in its CAPWAP discovery responses, use the config network ap-discovery nat-ip-only {enable | disable} command.


      Note

      If you disable nat-ip-only , the controller sends all active AP-Manager interfaces with their non-NAT IP in discovery response to APs.

      If you enable nat-ip-only , the controller sends all active AP-Manager interfaces with NAT IP if configured for the interface, else non-NAT IP.

      We recommend that you configure the interface as AP-Manager interface with NAT IP or non-NAT IP keeping these scenarios in mind because the AP chooses the least loaded AP-Manager interface received in the discovery response.


Guidelines and Restrictions on Controller Discovery Process

  • During the discovery process, the 1040, 1140, 1260, 3500, and 3600 series access points will only query for Cisco CAPWAP Controllers. It will not query for LWAPP controllers. If you want these access points to query for both LWAPP and CAPWAP controllers then you need to update the DNS.

  • Ensure that the controller is set to the current time. If the controller is set to a time that has already occurred, the access point might not join the controller because its certificate may not be valid for that time.

  • To avoid downtime restart CAPWAP on AP while configuring Global HA, so that AP goes back and joins the backup primary controller. This starts a discovery with the primary controller in the back ground. If the discovery with primary is successful, it goes back and joins the primary again.

Verifying that Access Points Join the Controller

When replacing a controller, ensure that access points join the new controller.

Verifying that Access Points Join the Controller (GUI)

Procedure


Step 1

Configure the new controller as a primary controller as follows:

  1. Choose Controller > Advanced > Master Controller Mode to open the Master Controller Configuration page.

  2. Select the Master Controller Mode check box.

  3. Click Apply to commit your changes.

  4. Click Save Configuration to save your changes.

Step 2

(Optional) Flush the ARP and MAC address tables within the network infrastructure.

Step 3

Restart the access points.

Step 4

Once all the access points have joined the new controller, configure the controller not to be a primary controller by unselecting the Master Controller Mode check box on the Master Controller Configuration page.


Verifying that Access Points Join the Controller (CLI)

Procedure


Step 1

Configure the new controller as a primary controller by entering this command:

config network master-base enable
Step 2

(Optional) Flush the ARP and MAC address tables within the network infrastructure.

Step 3

Restart the access points.

Step 4

Configure the controller not to be a primary controller after all the access points have joined the new controller by entering this command:

config network master-base disable