广播风暴 on Zero Day Notes

记一次交换机物理环路引发的整栋楼广播风暴

Mon, 29 Jun 2026 11:16:49 +0000

问题背景

某周一上午9:15，正是全员打卡上班的高峰时段，IT服务台电话瞬间被打爆——6楼整层约120台终端全部断网，OA系统、邮件、ERP一律打不开，连本地文件共享都无法访问。与此同时，5楼和7楼也开始零星报障，部分终端时断时续。

这是一栋12层的办公大楼，核心交换机是两台华为S12700做CSS集群，每层楼一台华为S5735-L48T4X-A做接入，上行10G光纤到核心，接入交换机之间没有横向互联。6楼接入交换机是SW-F6-01，负责6楼全部48个信息点。网络拓扑很标准：核心—接入两层架构，按理说不该出现环路。但事实是——6楼瘫痪了，而且速度极快，从第一个报障电话到整层断网，不到3分钟。

紧急程度：P1——整个楼层业务中断。

故障现象

从监控系统和现场排查来看，故障表现非常典型：

1. 终端侧现象

所有6楼终端Ping网关10.6.254.1丢包率95%以上，偶尔通一个包延迟高达2000ms+
DHCP无法获取地址，已有IP的终端ARP表混乱，网关MAC频繁跳变
部分终端右下角网络图标黄色感叹号，提示"未识别的网络"

2. 交换机侧现象

登录SW-F6-01，CPU利用率飙到99%，命令行响应极慢，display cpu-usage需要30秒才返回
display interface brief看到多个端口流量异常：G0/0/1到G0/0/48中有十几个端口出方向流量持续跑到线速（1000Mbps）
display mac-address表项数量从正常的200条暴涨到64000条（MAC表容量上限），且MAC地址在端口之间疯狂漂移
核心交换机CSS集群CPU也达到78%，6楼VLAN对应的VLANIF接口入方向流量达到8Gbps（正常不到200Mbps）

3. 日志关键信息

SW-F6-01上持续刷出以下日志：

%%01L2IFPPI/4/MAC_FLAPPING_ALARM(l):OID 1.3.6.1.4.1.2011.5.25.160.3.7
MAC address 00e0-fc12-3456 has flapped from GE0/0/5 to GE0/0/22, lasted 2 seconds.
%%01L2IFPPI/4/MAC_FLAPPING_ALARM(l):OID 1.3.6.1.4.1.2011.5.25.160.3.7
MAC address 00e0-fc12-3456 has flapped from GE0/0/22 to GE0/0/5, lasted 1 seconds.
%%01L2IFPPI/4/MAC_FLAPPING_ALARM(l):OID 1.3.6.1.4.1.2011.5.25.160.3.7
MAC address ffff-ffff-ffff in VLAN 206 has flapped from GE0/0/5 to GE0/0/22

核心交换机日志：

1
2

%%01SECE/4/ARPMISS(l):Speed of ARP Miss packets exceeded the configured rate limit.
%%01SECE/4/ARPMISS(l):Speed of ARP Miss packets exceeded the configured rate limit.

MAC地址在GE0/0/5和GE0/0/22之间反复跳变，且出现了全F的广播MAC漂移——这是典型的二层环路广播风暴特征。

排查过程

第一步：确认故障范围

先通过核心交换机确认故障边界。登录核心CSS集群，查看各VLAN接口流量：

<CORE-SW> display interface Vlanif 206
Vlanif206 current state: UP
Line protocol current state: UP
Description: 6F-Office-VLAN
Input bandwidth utilization: 98%    ← 正常应 <5%
Output bandwidth utilization: 3%
Input: 8234567 packets/sec, 8.2 Gbps
Output: 12345 packets/sec, 12 Mbps

VLAN 206（6楼办公VLAN）入方向流量8.2Gbps，而上行10G链路带宽的80%+都被这些垃圾流量吃掉了。其他楼层VLAN流量正常。

结论：故障范围锁定在6楼VLAN 206，且是二层广播风暴。

第二步：判断环路类型

广播风暴的常见原因有三：物理环路、ARP风暴攻击、蠕虫病毒扩散。通过以下特征快速判断：

