一次广播风暴打停我们机房四小时：完整复盘

先交代背景：公司两个机房，网络设备 800 多台，核心-汇聚-接入三层架构，监控告警都有，值班也有。就是这么一套看着挺齐的体系，去年 10 月被一个物理环路放倒了四个小时。以下是完整复盘，包括我们做错的两步。给后来人参考。

事故时间线

14:05，行政那边先在群里喊 OA 打不开。紧接着视频会议陆续掉线。值班同事看监控，绿色页面上瞬间弹开一片红。

14:10，告警超过 3000 条。不是夸张，是实数——每台设备的每个端口、每个 VLAN 接口全在告，SNMP 采集超时和端口抖动的告警混在一起滚屏。

14:15，我们的第一个错误判断：出口带宽打满了。这个结论看着合理，因为监控大屏上核心交换机上联口利用率确实冲到了 100%。于是先去查出口路由器和防火墙——查了 20 分钟，出口流量只有平时的 60%，没问题。方向错了，白扔 20 分钟。

14:35，回到内网。ping 核心，丢包 30% 起跳；ping 部分接入交换机直接不通。但奇怪的是丢包不是全网的——同一个机房，有的 VLAN 完全正常，有的几乎全丢。这个“部分 VLAN 全丢”的特征，后来复盘时才意识到就是环路的标准信号，当时没人在意。

14:40，第二个错误：怀疑是核心交换机卡死，直接重启了核心 A。

事后看这一步最冤：重启没解决任何问题（因为根因在接入层），反而让本来还撑着的部分业务又断了一轮，冷启动加协议收敛花了 11 分钟。经验教训写在前面：找不到根因的时候，重启是最贵的操作。

15:00，一位老同事上线。他看了一眼丢包的分布，说了句“查 MAC 漂移”。登录核心交换机，看 MAC 地址表：

display mac-address // 同一个 MAC 在两个不同端口之间反复跳动

一个 MAC 地址同时出现在两个上联口，每几秒跳一次。这是教科书级的环路特征——广播帧在环里转，MAC 表被反复刷新覆盖。到这一步，方向终于对了。

15:20，顺着 MAC 漂移定位到一台接入交换机（华为 S5735，三层楼的配线间）。看接口状态，其中一个端口是新启用的，description 还没写。配线间现场一看：新办公区装修，工人图省事把一根网线的两头都插在了新装的小交换机上。8 口非管理型交换机，几十块钱那种。物理环，就这么简单。

display stp brief

15:26，拔线。全网 40 秒内恢复。

从用户报障到恢复 81 分钟。但加上我们重启核心造成的二次中断、业务侧确认恢复、以及事后应急值守，这一天从 14:05 折腾到 17:40，视频会议系统当天彻底废了。这就是标题里那四个小时。

复盘：五个问题，一个比一个扎心

问题一：接入层环路检测，全网没配。

这是根因中的根因。STP 本来防环，但接入交换机那些口配的是 edge port（边缘端口），底下接的是非管理小交换机，BPDU 根本不过去。环路检测（loopback-detect / loop guard）是另一道防线，我们没开。全网 400 多台接入交换机，一台都没有。

事故后一周内我们补了配置基线，华为设备两行：

• loopback-detect enable
• loopback-detect action shutdown（配 port-error-down 恢复策略，别用默认的 trap-only）

锐捷、华三的命令名字不一样，思路一样：检测到环自动关口，而不是只发个告警。

问题二：3000 条告警等于零条告警。

风暴起来的瞬间，监控的告警是“每端口 × 每指标”独立触发的，3000 条同时到，值班看到的就是一堵墙。里面其实只有一类是根因（MAC 漂移、端口抖动），其余全是被连坐的。

事后我们换了工具，选型时最看重的能力就是告警关联和压缩：同一个故障源引发的多条告警压成一条、按拓扑依赖判定谁根因谁受害者、自适应阈值减少误报。现在用的是 ManageEngine（卓豪）的 OpManager，四层告警治理是它打动我们的点——事故场景下的价值很直白：3000 条压成十几条，第一屏就是“某接入交换机 22 口 MAC 漂移”。工具不是重点，没有告警压缩能力的监控，规模一大就是告警洪水，这是拿四个小时换来的结论。

问题三：MAC 漂移这种强信号，不在告警清单里。

定位环路的黄金信号，我们的监控根本没采。恢复后加了：MAC 地址重复出现于多端口、端口广播包速率突增（每秒过万直接告）、单端口流量 10 倍于基线。这三条现在是我们最灵的告警，一年能提前拦两三回。

问题四：流量可视化只覆盖了出口，内网是黑的。

第一阶段 20 分钟的误判，根源在这：出口链路有流量数据，内网核心没有。如果当时能看到核心上联的流量构成——某个 VLAN 的广播流量占了 80%——5 分钟就能锁定方向。事故后核心和出口全开了 NetFlow 采集（用的 NetFlow Analyzer，和 OpManager 一个界面），现在出任何“网络慢”的工单，值班第一件事拉流量 TopN，按 IP、应用、VLAN 三个维度切，两分钟定位到源。

问题五：值班没有处置权限，多了 25 分钟。

最扎心的一个。15:20 已经定位到那台交换机了，值班同事不敢拔——动生产设备要项目经理批。电话打过去，项目经理在开会，又找主管，一圈下来 25 分钟。事后我们改了应急预案：环路、广播风暴这类“每分钟都在扩大损失”的故障，值班有一线处置权，先拔后补流程。制度比技术便宜，但最难改。

那根网线值多少钱

复盘最后算了一笔账：4 小时业务受影响，按公司业务系统的营收折算，加上视频会议全部改期的协调成本，那次事故的直接损失估计在六位数。而事故链的起点是一根 15 块钱的网线，和全网 400 台交换机上没配的两行命令。

网络故障最有意思也最残忍的地方：它总能精准找到你体系里最薄的那一块。这次是环路检测和告警治理，下次可能是别的。写这篇不为别的，就一个建议——拿我们这五个问题对照你自己的环境过一遍，特别是第一条，接入层的环路检测，现在就可以查。别等你的 15 块钱网线出现。