上周三下午，何通环路运维群里炸了锅。抓包核心交换机的分析一个端口指示灯疯了似的狂闪，办公网访问OA系统时断时续，内网ping网关的何通环路延迟从1ms飙到300ms，丢包率20%。抓包我登上核心交换机一看，分析CPU利用率直接冲到85%。内网这种症状十有八九是何通环路二层环路——广播帧在环里转圈，把带宽和CPU全吃光了。抓包

但问题来了：交换机上没开STP诊断，分析哪个端口在环路？内网哪台设备接错了线？靠猜不行。我抓起笔记本，何通环路接上核心交换机的抓包镜像端口，打开Wireshark。分析

抓包第一眼：广播风暴的指纹

Wireshark的抓包窗口一开，数据包像瀑布一样往下滚。不用细看，eth.dst == ff:ff:ff:ff:ff:ff的广播帧占了八成以上。正常网络里广播帧比例通常低于5%，现在这个数字说明广播帧在无限循环。

更关键的是，同一个源MAC的广播帧反复出现。我随手点开一个，源MAC是00:1a:2b:3c:4d:5e，序列号几乎一样，只是IP层的TTL在递减。这说明帧在绕圈，每经过一台交换机TTL减一，直到归零才消失。

过滤器：eth.dst == ff:ff:ff:ff:ff:ff && ip.src == 192.168.1.100

加上这个过滤器后，同一个广播帧在1秒内被抓到了47次。47次。正常情况下一台交换机只会转发一次。这个数字直接坐实了环路的存在。

用IO Graph定位风暴周期

Wireshark的统计功能比肉眼靠谱。我打开Statistics → IO Graph，把Y轴单位设成Packets per 100ms。图表上出现了一个规律的锯齿波——每200ms一个尖峰，峰值约1200个包，谷值也有400个。这种周期性说明环路里有一个设备在持续产生广播，可能是ARP请求或者DHCP发现。

如果锯齿波是均匀的，说明环路路径固定；如果波形杂乱，可能有多条环路或者设备在反复重启。我遇到的是前者，路径固定，说明只有一条环。

顺着MAC地址找凶手

接下来要做的是找出环路的入口和出口。Wireshark里点开一个广播帧，看它的源MAC。然后在核心交换机的MAC地址表里搜这个MAC，发现它出现在两个端口上：Gi0/1和Gi0/24。正常情况下一个MAC只能对应一个端口。两个端口意味着这个MAC的帧从两个方向都能到达，典型的环路特征。

我顺着Gi0/24查下去，发现它连的是一台接入交换机。再登到那台接入交换机上，查它的MAC表，发现同一个MAC又出现在两个端口：Fa0/5和Fa0/10。继续追，Fa0/5连的是一台桌面交换机，Fa0/10连的是另一台桌面交换机。两台桌面交换机之间又有一根网线直连——就是这根线，把整个网络接成了一个环。

整个过程在Wireshark里只用了两个过滤器：一个抓广播，一个抓特定源MAC。前后不到十分钟。

几个容易踩的坑

抓包位置很关键。如果你在接入交换机上抓，可能只看到广播帧增多，但看不到循环的路径。最好在核心交换机的镜像端口抓，或者用交换机的端口镜像功能把可疑端口的流量复制出来。

另外，Wireshark默认的抓包缓冲区只有2MB，广播风暴几秒钟就能填满。记得在Capture Options里把缓冲区调到200MB以上，或者用ring buffer模式循环覆盖。我那次抓了30秒就停了，文件大小1.2GB，足够分析。

还有一点：如果网络里开了STP，环路可能被阻塞端口挡住了，你抓不到风暴。但STP收敛需要时间，如果拓扑变化频繁，或者有人把STP关了，风暴就会爆发。所以抓包前先确认STP状态，show spanning-tree看一眼根桥和端口角色。

环路解决后，核心交换机CPU从85%掉到12%，ping延迟回到1ms。那根多余的网线被拔掉，两端贴上了“禁止连接”的标签。Wireshark的抓包文件我留了一份，下次再遇到类似问题，直接对比广播帧的周期和源MAC，五分钟就能定位。