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

问题背景

某周一上午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

核心交换机日志：

%%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配置：

[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是否全局启用：

# 在每台接入交换机上执行
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没开，等于白搭。就像买了保险但没激活保单，出事了才发现根本赔不了。

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

1. 全局开关优先于端口配置——STP、DHCP Snooping、环路检测等功能都有全局开关，配置时一定要先确认全局是否启用。这不仅是华为设备的特点，思科、H3C、锐捷等厂商也是同样的逻辑。

2. 配置合规检查要自动化——人工检查永远有遗漏，尤其是批量设备上线的时候。脚本巡检+告警推送，才是可靠的保障。

3. 物理环路是最暴力的故障——一个简单的双头插线操作，就能在几秒内让一台48口交换机的CPU跑到100%，MAC表打满，三层设备也跟着遭殃。二层环路的影响范围和扩散速度远超大多数网络故障，必须把STP当成本命技能来维护。

4. 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是二层环路排查的四件套，建议熟记。