1. 从能 ping 通到下载失败的认知断层很多人第一次遇到这个问题时脑子里蹦出来的第一个念头是网络没问题啊ping 都通了。这个判断本身没错但结论下错了。ping 通只证明了一件事ICMP 报文在两端之间能完成一次往返。它证明不了 TCP 握手能成功更证明不了几百字节到几 KB 的工程数据包能完整穿过整条链路。PLC 远程维护场景里ping 通但下载失败几乎是最高频的一类故障。它的典型表现是工程师在办公室或家里通过远程通道连到现场路由器ping 一下 PLC 的 IP延迟正常、不丢包心里一松然后打开编程软件点下载进度条卡在某个百分比或者干脆弹出一个连接中断目标不可达通信超时的报错。反复重试偶尔能成一次大部分时候失败。这里的关键认知是ping 用的是小包下载用的是大包。默认情况下Windows 的 ping 只发 32 字节的数据加上 IP 头和 ICMP 头也就 60 字节左右。而 PLC 程序下载、固件更新、在线监控这些操作单个 TCP 报文的数据载荷动辄 1400 字节以上。当链路的 MTU最大传输单元被某种隧道封装压缩之后小包能过大包过不去就出现了ping 通但下载失败这个看似矛盾的现象。我先把结论摆在这里这类问题的排查顺序应该是 MTU 优先而不是先怀疑 PLC、先怀疑编程软件、先怀疑防火墙。因为 MTU 问题是唯一一个能完美解释小包通、大包挂这个特征的。下面我把整个排查链路拆开讲包括每一步为什么这么做、怎么验证、以及我实际踩过的坑。2. 为什么隧道封装会把 MTU 悄悄吃掉2.1 标准以太网的 1500 字节是怎么来的要理解 MTU 问题得先知道 1500 这个数字的来历。以太网帧的标准最大载荷是 1500 字节这是几十年前定下来的规矩一直沿用至今。一个完整的以太网帧结构大致是14 字节以太网头 1500 字节载荷 4 字节 FCS 校验总共 1518 字节。这个 1500 就是所谓的 MTU。当两台设备在同一个局域网内直接通信时MTU 就是 1500谁也不用改。但一旦中间加了隧道事情就变了。隧道的工作方式是把原始的数据包整个塞进一个新的数据包里再发出去。这个塞进去的动作需要额外的头部空间。2.2 隧道封装到底占了多少字节不同的隧道协议额外开销不一样。我列一个常见的对照表方便你心里有数封装类型额外开销约有效 MTU无封装纯以太网01500GRE24 字节1476IPsec传输模式50-60 字节1440-1450IPsec隧道模式60-80 字节1420-1440双层封装隧道套隧道100 字节1400 以下注意这里的开销是叠加的。如果你的远程通道本身就是隧道套隧道——比如先有一层加密隧道里面又跑了一层 GRE——那有效 MTU 可能只剩 1360 甚至更低。问题的核心在于路径上的设备并不会自动协商出一个大家都满意的 MTU。发送端默认按自己的 MTU通常是 1500发包包到了隧道入口如果包太大塞不进去理想情况下应该回一个 ICMP 需要分片的消息告诉发送端你把包改小点。但现实是很多网络设备出于安全策略直接把这类 ICMP 消息拦掉了。发送端收不到反馈就傻乎乎地一直发大包一直失败。2.3 为什么 ping 通不代表大包能通现在回到那个矛盾现象。你 ping PLC 的时候发的是 32 字节的小包加上各种头也就 60 字节左右远小于任何隧道的有效 MTU所以畅通无阻。但下载程序时TCP 会尝试发送 MSS最大报文段长度大小的数据通常是 1460 字节。这个包加上 TCP 头、IP 头正好 1500 字节到了隧道入口塞不进去被丢弃。TCP 有重传机制会重试几次但如果每次都失败最终就超时断开。更隐蔽的一种情况是TCP 三次握手能成功但数据传输阶段失败。因为握手包很小能过一旦开始传数据大包被丢连接就卡死。这解释了为什么有些工程师看到能连上就以为网络没问题结果下载到一半崩掉。这里有个经验判断如果 ping 通、能建立连接、但一传数据就断且断的位置每次都在差不多的进度那基本可以锁定是 MTU 问题而不是 PLC 或软件的问题。3. 一套可复现的 MTU 排查顺序3.1 第一步用带 DF 标志的 ping 探出真实 MTU这是整个排查里最关键的一步也是最容易被跳过的一步。普通 ping 探不出 MTU必须用禁止分片DF标志。原理是如果包的大小超过了路径 MTU且设置了 DF 标志那么路径上的设备就不能分片只能丢弃并返回错误。这样你就能通过逐步调整包大小找到那个刚好能过的临界值。Windows 下的命令是这样的ping -f -l 1472 192.168.1.10这里的-f是禁止分片-l 1472是数据载荷大小。为什么是 1472 而不是 1500因为 1472 8 字节 ICMP 头 20 字节 IP 头 1500。也就是说-l的值加上 28才是实际的 IP 包大小。如果返回需要拆分数据包但设置 DF说明 1472 太大了往下调。如果返回正常回复说明这个大小能过。我的习惯是从 1472 开始每次减 8直到能通为止。比如ping -f -l 1400 192.168.1.10 ping -f -l 1300 192.168.1.10 ping -f -l 1200 192.168.1.10找到能通的最大值后加上 28就是这条路径的实际 MTU。比如-l 1372能通那实际 MTU 就是 1400。Linux 下的命令略有不同ping -M do -s 1472 192.168.1.10-M do对应禁止分片-s指定包大小。逻辑完全一样。3.2 第二步区分是路径 MTU 小还是某一跳 MTU 小有时候你会发现从 A 点 ping PLC 能通的最大包和从 B 点 ping 能通的最大包不一样。这说明路径上不同位置的 MTU 不一致。这时候需要分段测试先 ping 隧道入口再 ping 隧道出口最后 ping PLC。每一段都测一遍最大可通包大小就能定位到是哪一段把 MTU 压低了。我遇到过一个案例办公室到现场路由器这一段 MTU 是 1500但现场路由器到 PLC 这一段因为中间有个老旧的交换机MTU 只有 1400。结果就是从办公室直接 ping PLC最大只能到 1400 左右但 ping 现场路由器本身能到 1472。这个差异直接指向了问题所在。3.3 第三步确认 ICMP 是否被拦截有一种情况会让上面的方法失效路径上的设备把 ICMP 全拦了包括需要分片的消息。这时候你用 DF ping 会一直失败但失败原因不是 MTU 小而是 ICMP 根本不通。怎么区分很简单先不加 DF 标志 ping 一下如果普通 ping 能通加 DF 就全挂那可能是 ICMP 被选择性拦截也可能是 MTU 问题。这时候需要换一种验证方式。可以用tracertWindows或tracerouteLinux配合不同包大小来探测。Windows 下tracert -f 1 -l 1472 192.168.1.10如果某一跳之后全部超时而那一跳之前正常说明问题出在那一跳之后。Linux 下可以用traceroute的-F参数禁止分片。3.4 第四步在 PLC 侧抓包确认如果条件允许在现场侧做一次抓包是最直接的证据。用科来或者 Wireshark过滤 ICMP 和 TCP。你会看到小包正常往返大包发出后没有回应或者收到 ICMP 需要分片但发送端没有调整。抓包能一锤定音避免在错误的方向上浪费时间。抓包时重点看两个东西一是大包是否真的发出去了二是是否有 ICMP 错误返回。如果大包发出去了但没回应且没有 ICMP 错误那基本就是路径上某处静默丢弃了大包MTU 问题坐实。4. 找到 MTU 之后怎么改才有效4.1 改哪里发送端、隧道端还是 PLC 端找到实际 MTU 之后下一步是决定在哪里改。这里有个原则优先在发送端改其次在隧道端改最后才考虑 PLC 端。原因是 PLC 作为工业设备它的网络参数往往不是随便能动的而且改了可能影响其他通信。发送端改 MTU 是最直接的。Windows 下可以用 netsh 命令netsh interface ipv4 set subinterface 以太网 mtu1400 storepersistent把以太网换成你实际使用的网卡名称。这个命令会把该网卡的 MTU 永久设为 1400。改完之后所有从这个网卡发出的包都会按 1400 来分片大包问题自然消失。Linux 下ip link set dev eth0 mtu 1400如果要永久生效需要写进配置文件不同发行版位置不一样。麒麟系统一般在/etc/sysconfig/network-scripts/ifcfg-eth0里加一行MTU1400CentOS 7 也是类似的位置。4.2 改 MTU 和改 MSS 的区别这里要澄清一个常见混淆MTU 是链路层的概念MSS 是 TCP 层的概念。改 MTU 会影响所有协议改 MSS 只影响 TCP。对于 PLC 下载这种 TCP 通信改 MSS 有时候更精准。Linux 下可以用 iptables 做 MSS 钳制iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu这条规则的意思是对所有转发的 TCP SYN 包把 MSS 自动钳制到路径 MTU 对应的值。这样发送端在握手时就会知道该用多大的 MSS从源头避免大包问题。Windows 下没有直接对应的命令但可以通过改 MTU 达到类似效果。因为 TCP 的 MSS 是根据 MTU 自动计算的MTU 改了MSS 自然跟着变。4.3 改完之后必须验证的三件事改完 MTU 不是就完事了必须验证三件事第一用 DF ping 确认新的 MTU 下大包能通。比如你设了 1400那就 ping-f -l 1372应该能通。第二实际做一次 PLC 程序下载看是否还断。这是最终验证不能省。第三观察一段时间确认没有引入新的问题。有时候 MTU 改小了虽然解决了大包问题但可能让某些依赖大包的应用变慢。不过对于 PLC 维护场景这点性能损失完全可以接受。我个人的习惯是改完 MTU 后至少做两次完整的下载测试中间间隔几分钟确认稳定性。因为有些 MTU 问题是间歇性的一次成功不代表次次成功。5. 那些年我在 MTU 上踩过的坑5.1 坑一以为 ping 通就万事大吉这是我早期最常犯的错误。看到 ping 通就排除了网络问题转头去折腾 PLC 的通信设置、编程软件的驱动、甚至重装软件。折腾半天问题依旧。后来才明白ping 通只是最低门槛真正的验证要用大包。这个坑的教训是排查顺序错了后面全是无用功。现在我遇到能 ping 通但连不上的问题第一反应就是测 MTU五分钟就能排除或确认效率完全不一样。5.2 坑二改了 MTU 但没改对地方有一次我在办公室的电脑上改了 MTU测试也通了但现场另一台电脑下载还是失败。后来发现现场那台电脑走的是另一条路径MTU 限制不一样。这提醒我MTU 是路径相关的不是设备相关的。同一条链路的不同端点可能因为路由不同而有不同的有效 MTU。所以改 MTU 之前一定要确认你改的是实际出问题的那条路径的发送端。如果有多条路径每条都要单独测、单独改。5.3 坑三忽略了 ICMP 被拦截的情况有一次用 DF ping 怎么都不通我以为 MTU 小到离谱结果发现是路径上的防火墙把 ICMP 全拦了。这种情况下DF ping 的结果完全不可信。后来我改用 TCP 层的方法验证用telnet或nc连 PLC 的端口看能不能建立连接再传一些数据看会不会断。Linux 下可以用nc测试nc -v 192.168.1.10 102102 是西门子 PLC 常用的 ISO-TSAP 端口。如果连接能建立但传数据就断结合前面的分析基本能确认是 MTU 问题。5.4 坑四MTU 改得太小有人一发现 MTU 问题就干脆把 MTU 改成 1200 甚至 1000觉得小一点总没错。这确实能解决大包问题但会带来新问题包变小了同样的数据需要更多的包来传传输效率下降下载时间变长。而且有些应用对 MTU 有下限要求改太小可能导致其他异常。我的建议是找到实际能通的最大值然后留 20-40 字节的余量。比如实测 1400 能通那就设 1380 或 1360。留余量是因为网络状况可能变化留点缓冲更稳。5.5 坑五忘了 PLC 侧也可能有 MTU 限制虽然大多数时候问题出在发送端或隧道端但 PLC 侧也不是完全无辜。有些 PLC 的网口 MTU 是可配的如果被设成了很小的值也会导致大包过不去。这种情况比较少见但如果前面都排查完了还是不行值得去 PLC 的网络设置里看一眼。6. 把 MTU 排查固化成流程6.1 一张排查顺序表我把整个排查过程整理成一张表方便你按顺序执行步骤操作判断依据下一步1普通 ping PLC通/不通不通先查基础网络2DF ping 逐步减小包找到最大可通包算出实际 MTU3分段 DF ping定位瓶颈段确定改哪里4抓包确认看大包是否被丢坐实 MTU 问题5改发送端 MTU设为实测值减余量验证6实际下载测试成功/失败失败回到步骤 2这张表的价值在于它把凭感觉排查变成了按流程排查。每一步都有明确的判断依据和下一步动作不会卡在某个环节反复试错。6.2 几个能省时间的命令除了前面提到的 ping 和 netsh还有几个命令在排查时很有用查看当前网卡 MTUnetsh interface ipv4 show subinterfacesLinux 下ip link show查看路由表确认走的是哪条路径route printLinux 下ip route show这些命令能帮你快速了解当前的网络配置避免在错误的前提上做判断。6.3 什么时候该放弃 MTU 方向虽然 MTU 是这类问题的头号嫌疑但也不是唯一可能。如果 DF ping 显示大包能通实际下载还是失败那就要考虑其他方向了比如 PLC 的连接数限制、编程软件的版本兼容性、防火墙的应用层策略等。这时候 MTU 排查的结论大包能通本身就是一个有价值的信息它帮你排除了一个方向让你能集中精力查别的。我一般给自己设一个时间盒MTU 排查不超过 30 分钟。如果 30 分钟内没找到明确的 MTU 证据就暂时放下转去查其他方向。因为 MTU 问题的特征是小包通大包挂如果这个特征不明显硬磕 MTU 就是浪费时间。7. 远程维护场景下的额外注意事项7.1 远程通道本身的稳定性远程维护和现场维护最大的区别是中间多了一条不受你控制的通道。这条通道的 MTU 可能随时变化比如运营商调整了线路、隧道软件更新了协议、中间某台设备重启了。所以远程维护时MTU 问题可能不是一次性的而是反复出现的。我的做法是在第一次排查出 MTU 值之后把它记下来写进维护文档。下次再遇到类似问题直接从那个值开始测能省不少时间。如果发现 MTU 值变了说明通道有变动需要重新评估。7.2 不同编程软件的差异不同 PLC 编程软件对 MTU 的敏感度不一样。有的软件在 MTU 不够时会自动重试并调整包大小表现是慢但能成有的软件直接报错断开表现是完全不行。所以同样的 MTU 问题在不同软件上表现可能不同。排查时不要因为换个软件就好了就以为问题解决了那只是软件容错能力不同根因还在。7.3 安全策略与 MTU 的交互有些安全策略会主动拦截 ICMP包括需要分片的消息。这种情况下即使 MTU 有问题发送端也收不到反馈表现就是莫名其妙地断。这时候需要在安全策略上放行 ICMP 类型 3 代码 4需要分片但设置了 DF或者直接在发送端把 MTU 改小绕过这个问题。注意放行 ICMP 需要评估安全影响不是所有环境都适合。如果安全要求高优先选择改 MTU 的方案。8. 我个人的经验收尾这套 MTU 排查方法我从第一次踩坑到现在用了好几年基本上每次遇到ping 通但下载失败都能在半小时内定位。最深的体会是网络排查最怕的不是问题难而是方向错。ping 通这个假象太容易让人跑偏把时间浪费在 PLC 和软件上。如果你只记一件事就记这个遇到能 ping 通但连不上/传不了数据先测带 DF 标志的大包 ping。这一个动作就能帮你排除掉一大半的可能性。剩下的按我上面那张表一步步走基本都能找到答案。最后分享一个小技巧在远程维护的电脑上把常用的 MTU 测试命令做成一个批处理脚本一键执行自动从 1472 往下试到 1200把能通的最大值打印出来。这样每次遇到问题双击一下几秒钟就知道结果比手动一条条敲命令快得多。这个脚本我用了两年多省下的时间相当可观。