简介
本文档介绍IOS® XE和COS上的CAPWAP接入点路径最大传输单元(PMTU)发现机制、问题和解决方案。
场景和范围
当远程站点的CAPWAP接入点(AP)通过WAN注册到无线LAN控制器(WLC)时,尤其是当路径包括VPN、GRE或MTU低于标准1500字节的任何网段时,您通常会看到PMTU问题。
我们还检查使用可扩展身份验证协议传输层安全(EAP-TLS)的身份验证。 由于EAP-TLS交换大型证书,减少的路径MTU会增加分段风险。
在代码版本17.9.3上捕获所有日志。输出被截断为仅显示相关行。
CAPWAP控制与数据(协商内容)
CAPWAP控制:
控制信道处理关键管理消息,例如加入请求、配置交换和保持连接信号。这些消息使用DTLS进行保护,并且是路径MTU(PMTU)协商过程的主要焦点,以确保可靠、有效的控制平面通信。
CAPWAP数据:
此通道传输封装的客户端流量,通常在大多数部署中还受DTLS保护。当控制信道上发生PMTU协商时,生成的PMTU值间接确定数据平面封装的最大数据包大小,从而影响客户端数据传输的可靠性和分段。
Examples
- 控制数据包:加入请求和响应、配置更新以及回应/保持连接消息。
- 数据包:在接入点(AP)和无线局域网控制器(WLC)之间传输的封装客户端帧。
事实:最大大小的CAPWAP数据包
IOS AP(示例)
发送的PMTU数据包大小:1499字节=以太网+ CAPWAP PMTU
- 以太网= 14字节
- CAPWAP PMTU = 1485字节
- 外部IP = 20字节
- UDP = 25字节
- DTLS = 1440字节
AP-COS(示例)
发送的PMTU数据包大小:1483字节=以太网+ CAPWAP PMTU
- 以太网= 14字节
- CAPWAP PMTU = 1469字节
- 外部IP = 20字节
- UDP = 25字节
- DTLS = 1424字节
三阶段PMTU检查
两个平台都会探测三个硬编码PMTU值:信道 576、信道 1005 和信道 1485。区别在于每个平台计算以太网报头的方式:
CAPWAP PMTU发现机制
IOS AP行为
AP加入阶段
在CAPWAP加入期间,AP会使用DF位设置协商最大1485字节的CAPWAP PMTU。它等待5秒以等待响应。
数据包捕获(示例)
数据包编号106您会看到一个1499字节的探测(DF集)。 没有大小相同的响应表示数据包无法在不分段的情况下通过路径。然后您将看到ICMP“需要分段”。

