服务器 2012,巨型帧 - 我应该预料到问题吗?

服务器 2012,巨型帧 - 我应该预料到问题吗?

好吧,这听起来可能很愚蠢 - 但在实践中启用巨型帧有什么负面影响吗?

据我了解:

  • 任何交换机或以太网适配器如果发现无法处理的巨型帧就会将其丢弃。
  • TCP 不是问题,因为最大帧大小是在 setinuo 阶段协商的。
  • UCP 是一个理论问题,因为服务器可能只发送一个在途中被丢弃的大型 UDP 数据包。

但实际上,由于 UDP 是基于数据包的,我并不认为任何软件会在没有应用程序级配置更改的情况下发送大于 1500 字节网络的 UDP 数据包 - 至少这是我进行编程的方式,因为如果不亲自测试,很难获得合适的 MTU 大小,因此您在编程时会退回到最多 1500 个数据包。

所讨论的网络是标准的小型企业网络 - 我们现在从非托管 24 端口交换机升级到具有 4 个 10g 端口的 52 端口交换机(netgear - 相当便宜),并将文件服务器移至 10g 以提供 ISCSI 服务。我以太网级别的所有设备至少可以处理 9000 字节,并且由于本地防火墙,我确实希望获得更大的数据包(更少的防火墙处理),但网络也通过 NAT 连接到互联网。最重要的是,不同的机器经常移动(下载)大文件(多 GB 区域)进行处理。

问题是 - 当我仅启用巨型帧时会出现问题吗?

再说一遍,这并不是完全无知 - 我只是没有看到程序发送超过 1500 字节的 UDP 数据包(如果这是一个实际问题,请告诉我)并且对于 TCP,MTU 无论如何都会得到协商。

如果出现问题,我可以转到专用 VLAN,但这也有其自身的问题,因为基本上大多数工作站都必须位于两个 VLAN 上。

答案1

实际上仅启用巨型帧有什么负面影响吗?

不,只要在切换 JF 时您立即确认服务器可以使用适当的 NIC,那么就没有任何实际缺点。

答案2

唯一的问题是,在标记帧中添加了额外的 14 个字节。对于某些硬件来说,这足以触发“掉落到地板上”的操作。我自己也遇到过这种情况,但通过将相关交换机上的 MTU 设置为 9014,并将其他所有值设置为 9000,可以解决这个问题。

相关内容