背景介紹

甲方是一家船舶機械零件制造型企業，一直使用的是全套Cisco交換機部署的生成樹冗余網絡架構。

根橋為核心層交換機，僅做局域網通信使用。接入端設備由工業相機和采集器，數據回傳至中心控制臺，整網拓撲如下：

網絡拓撲說明：

• 企業有多個加工車間，每個車間網絡均屬于不同VLAN，邏輯隔離；
• 車間交換網絡匯聚上聯至核心交換網絡；
• 車間交換網絡環狀互聯，使能STP協議，阻塞口為網橋鏈路的交換機接口；
• 核心層交換網絡同樣使能STP協議，多鏈路冗余互聯；
• 連接工業相機、采集器等終端接口為STP邊緣接口，拓撲變更不參與計算。

問題描述

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

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

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

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

排查分析

第一步、檢查關鍵配置是否變動

在設計拓撲中，可以看到STP備用鏈路是無線網橋回傳鏈路，眾所周知，無線延時比有線更高且不穩定，那會不會是鏈路切換到無線網橋側傳輸了呢？這里查看3、4號交換機相關配置項：

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

第二步、確認生成樹拓撲是否符合預期

確認交換機配置無誤，下一步確定STP拓撲收斂情況，這里主要看“加工車間B”這個問題局點的設備，其它區域可暫時不用關心，命令：

show spanning-tree interface

查看相關Cisco交換機端口狀態：

可以看到：

• 接入終端的3號交換機的11口是AP口為阻塞狀態，12口為DP口轉發狀態：
• 上聯核心的4號交換機11、12是DP口為轉發狀態

說明交換網絡的拓撲收斂并沒有什么問題，符合預期，排除了數據走無線網橋轉發導致延時過高的可能。接下來考慮是否經過了核心層網絡才導致延時過高？下一步直連3號接入交換機測試。

第三步、直連工業相機所在3號交換機確認時延

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

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

第四步、抓取PC接口交互數據包

PC打開wireshark抓包，發現網絡中充斥下大量的“UDP單播報文”，包速率近10000包/秒，吞吐量100Mbps：

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

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

第五步、確認采集器在線情況

問題原因是采集器102不在線導致工業相機的單播流變為“未知單播幀”泛洪，所以PC ping采集器確認連通性：

查看3號交換機MAC表：

可見該終端是不存在于網絡中的，可能是線路松動、水晶頭老化。

解決方案

問題原因：Cisco交換機泛洪巨量單播幀導致自身轉發延時變高

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

解決方案：調整采集器的網線和水晶頭恢復網絡上線

恢復采集器上線后，可以看到3號交換機能學到其MAC地址條目了：

“未知單播幀”變為已知單播幀，流量由交換機單播轉發，網絡恢復正常，延時下降：