对应的AP级别调试(“debug capwap client path-mtu”)显示,AP首先尝试了1485字节,然后等待5秒进行响应。如果没有响应,它会发送另一个长度较小的加入请求数据包,因为此数据包仍处于加入阶段,我们没有时间浪费。如调试日志中所示,它转至最小值以使AP加入WLC:
*Jul 11 18:27:15.000: CAPWAP_PATHMTU: CAPWAP_DTLS_SETUP: MTU = 1485
*Jul 11 18:27:15.000: CAPWAP_PATHMTU: Setting default MTU: MTU discovery can start with 576
*Jul 11 18:27:15.235: %CAPWAP-5-DTLSREQSUCC: DTLS connection created sucessfully peer_ip: 10.201.234.34 peer_port: 5246
*Jul 11 18:27:15.235: CAPWAP_PATHMTU: Sending Join Request Path MTU payload, Length 1376, MTU 576
*Jul 11 18:27:15.235: %CAPWAP-5-SENDJOIN: sending Join Request to 10.201.234.34
...
*Jul 11 18:27:20.235: %CAPWAP-5-SENDJOIN: sending Join Request to 10.201.234.34
*Jul 11 18:27:21.479: %CAPWAP-5-JOINEDCONTROLLER: AP has joined controller c9800-CL
如果此时运#showcapwap客户端rcb,您会看到576字节的CAPWAP AP MTU:
3702-AP#show capwap client rcb
AdminState : ADMIN_ENABLED
Primary SwVer : 17.9.3.50
..
MwarName : c9800-CL
MwarApMgrIp : 10.201.234.34
OperationState : JOIN
CAPWAP Path MTU : 576
运行状态阶段
在AP成功加入无线LAN控制器之后。您会看到正在运行的PMTU发现机制,30秒后,您可以看到AP开始通过发送另一个CAPWAP数据包(其中的DF位集为下一个最高PMTU值的大小)来协商更高的PMTU值。
在本示例中,AP尝试了1005字节值。由于IOS从PMTU字段中排除以太网,因此您会看到线路上有1019个字节。如果WLC响应,AP将PMTU更新为1005字节。否则,它将等待30秒并再次尝试。
此屏幕截图显示1005 PMTU的AP协商成功(请参阅数据包#268和#269)。 请注意,这些数据包具有不同的大小,这是因为WLC具有不同的PMTU计算算法。

此处,相应的AP级别Debug(debug capwap client pmtu)显示AP成功协商1005字节PMTU并更新AP PMTU值的位置。
*Jul 11 18:28:39.911: CAPWAP_PATHMTU: PMTU Timer Expired: Trying to send higher MTU packet 576
*Jul 11 18:28:39.911: CAPWAP_PATHMTU: PMTU Timer:Sending Path MTU packet of size 1005
*Jul 11 18:28:39.911: CAPWAP_PATHMTU: MTU = 1005 for current MTU path discovery
*Jul 11 18:28:39.911: CAPWAP_PATHMTU: Ap Path MTU payload with MTU 1005 sent 888
*Jul 11 18:28:39.911: CAPWAP_PATHMTU: Stopping the message timeout timer
*Jul 11 18:28:39.911: CAPWAP_PATHMTU: Setting MTU to : 1005, it was 576
*Jul 11 18:28:39.911: CAPWAP_PATHMTU: Updating MTU to DPAA
*Jul 11 18:28:39.915: CAPWAP_PATHMTU: Sending MTU update to WLC
*Jul 11 18:28:39.915: CAPWAP_PATHMTU: MTU = 1005 for current MTU path discovery
*Jul 11 18:28:39.915: CAPWAP_PATHMTU: Ap Path MTU payload with MTU 1005 sent 21
如果您在此时已#show行(配置capwap客户端rcb),您会发现1005字节的CAPWAP AP MTU,以下是show输出:
3702-AP#show capwap client rcb
AdminState : ADMIN_ENABLED
Primary SwVer : 17.9.3.50
Name : 3702-AP
MwarName : c9800-CL
MwarApMgrIp : 10.201.234.34
OperationState : UP
CAPWAP Path MTU : 1005
30秒后,AP再次尝试协商下一个更高的值1485字节,但是,当AP处于运行状态时,AP收到ICMP unreachable。ICMP unreachable有一个下一跳值,AP将使用该值来计算自己的PMTU,如调试所示。
*Jul 11 18:29:45.911: CAPWAP_PATHMTU: PMTU Timer:Sending Path MTU packet of size 1485
*Jul 11 18:29:45.911: CAPWAP_PATHMTU: MTU = 1485 for current MTU path discovery
*Jul 11 18:29:45.911: CAPWAP_PATHMTU: Ap Path MTU payload with MTU 1485 sent 1368
*Jul 11 18:29:45.911: CAPWAP_PATHMTU: Received ICMP Dst unreachable
*Jul 11 18:29:45.911: CAPWAP_PATHMTU: Src port:5246 Dst Port:60542, SrcAddr:10.201.166.185 Dst Addr:10.201.234.34
*Jul 11 18:29:45.911: CAPWAP_PATHMTU: Calculated MTU 1293, last_icmp_mtu 1300
*Jul 11 18:29:48.911: CAPWAP_PATHMTU: Path MTU message could not reach WLC, Removing it from the Reliable Queue
相应的AP级别捕获
注意ICMP不可达数据包编号281,然后AP尝试通过遵循数据包编号288上1300字节的ICMP下一跳值和289上的响应来协商PMTU:

COS AP行为
AP-COS AP的发现机制存在差异。我们从AP加入开始。
AP加入阶段
在加入时,AP会发送一个具有最大值的加入请求,并等待五秒。
如果没有响应,它会再次尝试并再等待五秒。
如果仍然没有响应,它将发送另一个包含1005字节的加入请求。如果成功,它会更新PMTU并继续(例如,映像下载)。 如果1005字节的DF探针仍然无法到达控制器,它将降至最低576并重试。
以下是AP级别的debug capwap client pmtu:
Jul 11 19:06:10 kernel: [*07/11/2023 19:06:10.7065] AP_PATH_MTU_PAYLOAD_msg_enc_cb: request pmtu 1485, update FALSE
Jul 11 19:06:10 kernel: [*07/11/2023 19:06:10.7066] Sending Join request to 10.201.234.34 through port 5248, packet size 1376
Jul 11 19:06:10 kernel: [*07/11/2023 19:06:10.7066] Sending Join Request Path MTU payload, Length 1376
..
Jul 11 19:06:15 kernel: [*07/11/2023 19:06:15.3235] AP_PATH_MTU_PAYLOAD_msg_enc_cb: request pmtu 1485, update FALSE
Jul 11 19:06:15 kernel: [*07/11/2023 19:06:15.3235] Sending Join request to 10.201.234.34 through port 5248, packet size 1376
Jul 11 19:06:15 kernel: [*07/11/2023 19:06:15.3235] Sending Join Request Path MTU payload, Length 1376
Jul 11 19:06:15 kernel: [*07/11/2023 19:06:15.3245] chatter: chkcapwapicmpneedfrag :: CheckCapwapICMPNeedFrag ICMP_NEED_FRAG sent to capwapd, needfrag_count 9184
..
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.0794] AP_PATH_MTU_PAYLOAD_msg_enc_cb: request pmtu 1005, update FALSE
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.0794] Sending Join request to 10.201.234.34 through port 5248, packet size 896
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.0794] Sending Join Request Path MTU payload, Length 896
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.0831] Join Response from 10.201.234.34, packet size 917
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.0832] AC accepted previous sent request with result code: 0
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.0832] Received wlcType 0, timer 30
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.5280] WLC confirms PMTU 1005, updating MTU now.
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.5702] PMTU: Set capwap_init_mtu to TRUE and dcb's mtu to 1005
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.5816] CAPWAP State: Image Data
Jul 11 19:06:20 kernel: [*07/11/2023 19:06:20.5822] AP image version 17.9.3.50 backup 17.6.5.22, Controller 17.9.3.50
请注意,数据包大小为1483字节,即pmtu值,没有以太网报头,这与AP-COS预期一致。您可以在此处查看数据包编号1168的以下内容:

