交换机“CPU 使用率 100%”导致全楼卡死？一次从广播风暴到环路的完整排障

一、故障背景：全楼突然“卡成 PPT”

那天，我正在校园机房巡检，突然接到教室管理员的电话：

“整层楼的网络都卡了，像 PPT 一样一页一页刷！”

我立刻远程登陆楼层交换机，发现一个惊人的现象：

交换机 CPU 使用率：100% 持续 10 分钟
    •    Ping 延迟从 1ms 升到 300ms
    •    SSH 登陆几乎卡死
    •    数据转发明显停顿

对交换机来说，CPU 打满意味着整个楼层都“半瘫痪”了。

我第一次遇到这么严重的“全楼级故障”，于是和工程师开始展开完整排障。

二、第一阶段：是上行带宽被打满了吗？

我们首先查看上行口流量：

display interface GigabitEthernet 0/0/X

结果发现带宽使用率正常：
    •    上行带宽峰值只有 30%
    •    没有大量广播
    •    没有异常突发写入

这意味着：不是外部原因，而是交换机内部被“某种行为”拖死。

三、第二阶段：查看日志——每次 CPU 100% 都必须看这里

日志是运维的“黑匣子”。

我们查看：

display logbuffer

出现几条可疑记录：
    •    大量 ARP 请求
    •    重复 MAC 地址漂移
    •    STP 警告：BPDU 变化频繁

三条信息放在一起，只可能指向一个方向：

🔥 网络环路或广播风暴正在发生！

四、第三阶段：快速定位“风暴源”

我们开始逐个检查端口流量。

display interface counters error

发现其中某个端口：
    •    入方向广播包：每秒 30000+
    •    MAC 地址表不停刷新（漂移）
    •    错包率巨大

这说明：

这个接口连接的设备或链路正在制造“广播风暴”。

但是这个端口连接的不是交换机，而是——某间教室的一个 AP。

五、第四阶段：去现场检查，发现“罪魁祸首”的离谱原因

我们赶到现场，发现 AP 有两根网线：
    •    一根从弱电箱来
    •    另一根从隔壁教室的面板来

学生为了“改善 WiFi”，擅自把两个网口都插进了同一个 AP！

这就等价于把一根网线打成了“回环”——无视 STP 的物理环路。

这会造成：

✔ 无限循环的广播包

✔ MAC 地址不停漂移

✔ 交换机 CPU 被打满

✔ 整层楼瘫痪

属于典型的“低级错误，引发大事故”。

六、第五阶段：断开环路后，系统瞬间恢复

我们拔掉多余的网线后：
    •    CPU 从 100% → 8%
    •    网络从一卡一卡 → 恢复流畅
    •    日志告警全部消失
    •    MAC 表不再漂移

整个楼层 5 秒内恢复。

这证明：

故障完全就是因为“用户私自接线引发广播风暴”。

七、技术深挖：为什么环路如此恐怖？

交换机会不断广播：
    •    ARP
    •    DHCP
    •    广播包
    •    多播
    •    探测包

环路会导致这些包：

一条回路 → 无限复制 → 席卷整个网络

造成：

❌ CPU 打满

❌ ARP 表被刷新崩溃

❌ 多播泛洪

❌ 整楼网络中断

❌ 即便重启交换机也会再次崩溃

这是弱电和校园网络里最常见、危害最大的“致命事故”。

八、为什么 STP 没能阻止这次环路？

因为：
    •    这台 AP 是“二次转接设备”
    •    STP 在 AP 侧被关闭
    •    交换机无法阻断 AP 内部产生的环路

简单来说：

环路发生在 AP 内部，交换机根本防不住。

这也是为什么工程师一直告诫：

“AP、路由器、交换机千万不要双网线互联！”

九、事后优化：为防止再次发生，我们做了三件事

✔ ① 开启 BPDU Guard（BPDU 防护）

任何端口收到 BPDU → 自动关闭
杜绝错误接线导致二级环路。

✔ ② AP 端口开启 storm-control

限制广播包、未知单播包速率。

✔ ③ 宿舍、教室张贴“禁止乱接网线”提示

并纳入巡检规范。

这三步极大降低了类似事故再次发生的概率。

十、我从这次事故中得到的成长

这一整次系统级故障，让我真正理解：

① 运维排障不是看带宽，而是看“异常行为”

CPU 打满 ≠ 上行满
CPU 打满通常来自：
    •    环路
    •    欺骗
    •    广播风暴
    •    MAC 漂移
    •    病毒感染
    •    DHCP 泛洪

这是一个思维升级。

② STP 不是万能的，任何“二级设备”都是隐患

特别是：
    •    学生自带 AP
    •    家用路由器
    •    网线分配器
    •    二级交换机

它们极容易制造环路。

③ 排障一定要“逐段验证”，不能靠猜

我的排障路径是：
    1.    看 CPU
    2.    看日志
    3.    看错误包
    4.    找广播源
    5.    去现场核查
    6.    修复并验证

这套流程在后来无数项目里都帮助了我。

十一、结语：运维的世界里，没有小问题

这一层楼瘫痪事件让我第一次真正意识到：

网络崩溃不是技术问题，而是人性 + 习惯 + 物理层造成的综合问题。

也让我更加确定：
未来我要走的，就是“运维 + 可观测性 + 安全”的道路。