MTU 修改是否会影响两个方向？
ifconfig 1.2.3.4 mtu 1492
这会将传入、传出数据包或两者的 MTU 设置为 1492？我认为这仅适用于传入
ifconfig 1.2.3.4 mtu 1492
This will set MTU to 1492 for incoming, outgoing packets or both? I think it is only for incoming
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
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 调制解调器，它会拒绝该数据包，并回复一条互联网控制 (ICMP) 消息，通知我们数据包太大。然后我们会用较小的数据包重试传输。这称为路径 MTU 发现。类似地，在 TCP 层的下一层，避免分段的另一个因素是 MSS（最大分段大小）选项，其中两台主机均回复它们可以在不分段的情况下传输的最大大小的数据包。这通常是根据 MTU 计算得出的。
当配置错误的防火墙丢弃所有 ICMP 流量时，就会出现问题。当您连接到（例如）Web 服务器时，您会构建一个 TCP 会话并发送您愿意根据 1500 字节 MTU 接受 TCP 数据包的消息（因为您通过以太网连接到路由器。）服务器想要向您发送大量数据，它们会将其分割成块（与 TCP 和 IP 标头结合使用时），形成 1500 字节的有效负载并将其发送给您。您的 ISP 会收到其中之一，然后尝试将其包装到 PPPoE 数据包中以发送到您的 ADSL 调制解调器，但它太大而无法发送。因此，它会回复 ICMP 无法访问，这将（在完美的情况下）导致远程计算机缩小其用于连接的 MSS 并重新传输。然而，如果防火墙损坏，外部 Web 服务器将永远无法到达此 ICMP 消息，并且此数据包将永远不会到达您的手中。
最终，在以太网设备上设置 MTU 有助于将正确大小的帧发送到 ADSL 调制解调器（以避免它要求您使用较小的帧重新传输），但在构建 TCP 时影响发送到远程主机的 MSS 大小至关重要连接。
TLDR: Both. It will only transmit packets with a payload length less than or equal to that size. Similarly, it will only accept packets with a payload length within your MTU. If a device sends a larger packet, it should respond with an ICMP unreachable (oversized) message.
The nitty gritty:
Tuning the MTU for your device is useful because other hops between you and your destination may encapsulate your packet in another form (for example, a VPN or PPPoE.) This layer around your packet results in a bigger packet being sent along the wire. If this new, larger packet exceeds the maximum size of the layer, then the packet will be split into multiple packets (in a perfect world) or will be dropped entirely (in the real world.)
As a practical example, consider having a computer connected over ethernet to an ADSL modem that speaks PPPoE to an ISP. Ethernet allows for a 1500 byte payload, of which 8 bytes will be used by PPPoE. Now we're down to 1492 bytes that can be delivered in a single packet to your ISP. If you were to send a full-size ethernet payload of 1500 bytes, it would get "fragmented" by your router and split into two packets (one with a 1492 byte payload, the other with an 8 byte payload.)
The problem comes when you want to send more data over this connection - lets say you wanted to send 3000 bytes: your computer would split this up based on your MTU - in this case, two packets of 1500 bytes each, and send them to your ADSL modem which would then split them up so that it can fulfill its MTU. Now your 3000 byte data has been fragmented into four packets: two with a payload of 1492 bytes and two with a payload of 8 bytes. This is obviously inefficient, we really only need three packets to send this data. Had your computer been configured with the correct MTU for the network, it would have sent this as three packets in the first place (two 1492 byte packets and one 16 byte packet.)
To avoid this inefficiency, many IP stacks flip a bit in the IP header called "Don't Fragment." In this case, we would have sent our first 1500 byte packet to the ADSL modem and it would have rejected the packet, replying with an Internet Control (ICMP) message informing us that our packet is too large. We then would have retried the transmission with a smaller packet. This is called Path MTU discovery. Similarly, a layer below, at the TCP layer, another factor in avoiding fragmentation is the MSS (Maximum Segment Size) option where both hosts reply with the maximum size packet they can transfer without fragmenting. This is typically computed from the MTU.
The problem here arises when misconfigured firewalls drop all ICMP traffic. When you connect to (say) a web server, you build a TCP session and send that you're willing to accept TCP packets based on your 1500 byte MTU (since you're connected over ethernet to your router.) If the foreign web server wanted to send you a lot of data, they would split this into chunks that (when combined with the TCP and IP headers) came out to 1500 byte payloads and send them to you. Your ISP would receive one of these and then try to wrap it into a PPPoE packet to send to your ADSL modem, but it would be too large to send. So it would reply with an ICMP unreachable, which would (in a perfect world) cause the remote computer to downsize its MSS for the connection and retransmit. If there was a broken firewall in the way, however, this ICMP message would never be reached by the foreign web server and this packet would never make it to you.
Ultimately setting your MTU on your ethernet device is desirable to send the right size frames to your ADSL modem (to avoid it asking you to retransmit with a smaller frame), but it's critical to influence the MSS size you send to remote hosts when building TCP connections.
ifconfig ... mtu设置从接口发送的第 2 层有效负载的 MTU，并将拒绝在此接口上接收的较大第 2 层有效负载。您必须确保以太网链路两侧的 MTU 匹配；您不应该在同一个以太网广播域中的任何地方使用不匹配的MTU值。请注意，以太网标头不包含在您设置的 MTU 中。另外，
ifconfig已经在 Linux 中很久没有维护了，并且是 旧且已弃用；遗憾的是 Linux 发行版仍然包含它，因为它们害怕破坏旧脚本。这对于鼓励人们继续使用它具有非常负面的影响。您应该使用iproute2系列命令：ifconfig ... mtu <value>sets the MTU for layer2 payloads sent out the interface, and will reject larger layer2 payloads received on this interface. You must ensure your MTU matches on both sides of an ethernet link; you should not have mismatched mtu values anywhere in the same ethernet broadcast domain. Note that the ethernet headers are not included in the MTU you are setting.Also,
ifconfighas not been maintained in linux for ages and is old and deprecated; sadly linux distributions still include it because they're afraid of breaking old scripts. This has the very negative effect of encouraging people to continue using it. You should be using theiproute2family of commands:根据接口 MTU 大小，可能会丢弃较大的传入数据包。
例如，默认 MTU 1500
Linux 2.6 CentOS（使用以太网控制器进行测试：Intel Corporation 80003ES2LAN 千兆位以太网控制器（铜）（修订版 01））
丢弃巨型数据包 >1504。 ifconfig 中出现错误，并且 ethtool -S 输出中有 rx_long_length_errors 指示。
增加 MTU 表示应支持巨型数据包。
何时因数据包大小太大而丢弃数据包的阈值似乎取决于 MTU（-4096、-8192 等）
Oren
Large incoming packets may be dropped based on the interface MTU size.
For example, the default MTU 1500 on
Linux 2.6 CentOS (tested with Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01))
drops Jumbo packets >1504. Errors appear in ifconfig and there are rx_long_length_errors indications for this in ethtool -S output.
Increasing MTU indicates Jumbo packets should be supported.
The threshold for when to drop packets based on their size being too large appears to depend on MTU (-4096, -8192, etc.)
Oren
毫无疑问，ifconfig 配置的 MTU 会影响 Tx ip 碎片，我没有更多评论。
但对于 Rx 方向，我发现该参数是否会影响传入的 IP 数据包，这取决于情况。不同的制造商表现不同。
我测试了手头的所有设备，发现以下3种情况。
测试用例：
在 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 时，在 ICMP_SIZE=1476 时 ping 成功，在 ICMP_SIZE=1477 及以上时 ping 失败。似乎有一个实用的MTU=1504（20B（IP头）+8B（ICMP头）+1476B（ICMP数据））。
当 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 时，在 ICMP_SIZE=1476 时 ping 成功，在 ICMP_SIZE=1477 及以上时失败。
当 MTU_SIZE=1490 时，ICMP_SIZE=1466 时 ping 成功，ICMP_SIZE=1467 及以上时 ping 失败。
当 MTU_SIZE=1501 时，ICMP_SIZE=1477 时 ping 成功，ICMP_SIZE=1478 及以上时 ping 失败。
当 MTU_SIZE=500 时，ICMP_SIZE=476 时 ping 成功，ICMP_SIZE=477 及以上时 ping 失败。
当 MTU_SIZE=1900 时，ICMP_SIZE=1876 时 ping 成功，ICMP_SIZE=1877 及以上时 ping 失败。
这种情况的行为与 Edward Thomson 所说的完全一样，只是在我的测试中 PRACTICAL MTU=MTU_SIZE+4。
情况 3：
设备 1 = Linux 4.4.50，带 Raspberry Pi 2 模块 B ETH：
当 MTU_SIZE=1500 时，在 ICMP_SIZE=1472 时 ping 成功，在 ICMP_SIZE=1473 及以上时 ping 失败。因此，实际 MTU=1500（20B（IP 标头）+8B（ICMP 标头）+1472B（ICMP 数据））在那里工作。
当 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 在为什么 MTU 配置不'中所说的完全相同接收方向生效吗？。
总而言之，在现实世界中，设置 ifconfig mtu 后，
有时，无论您设置什么 MTU 值（启用巨型帧除外），Rx IP 数据包在超过 1504 时都会被丢弃。
有时，当超过您在接收设备上设置的 MTU+4 时，Rx IP 数据包会被丢弃。
有时，当超过时，Rx IP 数据包会被丢弃1500，无论你设置什么MTU值。
……
There is no doubt that MTU configured by ifconfig impacts Tx ip fragmentation, I have no more comments.
But for Rx direction, I find whether the parameter impacts incoming IP packets, it depends. Different manufacturer behaves differently.
I tested all the devices on hand and found 3 cases below.
Test case:
On Device0 ping 192.168.225.34 -s ICMP_SIZE,
Checking how MTU_SIZE impacts Rx of Device1.
case 1:
Device1 = Linux 4.4.0 with Intel I218-LM:
When MTU_SIZE=1500, ping succeeds at ICMP_SIZE=1476, fails at ICMP_SIZE=1477 and above. It seems that there is a PRACTICAL MTU=1504 (20B(IP header)+8B(ICMP header)+1476B(ICMP data)).
When MTU_SIZE=1490, ping succeeds at ICMP_SIZE=1476, fails at ICMP_SIZE=1477 and above, behave the same as MTU_SIZE=1500.
When MTU_SIZE=1501, ping succeeds at ICMP_SIZE=1476, 1478, 1600, 1900. It seems that jumbo frame is switched on once MTU_SIZE is set >1500 and there is no 1504 restriction any more.
case 2:
Device1 = Linux 3.18.31 with Qualcomm Atheros AR8151 v2.0 Gigabit Ethernet:
When MTU_SIZE=1500, ping succeeds at ICMP_SIZE=1476, fails at ICMP_SIZE=1477 and above.
When MTU_SIZE=1490, ping succeeds at ICMP_SIZE=1466, fails at ICMP_SIZE=1467 and above.
When MTU_SIZE=1501, ping succeeds at ICMP_SIZE=1477, fails at ICMP_SIZE=1478 and above.
When MTU_SIZE=500, ping succeeds at ICMP_SIZE=476, fails at ICMP_SIZE=477 and above.
When MTU_SIZE=1900, ping succeeds at ICMP_SIZE=1876, fails at ICMP_SIZE=1877 and above.
This case behaves exactly as Edward Thomson said, except that in my test the PRACTICAL MTU=MTU_SIZE+4.
case 3:
Device1 = Linux 4.4.50 with Raspberry Pi 2 Module B ETH:
When MTU_SIZE=1500, ping succeeds at ICMP_SIZE=1472, fails at ICMP_SIZE=1473 and above. So there is a PRACTICAL MTU=1500 (20B(IP header)+8B(ICMP header)+1472B(ICMP data)) working there.
When MTU_SIZE=1490, behave the same as MTU_SIZE=1500.
When MTU_SIZE=1501, behave the same as MTU_SIZE=1500.
When MTU_SIZE=2000, behave the same as MTU_SIZE=1500.
When MTU_SIZE=500, behave the same as MTU_SIZE=1500.
This case behaves exactly as Ron Maupin said in Why MTU configuration doesn't take effect on receiving direction?.
To sum it all, in real world, after you set ifconfig mtu,
sometimes the Rx IP packts get dropped when exceed 1504 , no matter what MTU value you set (except that the jumbo frame is enabled).
sometimes the Rx IP packts get dropped when exceed the MTU+4 you set on receiving device.
sometimes the Rx IP packts get dropped when exceed 1500, no matter what MTU value you set.
... ...
它是最大传输单元，因此它明确设置了传出最大数据包大小。我不确定是否会拒绝大于 MTU 的传入数据包。
It's the Maximum Transmission Unit, so it definitely sets the outgoing maximum packet size. I'm not sure if will reject incoming packets larger than the MTU.