一次核心交换机STP风暴导致全楼网络瘫痪的排查实录

发表于 分类于 ， 阅读次数： 本文字数： 1.8k 阅读时长 ≈ 6 分钟

问题背景

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

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

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

故障现象

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

1
2
3
4
5
6
<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 接口详情：

1
2
3
4
<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%，流量极不正常。

查看该接口连接的设备：

1
2
3
4
5
6
<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 可以正常登录。

解决方案

立即处理：

  1. 移除会议室哑交换机，或只保留一根网线连接到楼层交换机
  2. 对接入交换机的 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 这些配置看起来很基础，但往往是防止意外事故的关键防线。

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