Introduction
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.
Prerequisites
Requirements
Cisco recommends that you have knowledge of these topics:
- Basic understanding of CAPWAP
- RFC1911
Components Used
The information in this document is based on these software and hardware versions:
- AIR-AP3702I-Z-K9
- 2960X running 15.0(2)EX1
- 2960S running 15.0(2)ES10a
- 5508 running 8.2.155.17
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.
Background Information
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.
Configure
Network Diagram
Configurations
2960X:
interface Vlan7
ip address 7.7.7.1 255.255.255.0
!
interface Vlan8
ip address 8.8.8.1 255.255.255.0
2960S-A:
interface Vlan8
ip address 8.8.8.2 255.255.255.0
!
interface Tunnel1
ip address 172.16.1.1 255.255.255.0
no ip unreachables
tunnel source 9.9.9.2
tunnel destination 9.9.9.3
tunnel path-mtu-discovery
2960S-B:
interface Vlan9
ip address 9.9.9.3 255.255.255.0
!
interface Vlan10
ip address 10.10.10.3 255.255.255.0
!
interface Tunnel1
ip address 172.16.1.2 255.255.255.0
no ip unreachables
tunnel source 9.9.9.3
tunnel destination 9.9.9.2
tunnel path-mtu-discovery
WLC5508:
(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
Verify
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
where
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.

Troubleshoot
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.