MTU 与巨型帧

MTU（最大传输单元，Maximum Transmission Unit）改错是排查成本最高的网络问题之一：小包能通、ping 也通，但大文件传输卡死或极慢——因为症状不是「断网」，而是「部分数据传不过去」。这篇讲清楚什么时候要调它，以及怎么改才安全。

改 MTU 前必须先有退路

调大 MTU 需要网络链路上的每一段都支持同样的值，改错会导致大包丢弃、连接卡死甚至看起来像失联。开始前确认你有以下至少一条退路：物理控制台、IPMI/BMC，或者机器就在手边。失联后的自救步骤见改静态 IP 与失联自救。

MTU 是什么，为什么要关心它

MTU 是一个网络接口一次能发送的最大数据包大小（不含帧头），以太网的默认值是 1500 字节。巨型帧（Jumbo Frame）通常指把它调大到 9000 字节，好处是同样大小的文件需要传输的包数量变少，包头开销占比下降，对高吞吐的存储和虚拟化迁移网络有实际收益。

对大多数人的场景，默认的 1500 已经够用，调大 MTU 只在下面这些场景才值得做：

宿主机之间跑 NFS、iSCSI、Ceph 的存储网络，追求吞吐。
集群节点之间的迁移网络，经常搬运大内存镜像。
你的交换机、网卡都明确支持巨型帧，而且是一段专用的物理网络，不和普通上网流量混在一起。

面向公网或普通内网的接口，不要碰它

连接家用路由器、光猫的接口几乎不需要调 MTU，改了反而可能和上级设备不一致导致连不上。MTU 调整只在你自己完全控制的、两端设备都确认支持的链路上才有意义。

开始之前

最关键的前提：链路上的每一环都要用同一个 MTU。 这包括：

参与的物理网卡。
中间的交换机端口（很多消费级交换机不支持巨型帧，或者默认关闭）。
Linux Bridge / Bond / VLAN 接口本身。
客户机里的虚拟网卡。

任何一环没跟上，大包就会被丢弃或强制分片，症状是「小包正常、大包卡死」。

# 宿主机 shell，备份当前配置
cp /etc/network/interfaces /root/interfaces.bak

操作步骤

第一步：确认交换机支持

先查交换机管理界面或说明书，确认对应端口开启了巨型帧支持，并设置成不小于你打算用的 MTU。这一步在软件层面做不到，必须去交换机上确认。

第二步：在接口上设置 MTU

在物理网卡上直接设置：

text

auto eno1
iface eno1 inet manual
        mtu 9000

如果 MTU 是设在参与 Bond 或网桥的物理网卡上，网桥通常会自动继承成员接口里最小的 MTU，但稳妥的做法是在网桥自身也显式声明，避免不同版本行为不一致：

text

auto vmbr1
iface vmbr1 inet static
        address 10.10.10.2/24
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        mtu 9000

VLAN 接口、Bond 接口的写法类似，都是加一行 mtu 9000。

检查语法再应用

ifup --no-act vmbr1

确认没有报错再执行 ifreload -a。当前 SSH 会话如果走的正是这个接口，可能会短暂中断。

第三步：客户机虚拟网卡也要跟上

如果这个网络是给客户机用的（不只是宿主机之间的存储网络），客户机的虚拟网卡和其内部操作系统的接口 MTU 也要设成一致的值。在客户机内部：

# 客户机内部（Linux 示例）
ip link set dev eth0 mtu 9000

Windows 客户机在网络适配器的高级属性里有类似的 Jumbo Frame 选项，取决于 VirtIO 驱动版本。

特殊情况：SDN 隧道的额外开销

如果这个网络之上还叠加了 VXLAN 或 QinQ 这类封装（见 SDN Zone 实战），封装本身会占用额外字节，内层 MTU 要相应调小：

封装方式	额外开销	举例
QinQ（双层 VLAN）	4 字节	物理链路 1500 时，内层配 1496
VXLAN	50 字节	物理链路 1500 时，内层配 1450

检查结果

最可靠的验证方法是用「禁止分片」的 ping，直接测出实际能通过的最大包大小：

# 宿主机 shell，-M do 表示禁止分片，-s 后面是负载大小（不含 28 字节的 IP+ICMP 头）
ping -M do -s 8972 10.10.10.1

# 如果上面失败，逐步调小负载大小定位实际支持的 MTU
ping -M do -s 1472 10.10.10.1

8972 = 9000 - 28，能通说明链路整段都支持 9000 的 MTU。如果 -s 8972 失败但 -s 1472 成功，说明链路中某一环还停留在 1500，需要回去逐段排查。

# 确认接口实际生效的 MTU
ip link show vmbr1

再做一次真实的大文件传输测试（比如 scp 一个几 GB 的文件，或跑一次存储上的读写基准），确认吞吐确实有提升，而不是配完就假设生效。

常见问题

改完之后 ping 通，但文件传输卡在某个进度不动。 典型的 MTU 不一致症状：小包（ping 默认 56 字节）能过，大包在中间某一跳被丢弃且没有正确返回「需要分片」的 ICMP 消息（常见于消费级设备关闭了 PMTUD）。用上面 ping -M do -s 的方法逐段定位。

只改了宿主机，客户机里没改。 客户机网卡的 MTU 独立于宿主机网桥，不会自动继承，需要在客户机操作系统内部单独设置。

改完 SSH 直接断了，而且改小了都连不上。 说明这条链路本来就不支持你设的值，先用改静态 IP 与失联自救里的退路（物理控制台、IPMI）改回 1500，确认恢复后再重新排查交换机配置。

VXLAN 网络里，大包传不过去但小包正常。 检查内层网络的 MTU 是否已经按封装开销减去了 50 字节，这是 VXLAN 场景最容易漏掉的一步。

MTU 与巨型帧 ​

MTU 是什么，为什么要关心它 ​

开始之前 ​

操作步骤 ​

第一步：确认交换机支持 ​

第二步：在接口上设置 MTU ​

第三步：客户机虚拟网卡也要跟上 ​

特殊情况：SDN 隧道的额外开销 ​

检查结果 ​

常见问题 ​

延伸阅读 ​