巨帧为何会黑洞？MTU怎么统一？是否合适局域网

巨帧配置在存储和虚拟化网络里很常见，但它最难排的故障不是完全不通，而是业务偶尔卡死、重传升高、抓包却只看到零散超时，这就是典型的MTU黑洞。

边缘最大传输单元失配是黑洞的第一来源。服务器网卡、虚拟交换机、物理交换机和中间安全设备只要有一段仍停在一千五百字节，而源主机已经按九千字节发送，超出链路承载能力的报文就会在途中被直接丢弃。二层交换设备不会像老式三层设备那样主动替你“补救”，它只能丢。更隐蔽的是，某些宿主机网卡启用了大包卸载，主机侧抓包看到的仍像是正常大帧，实际在线缆上的分段方式却不同，导致运维误以为路径没有问题。巨帧能否成立的前提是整条二层与服务链路径都统一，包括虚拟交换机、电机控制器和旁路防火墙。若中间还经过负载均衡或安全探针，这些设备自己的虚接口也必须跟着统一，否则错误会只在经过服务链的流量上出现。只核对交换机端口而忽略宿主机内的虚拟交换结构，往往会把问题遗漏在最靠近业务的一跳。

即便路径中有人能检测到超大报文，路径最大传输单元探测被拦截后，发送端也不一定会把包缩小。很多系统依赖“需要分片但禁止分片”的控制报文反馈，再调整报文尺寸。如果安全策略默认丢弃这类反馈，源端就会持续发送过大的报文，表现为连接建立后卡在大对象传输阶段，小包命令和心跳却完全正常。叠加虚拟扩展局域网、通用路由封装或加密隧道时，额外开销会进一步压缩可用MTU，使原本在纯二层内能跑的巨帧，跨一层虚拟化边界后立刻失效。很多人只在服务器网卡上改巨帧，却忘了同步调整传输控制最大报文段钳制和安全设备策略，结果应用层超时比链路层告警先出现。工程上，巨帧不该按“最大值”拍脑袋统一，而要按最窄路径倒推，并允许必要的控制报文类型穿越。

MTU问题的本质是边界不一致。巨帧只适合全路径都可控的局域网，一旦中间夹了默认一千五百字节或屏蔽探测的设备，黑洞就比吞吐收益更先出现。