nix*_*win 10 ethernet wide-area-network errors
我的 Ubuntu 服务器以太网接口连接到 ISP 的多路复用器显示错误。这是快照：
RX packets:204564288 errors:3193970 dropped:0 overruns:0 frame:3138402
TX packets:29305799 errors:38752 dropped:0 overruns:0 carrier:38762
collisions:2205053 txqueuelen:1000
Ubuntu 接口支持全双工，但只能协商半双工连接。当我将不同的设备（路由器）连接到 MUX 时，它也显示此类错误。分配的带宽是 50 mbps，但我只有 20 mbps。ISP 不愿意在 MUX 中更改他们的设备（看起来像以太网交换机或集线器）。ISP 工程师将其归咎于我的错。但是我检查了 3 个以上的设备，都显示错误。那么，是否有任何适用于 Linux 的工具可以用来深入探究这些错误的原因，或者我可以做些什么来重新配置我的服务器界面以消除这些错误？
由于 ISP 将其一侧硬编码为 100-Full，因此很可能存在双工不匹配，这实质上禁用了 ISP 以太网 PHY 上的自动协商。
将 ISP 设置为 100-Full 并且您的一侧保持在自动/自动（预感，但很常见），您一侧的自动协商会将接口配置为 100-Half —— ISP 侧的双工不匹配将保持 100-Full。
使固定
您可以通过将以太网 PHY 硬编码为 100-Full 来解决问题——或者特别是 ISP 设置的任何值。大多数 ISP 使用 100-Full。
附加细节
由于 100-Full 到 100-Half 的双工不匹配，100-Full 侧禁用 CSMA/CD，而 CSMA/CD 在 100-Half 侧保持有效。100-Full 侧传输不考虑介质是否空闲。100-Half 侧按照 CSMA/CD 的定义执行 CSMA/CD 检查和退避。 这就是为什么在应该是 50 Mb/s 的 Internet 电路上只能达到 20 Mb/s 的原因。由于 100 个半边检测冲突而导致的 CSMA/CD 退避限制了吞吐量。
通过将接口硬编码为 100-Full 以匹配 ISP，双方都将禁用 CSMA/CD，因此将禁用退避和冲突检测，您应该获得更接近 50 Mb/s 互联网电路数据速率的数字。
历史
许多 ISP 对其以太网 PHY 切换进行了硬编码，因为有一段时间这样做更可靠。当最初的 802.3u 100 Mb/s 快速以太网标准发布时，速度和双工的自动协商存在，但不是必需的。直到 802.3z 1 Gb/s 千兆以太网标准才要求自动协商。
许多网络工程师对自动协商存在误解。最大的误解是，如果只有一侧实现自协商，自协商可以正确协商速度和双工。这是错误的——正如你所看到的。
造成这种情况的原因可能源于以下原因——如果一侧硬编码为 100-Full，则运行自动协商的另一侧似乎总是计算出 100 Mb/s 部分。如果一侧硬编码为 10-Full，则相同——运行自动协商的另一侧可以计算出 10 Mb/s 部分。确定链路速度的能力来自称为并行检测的功能，该功能在所有本地支持的链路速度上尝试接收到的物理层信号，直到找到匹配项。但是，并行检测仅适用于速度，不适用于双工匹配。这就是为什么会发生双工不匹配的原因——因为当接口无法通过自动协商确定另一端时，它总是会回退到半双工。
肥皂盒
曾几何时，对自动协商的支持参差不齐，它造成的问题与它要解决的问题一样多。 那个时候，在这位网络工程师看来——已经过去了。 虽然自动协商问题仍然存在，但我在过去 5 年中看到的由于自动协商配置而导致的问题数量使我因禁用自动协商而看到的问题数量相形见绌。
我从来没有遇到过一个 ISP 不愿意在被要求时将他们的以太网切换更改为自动/自动的。对于大多数电缆和 DSL 调制解调器和网关，这不是问题。NxT1 和带有以太网切换的光纤管理 CPE 路由器通常存在此问题。问题是网络管理员必须首先询问。
通过将 ISP 硬编码为 100-Full，他们承担了义务。必须记录和继续的义务。自动协商是现在稳定的技术，已经存在多年，并为我们解决了这个问题。如前所述，自动协商引起的问题数量远远超过 2011 年因禁用自动协商而出现的问题数量。技术存在解决此问题，请使用它。也许我们应该手动设置初始 TCP SYN、MSS 并管理每个 TCP 虚拟电路的接收窗口？我孩子。
咆哮。