黑洞是怎么形成的
路径 MTU 发现依赖中间设备用 ICMP「需要分片」消息告知发送方把包改小。一旦这些 ICMP 被策略过滤，发送方就收不到任何反馈：大于某长度且不允许分片的报文在途中被静默丢弃，而小报文一路正常。于是现象很迷惑人——握手成功、小接口正常，一旦响应体变大就卡住或超时。这种「小包通、大包丢」的组合就是 MTU 黑洞最典型的特征，隧道与叠加封装场景尤其常见。
基本信息
| 适用平台 | Linux、Windows、网络设备与隧道链路均可出现 |
|---|---|
| 关键字段 | ip.flags.df、icmp.type == 3 && icmp.code == 4 |
| 探测方法 | Linux 用 ping -M do -s 逐档加大体积；Windows 用带不分片选项的 ping |
| 常见诱因 | GRE/IPsec/VXLAN 等封装削减可用载荷、中间设备过滤 ICMP |
典型使用场景
- 小接口正常、大响应卡死的接口定位
- 建立 VPN 或专线后发现部分业务不可用，确认是否封装改变了可用载荷
- 容器或云网络叠加封装后出现间歇性超时
- 升级网络设备或调整过滤策略后排查新出现的连接停滞
- 验证路径 MTU 探测是否被正确放行
- 为「ping 正常但业务慢」类工单提供可复核的解释
核对步骤
核对步骤
ip.flags.df == 1 && frame.len > 1400 # 捞出不分片的大包
icmp.type == 3 && icmp.code == 4 # 正常时应能看到分片需求通报
# 逐档加大探测体积，找到由通到不通的临界长度
ping -M do -s 1472 <目标> # 1500 MTU 下的常用临界探测
ping -M do -s 1400 <目标> # 封装的隧道通常需要更小结果逐项读法
| 观察结果 | 含义 | 处置方向 |
|---|---|---|
| 小包通、大包无响应 | 典型黑洞特征 | 检查 ICMP 是否被过滤并调整路径 MTU |
| 收到 needs fragmentation | 探测机制正常工作 | 按提示长度收敛即可，问题在参数不在策略 |
| 临界值明显偏小 | 存在封装或隧道 | 按隧道可用载荷设置 MSS 而非物理 MTU |
| 各长度都通但业务仍慢 | 不是 MTU 问题 | 转向窗口、丢包与重传方向排查 |
TCP 侧通常会自动收敛到更小的报文段长度，表现为「慢」而不是「完全不通」，把这种慢误判为性能问题会绕远路。
用 ping 探测时要注意探测路径与业务路径未必完全一致：策略路由、隧道选择都可能让两者走出不同链路，结论要结合业务侧抓包确认。