MSS 与 MTU 为什么会打断 BGP
BGP 跑在 TCP 上，握手与 Keepalive 报文都很小，能顺利通过；而携带大量前缀的 Update 可能达到数千字节。若路径中某段 MTU 较小（隧道、IPsec、PPPoE 场景常见），又不允许分片、且 ICMP 需要分片报文被过滤，TCP 就会不断重传却无法送达，表现为「会话能建立、一大批量更新就卡住或断开」。
基本信息
| 典型症状 | 连接建立后才断、大批量更新后中断、偶发握手失败 |
|---|---|
| 根因 | 路径 MTU 变小且 ICMP 被禁，PMTUD 失效形成黑洞 |
| 处理手段 | 在隧道或接口上钳制 TCP MSS，按最小 MTU 反推 |
| Cisco 配置 | 接口下 ip tcp adjust-mss <值>（不同平台命令名称可能不同） |
| 验证手段 | 抓包看是否出现大量重传与无回应的报文 |
典型使用场景
- GRE、IPsec、VXLAN 等隧道承载 BGP：隧道封装开销使有效 MTU 变小
- 跨运营商互联：中间存在 PPPoE 等封装，实际可用 MTU 低于 1500
- MPLS 标签栈较深：压入多层标签后报文变长，超出口径被丢弃
- 虚拟化环境：宿主机网卡与 overlay 层 MTU 设置不一致
- 割接验证：把大包探测作为对等上线前的常规检查项
配置与探测
配置与探测
# 接口或隧道上钳制 MSS（值按最小 MTU 反推，例如 1400 MTU 对应 1360）
interface Tunnel0
ip tcp adjust-mss 1360
!
# 大包探测：IPv4 头与 ICMP 头共 28 字节，1400 表示探测 1400 字节数据
ping 10.0.0.2 size 1400 df-bit repeat 5
# 若出现 % 分片被丢弃或超时，说明路径 MTU 小于该值
!
# 抓包看重传模式
tcpdump -i eth0 -nn 'host 10.0.0.2 and tcp port 179'症状与判断
| 现象 | 可能原因 | 验证方式 |
|---|---|---|
| 小报文正常、大批更新后挂住 | MSS/MTU 不匹配 | 抓包看重传与大包是否到达 |
| 会话稳定但前缀数远少于对端 | 部分 Update 被丢弃 | 对比两端前缀计数与抓包 |
| 偶发握手失败 | SYN 带选项后超过路径 MTU | 探测不同大小的包 |
| 隧道链路一切正常、BGP 反复超时 | 封装开销未计入 MTU | 按隧道协议计算有效 MTU |
排错顺序
排错顺序
# 1) 明确承载路径的实际 MTU
show interface Tunnel0 | include MTU
# 2) 用不同大小的包逐级探测
ping 10.0.0.2 size 1500 df-bit
ping 10.0.0.2 size 1400 df-bit
# 3) 抓包确认重传与 ICMP 情况
tcpdump -i eth0 -nn 'icmp'
# 4) 找到最小 MTU 后设置 MSS，并重置邻居验证MSS 钳制只影响 TCP 会话的报文长度，不改变物理 MTU，也不会影响 ICMP 或 UDP 流量。设置值应按路径最小 MTU 减去 IP 与 TCP 头开销计算，照抄其他网络的数值往往不适用。