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.
-
Do not use the following IP addresses with Cisco Wave 2 APs in the network to avoid the AP from dropping packets:
-
10.128.128.126
-
10.128.128.127
-
10.128.128.128
-
6.0.0.7
-
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.
Link Latency
You can configure link latency on the controller to measure the link between an access point and the controller. This feature can be used with all access points joined to the controller but is especially useful for FlexConnect and OfficeExtend access points, for which the link could be a slow or unreliable WAN connection. Specifically for Cisco OEAPs, the least latency controller join feature can be used to guide the AP’s controller selection.
-
Link latency monitors the round-trip time of the CAPWAP heartbeat packets (echo request and response) from the access point to the controller and back. This time can vary due to the network link speed and controller processing loads. The access point timestamps the outgoing echo requests to the controller and the echo responses received from the controller. The access point sends this delta time to the controller as the system round-trip time. The access point sends heartbeat packets to the controller at a default interval of 30 seconds.
Note
Link latency calculates the CAPWAP response time between the access point and the controller. It does not measure network latency or ping responses.
-
The controller displays the current round-trip time as well as a running minimum and maximum round-trip time. The minimum and maximum times continue to run as long as the controller is up or can be cleared and allowed to restart.
-
You can configure link latency for a specific access point using the controller GUI or CLI or for all access points joined to the controller using the CLI.
This section contains the following subsections:
Restrictions for Link Latency
-
Link latency is supported for use only with FlexConnect access points in connected mode. FlexConnect access points in standalone mode are not supported.
Configuring Link Latency (GUI)
Procedure
Step 1 |
Choose Wireless > Access Points > All APs to open the All APs page. |
Step 2 |
Click the name of the access point for which you want to configure link latency. |
Step 3 |
Choose the Advanced tab to open the All APs > Details for (Advanced) page. |
Step 4 |
Select the Enable Link Latency check box to enable link latency for this access point or unselect it to prevent the access point from sending the round-trip time to the controller after every echo response is received. The default value is unselected. |
Step 5 |
Click Apply to commit your changes. |
Step 6 |
Click Save Configuration to save your changes. |
Step 7 |
When the All APs page reappears, click the name of the access point again. |
Step 8 |
When the All APs > Details for page reappears, choose the Advanced tab again. The link latency and data latency results appear below the Enable Link Latency check box:
|
Step 9 |
To clear the current, minimum, and maximum link latency and data latency statistics on the controller for this access point, click Reset Link Latency. |
Step 10 |
After the page refreshes and the All APs > Details for page reappears, choose the Advanced tab. The updated statistics appear in the Minimum and Maximum text boxes. |
Configuring Link Latency (CLI)
Procedure
Step 1 |
Enable or disable link latency for a specific access point or for all access points currently associated to the controller by entering this command: config ap link-latency {enable | disable} {Cisco_AP | all} The default value is disabled.
|
||
Step 2 |
See the link latency results for a specific access point by entering this command: show ap config general Cisco_AP Information similar to the following appears:
The output of this command contains the following link latency results:
|
||
Step 3 |
Clear the current, minimum, and maximum link latency statistics on the controller for a specific access point by entering this command: config ap link-latency reset Cisco_AP |
||
Step 4 |
See the results of the reset by entering this command: show ap config general Cisco_AP |