實戰(zhàn)案例:兩個千兆口匯聚成一個 2Gbps 端口,點對點跑流怎么還只有 1Gbps 呢?
本期分享的案例是有線網(wǎng)絡(luò)的相關(guān)問題。
問題背景
經(jīng)常會接到用戶反饋使用我們的可支持匯聚的交換機(不管是靜態(tài)匯聚還是LACP),與NAS對接或者與交換機對接,單終端傳輸文件或這跑吞吐量都無法實現(xiàn)帶寬疊加的效果,只能跑滿一個端口的帶寬。
如上兩種拓撲,使用交換機和交換機匯聚;或者交換機和NAS服務(wù)器直接匯聚后,使用電腦從NAS點對點讀取/發(fā)送文件,會出現(xiàn)只能跑滿單個物理端口的速率(1G)無法實現(xiàn)2G的傳輸,用戶就會認為是交換機設(shè)備的問題,無法實現(xiàn)帶寬的疊加。
排查思路
- 確認關(guān)于匯聚的設(shè)置沒有問題;
- 確認網(wǎng)線質(zhì)量沒有問題;
- 確認電腦和電腦跑吞吐量的瓶頸不在電腦;
基礎(chǔ)分析
(1) 確認以上幾點完全設(shè)置正確。并沒有因為設(shè)置或者物理線路的問題影響本問題的判斷;
(2) 了解交換機匯聚的機制,以及幾種匯聚算法的對應(yīng)交換機的處理行為:
交換機做端口匯聚的算法機制:交換機由于是不支持應(yīng)用層分析的,因此做匯聚之后是不支持連接數(shù)均衡的,因此交換機的算法只是基于每一個進入交換機的數(shù)據(jù)包經(jīng)過計算后將其分配到某一個物理端口傳遞。
交換機的算法有以下幾種:
- 源MAC地址:這種算法是將進入交換機的數(shù)據(jù)包的源MAC地址進行哈希計算后,然后根據(jù)HAS計算后的結(jié)果分配一個物理端口傳遞該數(shù)據(jù)包;
- 目的MAC地址:這種算法是將進入交換機的數(shù)據(jù)包的目的MAC地址進行哈希計算后,然后根據(jù)HAS計算后的結(jié)果分配一個物理端口傳遞該數(shù)據(jù)包;
- 源目的MAC地址:這種算法是將進入交換機的數(shù)據(jù)包的源MAC地址和MAC地址進行哈希計算后,然后根據(jù)HAS計算后的結(jié)果分配一個物理端口傳遞該數(shù)據(jù)包;
- 其余三種源IP,目的IP,源目的IP機制和MAC機制一樣,只是用IP來進行HAS計算,然后再匹配端口,當某些流量場景二層數(shù)據(jù)包較多的情況,需要使用基于MAC的算法來分流。
以源目的MAC地址為例,是以源目的MAC地址為輸入條件進行哈希計算,得到轉(zhuǎn)發(fā)的端口號,兩組不同的源目的MAC地址經(jīng)過算法處理可能得出的端口號一樣,例如兩個端口匯聚,很多HAS值最終都會均分到這兩個端口上。
問題總結(jié)
交換機做端口匯聚后,由于是單終端,因此根據(jù)交換機的算法得到的HAS值對應(yīng)匹配一個物理端口,數(shù)據(jù)只能在一個端口轉(zhuǎn)發(fā),所以只能跑滿一個端口的速率。只有在多終端的使用場景下,交換機的匯聚才能體現(xiàn)出帶寬疊加的作用。
這類問題根據(jù)用戶的想法是端口匯聚了就應(yīng)該跑滿所有的端口,但是實際是不能實現(xiàn)的,因為交換機不是基于連接數(shù)來匹配的,而是基于每個包的HAS值算法再匹配端口的,了解了這樣的一個機制后再來看這個問題就很好理解了。