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

問題背景

經常會接到用戶反饋使用我們的可支持匯聚的交換機（不管是靜態(tài)匯聚還是LACP），與NAS對接或者與交換機對接，單終端傳輸文件或這跑吞吐量都無法實現(xiàn)帶寬疊加的效果，只能跑滿一個端口的帶寬。

如上兩種拓撲，使用交換機和交換機匯聚；或者交換機和NAS服務器直接匯聚后，使用電腦從NAS點對點讀取/發(fā)送文件，會出現(xiàn)只能跑滿單個物理端口的速率（1G）無法實現(xiàn)2G的傳輸，用戶就會認為是交換機設備的問題，無法實現(xiàn)帶寬的疊加。

排查思路

• 確認關于匯聚的設置沒有問題；
• 確認網線質量沒有問題；
• 確認電腦和電腦跑吞吐量的瓶頸不在電腦；

基礎分析

(1) 確認以上幾點完全設置正確。并沒有因為設置或者物理線路的問題影響本問題的判斷；

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

交換機做端口匯聚的算法機制：交換機由于是不支持應用層分析的，因此做匯聚之后是不支持連接數(shù)均衡的，因此交換機的算法只是基于每一個進入交換機的數(shù)據(jù)包經過計算后將其分配到某一個物理端口傳遞。

交換機的算法有以下幾種：

• 源MAC地址：這種算法是將進入交換機的數(shù)據(jù)包的源MAC地址進行哈希計算后，然后根據(jù)HAS計算后的結果分配一個物理端口傳遞該數(shù)據(jù)包；
• 目的MAC地址：這種算法是將進入交換機的數(shù)據(jù)包的目的MAC地址進行哈希計算后，然后根據(jù)HAS計算后的結果分配一個物理端口傳遞該數(shù)據(jù)包；
• 源目的MAC地址：這種算法是將進入交換機的數(shù)據(jù)包的源MAC地址和MAC地址進行哈希計算后，然后根據(jù)HAS計算后的結果分配一個物理端口傳遞該數(shù)據(jù)包；
• 其余三種源IP，目的IP，源目的IP機制和MAC機制一樣，只是用IP來進行HAS計算，然后再匹配端口，當某些流量場景二層數(shù)據(jù)包較多的情況，需要使用基于MAC的算法來分流。

以源目的MAC地址為例，是以源目的MAC地址為輸入條件進行哈希計算，得到轉發(fā)的端口號，兩組不同的源目的MAC地址經過算法處理可能得出的端口號一樣，例如兩個端口匯聚，很多HAS值最終都會均分到這兩個端口上。

問題總結

交換機做端口匯聚后，由于是單終端，因此根據(jù)交換機的算法得到的HAS值對應匹配一個物理端口，數(shù)據(jù)只能在一個端口轉發(fā)，所以只能跑滿一個端口的速率。只有在多終端的使用場景下，交換機的匯聚才能體現(xiàn)出帶寬疊加的作用。

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