特征	物理环路	ARP攻击	蠕虫病毒
MAC漂移	两个端口间高频往复	分散，无规律	分散
广播包占比	>95%	ARP包为主	混合流量
全F广播MAC漂移	有	无	偶尔
流量对称性	两个端口双向跑满	单向为主	不定

SW-F6-01的MAC漂移集中在GE0/0/5和GE0/0/22两个端口之间，且双向流量都跑到线速——典型物理环路特征。

第三步：定位环路端口

在SW-F6-01上执行MAC漂移检测，获取精确的环路端口对：

[SW-F6-01] display mac-address flapping
Flapping VLAN 206:
MAC Address    From/To        Flapping Time
00e0-fc12-3456 GE0/0/5  -> GE0/0/22    2026-06-29 09:17:32
00e0-fc12-3456 GE0/0/22 -> GE0/0/5     2026-06-29 09:17:33
00e0-fc89-abcd GE0/0/5  -> GE0/0/22    2026-06-29 09:17:33
00e0-fc89-abcd GE0/0/22 -> GE0/0/5     2026-06-29 09:17:34

MAC地址只在GE0/0/5和GE0/0/22之间跳变，环路就出在这两个端口之间。

第四步：确认物理连接

通过网管系统查看GE0/0/5和GE0/0/22的端口描述信息：

[SW-F6-01] display interface GE0/0/5
GigabitEthernet0/0/5 current state: UP
Description: 6F-MeetingRoom-A

[SW-F6-01] display interface GE0/0/22
GigabitEthernet0/0/22 current state: UP
Description: 6F-MeetingRoom-A-2

两个端口都连着6楼A会议室。联系行政确认：A会议室有6个信息点，4个墙面面板+2个地插。今天早上8:50有一个供应商来会议室做产品演示，需要联网，自行从地插拉了一根网线插到墙面上——他把同一台交换机下的两个端口用一根网线连了起来。

地插（GE0/0/22）——网线——墙面面板（GE0/0/5），物理环路就这样形成了。

第五步：检查STP状态——为什么环路没有自动阻断？

这是最关键的问题。按照我们的网络标准，所有接入交换机都应该启用MSTP，环路应该被STP自动阻断。查看MSTP状态：

[SW-F6-01] display stp interface GE0/0/5 brief
Port           Role   State
GE0/0/5        -      -

[SW-F6-01] display stp interface GE0/0/22 brief
Port           Role   State
GE0/0/22       -      -

端口STP角色显示为空——说明STP根本没在这两个端口上生效。进一步检查全局MSTP配置：

1
2

[SW-F6-01] display stp global
MSTP is disabled globally.

MSTP全局未启用！ 这才是问题的根源——去年6楼交换机因硬件故障更换，新交换机上线时是用的初始配置模板，模板里漏掉了stp enable全局命令。虽然端口下有stp edged-port enable的配置，但全局STP未开启，端口级的STP配置等于白搭。

第六步：紧急止血

必须立即打断环路。有两种方案：

方案A：直接shutdown环路端口——风险低，见效最快 方案B：全局启用STP——在广播风暴期间启用STP，STP报文可能被淹没在风暴中无法正常收发，收敛时间不可控

选择方案A，先shutdown再处理根因：

[SW-F6-01] interface GE0/0/5
[SW-F6-01-GE0/0/5] shutdown
[SW-F6-01-GE0/0/5] quit
[SW-F6-01] interface GE0/0/22
[SW-F6-01-GE0/0/22] shutdown
[SW-F6-01-GE0/0/22] quit

Shutdown后10秒，CPU从99%降到12%，MAC表项从64000条降到180条，6楼网络在30秒内完全恢复。

解决方案

1. 紧急恢复（已完成）

shutdown环路端口，网络恢复正常。通知会议室供应商正确使用单口连接。

2. 根治——全局启用MSTP

在SW-F6-01上启用MSTP并配置最佳实践参数：

# 全局启用MSTP
[SW-F6-01] stp mode mstp
[SW-F6-01] stp enable

