一次园区网全网变慢的排查实录：从广播风暴到环路定位

时间：2025年某月某日
环境：某大型园区网（核心层+汇聚层+接入层架构）

一、 故障突袭：平静的周一早晨

周一上午9点，正是园区办公的高峰期。监控大屏突然告警闪烁，用户侧的投诉电话瞬间打爆了运维组：“网页打不开！”“ERP系统转圈圈！”“视频会议卡成PPT！”

从现象来看，并不是某个单独的区域掉线，而是全网性的业务中断。这种“伤筋动骨”的故障，往往意味着核心层或者关键汇聚层出了问题。

二、 初步诊断：网络真的“堵”了

登录核心交换机（华为/H3C系列），第一时间查看CPU和内存利用率。

display cpu-usage

现象：核心交换机CPU利用率飙升至 85% 以上，且持续居高不下。对于核心设备来说，这是一个非常危险的信号。

接着查看接口流量，重点关注上行端口和VLAN接口：

display interface brief

发现：核心交换机的下行端口（连接汇聚层）的 Broadcast（广播包）计数在疯狂跳动，每秒增长速度肉眼可见。

初步结论：网络中存在异常流量，导致设备CPU过载，转发性能下降。极大概率是广播风暴。

三、 深入排查：谁在制造风暴？

广播风暴通常是网络二层环路最典型的症状。现在的问题是：环路在哪里？

1. 锁定风暴源头

在核心交换机上，我迅速开启了流量统计功能，试图通过ACL或镜像端口抓包分析。但由于CPU已经高负载，复杂的抓包操作可能会加剧故障。于是，我采用了更直接的“看日志”法。

display logbuffer

日志中充斥着大量的 MAC address flapping（MAC地址漂移）告警：

Warning: MAC address 0000-5e00-0101 has moved from GigabitEthernet1/0/10 to GigabitEthernet2/0/20. Warning: MAC address 0000-5e00-0101 has moved from GigabitEthernet2/0/20 to GigabitEthernet1/0/10.

关键线索：同一个MAC地址在两个不同的端口之间频繁跳变。这是二层环路的铁证！交换机不知道该往哪个端口转发数据帧，导致数据帧在环路中无限循环复制，瞬间吞噬带宽。

2. 追踪漂移端口

根据日志，漂移发生在 GigabitEthernet1/0/10 和 GigabitEthernet2/0/20 两个端口之间。这两个端口分别下联至两台不同的汇聚交换机。

这意味着，环路很有可能发生在这一层的下联网络中，或者是两台汇聚之间的互联出现了逻辑错误。

四、 紧急止损：切断环路

在排查具体原因之前，必须先恢复业务。既然锁定了这两个端口存在环路，我尝试在这两个端口上开启风暴控制：

interface GigabitEthernet1/0/10 storm-control broadcast min-rate 1000 max-rate 1500

然而，由于风暴过于猛烈，风暴控制的效果并不明显。为了保全大局，我不得不采取“断臂求生”的策略：关闭其中一个处于漂移状态的端口。

interface GigabitEthernet1/0/10 shutdown

奇迹发生：端口关闭后几秒钟，核心交换机CPU利用率断崖式下跌至 15%，用户侧反馈网络恢复畅通。

五、 根因分析：那个“罪魁祸首”

网络恢复了，但问题没解决。为什么会产生环路？这需要去现场查看。

我来到了连接 GigabitEthernet1/0/10 对应的汇聚交换机所在的弱电间。经过排查，发现这台汇聚交换机下联的一个接入交换机配置异常。

现场情况还原：

1. 某接入交换机原本通过单光纤上联至汇聚A。

2. 周末有施工队进场，为了“增加冗余”，施工人员私自从该接入交换机拉了一根网线，上联到了汇聚B。

3. 致命错误：这根新拉的上联线被插在了接入交换机的 Access端口（属于VLAN 10），而不是预期的Trunk端口或配置正确的聚合口。

4. 同时，汇聚A和汇聚B之间本身就有二层互联线。

环路逻辑图：

接入交换机 -> 汇聚A -> 汇聚B -> 接入交换机 -> 汇聚A …

由于新接入的端口配置错误，STP（生成树协议）计算失败，导致数据帧在接入层与汇聚层之间形成了一个巨大的二层环路。

六、 复盘与反思：如何避免悲剧重演？

这次故障虽然排查时间短，但影响范围广。事后我们进行了深刻的复盘：

1. STP配置疏忽：

• 核心交换机应配置为 Root Primary，汇聚为 Secondary。

• 接入层端口应开启 BPDU Protection（BPDU保护），防止私接设备发送BPDU干扰生成树。

• 边缘端口应开启 Root Protection（根保护）或 Loop Protection（环路保护）。

2. 端口管理规范：

• 所有未使用的端口应默认处于 shutdown 状态。

• 新端口上线前必须由网络工程师进行配置，严禁施工方私自插线配置。

3. 监控告警优化：

• 此次故障其实在风暴形成初期就有端倪，如果我们在接入层交换机部署了广播包阈值告警，或许能在用户投诉前发现问题。

4. 环路检测工具：

• 考虑在交换机上全局开启 Loopback-detection（回环检测）功能，当端口检测到环路时自动 Err-Disable，将故障隔离在最小范围。

七、 总结

网络排查的过程就像破案。

• 现象是全网变慢；

• 线索是CPU高负载和广播包计数；

• 证据是MAC地址漂移日志；

• 凶手是错误的二层线路连接和端口配置。

作为网络工程师，面对环路故障，最核心的思路就是：先止损（断开环路），后分析（查配置、查物理），最后加固（优化STP、规范管理）。希望这次实录能给各位同仁的日常运维工作带来一点参考。