GS1920 在9K MTU下的網路傳輸崩潰問題

JeremyJoung

我這邊有台新採購的GS1920 替換了原本舊的GS1910
但是當把SWITCH安裝上去後 整個內網的傳輸速度幾乎崩潰 上傳速度衰退到100M 甚至10M不到
而且在網路壅塞時 是全硬體等級的阻塞 連周邊"所有無關裝置"都會跟著掉PING
而內部下載速度是正常的達98X 對外上網速度也是正常的

我重新安裝一次SWITCH 並且一步一步偵測後
在剛開機瞬間 網路效能還是正常的， PC對閘道(ESXi)速度達98X，但等開始逐步加掛硬體後 網路整體傳輸速度舊顯著的下降

我剛用LACP掛上一台 Synology DS1618 後 周遭的網路速度就直接跌到了300~700
全部裝置掛上去後 網路速度就又跌到100不到

再進一步測試中

如果本機電腦開9K封包 那麼上傳就會崩潰 反之如果降低MTU 上傳速度就會逐漸恢復
我反覆測試了各種排列組合 已"確定"了巨大封包會導致網路崩潰
並且可以在多台不同電腦 不同VLAN條件下 反覆重現相同錯誤

MTU	send	receive
9014	50.5	985
8014	441	964
7014	260~336	984
6014	922	972
5014	960	909
4088	718	938
4014	765	929
3014	782~848	962
2014	772~854	916~951
1514	836~897	870~922

9K封包

本機降低到6K封包後

192.168.3.1 是pfsense 虛擬機閘道 中間透過VLAN連線

另外
如果ESXi伺服器沒直接插在GS1920上 只要中間多串任何一個SWITCH 對伺服器的傳輸速度也會恢復正常(8XX)
代表GS1920 跟 ESXi 間的通訊有瑕疵

我的物理路徑

Intel I219-V(1514~9014) <35M> GS1900(VLAN) <DAC LACP> GS1920 <2M LACP> HP DL380G8 > ESXi 6.5(9000) > pfsense 2.6 (VLAN 9000)

而在GS1920中 Path MTU表 顯示也是空白的
這是滿嚴重的產品BUG 目前確定是MTU通知異常 但是具體是哪邊的問題則不清楚
是ICMP MTU異常或是對舊系統相容性錯誤 還是怎樣麻煩你們查清楚後 盡快修復更新

不然 買了新的交換器卻導致網路崩潰 這樣根本不行

謝謝

Zyxel小編 YM

你好,

為了釐清 GS1920 與 GS1910 在 MTU 設定為 9000 bytes 時所產生的不同結果，以下是建議的測試步驟與環境說明：

測試環境簡化

當遇到複雜問題時，建議先將測試環境簡化為最基本架構，以利排除干擾因素並聚焦於核心差異。

測試設備與設定

• 測試交換器：GS1920-24HP
• 韌體版本：V4.50
• 設定狀態：採用出廠預設值，未設定 VLAN 或 Storm Control

測試方式

• 使用 Windows 11 主機執行以下指令：

測試標準傳輸行為

• 使用 Windows 11 主機執行以下指令：

• -l 參數指定 payload 大小為 9000 bytes

測試結果請參考以上說明

JeremyJoung

韌體 4.8 / 5.0 我都測試過

而且 我透過交叉測試已經把問題縮限到 DL380G8 ESXi 6.5 直接插在GS1920-48 上時
當傳輸方MTU大於接收方MTU時 SWITCH傳輸會硬體崩潰

我不理解這是什麼BUG 過去經驗也從沒見過這種現象
而我可以穩定的在多台電腦任意重現這個BUG
SWITCH逐步重新安裝後 也還是一樣
所以這不是什麼無法分析的個人誤差 這是行為明確的BUG
本文中 我已經提供非常詳盡的背景環境了 觸發條件我也列了
如果覺得細節仍不夠 可以再補充 要直接來現場側錄也可以
總之 想辦法給我"修正"這個BUG

並且不只是ESXi 就連DS1618 NAS也一樣癱瘓

要不是NAS傳輸崩潰 我還根本不知道有這個BUG

我現在都還不知道 該怎麼跟辦公室交代目前的網路癱瘓狀況