# 配置MSTP域（与核心交换机保持一致）
[SW-F6-01] stp region-configuration
[SW-F6-01-mst-region] region-name HQ-OFFICE
[SW-F6-01-mst-region] revision-level 1
[SW-F6-01-mst-region] instance 1 vlan 201 to 210
[SW-F6-01-mst-region] active region-configuration
[SW-F6-01-mst-region] quit

# 核心交换机作为根桥
[SW-F6-01] stp instance 0 root secondary
[SW-F6-01] stp instance 1 root secondary

# 优化STP收敛参数
[SW-F6-01] stp timer hello 2
[SW-F6-01] stp timer forward-delay 15
[SW-F6-01] stp timer max-age 20

3. 接入端口安全加固

对所有接入端口启用BPDU Guard和边缘端口，防止终端侧引入环路：

# 批量配置接入端口
[SW-F6-01] port-group group-member GE0/0/1 to GE0/0/48
[SW-F6-01-port-group] stp edged-port enable
[SW-F6-01-port-group] stp bpdu-protection enable
[SW-F6-01-port-group] quit

# 上行端口保持默认STP参与（不设为边缘端口）
[SW-F6-01] interface XGE0/0/1
[SW-F6-01-XGE0/0/1] undo stp edged-port
[SW-F6-01-XGE0/0/1] quit

BPDU Guard的作用：如果有人在边缘端口上接入了一台交换机（发了BPDU），端口会立即err-down，阻断环路产生。这是防止终端侧环路的最有效手段。

4. 开启环路检测（Loop Detection）作为双保险

即使STP启用，也配置环路检测作为补充防护：

[SW-F6-01] loop-detect enable
[SW-F6-01] loop-detect interval 5
[SW-F6-01] port-group group-member GE0/0/1 to GE0/0/48
[SW-F6-01-port-group] loop-detect action shutdown
[SW-F6-01-port-group] quit

5. 全网排查STP状态

对全部12台接入交换机逐一检查MSTP是否全局启用：

1
2

# 在每台接入交换机上执行
display stp global

发现除了SW-F6-01，SW-F9-01和SW-F11-01也是MSTP全局关闭的——这两台也是去年硬件更换时遗漏的。立即补上相同的MSTP配置。

根因分析

这次故障的根本原因是双重防护缺失：

1. 直接原因：会议室供应商用一根网线连接了同一台交换机下的两个接入端口，形成物理环路，触发广播风暴。

2. 根本原因：SW-F6-01（以及SW-F9-01、SW-F11-01）的MSTP协议全局未启用。去年这三台交换机因硬件故障更换，上线时使用的初始配置模板遗漏了stp enable全局命令。虽然端口下配置了stp edged-port enable，但在全局STP关闭的情况下，端口级STP配置不会生效，等于形同虚设。

3. 管理原因：交换机上线缺少配置合规检查流程。新设备上线后只有Ping通网关的连通性验证，没有协议级检查（如STP状态、LLDP邻居、端口安全策略等），导致配置遗漏长期潜伏。

预防措施

1. 配置基线检查自动化

编写Python脚本，通过NETCONF/SSH批量巡检所有接入交换机的关键配置项，纳入每日自动巡检：

#!/usr/bin/env python3
"""接入交换机配置基线巡检脚本"""
import paramiko
import csv

CHECK_LIST = [
    ("STP全局状态", "display stp global", "MSTP is enabled"),
    ("Loop Detection", "display loop-detect", "Loop detect is enabled"),
    ("NTP同步状态", "display ntp-service status", "clock is synchronized"),
    ("SSH版本", "display ssh server status", "SSH version : 2.0"),
    ("SNMPv3", "display snmp-agent group", "v3"),
]

def check_switch(host, username, password):
    results = []
    ssh = paramiko.SSHClient()
    ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
    ssh.connect(host, username=username, password=password)
    for name, cmd, expected in CHECK_LIST:
        stdin, stdout, stderr = ssh.exec_command(cmd)
        output = stdout.read().decode()
        ok = expected in output
        results.append((name, "PASS" if ok else "FAIL"))
    ssh.close()
    return results

# 批量巡检并输出报告...

将巡检结果接入企业微信告警，任何一台交换机的STP状态变为disabled，5分钟内通知网络组。

2. 交换机上线SOP完善

新增交换机上线检查清单中的必检项：

