實戰案例：兩個千兆口匯聚成一個 2Gbps 端口，點對點跑流怎麼還只有 1Gbps 呢？

本期分享的案例是有線網路的相關問題。

問題背景
經常會接到用戶回饋使用我們的可支援匯聚的交換器（不管是靜態匯聚還是LACP），與NAS對接或與交換器對接，單終端傳輸檔案或這跑吞吐量都無法實現頻寬疊加的效果，只能跑滿一個連接埠的頻寬。

如上兩種拓撲，使用交換器和交換器匯聚；或交換器和NAS伺服器直接匯聚後，使用電腦從NAS點對點讀取/發送文件，會出現只能跑滿單一實體連接埠的速率（1G）無法實現2G的傳輸，用戶會認為是交換器設備的問題，無法實現頻寬的疊加。

排查思路
確認關於匯聚的設定沒有問題；
確認網線品質沒有問題；
確認電腦和電腦跑吞吐量的瓶頸不在電腦；


基礎分析
(1) 確認以上幾點完全設定正確。並沒有因為設定或物理線路的問題影響本問題的判斷；

(2) 了解交換器匯聚的機制，以及幾種匯聚演算法的對應交換器的處理行為：

交換器做埠匯聚的演算法機制​​：交換器由於是不支援應用層分析的，因此做匯聚之後是不支援連接數均衡的，因此交換器的演算法只是基於每一個進入交換器的資料包經過計算後將其分配到某一個實體連接埠傳遞。

交換器的演算法有以下幾種：

來源MAC位址：此演算法是將進入交換器的封包的來源MAC位址進行雜湊計算後，然後根據HAS計算後的結果分配一個實體連接埠傳遞該封包；


目的MAC位址：此演算法是將進入交換器的封包的目的MAC位址進行雜湊計算後，然後根據HAS計算後的結果分配一個實體連接埠傳遞該封包；
來源目的MAC位址：此演算法是將進入交換器的封包的來源MAC位址和MAC位址進行雜湊計算後，然後根據HAS計算後的結果分配一個實體連接埠傳遞該封包；
其餘三種來源IP，目的IP，源目的IP機制和MAC機制一樣，只是用IP來進行HAS計算，然後再匹配端口，當某些流量場景二層數據包較多的情況，需要使用基於MAC的算法來分流。


以來源目的MAC位址為例，是以來源目的MAC位址為輸入條件進行雜湊計算，得到轉送的連接埠號，兩組不同的來源目的MAC位址經過演算法處理可能得出的連接埠號碼一樣，例如兩個埠匯聚，很多HAS值最終都會均分到這兩個埠上。

問題總結
交換器做端口匯聚後，由於是單終端，因此根據交換機的演算法得到的HAS值對應匹配一個物理端口，數據只能在一個端口轉發，所以只能跑滿一個端口的速率。只有在多終端的使用場景下，交換器的匯聚才能反映出頻寬疊加的功能。


這類問題根據用戶的想法是端口匯聚了就應該跑滿所有的端口，但是實際上是不能實現的，因為交換機不是基於連接數來匹配的，而是基於每個包的HAS值算法再匹配端口的，了解了這樣的一個機制後再來看這個問題就很好理解了。