本期分享的案例是有線/無線網(wǎng)絡(luò)的相關(guān)問題。

一、背景介紹

客戶是一家工作室，主要業(yè)務(wù)是做自媒體，對(duì)于網(wǎng)絡(luò)要求很高，每日都會(huì)負(fù)載很大的上下行流量。入戶是下行10Gbps的萬兆寬帶，路由和核心交換機(jī)也都是萬兆設(shè)備，匯聚和接入交換機(jī)通過匯聚的方式互聯(lián)，設(shè)備品牌是某J。

現(xiàn)場(chǎng)簡(jiǎn)化拓?fù)淙缦拢?/p>

規(guī)劃配置如下：

• 傻瓜式網(wǎng)絡(luò)，網(wǎng)段為：10.0.0.0/16
• 所有的路由器、交換機(jī)全部都是管理型設(shè)備

二、問題現(xiàn)象

IT客戶使用的方式主要是終端（PC1....PC6等）跑大流量的下載任務(wù)，使用過程中存在問題：匯聚和接入交換機(jī)之間的2Gbps匯聚口LAG無法跑滿，并且在跑大流量的時(shí)候PC上網(wǎng)會(huì)出現(xiàn)卡頓的情況。

三、排查分析

第一步：確認(rèn)總吞吐量無法跑滿2Gbps問題

首先查看交換機(jī)匯聚口兩條鏈路的吞吐總量，可以看到接入交換機(jī)的兩條物理鏈路上分別為996Mbps+250Mbps，差不多總計(jì)1.3Gbps。

從目前的現(xiàn)象來看是因?yàn)閱螚l鏈路的流已經(jīng)打滿了，但是另外一條鏈路遠(yuǎn)不到瓶頸，所以總吞吐量沒法打滿。并且從這個(gè)現(xiàn)象來看，如果流量繼續(xù)跑9口（打滿流量的那條鏈路），那么就可能會(huì)產(chǎn)生丟包。

第二步：確認(rèn)大流量的情況下丟包情況

跑高吞吐量時(shí)PC ping測(cè)試外網(wǎng)和內(nèi)網(wǎng)網(wǎng)關(guān)的結(jié)果如下：

從目前的現(xiàn)象來看確實(shí)存在丟包了，大概率是該P(yáng)C的流量打在了那條將近跑滿1Gbps的物理鏈路上。

綜上所述，那么基于這種情況初步判斷是匯聚分流不均勻?qū)е?，由于交換機(jī)可看信息有限，我們就要從原理側(cè)進(jìn)行分析并嘗試解決。

第三步：深度思考匯聚算法

因?yàn)閰R聚算法要么基于IP要么基于MAC，所以一條四元組固定的會(huì)話流只會(huì)走1條固定的物理鏈路。因此當(dāng)前的總流量打不起來的問題，基于拓?fù)洌?/p>

分析如下：

• 會(huì)話1來自PC5—峰值肯可能是700Mbps，正好hash到了匯聚物理口9
• 會(huì)話2來自PC6—峰值肯可能是300Mbps，正好hash到了匯聚物理口10
• 會(huì)話3來自PC4—峰值肯可能是600Mbps，正好hash到了匯聚物理口9
• 會(huì)話4來自PC5—峰值肯可能是300Mbps，正好hash到了匯聚物理口10

所以總的流量是：

• 9物理口實(shí)際最多只能1Gbps而達(dá)不到1.3Gps（600+700）
• 10物理口實(shí)際可達(dá)預(yù)期600Mbps，因?yàn)樵摽谑?bps還不到瓶頸。

基本結(jié)論：

交換機(jī)匯聚口是不具備帶寬均衡策略的，所以如果有PC又概率性的走到9口那就會(huì)導(dǎo)致丟包的情況出現(xiàn)?；诖?，符合現(xiàn)場(chǎng)存在“總吞吐量達(dá)不到2Gbps和高吞吐量下PC出現(xiàn)通信丟包的問題現(xiàn)象”

四、解決方案

從上述分析出發(fā)，這是一個(gè)數(shù)學(xué)的概率性問題，所以可以嘗試增加匯聚口，如下：

• 會(huì)話1—峰值肯可能是700Mbps，正好hash到了匯聚物理口9
• 會(huì)話2—峰值肯可能是300Mbps，正好hash到了匯聚物理口10
• 會(huì)話3—峰值肯可能是600Mbps，正好hash到了匯聚物理口11

即每個(gè)口的hash就能大概率的均衡過去了，每個(gè)物理口皆保持在1Gbps以下

可以明顯的看到分流更均勻了，每個(gè)物理口的流量都未達(dá)到1Gbps瓶頸，然后測(cè)試下PC ping網(wǎng)關(guān)和外網(wǎng)的情況：

基本沒有再出現(xiàn)丟包的問題，問題解決！