背景介紹

客戶企業(yè)是一家200人左右規(guī)模的零售行業(yè)公司，公司網(wǎng)絡(luò)做的是經(jīng)典全千兆三層網(wǎng)絡(luò)架構(gòu)，部署出口iKuai軟路由+內(nèi)網(wǎng)某為交換機(jī)。大致拓?fù)淙缦聢D所示：

典型拓?fù)?/p>

網(wǎng)段規(guī)劃如下：

• 無線網(wǎng)段：VLAN10-172.16.10.0/24
• 監(jiān)控網(wǎng)段：VLAN20-172.16.20.0/24
• 辦公網(wǎng)段：VLAN30-172.16.30.0/24
• 管理網(wǎng)段：VLAN100-192.168.90.0/24（含所有交換機(jī)、路由、服務(wù)器）

目前問題是：公司IT經(jīng)常發(fā)現(xiàn)iKuai出口路由的CPU經(jīng)常飆高到90%以上，訪問頁面特別卡，同時下面的終端上網(wǎng)都出現(xiàn)了卡頓、延時等問題，整網(wǎng)崩掉了。

已有分析

• 重啟大法無效，重啟了路由器、核心交換機(jī)，故障依舊；
• 路由器LAN口流量統(tǒng)計發(fā)現(xiàn)千兆鏈路的帶寬被吃滿了，但是WAN口卻詭異的沒有任何大流量？

• 把核心交換機(jī)拔掉，找臺PC直連愛快路由，速度快到起飛！

上述測試說明路由器、交換機(jī)等設(shè)備應(yīng)無大問題，遇到這種高吞吐統(tǒng)計的問題，推測網(wǎng)絡(luò)中存在了環(huán)路導(dǎo)致廣播風(fēng)暴吃滿帶寬、破壞地址表？

排障分析

第一步：確認(rèn)問題現(xiàn)象

我們使用VLAN30辦公區(qū)PC ping測試百度IP：

可以看到丟包相當(dāng)嚴(yán)重。

第二步：確認(rèn)網(wǎng)絡(luò)中的環(huán)路問題

我們常見的環(huán)路主要是二層環(huán)路，主要有兩種表現(xiàn)：

• 廣播風(fēng)暴：導(dǎo)致端口帶寬滿載，地址表被破壞；
• 組播/廣播泛洪：如DHCP、ARP等報文量過大流進(jìn)CPU，也會導(dǎo)致CPU性能下降。

如上拓?fù)?，因為路由器僅WAN和LAN口在用，從前面的流量統(tǒng)計分析中“WAN口無大流量而LAN口流量異常過大”。我們只需要在核心交換機(jī)上聯(lián)接口查看數(shù)據(jù)統(tǒng)計即可，確認(rèn)到底這個大流量是不是廣播&組播！

命令如下：

<核心交換機(jī)>dis int g0/0/1    
釋義：查看上聯(lián)口數(shù)據(jù)統(tǒng)計，每隔5s敲一次確認(rèn)報文變化量

從上圖可以看到問題復(fù)現(xiàn)時，核心交換上聯(lián)GE0/0/1接口的組播&廣播報文在5秒內(nèi)增長是非常緩慢的，基本排除了可能存在的二層環(huán)路以及報文泛洪的問題。

但是注意：細(xì)看核心交換上聯(lián)接口統(tǒng)計，5秒內(nèi)收/發(fā)單播包35000個/秒，相當(dāng)于每秒同時雙向收發(fā)7000個，這個量是非常驚人的！全網(wǎng)癱瘓的情況下單播包怎會有如此大的吞吐？

下一步需要抓取數(shù)據(jù)流分析。

第三步：內(nèi)網(wǎng)主干路數(shù)據(jù)流分析

我們在核心交換機(jī)上做鏡像抓取上聯(lián)出口路由接口的流：

抓包如下：

從這條流分析如下：

該流為源VLAN20監(jiān)控網(wǎng)訪問目的172.16.40.0/24的UDP流，據(jù)統(tǒng)計這些流吞吐量高達(dá)1Gbps，它是占滿千兆鏈路帶寬的主要原因，也是路由器收發(fā)包滿載導(dǎo)致CPU持續(xù)高位的主要原因。那么這些“異常流”為何會出現(xiàn)在核心交換與路由之間并且泛洪的呢？我們來看下數(shù)據(jù)包MAC地址對比一下：

按照時序看第一個：

按照時序看第二個：

分析得出：這個UDP包在交換機(jī)和路由器之間互轉(zhuǎn)循環(huán)，即：SW—>R—>SW—>R。。。。一直循環(huán)到TTL=0然后才丟掉UDP包！

得出結(jié)論：

路由器和交換機(jī)之間發(fā)生了路由環(huán)路，監(jiān)控網(wǎng)訪問的目的網(wǎng)段是172.16.40.0/24。但很奇怪的是內(nèi)網(wǎng)并不存在這個網(wǎng)段，即便是監(jiān)控設(shè)備去訪問該網(wǎng)段也會被路由器從WAN口發(fā)出去才對，怎么又彈回來了呢？那一定是和配置有關(guān)了！

第四步：檢查核心交換機(jī)和路由器的路由表

核心交換機(jī)路由表如下：

核心交換配置是標(biāo)準(zhǔn)的沒問題，再看看iKuai路由表：

iKuai上的回程路由，IT人員為了省事配成了172.16.0.0/16（即包含內(nèi)網(wǎng)所有網(wǎng)段）下一跳給核心，這個做法簡直災(zāi)難！一旦內(nèi)網(wǎng)訪問172.16.1.X、172.16.2.X、172.16.200.X主干路就環(huán)了，鏈路帶寬就爆了呀！

總結(jié)及解決方案

小結(jié)如下

• 項目內(nèi)網(wǎng)有3個VLAN網(wǎng)段，分別是172.16.10/20/30.X；
• 某為核心交換機(jī)全0路由下一跳指向iKuai出口路由器，保證上外網(wǎng)，此配置無問題；
• 為了省事，iKuai的回程靜態(tài)路由配置成一條：目的172.16.0.0/16下一跳指向核心。這個配置下，一旦訪問非內(nèi)網(wǎng)段且處于172.16.0.0/16網(wǎng)段的IP時便發(fā)生路由環(huán)路，比如訪問172.16.1.1，路徑跟蹤如下：

解決方案

回程路由一定要包含明細(xì)，不要搞大網(wǎng)段！如下：