运行状态阶段
在AP达到RUN状态后。它继续尝试每隔30秒改进PMTU,发送带有DF设置和下一个硬编码值的CAPWAP数据包。
这是AP级别调试(debug capwap client pmtu)
Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1341] wtpEncodePathMTUPayload: Total Packet Size: 1485
Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1341] wtpEncodePathMTUPayload: Capwap Size is 1376.
Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1341] [ENC]AP_PATH_MTU_PAYLOAD: pmtu 1485, len 1352, buffer len 1376
Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1341] capwap_build_and_send_pmtu_packet: packet length = 1485 for current path MTU discovery
Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1343] Ap Path MTU payload sent, length 1368
Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1343] WTP Event Request: AP Path MTU payload sent to 10.201.234.34, seq num 53
Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1351] pmtu icmp pkt(ICMP_NEED_FRAG) from click received
Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1351] chatter: chkcapwapicmpneedfrag :: CheckCapwapICMPNeedFrag ICMP_NEED_FRAG sent to capwapd, needfrag_count 9187
Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1351] PMTU data: dcb->mtu 1005, pmtu_overhead:1184 capwapsize_mtu: 1293 next_hop_mtu 1300, last_icmp_mtu 0 router_path_mtu 0
Jul 11 19:08:15 kernel: [*07/11/2023 19:08:15.1351] PMTU: Last try for next hop MTU failed
Jul 11 19:08:17 kernel: [*07/11/2023 19:08:17.9850] wtpCleanupPMTUPacket: PMTU: Found matching PMTUpacket at:50 position of the Q
..
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6435] wtpEncodePathMTUPayload: Total Packet Size: 1485
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6435] wtpEncodePathMTUPayload: Capwap Size is 1376.
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6436] [ENC]AP_PATH_MTU_PAYLOAD: pmtu 1485, len 1352, buffer len 1376
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6436] capwap_build-and-send_pmtu_packet: packet length = 1485 for current path MTU discovery
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6437] Ap Path MTU payload sent, length 1368
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6438] WTP Event Request: AP Path MTU payload sent to 10.201.234.34, seq num 59
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6446] pmtu icmp pkt(ICMP_NEED_FRAG) from click received
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6446] chatter: chkcapwapicmpneedfrag :: CheckCapwapICMPNeedFrag ICMP_NEED_FRAG sent to capwapd, needfrag_count 9188
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6446] PMTU data: dcb->mtu 1005, pmtu_overhead:1184 capwapsize_mtu: 1293 next_hop_mtu 1300, last_icmp_mtu 0 router_path_mtu 0
Jul 11 19:08:43 kernel: [*07/11/2023 19:08:43.6447] PMTU: Last try for next hop MTU failed
Jul 11 19:08:46 kernel: [*07/11/2023 19:08:46.4945] wtpCleanupPMTUPacket: PMTU: Found matching PMTUpacket at:55 position of the Q
以下是相应的AP捕获。查看数据包编号1427和1448:

