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

問題背景

經常會接到用戶反饋使用我們的可支持匯聚的交換機（不管是靜態匯聚還是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值算法再匹配端口的，了解了這樣的一個機制后再來看這個問題就很好理解了。