JeremyJoung

我再把之前已經說明過的環境再條列的更簡單一點

1. 對外上網時都正常 對內上傳效能會隨著MTU增加逐漸下降 詳細見MTU表格
2. 不管有沒有走VLAN效果都一樣 也沒有WINDOWS版本與網卡區別 全都會死
3. SWITCH只有在全裸機效能是正常的 但是開始接上設備後 網路就會逐漸癱瘓
4. ESXi 閘道 不直接插在GS1920上時 問題會改善(7XX) 但仍非完全正常(98X)
5. 出問題時 連ESXi內的HTTPS 都會跟著癱瘓

對於一個伺服器網通設備 這是很嚴重的BUG問題

只剩10M不到的頻寬 這能見人嗎?

JeremyJoung

iperf3 -l 參數沒有任何效果 所有電腦都還是一樣 只要開了9K 結果都是一樣

而且該 -l 也不是MTU的意思 完全無關 這不是 ping

Zyxel小編 YM

• 支援工程師測試如下:

• 使用 iperf 測試未發現任何異常。
• 將 MTU size 調整為 9000（即 jumbo frame 設定）後，透過 iperf 測速並擷取封包，確認已成功送出 9014-byte 的封包，速度正常。
• 請確認雙方網卡的 MTU 設定是否一致，包含接收端與傳送端。
• 關於「當傳輸方 MTU 大於接收方 MTU 時 SWITCH 傳輸會硬體崩潰」的說法，需釐清實際需求。
• 為何會有兩端 MTU 設定不一致的情況？
• 一般而言，傳輸與接收端的 MTU 應保持一致，否則容易導致封包遺失或速率下降。

JeremyJoung

一開始的時候 所有裝置都是9K 但當偵測到速度異常開始除錯時 發現MTU參數會影響到上傳網速 所以才降低本機MTU
MTU大於變慢 這是根據實驗後推論出來的結果 不是實際需求 實際需求都是9K全開

為什麼MTU會影響網速我不知道 但我實際逐步測試後 得到的MTU測試表如同主文
結論上來說 MTU就是有100%的直接影響 是直接原因還是間接原因不清楚
但在辦公室內多台電腦都可以獲得類似的實驗結果

另外
不只是對pfsense閘道 PC對ESXi內的其他伺服器測速時 也可以得到相同的降速結論 目前該ESXi內的所有伺服器都可以測出這個結果

還有些網路排列組合沒有測試過
也有碰到大幅改變網路環境後 問題就消失測不出異常的
但在已測過的條件中 已確定因素都是可以被不斷重現的

JeremyJoung

補充一下

目前發現了兩個網路異常錯誤

一個是內網裝置 部分主機的HTTPS 會一直整個卡死癱瘓 網頁全白讀不出來

另一個是 網芳傳輸除了變慢卡住 還開始出現不確定性的資料破損 備份檔案(7z)損壞問題

這都是在更換SWITCH前從沒發生過的異常現象

JeremyJoung

在進一步的交叉測試中 變慢問題集中在ESXi內的虛擬機上

速度測試只要是連到與GS1920對接的ESXi內的主機 就會出現速度異常

在異常時ESXi的網孔會直接卡死 所有連線time out

與網卡網孔無關 交換網孔也一樣

但若測試目標不是ESXi的 目前幾個測試樣本沒看到問題

ESXi 是HP DL380 G8

影像檔 是 HPE-ESXi-6.5.0-Update3

全都是官方版本

JeremyJoung

請問
有沒有比較科學化的除錯方式
老闆已經開始在問網路障礙的問題了 我必須要給個交代

這種黑箱盲測的方式 很難找到正確的關鍵
而且 這個BUG應該帶有隱蔽性 若沒滿足特定條件則無法觸發

這我這BUG就是有明確規律的 但遠端也根本聽不出所以然

有沒有更明確的雙像除錯方法?

Zyxel小編 YM

可以提供 tech-support 給我們判斷

請提供兩端網卡的 MTU 設定，包含接收端與傳送端。

來源 switch 開 mirror port 抓異常狀況時的封包

目的地同時也抓取封包

以上資訊提供給後端工程師分析