PDF(1.6 MB) View with Adobe Reader on a variety of devices
ePub(1.8 MB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(1.3 MB) View on Kindle device or Kindle app on multiple devices
Updated:August 5, 2020
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document discusses how the Control and Provisioning of Wireless Access Points (CAPWAP) Path Maximum Transmission Unit (PMTU) Discovery works and how it adjusts accordingly when the network changes.
Cisco recommends that you have knowledge of these topics:
Basic understanding of CAPWAP
The information in this document is based on these software and hardware versions:
2960X running 15.0(2)EX1
2960S running 15.0(2)ES10a
5508 running 22.214.171.124
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
It describes a scenario where a CAPWAP Access Point (AP) is physically installed in a remote office location needing to register to a Wireless LAN Controller (WLC) across the WAN that’s physically installed in a Data Center.To add further, remote site is logically attached to the Data Center (DC) using VPN or a Generic Routing Encapsulation (GRE) tunnel and your WiFi client fails to authenticate using Extensible Authentication Protocol (EAP-TLS) method and you wonder why. With additional overhead introduced by the tunnelling protocol, fragmentation can become an hindrance if the network doesn’t adjust accordingly.
ip address 126.96.36.199 255.255.255.0
ip address 188.8.131.52 255.255.255.0
ip address 184.108.40.206 255.255.255.0
ip address 172.16.1.1 255.255.255.0
no ip unreachables
tunnel source 220.127.116.11
tunnel destination 18.104.22.168
ip address 22.214.171.124 255.255.255.0
ip address 10.10.10.3 255.255.255.0
ip address 172.16.1.2 255.255.255.0
no ip unreachables
tunnel source 126.96.36.199
tunnel destination 188.8.131.52
(WLC5508) >show interface summary
Number of Interfaces.......................... 18
Interface Name Port Vlan Id IP Address Type Ap Mgr Guest
-------------------------------- ---- -------- --------------- ------- ------ -----
vlan_50 1 50 192.168.50.11 Dynamic No No
vlan_60 1 60 192.168.60.11 Dynamic No No
vlan_70 1 70 192.168.70.11 Dynamic No No
management 1 178 10.67.81.11 Static Yes No
The initial CAPWAP PMTU discovery occurs during the CAPWAP JOIN state. The AP attempts to negotiate at the maximum CAPWAP PMTU of 1485 Bytes (packet #73 figure 1) using the following equation.
1499 Bytes = Ethernet + CAPWAP PMTU
CAPWAP PMTU = Outer IP + UDP + DTLS
Ethernet = 14 Bytes
CAPWAP PMTU = 1485 Bytes
Outer IP = 20 Bytes
UDP = 25 Bytes
DTLS = 1440 Bytes
When the WLC sees this and a corresponding response is sent back to the AP, this value becomes the initial CAPWAP PMTU. If the WLC doesn’t receive this from the AP, WLC and AP uses 576 Bytes instead. This section of AP switchport capture describes the AP attempt in negotiating the initial CAPWAP PMTU which eventually fails to get responded by the WLC.
The corresponding debug seen on the AP (debug capwap client info), is shown in the next image.
As you can see, the initial attempt by the AP fails to get responded leading to a retransmission of a CAPWAP Join Packet after approximately 5 seconds. So immediately, AP falls back to the lowest CAPWAP PMTU of 576 Bytes as shown in this image.
During the RUN state, AP attempts to periodically improve the CAPWAP PMTU by sending the next highest CAPWAP PMTU value every 30 seconds thereafter. If the AP receives the corresponding response from the WLC, the current value gets adjusted. If it doesn’t, AP waits another 30 seconds before repeating the attempt to improve the current CAPWAP PMTU. This image shows a successful CAPWAP PMTU negotiation.
And the corresponding debug on the AP is showing in this image.
Finally, you can check the CAPWAP PMTU negotiated on the WLC as shown in this image.
You can check the current PMTU size on the AP using the command, as shown in this image.
Now one might ask, how does the CAPWAP PMTU adjust dynamically if the path IP MTU has improved or degraded?
If improved, you should expect to see the next periodic attempt by the AP in improving the current CAPWAP PMTU get acknowledged by the WLC and adjust accordingly.
If degraded, the next periodic attempt by the AP to improve the current CAPWAP PMTU results in no corresponding response from the WLC and an ICMP Unreachable (Type 3, Code 4) with a next hop MTU which results in a lower CAPWAP PMTU. Should the Internet Control Message Protocol (ICMP) unreachable never reach the AP, AP does not make any adjustments to the current CAPWAP PMTU which may lead to dropped packets due to large fragments.
Note: It is important to note that ICMP unreachable maybe filtered by a firewall to prevent DoS attack which is a common practice. Ensure that this is not the case when things don’t work.
Here's an example of what happens when the tunnel interface IP MTU is changed from 1500 to 900.
As you can clearly see, ICMP Unreachable immediately reduces the CAPWAP PMTU to 576 Bytes until it gets adjusted to the next hop MTU value as shown in this image.
In summary, the CAPWAP PMTUD algorithm works like this.
Step 1. Initial CAPWAP PMTU will be negotiated during the AP join phase.
Step 2. 30 seconds later, AP will attempt to improve the current CAPWAP PMTU by sending the next pre-defined higher CAPWAP PMTU value (576, 1005 and 1485 Bytes).
Step 3 (option 1). If there is a corresponding WLC response to the attempt, adjust the current CAPWAP PMTU to the new value and repeat step 2.
Step 3 (option 2). If there is no corresponding WLC response to the attempt, leave the current CAPWAP PMTU unchanged and repeat step 2.
Step 3 (option 3). If there is no corresponding WLC response and we see an ICMP unreachable (Type 3, Code 4) with next hop value, adjust the CAPWAP PMTU to this value and repeat step 2.