STP on Zero Day Notes

一次交换机物理环路导致整栋楼广播风暴瘫痪的排查实录

Mon, 29 Jun 2026 07:00:00 +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风暴导致全楼网络瘫痪的排查实录

Wed, 08 Jun 2022 14:20:00 +0000

问题背景

某周三下午 14:20 左右，公司全楼约 300 名员工突然反映网络中断，表现为无法访问内网系统、互联网全部断开。影响持续约 25 分钟，直到网络恢复正常。

公司网络架构为三层设计：核心层（H3C S7503 核心交换机 ×2，堆叠）、汇聚层（各楼层汇聚交换机）、接入层（各区域接入交换机）。出口通过核心交换机直连防火墙接入互联网。

事故期间 IT 监控告警系统收到大量告警：核心交换机 CPU 使用率达到 100%，大量接口出现 CRC 错误。

故障现象

全楼用户无法访问内外网，ping 内网网关均超时
核心交换机 SSH 无法登录（CPU 负载过高导致管理面板无响应）
监控系统显示核心交换机上行接口流量在故障期间突然暴增至满带宽
各楼层汇聚交换机日志中出现大量 MAC 地址表抖动告警：

%STP-3-TOPOLOGY_CHANGE: Topology Change notification received on GigabitEthernet1/0/12
%STP-3-TOPOLOGY_CHANGE: Topology Change notification received on GigabitEthernet1/0/12
%STP-3-TOPOLOGY_CHANGE: Topology Change notification received on GigabitEthernet1/0/12
（以上日志每秒出现数十条）

核心交换机 CPU 告警日志：

`1`	`%SYSTEM-3-CPU_OVERLOAD: CPU utilization reached 100%`

排查过程

第一步：现场快速响应

接到告警后立即赶到机房，此时核心交换机 SSH 已经无法连接，只能通过 Console 口连接。Console 口可以登录，但响应非常慢，输入命令后需要等几秒才有回显。

第二步：查看当前 CPU 状态

1
2
3

<H3C-Core> display cpu-usage
Slot 1:
CPU Usage: 100%

CPU 持续 100%，正常运维操作受阻。先查看进程占用：

1
2
3

<H3C-Core> display process cpu
Process  CPU%  Process Name
STP      89%   Spanning Tree Protocol

STP 进程占用了 89% 的 CPU，几乎可以确认是生成树相关问题。

第三步：查看 STP 状态

<H3C-Core> display stp brief
 MST ID  Port                     Role  STP State    Protection
  0      GE1/0/1                  DSGN  FORWARDING   NONE
  0      GE1/0/2                  DSGN  FORWARDING   NONE
  0      GE1/0/12                 ROOT  FORWARDING   NONE
  ...

注意到 GE1/0/12 这个接口频繁出现拓扑变更通知（TCN），正常情况下 STP 拓扑是稳定的，不应该持续触发 TCN。

第四步：定位问题接口

查看 GE1/0/12 接口详情：

<H3C-Core> display interface GigabitEthernet 1/0/12
GigabitEthernet1/0/12 current state: UP
Input bandwidth utilization : 99.8%
Output bandwidth utilization: 99.7%

接口带宽利用率接近 100%，流量极不正常。

查看该接口连接的设备：

<H3C-Core> display lldp neighbor interface GigabitEthernet 1/0/12
Neighbor index  :1
Chassis ID      :5c-dd-70-xx-xx-xx
Port ID         :GigabitEthernet1/0/1
TTL             :120s
System name     :SW-Floor3-Access

该接口连接的是三楼的接入交换机。再查看三楼接入交换机的 MAC 地址表变化情况（通过另一条管理路径连上汇聚交换机，再 telnet 到接入交换机）：

1
2
3

[SW-Floor3-Access] display mac-address learning
MAC address learning: enabled
MAC entries: 8764 (normal: 256)

