接口 MTU 调整
MTU 不一致会造成「小包通、大包丢」的隐性故障：ping 小报文一切正常，业务一传大文件就卡死，VPN、VXLAN、存储与隧道场景高发。原因是路径中最小 MTU 决定了可通的最大报文尺寸，超过且不允许分片时被丢弃。改前必须评估全路径，改后用带禁止分片标志的大包 ping 逐点验证。
基本信息
| 适用平台 | 华为 VRP、思科 IOS、H3C Comware |
|---|---|
| 华为与 H3C | 接口下 mtu 值同时影响二层与三层承载 |
| 思科 | 区分接口 mtu 与 ip mtu，ip mtu 是三层分片依据 |
| 典型场景 | GRE 或 IPsec 隧道需要预留封装开销，常用 ip mtu 或 MSS 钳制 |
| 验证方法 | 用带 DF 标志的大包 ping 逐点探测路径 MTU |
MTU 相关参数
| 参数 | 适用平台 | 说明 |
|---|---|---|
| 接口 MTU | 三厂 | 接口可承载的最大报文长度，以太网默认 1500 |
| ip mtu | 思科 | 三层报文的 MTU，隧道场景常调小 |
| TCP MSS 调整 | 三厂 | 隧道场景钳制 TCP 最大段长，避免分片 |
| DF 标志探测 | ping 命令 | 用不允许分片的大包定位路径上最小的 MTU |
| 1472 与 1500 | 计算关系 | 1472 字节载荷加 28 字节报文头等于 1500 |
典型使用场景
- 隧道或 VPN 建立后部分大流量业务异常，怀疑封装开销导致超长
- 存储或备份类业务报「大包不通」，需要按路径 MTU 定位
- 数据中心与园区互联链路两端口径不一致，出现单向丢包
- 新增中间设备后路径 MTU 变小，业务间歇性超时
- 链路验收时用大包探测确认端到端可承载的报文尺寸
华为 VRP 与 H3C Comware
华为 VRP 与 H3C Comware
display interface GigabitEthernet0/0/1 | include MTU # 先看当前值
interface GigabitEthernet0/0/1
mtu 1500
ping -s 1472 10.1.1.1 # 大包探测；1473 起应出现不通或分片现象
display interface GigabitEthernet0/0/1 | include errors # 改动后观察错误计数思科 IOS
思科 IOS
interface GigabitEthernet0/1
mtu 1500 # 接口 MTU
ip mtu 1400 # 三层 MTU，隧道场景常调小
ping 10.1.1.1 size 1472 df-bit # 大包且禁止分片，验证路径 MTU
show interfaces GigabitEthernet0/1 | include MTU排查口径统一：先用不同包长（如 1400 与 1500）对照探测，确认是否为 MTU 类问题，再决定改哪一端。已在路径中传输失败的报文不会留下明显日志，只能靠主动探测。
只改一端会制造不对称：一端接受大包、另一端丢弃，表现为单向不通。要么全路径统一，要么按路径上最小 MTU 规划，并在隧道场景同步钳制 TCP MSS。