MTU 修改会影响两个方向吗？答案

【问题标题】：Do MTU modifications impact both directions?MTU 修改会影响两个方向吗？
【发布时间】：2011-06-15 16:18:54
【问题描述】：

ifconfig 1.2.3.4 mtu 1492

这会将传入、传出数据包或两者的 MTU 设置为 1492？我认为它只适用于传入

【问题讨论】：

程序员如何将此问题标记为题外话，真是令人惊讶。 MTU 大小对于编程中的许多事情都非常重要，并且知道它是如何工作的，以及为什么会这样工作，我认为这非常好。但是大多数程序员使用设计模式编写抽象的东西，甚至不愿意理解这些东西是如何工作的。这个问题不是关于如何做汤或煮鸡，这是关于我们程序员每天处理的事情，它怎么可能是题外话？

【解决方案1】：

TLDR：两者。它只会传输有效载荷长度小于或等于该大小的数据包。同样，它只会接受在您的 MTU 内具有有效负载长度的数据包。如果设备发送更大的数据包，它应该以 ICMP 不可达（超大）消息进行响应。

细节： 为您的设备调整 MTU 很有用，因为您和目的地之间的其他跃点可能会以另一种形式封装您的数据包（例如，VPN 或 PPPoE）。数据包周围的这一层会导致沿线路发送更大的数据包。如果这个新的、更大的数据包超过了层的最大大小，那么该数据包将被分成多个数据包（在理想世界中）或将被完全丢弃（在现实世界中）。

作为一个实际示例，请考虑将计算机通过以太网连接到 ADSL 调制解调器，该调制解调器向 ISP 提供 PPPoE。以太网允许 1500 字节的有效负载，其中 8 个字节将由 PPPoE 使用。现在我们减少到 1492 字节，可以在单个数据包中传送给您的 ISP。如果您要发送 1500 字节的全尺寸以太网负载，它会被您的路由器“分段”并分成两个数据包（一个具有 1492 字节的负载，另一个具有 8 字节的负载。）

当您想通过此连接发送更多数据时，问题就出现了 - 假设您想发送 3000 字节：您的计算机会根据您的 MTU 将其拆分 - 在这种情况下，两个数据包每个 1500 字节，然后发送它们连接到您的 ADSL 调制解调器，然后将它们拆分，以便它可以实现其 MTU。现在，您的 3000 字节数据已被分成四个数据包：两个有效负载为 1492 字节，两个有效负载为 8 字节。这显然是低效的，我们真的只需要三个数据包来发送这个数据。如果您的计算机为网络配置了正确的 MTU，它首先会以三个数据包的形式发送（两个 1492 字节数据包和一个 16 字节数据包。）

为避免这种低效率，许多 IP 堆栈在称为“不要分片”的 IP 标头中翻转一点。在这种情况下，我们会将第一个 1500 字节的数据包发送到 ADSL 调制解调器，它会拒绝该数据包，并回复一个 Internet 控制 (ICMP) 消息，通知我们我们的数据包太大。然后，我们将使用较小的数据包重试传输。这称为路径 MTU 发现。类似地，在 TCP 层的下一层，避免分段的另一个因素是 MSS（最大分段大小）选项，在该选项中，两个主机都以它们可以在不分段的情况下传输的最大大小的数据包进行回复。这通常是根据 MTU 计算得出的。

当配置错误的防火墙丢弃所有 ICMP 流量时，就会出现问题。当你连接到（比如说）一个网络服务器时，你建立一个 TCP 会话并发送你愿意接受基于你的 1500 字节 MTU 的 TCP 数据包（因为你通过以太网连接到你的路由器。）如果外国网络服务器想要向您发送大量数据，他们会将其拆分成块（当与 TCP 和 IP 标头结合时）产生 1500 字节的有效负载并将它们发送给您。您的 ISP 会收到其中一个，然后尝试将其包装成一个 PPPoE 数据包发送到您的 ADSL 调制解调器，但它太大而无法发送。所以它会回复一个 ICMP 不可达，这将（在一个完美的世界中）导致远程计算机缩小其 MSS 以进行连接并重新传输。但是，如果防火墙被破坏，则外部 Web 服务器将永远无法访问此 ICMP 消息，并且此数据包将永远无法发送给您。

最终在您的以太网设备上设置 MTU 以向您的 ADSL 调制解调器发送正确大小的帧（以避免它要求您使用较小的帧重新传输），但影响您发送到远程主机的 MSS 大小至关重要建立 TCP 连接时。

【讨论】：

我还想知道 MTU 是否实际传输到下一跳，或者总是只是使用 ICMP 错误计算。如果是显式传输，使用哪种协议？
MTU 仅来自连接层（即以太网帧为 1500 字节），然后根据 ICMP 错误进行更新（路径 MTU 发现。）
ICMP frag-needed 可能包括所需的 MTU。
在我的系统上，超大的传入数据包被硬件丢弃，它不会出现在/proc/net/snmp、ip -d -s link 中，也不会发送 ICMP 消息。只有ethtool -S 显示驱动程序ixgbe 3.19 的rx_long_length_errors。

【解决方案2】：