检查项	命令	期望结果
MSTP全局启用	`display stp global`	MSTP is enabled
MSTP域配置	`display stp region-configuration`	Region与核心一致
BPDU Guard	`display stp bpdu-protection`	至少48个边缘端口启用
环路检测	`display loop-detect`	Loop detect is enabled
端口安全	`display port-security`	已配置

上线后必须由第二人复核并签字确认。

3. 会议室信息点管理

会议室信息点在面板上标注编号，与交换机端口一一对应
地插面板贴上醒目标签：“请勿将网线连接两个网络面板”
非IT人员需要联网时，统一联系IT前台，由IT人员协助接线
对会议室端口启用端口安全（限制MAC地址数量为2个），减少环路风险

4. 网络监控增强

在Zabbix中新增以下监控项：

接入交换机CPU利用率 >70% 触发告警
接入交换机MAC表项数量超过阈值的80%触发告警
单端口出方向流量持续超过800Mbps超过30秒触发告警
STP拓扑变更通知（TCN）次数监控，单台交换机5分钟内超过3次触发告警

总结

这次故障的教训非常深刻：防护机制配置了不等于生效了。端口下写了stp edged-port enable，但全局STP没开，等于白搭。就像买了保险但没激活保单，出事了才发现根本赔不了。

网络运维中，以下几点值得铭记：

全局开关优先于端口配置——STP、DHCP Snooping、环路检测等功能都有全局开关，配置时一定要先确认全局是否启用。这不仅是华为设备的特点，思科、H3C、锐捷等厂商也是同样的逻辑。
配置合规检查要自动化——人工检查永远有遗漏，尤其是批量设备上线的时候。脚本巡检+告警推送，才是可靠的保障。
物理环路是最暴力的故障——一个简单的双头插线操作，就能在几秒内让一台48口交换机的CPU跑到100%，MAC表打满，三层设备也跟着遭殃。二层环路的影响范围和扩散速度远超大多数网络故障，必须把STP当成本命技能来维护。
BPDU Guard是终端接入的最后一道防线——接入端口设为边缘端口+BPDU Guard，一旦有终端侧设备发BPDU就自动err-down，简单粗暴但极其有效。

最终，从故障发生到网络恢复，用时约18分钟。其中5分钟是确认故障范围，3分钟是定位环路端口，2分钟是检查STP状态，1分钟shutdown止血。如果STP正常启用，这个环路从产生到被自动阻断只需要几秒钟，用户甚至不会感知到——这才是网络协议应有的价值。

排查工具备忘：display mac-address flapping、display stp global、display cpu-usage、display interface brief是二层环路排查的四件套，建议熟记。

核心交换机 STP 根桥被抢，广播风暴怎么来的？

Mon, 03 Feb 2025 13:26:40 +0000

一、问题背景

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

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

二、故障现象

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

行政楼 2/3/4 层用户大面积反馈“网页打开慢、钉钉转圈、共享文件夹访问超时”，但核心业务系统（位于数据中心）偶发可达，整体是“时通时断”的严重劣化，而非完全断网。
登上汇聚交换机 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

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

三、排查过程

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

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

`1`	`display stp`

-------[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 只是因为命令行显示的是“到根的开销”，需要进一步比对。

精确查看根桥身份：

`1`	`display stp root`

1
2

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

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

查看 NEW 的 STP 优先级：

`1`	`display stp \| include Bridge Priority`

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

根桥漂移后，原稳定拓扑被推翻， 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
2

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

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

1
2
3

system-view
stp priority 32768
undo stp root

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

1
2

system-view
stp root primary

等待 STP 重新收敛后，再次 display stp root，根桥 MAC 变回 CORE，Topology Change Count 停止增长，端口 Broadcast pps 回落到个位数，用户网络在 3 分钟内恢复。
事后复盘：NEW 作为临时补点本应只做接入，施工方却顺手配了根桥优先级。已要求所有接入层设备出厂/入场前统一刷标准配置模板，禁止任何非核心设备设置 stp root 或优先级低于 8192。

五、根因分析

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

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

六、预防措施

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

1
2

interface GigabitEthernet0/0/1
 stp root-protection

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

七、总结

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