背景介紹

客戶企業是一家200人左右規模的零售行業公司，公司網絡做的是經典全千兆三層網絡架構，部署出口iKuai軟路由+內網某為交換機。大致拓撲如下圖所示：

典型拓撲

網段規劃如下：

• 無線網段：VLAN10-172.16.10.0/24
• 監控網段：VLAN20-172.16.20.0/24
• 辦公網段：VLAN30-172.16.30.0/24
• 管理網段：VLAN100-192.168.90.0/24（含所有交換機、路由、服務器）

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

已有分析

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

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

上述測試說明路由器、交換機等設備應無大問題，遇到這種高吞吐統計的問題，推測網絡中存在了環路導致廣播風暴吃滿帶寬、破壞地址表？

排障分析

第一步：確認問題現象

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

可以看到丟包相當嚴重。

第二步：確認網絡中的環路問題

我們常見的環路主要是二層環路，主要有兩種表現：

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

如上拓撲，因為路由器僅WAN和LAN口在用，從前面的流量統計分析中“WAN口無大流量而LAN口流量異常過大”。我們只需要在核心交換機上聯接口查看數據統計即可，確認到底這個大流量是不是廣播&組播！

命令如下：

<核心交換機>dis int g0/0/1    
釋義：查看上聯口數據統計，每隔5s敲一次確認報文變化量

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

但是注意：細看核心交換上聯接口統計，5秒內收/發單播包35000個/秒，相當于每秒同時雙向收發7000個，這個量是非常驚人的！全網癱瘓的情況下單播包怎會有如此大的吞吐？

下一步需要抓取數據流分析。

第三步：內網主干路數據流分析

我們在核心交換機上做鏡像抓取上聯出口路由接口的流：

抓包如下：

從這條流分析如下：

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

按照時序看第一個：

按照時序看第二個：

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

得出結論：

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

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

核心交換機路由表如下：

核心交換配置是標準的沒問題，再看看iKuai路由表：

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

總結及解決方案

小結如下

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

解決方案

回程路由一定要包含明細，不要搞大網段！如下：