路径 MTU 发现是什么
PMTUD 让发送方自动找出整条路径上最小的 MTU：先把报文按出接口 MTU 发出去并置 DF 位禁止分片，途中某跳发现放不下就回一条 ICMP「需要分片」（IPv4 类型 3 代码 4），发送方据此下调并重试。IPv6 完全依赖这个机制，路由器不再做分片，只会回「包太大」（类型 2）。
基本信息
| 工作机制 | 置 DF 发送，收到 ICMP 需要分片后下调 MTU |
|---|---|
| 依赖报文 | IPv4 类型 3 代码 4；IPv6 类型 2 包太大 |
| 失败后果 | MTU 黑洞：大包被静默丢弃，小包正常 |
| 兜底手段 | net.ipv4.tcp_mtu_probing 自动探测，或中间设备做 MSS clamp |
| 查看接口 MTU | ip link show，注意隧道与 veth 接口的实际值 |
| 相关参数 | net.ipv4.ip_no_pmtu_disc，0 表示启用 PMTUD |
典型使用场景
- 建立 GRE、IPsec、VXLAN 隧道后，验证内层可用 MTU 并调整两端配置
- 排查「小包能通、大包超时」类故障，逐级试出实际可通尺寸
- PPPoE 环境下确认 MTU 是否为 1492 而非 1500
- 云环境跨可用区或跨账号通信出现丢包，确认中间设备的 ICMP 策略
- 为不能修改的应用开启 mtu_probing 做兜底
- 定位 IPv6 环境下的连接挂起，检查是否只回包太大而未真正下调
最小示例
最小示例
ping -M do -s 1472 8.8.8.8 # 1472+28=1500，通说明路径 MTU 至少 1500
ping -M do -s 1452 8.8.8.8 # 1452+28=1480，逐级试出最大可通尺寸
ip link show eth0 | grep mtu # 查看本地接口 MTU
sysctl net.ipv4.tcp_mtu_probing # 0 关闭，1 仅在检测到黑洞时探测，2 始终探测
sysctl -w net.ipv4.tcp_mtu_probing=1失败原因对照
| 环节 | 可疑点 | 确认方法 |
|---|---|---|
| 隧道 | GRE / IPsec 外层封装占用 MTU | 对比隧道两端接口 MTU 设置 |
| PPPoE | 实际 MTU 为 1492 而配置仍是 1500 | 用 DF 置位大包逐级测试 |
| 中间防火墙 | 禁用了 ICMP 差错报文 | 抓包看是否有类型 3 代码 4 返回 |
| 云网络 | VPC 网关或安全组行为差异 | 查厂商文档或提工单确认 |
| 终端主机 | 应用忽略 ICMP 导致缓存过期 | 观察 mtu_probing 是否生效 |
PMTUD 严重依赖 ICMP。把 ICMP 差错报文一并封死，是「网站部分能开、部分卡死」这类疑难故障的常见根因。