隧道 MTU 为什么会咬人
CAPWAP 把终端的以太网帧封装进 IP/UDP 报文后再送往 AC，封装本身会增加数十字节开销。如果 AP 到 AC 的路径 MTU 没有相应留出余量，超长报文会被丢弃或分片，用户侧的现象是「能 ping 通、网页打不开、大文件传不动」。AC 与 AP 跨广域网或跨隧道部署时最容易撞上这个问题。
基本信息
| 封装开销 | CAPWAP/IP/UDP 头部使报文加长数十字节 |
|---|---|
| 典型现象 | ping 小包正常、大包丢失，网页长时间转圈 |
| 判定方法 | 用逐步放大的探测报文定位路径 MTU |
| 处置手段 | 调整隧道 MTU、做 MSS 钳制、修正路径 MTU |
| 高发场景 | AC 与 AP 跨广域网或跨隧道部署 |
典型使用场景
- 跨广域网 AC 部署：中间链路使路径 MTU 变小，隧道更容易越界
- 网页打不开但 ping 正常：典型的 MTU 问题表征，先排除此项再查应用
- 大文件与视频卡顿：数据报文超长被丢弃，重传同样无效
- 上线前验证：新建隧道前先测路径 MTU，避免投产后再回头改
- 变更后回归：更换链路、新增隧道后重新核对 MTU
验证与处置
验证与处置
# 逐步放大探测载荷，找到能稳定通过的最大值
ping -M do -s 1400 <对端地址> # Linux：-M do 禁止分片
ping -f -l 1400 <对端地址> # Windows：-f 设置不分片标志
# 把可通的最大载荷加回 IP 与 ICMP 头部，即为路径 MTU 参考值
# 明显小于 1500 时，在 AP/AC 侧调低隧道 MTU 或对终端做 MSS 钳制
# 改完复测：大包稳定通过、网页与文件传输恢复正常排查项对照
| 检查项 | 正常表现 | 异常表现 |
|---|---|---|
| 小包连通性 | 稳定不丢 | 丢包说明问题不在 MTU |
| 大包连通性 | 1500 字节级可通 | 超过某长度后全部丢失 |
| 路径 MTU | 与隧道开销需求匹配 | 小于隧道开销，必然丢大包 |
| 隧道 MTU 配置 | 显式设置并留有余量 | 沿用默认值，跨网时越界 |
该问题最常见的误判是当成「网站故障」：本地小包测试一切正常，实际是隧道 MTU 太小导致大包被丢。
只改 AP 侧参数不改路径 MTU，问题照旧；需要端到端核对每一跳的 MTU 与 MSS 处理方式。