背景介紹

甲方是一家船舶機(jī)械零件制造型企業(yè)，一直使用的是全套Cisco交換機(jī)部署的生成樹冗余網(wǎng)絡(luò)架構(gòu)。

根橋為核心層交換機(jī)，僅做局域網(wǎng)通信使用。接入端設(shè)備由工業(yè)相機(jī)和采集器，數(shù)據(jù)回傳至中心控制臺，整網(wǎng)拓?fù)淙缦拢?/p>

網(wǎng)絡(luò)拓?fù)湔f明：

• 企業(yè)有多個加工車間，每個車間網(wǎng)絡(luò)均屬于不同VLAN，邏輯隔離；
• 車間交換網(wǎng)絡(luò)匯聚上聯(lián)至核心交換網(wǎng)絡(luò)；
• 車間交換網(wǎng)絡(luò)環(huán)狀互聯(lián)，使能STP協(xié)議，阻塞口為網(wǎng)橋鏈路的交換機(jī)接口；
• 核心層交換網(wǎng)絡(luò)同樣使能STP協(xié)議，多鏈路冗余互聯(lián)；
• 連接工業(yè)相機(jī)、采集器等終端接口為STP邊緣接口，拓?fù)渥兏粎⑴c計算。

問題描述

近期IT人員發(fā)現(xiàn)，從控制臺電腦訪問車間B的工業(yè)相機(jī)特別卡，ping工業(yè)相機(jī)和其所在的交換機(jī)延時基本都在20ms左右：

注：相機(jī)IP是192.168.1.153，所在的3號交換機(jī)IP為192.168.10.3

用了大半年都是不存在此問題的，ping延時均穩(wěn)定≤1ms，近期突然出現(xiàn)這個故障，延時發(fā)生位置：

問題看起來比較棘手，我們一起來看看該如何分析！

排查分析

第一步、檢查關(guān)鍵配置是否變動

在設(shè)計拓?fù)渲校梢钥吹絊TP備用鏈路是無線網(wǎng)橋回傳鏈路，眾所周知，無線延時比有線更高且不穩(wěn)定，那會不會是鏈路切換到無線網(wǎng)橋側(cè)傳輸了呢？這里查看3、4號交換機(jī)相關(guān)配置項：

因為STP根橋處于核心層，所有車間的交換機(jī)均為“非根橋”，所以每個成環(huán)交換機(jī)會決策出一個阻塞口。這里3、4號交換機(jī)成環(huán)，配置中3、4號交換機(jī)的12口優(yōu)先級均是高于11口的（小優(yōu)），所以阻塞口只會出現(xiàn)在3、4交換機(jī)的11口上，也就是備用阻塞鏈路是無線網(wǎng)橋鏈路，配置符合預(yù)期。

第二步、確認(rèn)生成樹拓?fù)涫欠穹项A(yù)期

確認(rèn)交換機(jī)配置無誤，下一步確定STP拓?fù)涫諗壳闆r，這里主要看“加工車間B”這個問題局點(diǎn)的設(shè)備，其它區(qū)域可暫時不用關(guān)心，命令：

show spanning-tree interface

查看相關(guān)Cisco交換機(jī)端口狀態(tài)：

可以看到：

• 接入終端的3號交換機(jī)的11口是AP口為阻塞狀態(tài)，12口為DP口轉(zhuǎn)發(fā)狀態(tài)：
• 上聯(lián)核心的4號交換機(jī)11、12是DP口為轉(zhuǎn)發(fā)狀態(tài)

說明交換網(wǎng)絡(luò)的拓?fù)涫諗坎]有什么問題，符合預(yù)期，排除了數(shù)據(jù)走無線網(wǎng)橋轉(zhuǎn)發(fā)導(dǎo)致延時過高的可能。接下來考慮是否經(jīng)過了核心層網(wǎng)絡(luò)才導(dǎo)致延時過高？下一步直連3號接入交換機(jī)測試。

第三步、直連工業(yè)相機(jī)所在3號交換機(jī)確認(rèn)時延

將PC直連接入3號交換機(jī)，同時ping交換機(jī)和工業(yè)相機(jī)的IP地址：

可見直連都有存在時延，并且終端響應(yīng)和交換機(jī)響應(yīng)時延一致，大概率就是該交換工作出了問題產(chǎn)生“轉(zhuǎn)發(fā)時延”。為驗證時延，下一步抓包看ICMP交互。

第四步、抓取PC接口交互數(shù)據(jù)包

PC打開wireshark抓包，發(fā)現(xiàn)網(wǎng)絡(luò)中充斥下大量的“UDP單播報文”，包速率近10000包/秒，吞吐量100Mbps：

這很奇怪，PC自己的IP地址并不是192.168.1.102，并且交換機(jī)也沒有配置鏡像，怎么會收到工業(yè)相機(jī)192.168.1.153發(fā)給102的單播流呢？和現(xiàn)場溝通，192.168.1.102是采集器，工業(yè)相機(jī)一方面會將視頻回傳中心控制臺，另一方面會傳給采集器。

從上述情形來看，UDP單播泛洪的根本原因只有1個：采集器102不在網(wǎng)絡(luò)中了，但工業(yè)相機(jī)153已固定好了傳輸目的IP和MAC，即便目標(biāo)不存在，依舊不會影響相機(jī)發(fā)流，所以這個UDP流為——“未知單播幀”！這種幀將在網(wǎng)絡(luò)中被交換機(jī)廣播轉(zhuǎn)發(fā)！

第五步、確認(rèn)采集器在線情況

問題原因是采集器102不在線導(dǎo)致工業(yè)相機(jī)的單播流變?yōu)椤拔粗獑尾狈汉椋訮C ping采集器確認(rèn)連通性：

查看3號交換機(jī)MAC表：

可見該終端是不存在于網(wǎng)絡(luò)中的，可能是線路松動、水晶頭老化。

解決方案

問題原因：Cisco交換機(jī)泛洪巨量單播幀導(dǎo)致自身轉(zhuǎn)發(fā)延時變高

• 加工車間B的采集器因網(wǎng)線松動、水晶頭老化掉線；
• 加工車間B的工業(yè)相機(jī)依舊指定向IP和MAC為采集器的目標(biāo)發(fā)UDP單播流，包速率近10000包/秒，吞吐量100Mbps：；
• 由于3號Cisco交換機(jī)上MAC地址表中不存在UDP包目的MAC條目，故此流為“未知單播包”，按照廣播泛洪轉(zhuǎn)發(fā)；
• Cisco交換機(jī)可能存在性能還是其它的未知原因，廣播泛洪此巨量單播幀后產(chǎn)生了“轉(zhuǎn)發(fā)時延”，導(dǎo)致PC訪問自己和終端時產(chǎn)生了高延時。

解決方案：調(diào)整采集器的網(wǎng)線和水晶頭恢復(fù)網(wǎng)絡(luò)上線

恢復(fù)采集器上線后，可以看到3號交換機(jī)能學(xué)到其MAC地址條目了：

“未知單播幀”變?yōu)橐阎獑尾髁坑山粨Q機(jī)單播轉(zhuǎn)發(fā)，網(wǎng)絡(luò)恢復(fù)正常，延時下降：