Taking into account that CAPWAP is "tunneling" IP data traffic from wireless clients and that CAPWAP runs over WAN links (Hybrid Remote Edge Access Point [H-REAP] setups), it is important for troubleshooting to understand the fragmentation behavior as well as the Path MTU Discovery mechanism from CAPWAP. The following sections provide an overview of how this works. For a more detailed explanation, refer to the CAPWAP and DTLS RFCs, as outlined in Figure 4-1.
CAPWAP-Control Packets Fragmentation
DTLS handshake messages can be quite large (in theory up to 224 – 1 bytes, but in practice many kilobytes). By contrast, UDP datagrams are often limited to less than 1500 bytes if fragmentation is not desired. Therefore, DTLS provides a mechanism for fragmenting a handshake message over numerous records. That is why you see the certificate exchanges divided into several frames. This is, for example, visible in Figure 4-5, described as Certificate (fragment) in frame 54 and onward.
CAPWAP-Data Packets Fragmentation
Like all tunnel protocols, CAPWAP adds overhead to data it is transporting, which might cause fragmentation. Although IP provides fragmentation and reassembly services, the CAPWAP protocol also provides such services. Environments in which the CAPWAP protocol is used involve firewall, NAT, and "middlebox" devices, which tend to drop IP fragments to minimize possible DoS attacks. By providing fragmentation and reassembly at the application layer, any fragmentation required due to the tunneling component of the CAPWAP protocol becomes transparent to these intermediate devices.
CAPWAP-MTU DISCOVERY and TCP-MSS Adjustment
To fix the fragmentation issue by the root, CAPWAP implementations perform MTU Discovery, which can avoid the need for fragmentation of CAPWAP packets. Initial path MTU discovery is done during the JOIN message (Path MTU discovery). After the AP is in the RUN state, you can adjust it (Dynamic Path MTU Discovery).
CAPWAP-P-MTU DISCOVERY
The initial path MTU discovery is done during the JOIN messages. The conditions are as follows:
Step 1. Join message will be sent from the AP to the controller by padding the message to 1485 bytes with a Don’t Fragment (DF) bit set.
Step 2. If the controller receives the message, it returns a join response padded up to 1485 bytes, and the AP updates its MTU size to 1485.
Step 3. If the join request with padded bytes of 1485 does not reach the controller, the AP times out after 3 seconds and sends a new join request without padding (MTU size 576).
Therefore, the AP will join the controller with an MTU size of either 1485 or 576 bytes; it can be changed only after the AP is in its run state (Dynamic Path MTU Discovery).
CAPWAP-Dynamic P-MTU Discovery
The dynamic Path-MTU is done as per RFC 1191:
Step 1. The AP sends CAPWAP (control and data) packets with the DF bit set.
Step 2. If the MTU has changed, the router sends an Internet Control Message Protocol (ICMP) error to the AP to fragment the packet.
Step 3. The AP immediately changes the MTU size to 576 bytes.
Step 4. The AP looks for next-hop MTU information in the ICMP error message and sends a P-MTU discovery packet. If the controller receives it, the AP uses it for all the future communications with the controller.
Step 5. If the ICMP error message does not have a next-hop MTU value, the AP starts from the lowest MTU (576) and increases every 30 seconds in steps of (576, 1006, 1492, 1500).
Notice MTU changes in the following output from the controller debugs:
TCP-MSS Adjustment Feature
Because fragmentation and reassembly in the middle of the data transport can slow the performance, the best solution is to prevent large packets already at the application layer.
The TCP-MSS-Adjustment feature modifies the maximum segment size (MSS) for TCP SYN packets traveling through the network and prohibits the application from sending packets that are too large. It can be enabled globally or configured per AP.