结论(算法总结)
总之,接入点上的CAPWAP PMTUD算法的工作方式如下。
步骤1.在AP加入阶段协商初始CAPWAP PMTU。
步骤2. 30秒后,AP尝试通过发送下一个预定义的较高值(576、1005、1485字节)来改进当前CAPWAP PMTU。
第3步(选项1)。 如果WLC响应,请将当前CAPWAP PMTU调整为新值并重复步骤2。
步骤3(选项2)。如果没有响应,请保留当前的CAPWAP PMTU并重复步骤2。
第3步(选项3)。 如果没有响应,并且ICMP不可达(类型3,代码4)包括下一跳MTU,请将CAPWAP PMTU调整为该值,然后重复步骤2。
NOTE:请参阅修复程序,确保在提供ICMP下一跳值时使用正确的CAPWAP PMTU。
相关CDET
问题1:
Cisco Bug ID CSCwf52815
AP-COS AP在更高值探测失败时不会认可ICMP不可达下一跳值。
修复:8.10.190.0、17.3.8、17.6.6、17.9.5、17.12.2。
IOS AP会遵循下一跳值并更新PMTU。
问题二:
Cisco Bug ID CSCwc05350
当ICMP未反映最大→双向PMTU时,非对称→(WLC-AP不同于AP-WLC)会导致PMTU抖动。
修复:8.10.181.0、17.3.6、17.6.5、17.9.2、17.10.1。
解决方法:在控制WLC和AP之间的MTU(路由器、防火墙、VPN集中器)的设备上,在两个方向上配置相同的MTU。
相关AP端思科漏洞ID CSCwc05364:COS-AP改进了PMTU机制,以便能够识别非对称MTU的最大定向MTU大小
相关WLC端Cisco Bug ID CSCwc48316:改进PMTU计算,使AP能够具有两个不同的MTU(一个上游和另一个)(标记为Closed by DE,因为它们没有解决此问题的计划)
问题三:
Cisco Bug ID CSCwf91557
AP-COS在达到最大硬编码值后停止PMTU发现。
在17.13.1中修复;也可通过思科漏洞ID CSCwf52815(位于17.3.8、17.6.6、17.9.5、17.12.2中)修复。
问题四:
Cisco Bug ID CSCwk70785
AP-COS未更新PMTU探测的MTU值,导致断开连接。
已在思科漏洞ID CSCwk90660 - APSP6 17.9.5]中修复,目标为17.9.6、17.12.5、17.15.2、17.16。
问题五:
Cisco Bug ID CSCvv53456
9800静态CAPWAP路径MTU配置(与AireOS奇偶校验)。
这允许9800基于每个AP加入配置文件配置静态CAPWAP路径MTU。 进入17.17。