故障現(xiàn)象

近日，根據(jù)流量監(jiān)控軟件的監(jiān)測分析結(jié)果，發(fā)現(xiàn)某聯(lián)通出口在晚高峰期使用率已經(jīng)達到80%，我們決定對該出口進行擴容。由于原有聯(lián)通出口與我們互聯(lián)是10G接口，而且該流控設(shè)備上已沒有萬兆端口，只能使用千兆口對接。但用千兆口對接，互聯(lián)網(wǎng)出口廠家對這次擴容的端口也是用萬兆端口，由于情況緊急，只得在出口廠家設(shè)備和我們流控設(shè)備之間增加一臺有萬兆光口的交換機，然后再使用鏈路聚合的模式和流控設(shè)備對接。因為互聯(lián)網(wǎng)出口廠家給我們這次擴容提供了10G的通道，結(jié)合我們目前的網(wǎng)絡(luò)狀況，可以先在交換機上捆綁3G來滿足當前業(yè)務(wù)的發(fā)展。

就在我們完成10G對接、3G鏈路聚合捆綁后，發(fā)現(xiàn)3G有兩個端口是沒有流量的，但是雙方的端口都是Up的。

故障分析

首先排除了物理層光路和光模塊的問題，兩者之間設(shè)備互聯(lián)除了光路和光模塊外，那就是兩個設(shè)備間運行的鏈路聚合協(xié)議。在流控設(shè)備上看到使用的端口負載分擔模式是“會話均衡”，而對端交換機采用的端口負載分擔模式是“srcdestip”，會不會是這個地方出現(xiàn)了問題?

故障解決

通過查詢資料和請教廠家技術(shù)工程師，我們對流控設(shè)備上的負載分擔模式進行了修改，修改成了“輪詢”后，鏈路聚合組成員的另外兩個端口開始有流量，這說明操作是正確的，故障得以解決。

經(jīng)驗總結(jié)

上面我們從對互聯(lián)網(wǎng)出口的監(jiān)測情況，根據(jù)現(xiàn)有設(shè)備情況采用鏈路聚合的模式來完成互聯(lián)網(wǎng)出口的接入，在出現(xiàn)端口沒有流量的故障后，首先排查了物理層，最后在數(shù)據(jù)鏈路層的鏈路聚合負載分擔模式上發(fā)現(xiàn)了端倪，通過修改一側(cè)設(shè)備的負載分擔模式達到了解決故障的目的。

后期通過查找資料，得知鏈路聚合的負載分擔模式有很多種，諸如基于源MAC、目的MAC、源和目的MAC、源IP、目的IP、源和目的IP這6種模式，它可以將數(shù)據(jù)流量均衡合理的分擔到不同鏈路上，最后能到達同一的目的地，避免鏈路阻塞。在日常網(wǎng)絡(luò)維護中，可以根據(jù)實際情況來選擇負載分擔模式，流量中該參數(shù)變化越頻繁，選擇此負載分擔模式的流量就越均衡。負載分擔只對出方向的流量有效，因此鏈路兩端設(shè)備的接口負載分擔模式可以不一樣。但是不同設(shè)備間如果該負載分擔的模式不相匹配，會引發(fā)流量的異常。即文章開頭出現(xiàn)的兩個端口沒有流量的情況。