关于机器和交换机中的 MTU 设置

Question

假设我有两台机器和一台交换机。

M1--开关--M2。

设置是：

• M1 将 MTU 设置为 100
• 交换机的 MTU 设置为 1000
• M2 的 MTU 设置为 1000。

问题：

1. 当M1尝试向M2发送一个100字节的数据包时，应该没有问题吧？

2. 当 M2 尝试向 M1 发送 1000 字节的数据包时，有什么问题吗？

3. M2 可以发送一个 1000 字节的数据包给 Switch，但是当 Switch 尝试将数据包发送给 M1 时，它需要将数据包分成 10 个小数据包。那正确吗？

更新：

更现实一点：M1、Switch 和 M2 都运行在 10G 网络上，我们使用 IPv4。

设置是：

• M1 将 MTU 设置为 1500

• 交换机的 MTU 设置为 9000

• M2 将 MTU 设置为 9000

它有助于回答这个问题吗？

Answer 1

您没有具体说明您在谈论什么网络技术，所以我将假设以太网和 IP[v4]。

以太网一直将其可接受的有效载荷长度范围定义为 46 到 1500 字节，并要求 LAN 上的所有设备（主机和交换机）能够接收具有 1500 字节有效载荷的帧。因此，以太网不提供分段机制，也不提供用于在设备之间通信或协商 MTU（或更重要的是，M R Us——最大接收单元）的机制。事实上，术语“MTU”或“最大传输单元”并未出现在 IEEE 802.3 规范中的任何地方。

所以让我们在图片中添加IP。IP 有一个 MTU 的概念，大多数现代 IP 堆栈都允许您基于每个接口（以及更多）设置 MTU。但是您所说的问题在 IP 的上下文中也不太适用，因为 IP 的最小 MTU 为 576。所以请允许我将您的问题重申为“M1 的 MTU 为 600，M2 的 MTU 为 1200 ”。但是我们应该说“Switch”有什么MTU？好吧，如果 Switch 只是一个第 2 层以太网交换机，它没有可设置 MTU 的概念。因此，要在 IP 上下文中解决您的问题，我们必须将该交换机变成路由器。因此，让我们称其为“路由器”，并假设它有两个以太网接口，一个连接到 M1，一个连接到 M2。假设它的两个接口都设置了 1200 的 MTU。

1. 当 M1 向 M2 发送一个带有 600 字节有效载荷的帧时，就没有问题。
2. 当 M2 向 M1 发送一个带有 1200 字节有效载荷的帧时，仍然没有问题。为什么不？因为设置 M1 的 MTU 并不一定会改变它的 MRU，而且根据我的经验，MTU 和 MRU 是分开的，并且实现不会给你改变 MRU 的方法。所以 M1 在该接口上的 MRU 将是 1500，因为它是以太网。
3. 路由器不知道它需要对来自 M2 的帧进行分段，因为它相信 M1 所在的以太网 LAN 上的所有主机都能够接收具有 1200 字节有效载荷的帧，因为它被配置为在该处配置了 1200 字节的 MTU界面。幸运的是，正如我在 (2) 中所讨论的那样，这可能仍然可以正常工作。

好的，仍然试图找到并回答您问题的真正精神，假设 M1 和路由器之间的链路实际上是 PPP 而不是以太网。PPP 协议允许主机通信/协商他们的 MRU。假设 M1 告诉路由器 M1 有 600 字节的 MRU 限制，因此路由器已将该链路的 MTU 设置为 600 字节。

现在，在这种情况下，如果 M2 向 M1 发送一个 1200 字节的 IP 数据报（不设置 IP 标头中的“不要分片”位），路由器将接收它就好了，并意识到它需要将其分片才能发送到M1。那么 Router 是否将其分成两个 600 字节的片段？嗯，不，这不是那么简单，原因有几个。

一个原因是每个片段都必须有自己的 IP 标头，这会在第一个片段之后的每个片段的大小上增加 20 个字节。另一个原因是 IP 的碎片偏移字段以 8 字节块而不是单个字节计数。

因此，假设 1200 字节的数据报特别是 UDP 数据报中的 1172 字节的应用程序数据（8 字节的 UDP 报头，20 字节的 IP 报头）。分片后，第一个分片将包含 20 字节的 IP 标头、8 字节的 UDP 标头和应用程序数据的前 568 字节，总共 586 字节。第二个帧将包含另一个 20 字节的 IP 标头，没有 UDP 标头，以及接下来的 576 个字节的应用程序数据，总共 586 个字节。这为最后一个片段留下了 28 个字节的应用程序数据，加上它的 IP 标头，将是 48 个字节。

基于 Kavin 的更新，他谈论的是巨型帧：
巨型帧是一些千兆以太网产品供应商在创建 GigE 时独立创建的东西，并且（我相信）随后被 IEEE 拒绝或忽略，似乎不太可能成为 802.3 以太网标准的一部分。即使 IEEE 802.3-2008 不仅包括 1000BASE-T 还包括 10 G BASE-T，也不包含任何关于 9000 字节帧有效载荷的内容。

提出巨型帧的供应商没有为巨型帧支持提供任何类型的自动协商或通信机制，也没有创建以太网层分段方法来处理您所说明的（非常常见的）情况。如果您想在这种非标准模式下运行以太网 LAN，您必须确保 LAN 上的所有主机和交换机都支持巨型帧。

如果 M1 的 NIC不能接收巨型帧，它会认为巨型帧是“以太网 jabber”——一个损坏的设备，“不断地继续 jabbing”；继续发送远远超出最大允许 1500（实际上是 1518）字节帧的末尾的位。请注意，jabber 的这个含义是一种以太网故障的术语，不要与名称相似的“Jabber”互联网聊天系统混淆。您必须决定是要停止在该网络上使用巨型帧，还是要升级 M1 以拥有支持巨型帧的 NIC。

如果M1的NIC是能够接收巨型帧，我怀疑该界面下设置的IPv4 MTU为1500将确保它不会发送任何珍宝在一个巨型以太网帧大小的IP数据包，但它最有可能能够在单个巨型以太网帧中接收大型 IP 数据报没问题，因为同样，MTU 不是 MRU，并且设置 IP 层 MTU 不会影响 NIC 允许的帧缓冲区大小。现在，如果您正在调整 NIC/驱动程序设置以告诉 NIC 仅使用 1500 字节缓冲区而不是 9000 字节缓冲区，这是以太网层更改，并且可能会使您的 NIC 表现得好像它没有支持 9000 字节的缓冲区。