实战：Ping突发高延时？生成树架构，备受网工推崇的Cisco交换也遭老罪咯！
甲方是一家船舶机械零件制造型企业，一直使用的是全套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”这个问题局点的设备，其它区域可暂时不用关心，命令：
查看相关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地址条目了：
“未知单播帧”变为已知单播帧，流量由交换机单播转发，网络恢复正常，延时下降：
