乙太網介面錯誤
我的 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:1000Ubuntu 介面能夠進行全雙工，但它只能協商半雙工連接。當我將不同的設備（路由器）連接到 MUX 時，它也顯示了此類錯誤。分配的頻寬是 50 mbps，但我只有 20 mbps。ISP 不願意在 MUX 中更改他們的設備（看起來像乙太網交換機或集線器）。ISP 工程師將其歸咎於我這邊。但我檢查了超過 3 台設備，都顯示錯誤。那麼，是否有任何適用於 Linux 的工具可以用來深入探究這些錯誤的原因，或者我可以做些什麼來重新配置我的伺服器介面以消除這些錯誤？
由於 ISP 將其一側硬編碼為 100-Full，您很可能會出現雙工不匹配，這實際上會禁用 ISP 乙太網 PHY 上的自動協商。
將 ISP 設置為 100-Full 並且您的一側保持在 auto/auto（預感，但很常見），您一側的自動協商會將介面配置為 100-Half - 與 ISP 一側的雙工不匹配將保持 100 滿。
使固定
您可以通過將乙太網 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-Half 側檢測衝突而導致的 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 虛擬電路管理接收視窗？我小子。
吐槽。