大包不通从哪查
能 ping 通小包但网页打不开、传大文件卡住，是典型的 MTU 黑洞。做法是用禁止分片的大包逐级缩小尺寸，找到突然能通的临界值，路径 MTU 就在这个数值附近，注意要把 IP 与 ICMP 头的 28 字节算进去。
基本信息
| 适用平台 | 三厂设备与主机 |
|---|---|
| 华为与 H3C | ping -s 载荷字节 目标地址 |
| 思科 | ping 目标地址 size 载荷字节 df-bit |
| 换算关系 | 载荷加 28 字节 IP 与 ICMP 头等于实际报文长度 |
| 高发场景 | PPPoE、GRE、IPSec 与各类隧道、叠加网络 |
| 处理手段 | 主机侧 TCP MSS 钳制，或按封装开销调整接口 MTU |
典型使用场景
- 网页打不开但 ping 正常，怀疑 MTU 问题
- 隧道或 VPN 场景大包不通
- 割接后个别应用异常，而基础链路测试正常
- 验证 MSS 钳制配置是否生效
- 排查分片被策略丢弃造成的间歇性故障
华为 VRP / H3C Comware
华为 VRP / H3C Comware
ping -s 1472 3.3.3.3 # 载荷 1472 加 28 等于 1500，标准以太网 MTU
ping -s 1400 3.3.3.3 # 缩小载荷重试
ping -s 1300 3.3.3.3 # 继续缩小
ping -s 1420 3.3.3.3 # 在临界区间内继续二分逼近思科 IOS
思科 IOS
ping 3.3.3.3 size 1472 df-bit # df-bit 表示禁止分片
ping 3.3.3.3 size 1400 df-bit
ping 3.3.3.3 size 1300 df-bit
traceroute 3.3.3.3 # 结合逐跳结果判断哪一段受限
show interfaces GigabitEthernet0/1 | include MTU # 核对接口 MTU 设置现象与处理方向
| 现象 | 可能原因 | 处理方向 |
|---|---|---|
| 小包通、大包不通 | 路径 MTU 小于发送端 | 逐步定位路径 MTU 后调整 |
| 隧道场景常见 | 封装带来额外开销 | 按封装开销下调接口 MTU |
| TCP 建立后卡住 | MSS 协商值过大 | 主机或设备侧做 MSS 钳制 |
| 只有部分应用异常 | 应用报文尺寸较大 | 对该网段统一做钳制 |
计算 MTU 时别漏掉头部开销：ping 的 size 是载荷字节，加上 IP 与 ICMP 的 28 字节才是实际报文长度。1472 加 28 正好 1500，这也是最常用的测试起点。
PPPoE、GRE 与隧道场景下路径 MTU 小于 1500 是常态。与其逐个调整接口 MTU，不如在主机或设备侧做 TCP MSS 钳制，改动点更少，对业务的影响也更可控。
对端屏蔽 ICMP 时，禁止分片测试可能得不到明确回执。这时要结合逐跳测试与其他层面的验证手段交叉判断，不能因为收不到 ICMP 就断言路径没有问题。