Configure CAPWAP Path MTU Discovery

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.

Bckground 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

DLTS                            =          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.