背景介紹

客戶企業(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ú)線網(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ù)器）

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

已有分析

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

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

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

排障分析

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

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

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

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

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

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

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

命令如下：

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

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

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

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

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

我們?cè)诤诵慕粨Q機(jī)上做鏡像抓取上聯(lián)出口路由接口的流：

抓包如下：

從這條流分析如下：

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

按照時(shí)序看第一個(gè)：

按照時(shí)序看第二個(gè)：

分析得出：這個(gè)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èn)的目的網(wǎng)段是172.16.40.0/24。但很奇怪的是內(nèi)網(wǎng)并不存在這個(gè)網(wǎng)段，即便是監(jiān)控設(shè)備去訪問(wèn)該網(wǎng)段也會(huì)被路由器從WAN口發(fā)出去才對(duì)，怎么又彈回來(lái)了呢？那一定是和配置有關(guān)了！

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

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

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

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

總結(jié)及解決方案

小結(jié)如下

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

解決方案

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