中间设备 MTU 的探测方法

发布时间:2026-07-28 14:52

大包过不去小包能通，是网络问题里最具迷惑性的一类：ping 测试正常，页面打开卡住；握手成功，传数据就断。根源常常在路径上某台设备的最大传输单元偏小，而自动发现机制又恰好失灵。掌握手动探测路径 MTU 的方法，这类问题可以当场定位。 ## 症状与原理 最大传输单元限制单次能封装的数据帧大小，超过限制的包要么被分片，要么在禁止分片时被丢弃。现代系统默认依赖路径 MTU 发现机制：发送端把包标记为禁止分片，途经设备放不下时返回过错消息，发送端据此调小包尺寸。机制的命门在那条过错消息：防火墙规则或设备配置把过错消息拦掉，发送端收不到反馈，坚持用大包重发，对端永远收不全，连接表现为小包正常大包不通。隧道与叠加网络还会让问题更隐蔽：封装头部占用空间，内层可用的传输单元比物理链路标称更小。 ## 手动探测的步骤 手动探测的思路是用固定尺寸、禁止分片的方式逐级试探，从常规上限开始： ```bash ping -M do -s 1472 目标地址 ``` 参数含义是禁止分片并附带指定字节数的数据，加上头部二十八字节恰好对应常见的千五最大传输单元。能通则说明路径支持该尺寸；不通则逐级减小数据长度重试，二分法可以加快定位，找到能通过的最大值，加上二十八字节就是路径的实际可用传输单元。反向也要测一次，两个方向的路径可能不同。定位到的数值与两端配置对照，要么调小两端设置适配路径，要么排查路径上限制过小的设备。 ## 验证与调整 调整后做完整验证：一是命令层面确认新尺寸稳定通过，重复多次排除偶然；二是应用层面验证大文件传输、页面加载这类实际场景恢复正常，应用层的会话建立与数据传输用的包尺寸不同，命令通过不等于应用恢复；三是持续观察，晚高峰链路拥塞时设备对大包的处理可能变化，留一天观察期更稳妥。顺云用户在自己组网的虚拟化环境里遇到类似症状时，注意虚拟网卡与叠加网络的头部开销，探测要以实际业务路径为准，包括隧道两端。 ## 注意事项 一是探测在业务低峰或测试地址上做，大包探测本身会增加网络负担。二是云端注意安全组与防火墙规则别拦掉过错消息，它是自动发现机制正常的前提。三是调整优先级：能统一路径上设备的单元尺寸就统一，不能统一再把两端设置调到实测值，留下的差异要在文档里登记。四是新建隧道、更换设备、业务上云之后顺手做一次探测，可以预防这类隐蔽故障。