一、问题背景

公司园区网采用典型三层架构：核心层一台华为 S7706（以下简称 CORE）作为 STP 根桥，汇聚层两台 S5730，接入层大量 S5731 接入交换机，全网联一、二层均启用 MSTP（多生成树）。根桥 CORE 上通过 stp root primary 设定为最优根，优先级 0（实际显示为 0/4096，按实例计），确保生成树拓扑稳定。

节后复工第一天，行政楼 3 层新扩了 12 个工位，施工方临时搬来一台华为 S1730S 傻瓜型可网管交换机（以下简称 NEW）用于补点。该交换机按惯例应作为接入层叶子节点挂到现有接入交换机下，不配置 STP 优先级（用默认 32768），乖乖当阻塞端口的下游即可。中午 13 点左右，行政楼整层及相邻的 2、4 层陆续出现网络卡顿、视频会议花屏、部分工位甚至拿不到 IP。

二、故障现象

现场观察与监控告警汇总如下：

1. 行政楼 2/3/4 层用户大面积反馈“网页打开慢、钉钉转圈、共享文件夹访问超时”，但核心业务系统（位于数据中心）偶发可达，整体是“时通时断”的严重劣化，而非完全断网。
2. 登上汇聚交换机 display interface brief，发现多个上联口入方向带宽长期 90%+，且 Broadcast 计数每秒几万包疯涨：

1
2
3

Interface                  PHY   Protocol  InUti  OutUti  Broadcast(pps)
GE0/0/24                   up    up        98%    95%     42000
GE0/0/23                   up    up        97%    92%     39000

3. 接入交换机面板端口指示灯呈“集体疯狂闪烁”状态，典型广播风暴特征。
4. 网管平台 Zabbix 触发 High Broadcast Ratio 与 STP Topology Change 告警，且 Topology Change Count 在几分钟内从 0 涨到 600+，说明生成树在频繁震荡重算。

三、排查过程

广播风暴 + 拓扑频繁变更，基本锁定在二层环路或 STP 异常，按“先抑制、再定位”的思路推进。

1. 先登录核心 CORE，查看当前根桥是否还是自己：

1

display stp

1
2
3
4
5

-------[CIST Global Info][Mode MSTP]-------
Protocol Status       : Enabled
Bridge Priority       : 0
Root Bridge ID        : 4c1f-ccxx-xxxx
Root Cost             : 0

Root Bridge ID 的 MAC 不是 CORE 自己的桥 MAC，而是 4c1f-cc...，说明根桥被别人抢走了！本应是自己（Cost 0、自己就是根），现在 Root Cost 仍是 0 只是因为命令行显示的是“到根的开销”，需要进一步比对。

2. 精确查看根桥身份：

1

display stp root

1
2

Root Bridge ID   : 4c1f-cc12-3456
Root Bridge Cost : 0

4c1f-cc12-3456 经 MAC 前缀查询是华为 S1700 系列，正是那台新搬来的 NEW 交换机！它成了根桥。

3. 查看 NEW 的 STP 优先级：

1

display stp | include Bridge Priority

在 NEW 上回显 Bridge Priority : 0（被施工方误设为 stp priority 0 或 stp root primary 想“保证稳定”），优先级高于 CORE，于是 STP 重新选举，NEW 抢占根桥。

4. 根桥漂移后，原稳定拓扑被推翻， NEW 与周边交换机之间形成次优路径且出现临时环路窗口，广播帧在环路中无限泛洪，形成广播风暴。再查拓扑变更：

1

display stp topology-change

1
2

Topology Change Count : 612
Last Topo Change Time : 2025-02-03 13:02:11

与告警时间吻合，确认 NEW 接入是触发点。

四、解决方案

目标是让 CORE 恢复根桥、消除环路、压制风暴。

1. 应急抑制：在汇聚/核心上临时对上联接入口开启广播抑制，先止血，避免风暴蔓延：

1
2

interface GigabitEthernet0/0/24
 storm-control broadcast min-rate 1000 max-rate 5000

2. 纠正根桥：将 NEW 的 STP 优先级改回默认，并取消其抢占设置：

1
2
3

system-view
stp priority 32768
undo stp root

3. 强制 CORE 重新稳坐根桥（双保险）：

1
2

system-view
stp root primary

4. 等待 STP 重新收敛后，再次 display stp root，根桥 MAC 变回 CORE，Topology Change Count 停止增长，端口 Broadcast pps 回落到个位数，用户网络在 3 分钟内恢复。

5. 事后复盘：NEW 作为临时补点本应只做接入，施工方却顺手配了根桥优先级。已要求所有接入层设备出厂/入场前统一刷标准配置模板，禁止任何非核心设备设置 stp root 或优先级低于 8192。

五、根因分析

根因是 NEW 交换机被错误配置了 STP 优先级 0（等价于 stp root primary），使其桥优先级高于原根桥 CORE。MSTP 选举根桥时比较“桥优先级 + MAC”，优先级数值越小越优，0 优于 CORE 的 4096（显示值），于是 NEW 被选举为新的根桥。

根桥变更触发全网生成树重算：大量端口角色/状态翻转（根端口、指定端口、阻塞端口重新分配），在收敛的过渡窗口内，本应阻塞的冗余链路短暂进入转发态，与既有物理连线构成二层环路。广播帧、未知单播帧在环路中反复泛洪且无法 TTL 终结，迅速演变为广播风暴，表现为端口灯狂闪、Broadcast pps 爆表、终端卡顿断网。拓扑每次震荡又产生新的 TC（Topology Change）报文，进一步加剧不稳定，形成“变更—环路—风暴—再变更”的恶性循环，直到根桥归位、环路消除才停止。

六、预防措施

1. 根桥保护（Root Protection）：在所有的接入交换机上联口配置 stp root-protection，一旦收到更优 BPDU 直接将该口置为 root-inconsistent（丢弃）状态，从协议层面杜绝下级设备抢占根桥。

1
2

interface GigabitEthernet0/0/1
 stp root-protection

2. BPDU 保护（BPDU Protection）：在连接终端/临时设备的边缘端口开启 stp edged-port enable 并全局 stp bpdu-protection，收到 BPDU 立即 shutdown 边缘口，防止私接设备扰乱生成树。
3. 标准配置模板 + 入场审计：所有交换机（含临时补点）入场前必须刷公司标准模板，模板中明确禁止设置 stp root 与低优先级，并由网络组验收后方可上线。
4. 环路防护与 TC 防护：开启 loop-protection 与 tc-protection，限制单位时间 TC 报文处理速率，避免频繁重算拖垮 CPU。
5. 监控加固：在 Zabbix 对 Topology Change Count、Broadcast pps、端口利用率设阈值告警，争取在风暴成形前发现。

七、总结

这起广播风暴的根因不在“环路本身”，而在“根桥被抢”——一台被误配优先级的临时交换机颠覆了整网生成树，收敛窗口里出现的瞬时环路才是风暴的直接推手。排查关键在于第一时间 display stp root 比对根桥 MAC，发现身份异常便知有人抢桥。最该记住的教训是：STP 不能只靠“约定”，必须用 root-protection、bpdu-protection 等协议机制把根桥和边缘口钉死，再配合标准模板与入场审计，才能避免“好心配置”变成全网故障。