MAC 表条目高达 8764！正常一台接入交换机最多几百条，出现这么多条目强烈说明有广播风暴，MAC 地址表在不断刷新。

第五步：找到广播风暴源头

在三楼接入交换机上，查看各接口的流量情况，发现有两个接口的 In/Out 流量都异常高：

GE1/0/23：In 95% / Out 94%
GE1/0/24：In 96% / Out 95%

立刻到现场查看这两个接口连接的是什么设备。

发现问题所在：三楼的一个会议室，一台 5 口的 TP-Link 哑交换机（无管理接口）将它的两个口分别插到了接入交换机的 GE1/0/23 和 GE1/0/24，形成了一个环路！

经询问，是当天下午有人觉得会议室网口不够用，就从库房找了一台旧的哑交换机接上，并且为了多用几个口，把两根网线都插到了楼层接入交换机上（一根接到 23 口，另一根接到 24 口），然后把会议室的网线也接到哑交换机上。这台哑交换机没有 STP 支持，直接形成了二层环路。

第六步：验证并处理

立即拔掉哑交换机上的一根网线，断开环路。

几秒钟后，核心交换机 CPU 开始下降：

1
2
3

CPU Usage: 67%  (30 seconds later)
CPU Usage: 24%  (60 seconds later)
CPU Usage:  8%  (90 seconds later)

全楼网络逐渐恢复，SSH 可以正常登录。

解决方案

立即处理：

移除会议室哑交换机，或只保留一根网线连接到楼层交换机
对接入交换机的 GE1/0/23 和 GE1/0/24 端口开启 BPDU Guard 和 Port Fast（如接入层交换机支持）

接入交换机端口配置（以 H3C 为例）：

1
2
3

[SW-Floor3-Access] interface GigabitEthernet 1/0/23
[SW-Floor3-Access-GE1/0/23] stp edged-port enable
[SW-Floor3-Access-GE1/0/23] stp bpdu-protection enable

stp edged-port enable 将该端口设为边缘端口（快速进入转发状态），stp bpdu-protection 确保一旦收到 BPDU 就关闭端口，防止哑交换机引发环路。

对所有接入端口（下联终端的端口）批量开启保护：

`1`	`[SW-Floor3-Access] stp bpdu-protection`

此命令在全局开启 BPDU Guard，适用于所有已配置为边缘端口的接口。

根因分析

此次事故的根本原因是未经授权的网络设备接入，且接入的是不支持 STP 的哑交换机，直接造成二层环路。环路导致广播风暴，大量 STP TCN 帧充斥网络，核心交换机 STP 进程持续处理拓扑变更请求，CPU 飙至 100%，正常数据转发能力丧失，全楼断网。

预防措施

1. 端口安全配置（核心）

所有接入端口启用 BPDU Guard 和 Port Fast，一旦检测到非法接入的交换机就自动关闭端口：

1
2

# 全局开启接入端口保护
stp bpdu-protection

2. 端口 MAC 地址绑定

对固定位置的终端，绑定 MAC 地址，防止未知设备接入：

1
2
3

port-security enable
port-security max-mac-count 1
port-security violation restrict

3. 用户权限管控

制定规定：任何人不得自行增减或调整网络设备，需求须提交 IT 工单处理。

4. 监控告警细化

完善接入层交换机的 STP 拓扑变更告警，发现 TCN 频繁触发时立即通知运维人员，缩短响应时间。

总结

这次事故对我们的提醒是：二层网络的风险往往来自"无害"的小设备。一台十几块钱的哑交换机就能让全楼断网 25 分钟，损失的是几百人的工作效率。

对于 IT 运维来说，不仅要把核心网络设备管理好，接入层的安全策略同样不可忽视。BPDU Guard、Port Security 这些配置看起来很基础，但往往是防止意外事故的关键防线。

另外，员工的安全意识培训也很必要——让大家知道"随便接交换机"可能会带来什么后果。