ifconfig ... mtu <value> 设置从接口发出的第 2 层有效负载的 MTU，并拒绝在此接口上接收到的较大的第 2 层有效负载。您必须确保您的 MTU 在以太网链路的两侧匹配；你不应该在同一个ethernet broadcast domain 的任何地方都有不匹配的mtu 值。请注意，以太网标头不包含在您设置的 MTU 中。

另外，ifconfig 已经很久没有在 linux 中维护了，现在是 old and deprecated;遗憾的是，Linux 发行版仍然包含它，因为它们害怕破坏旧脚本。这对鼓励人们继续使用它具有非常负面的影响。您应该使用iproute2 系列命令：

[mpenning@hotcoffee ~]$ sudo ip link set mtu 1492 eth0
[mpenning@hotcoffee ~]$ ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1492 qdisc mq state UP qlen 1000
    link/ether 00:1e:c9:cd:46:c8 brd ff:ff:ff:ff:ff:ff
[mpenning@hotcoffee ~]$

【讨论】：

【解决方案3】：

根据接口 MTU 大小，可能会丢弃较大的传入数据包。

例如，默认 MTU 1500 开启 Linux 2.6 CentOS（使用以太网控制器测试：Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01)）丢弃巨型数据包> 1504。 ifconfig 中出现错误，并且在 ethtool -S 输出中有 rx_long_length_errors 指示。增加 MTU 表示应支持巨型数据包。基于大小过大而丢弃数据包的时间阈值似乎取决于 MTU（-4096、-8192 等）

奥伦

【讨论】：

【解决方案4】：

它是最大传输单元，所以它肯定设置了传出的最大数据包大小。我不确定是否会拒绝大于 MTU 的传入数据包。

【讨论】：

【解决方案5】：

毫无疑问，ifconfig配置的MTU会影响Tx ip碎片，我没有更多的cmets。

但是对于 Rx 方向，我发现参数是否影响传入的 IP 数据包，这取决于。不同的制造商表现不同。我测试了手头的所有设备，发现以下3个案例。

测试用例：

Device0 eth0 (192.168.225.1, mtu 2000)Device1 eth0 (192.168.225.34, mtu MTU_SIZE)

在 Device0 上 ping 192.168.225.34 -s ICMP_SIZE，检查 MTU_SIZE 如何影响 Device1 的 Rx。

案例1：

Device1 = 带有 Intel I218-LM 的 Linux 4.4.0：

当 MTU_SIZE=1500 时，ping 在 ICMP_SIZE=1476 时成功，在 ICMP_SIZE=1477 及以上时失败。好像有个PRACTICAL MTU=1504 (20B(IP header)+8B(ICMP header)+1476B(ICMP data))。

当 MTU_SIZE=1490 时，在 ICMP_SIZE=1476 时 ping 成功，在 ICMP_SIZE=1477 及以上时失败，行为与 MTU_SIZE=1500 相同。

当 MTU_SIZE=1501 时，在 ICMP_SIZE=1476、1478、1600、1900 时 ping 成功。似乎将 MTU_SIZE 设置为 >1500 后开启巨型帧，不再有 1504 限制。

案例2：

Device1 = Linux 3.18.31 和 Qualcomm Atheros AR8151 v2.0 千兆以太网：

当 MTU_SIZE=1500 时，ping 在 ICMP_SIZE=1476 时成功，在 ICMP_SIZE=1477 及以上时失败。

当 MTU_SIZE=1490 时，ping 在 ICMP_SIZE=1466 时成功，在 ICMP_SIZE=1467 及以上时失败。

当 MTU_SIZE=1501 时，ping 在 ICMP_SIZE=1477 时成功，在 ICMP_SIZE=1478 及以上时失败。

当 MTU_SIZE=500 时，ping 在 ICMP_SIZE=476 时成功，在 ICMP_SIZE=477 及以上时失败。

当 MTU_SIZE=1900 时，ping 在 ICMP_SIZE=1876 时成功，在 ICMP_SIZE=1877 及以上时失败。

这个案例的行为与 Edward Thomson 所说的完全一样，只是在我的测试中 PRACTICAL MTU=MTU_SIZE+4。

案例 3：

Device1 = Linux 4.4.50 with Raspberry Pi 2 Module B ETH：

当 MTU_SIZE=1500 时，ping 在 ICMP_SIZE=1472 时成功，在 ICMP_SIZE=1473 及以上时失败。所以有一个 PRACTICAL MTU=1500 (20B(IP header)+8B(ICMP header)+1472B(ICMP data)) 在那里工作。

当 MTU_SIZE=1490 时，行为与 MTU_SIZE=1500 相同。

当 MTU_SIZE=1501 时，行为与 MTU_SIZE=1500 相同。

当 MTU_SIZE=2000 时，行为与 MTU_SIZE=1500 相同。

当 MTU_SIZE=500 时，行为与 MTU_SIZE=1500 相同。

这个案例的行为与 Ron Maupin 在Why MTU configuration doesn't take effect on receiving direction? 中所说的完全一样。

总而言之，在现实世界中，设置 ifconfig mtu 后，

Rx IP 包有时会在超过 1504 时被丢弃，无论您设置什么 MTU 值（启用巨型帧除外）。

有时，当超过您在接收设备上设置的 MTU+4 时，Rx IP 包会被丢弃。

Rx IP 包有时会在超过 1500 时被丢弃，无论您设置什么 MTU 值。

... ...

【讨论】：