第20篇：交换网络故障案例：某企业网环路致全网瘫痪
关键词：STP故障、根桥抢占、MAC地址漂移、CPU占用、BPDU攻击、环路排查、RSTP案例、MSTP案例、企业网
一、引言
在前几篇文章中，我们系统学习了 STP、RSTP 和 MSTP 的原理与配置。这些协议虽能防环，却也常在实战中出现配置偏差或人为失误，从而引发各种故障。这是网络工程师最常遇到的"诡异事件"之一：明明启用了 STP，却仍然出现各种莫名问题。本文通过若干真实的故障案例，带你认识根桥抢占、STP 抖动和 BPDU 攻击等典型问题，建立完整的排查思路和解决方案。
二、核心概念
2.1 交换网络故障分类
| 故障类型 | 说明 | 影响程度 |
|---|---|---|
| 根桥位置不正确 | 根桥被选举到非预期的交换机 | 中：转发路径改变 |
| STP 抖动 | 端口角色频繁变化，MAC 地址表不稳定 | 高：网络不稳定 |
| 环路未防住 | STP 未生效或配置错误下环路 | 极高：广播风暴 |
| BPDU 攻击 | 恶意设备发送伪造 BPDU 破坏网络 | 高：根桥被劫持 |
| MST 区域不一致 | 区域配置不匹配退化为单实例 | 中：负载分担失效 |
2.2 故障排查的基本原则
| 原则 | 说明 |
|---|---|
| 先全局后局部 | 先检查 STP 是否全局启用，再检查端口配置 |
| 先根桥后端口 | 先确认根桥位置，再排查端口角色 |
| 先物理后逻辑 | 先确认链路物理状态，再分析 STP 逻辑状态 |
| 先日志后配置 | 先查看系统日志，再分析配置差异 |
三、技术细节
3.1 常见故障症状及对应排查
| 症状 | 可能原因 | 排查命令 |
|---|---|---|
| 网络有短暂中断 | STP 抖动、端口反复 UP/DOWN | display stp topology-changes |
| 特定 VLAN 不通 | MSTP 实例配置不一致、VLAN 映射错误 | display stp instance X |
| 多 VLAN 共走同一条链路 | MST 区域配置不一致、实例根桥配置错误 | display stp region-configuration |
| 端口长时间无法 Forwarding | STP 模式不当、定时器异常 | display stp brief |
| 接入端口被 STP 阻塞 | 边缘端口未配置、BPDU 保护未启用 | display stp port |
| CPU 占用 100% | 广播风暴、MAC 地址震荡 | display cpu-usage |
3.2 交换机防环保护机制
| 保护机制 | 原理 | 配置位置 | 命令 |
|---|---|---|---|
| BPDU 保护 | 边缘端口收到 BPDU 时关闭端口 | 全局 + 端口 | stp bpdu-protection |
| 根保护 | 防止非根桥的端口收到更优 BPDU 时变为根端口 | 端口 | stp root-protection |
| 环路保护 | 端口收不到 BPDU 时不进入环路保护状态（防单向环路） | 端口 | stp loop-protection |
| TC 保护 | 限制拓扑变更通知的频率，防止 MAC 表项频繁清空 | 全局 | stp tc-protection |
| 配置保护 | 防止未授权修改 STP 配置 | 全局 | 通过 ACL 或权限控制 |
四、实战配置/案例分析
4.1 案例一：新设备抢占导致全网路径改变
故障时间：2024 年 6 月 10 日上午 故障范围：某企业约 500 台终端，全 VLAN 受影响
故障现象： 1. 财务部 PC 访问服务器延迟从 2ms 增加到 15ms 2. 视频会议频繁卡顿 3. 网络工程师登录核心交换机发现根桥位置异常
排查过程：
# 步骤1：检查当前根桥
<Core-SW> display stp
Root Bridge:
Bridge ID: 32768.00e0.fc12.0005 ← 根桥 ID 是 0005（应该是核心 0001）
# 步骤2：确认核心交换机 Bridge ID
<Core-SW> display stp
Local Bridge:
Bridge ID: 32768.00e0.fc12.0001
# 步骤3：登录新接入的交换机
# 上周网络部新接入一台接入交换机 Access-05
<Access-05> display stp
Root Bridge:
Bridge ID: 32768.00e0.fc12.0005 ← 本设备就是根桥！
Local Bridge:
Bridge ID: 32768.00e0.fc12.0005
# 根因分析
# 1. 核心交换机的 MAC 地址（0001）小于 Access-05 的 MAC 地址（0005）
# 优先级相同时 MAC 小者优先，但此处 Access-05 成了根桥
# 2. 发现 Access-05 的优先级被设为 0（最小值）
<Access-05> display current-configuration | include stp priority
stp priority 0
# 3. 新员工在 Access-05 上执行了 stp root primary
# 该命令会把优先级直接设为 0（华为默认行为），是全网最小优先级值
# 0 < 32768（核心默认值），所以 Access-05 抢占了根桥
# 修复方案
# 步骤1：在核心交换机重新明确较小优先级，确保成为根桥
[Core-SW] stp priority 0
# （也可用快捷命令 stp root primary，它会把优先级直接设为 0；二者二选一即可）
# 步骤2：新接入交换机恢复默认值
[Access-05] stp priority 32768
# 步骤3：验证拓扑恢复
<Core-SW> display stp brief
Root Bridge: 4096.00e0.fc12.0001 ← 核心恢复为根桥
# 预防措施
# 1. 接入交换机统一使用默认优先级（32768）
# 2. 核心交换机的下行端口配置根保护
[Core-SW] interface GigabitEthernet 1/0/1
[Core-SW-GigabitEthernet1/0/1] stp root-protection
[Core-SW-GigabitEthernet1/0/1] quit
4.2 案例二：STP 抖动导致网络频繁中断
故障时间：2024 年 8 月 20 日凌晨 故障范围：某园区网络，每 20~30 秒断网一次
故障现象： 1. 终端断网约 2 秒后恢复，循环出现 2. 核心交换机日志中有大量 STP 状态变更事件 3. 抓包发现大量 BPDU 报文
排查过程：
# 步骤1：查看拓扑变更计数
<Core-SW> display stp topology-changes
Topology Change Count: 2847 ← 拓扑变更非常频繁
Topology Change Time: 00:00:15 ← 距上次拓扑变更仅 15 秒（时:分:秒）
# 步骤2：观察端口角色变化
<Agg-SW> display stp brief
MSTID PortName PortRole PortSt
0 GE0/0/1 Root Forwarding
0 GE0/0/2 Alternate Discarding
# 30 秒后再次查看
<Agg-SW> display stp brief
MSTID PortName PortRole PortSt
0 GE0/0/1 Alternate Discarding ← 角色反转
0 GE0/0/2 Root Forwarding
# 步骤3：检查链路质量
<Agg-SW> display interface GigabitEthernet 0/0/1
Input:
runts: 15000 ← 异常
giants: 8500 ← 异常
input errors: 23000
CRC: 12000 ← CRC 错误很多
# 结论：GE0/0/1 的模块或光功率异常
# 链路频繁 UP/DOWN（flapping），触发 STP 拓扑变更
# 每次拓扑变更都会触发 MAC 地址表老化
# 修复
# 步骤1：更换光模块
# 步骤2：检查对端端口的光功率
<Agg-SW> display transceiver interface GigabitEthernet 0/0/1
RX power: -28dBm ← 偏低（正常应为 -3 ~ -15dBm）
# 步骤3：配置环路保护，防止误判
[Agg-SW] interface GigabitEthernet 0/0/1
[Agg-SW-GigabitEthernet0/0/1] stp loop-protection
[Agg-SW-GigabitEthernet0/0/1] quit
# 步骤4：配置 TC 保护，限制 MAC 表频繁清空
[Agg-SW] stp tc-protection
# 部分 VRP 版本支持阈值控制
[Agg-SW] stp tc-protection threshold 6
4.3 案例三：BPDU 攻击导致根桥被劫持
故障时间：2024 年 10 月 5 日上午 故障范围：某办公楼全楼终端无法上网
故障现象： 1. 运维人员发现根桥位置异常变化 2. 核心交换机日志中出现未知 BPDU 3. 排查发现某终端连接端口在发送伪造 BPDU
排查过程：
# 步骤1：检查根桥
<Core-SW> display stp
Root Bridge:
Bridge ID: 0.0200.0000.0000 ← 异常 Bridge ID
# 优先级为 0，MAC 为 02:00:00:00:00:00，明显是伪造的
# 步骤2：查看根端口收到的 BPDU
<Access-SW> display stp port GigabitEthernet 0/0/1
# 发现 GE0/0/1 收到的 BPDU 携带异常 Bridge ID
# 步骤3：定位攻击源
# GE0/0/1 下联的是一台员工 PC
# PC 上运行了某款网络工具，可手工伪造 BPDU 报文
# 这是 BPDU 攻击（也称为 Evil Twin 攻击）的常见表现
# 攻击者发送优先级为 0 的 BPDU，将自己的设备伪装成根桥
# 进而控制 STP 拓扑，将其他设备的流量引导经过自己的设备实施中间人攻击
# 修复
# 步骤1：关闭被攻击端口
[Access-SW] interface GigabitEthernet 0/0/1
[Access-SW-GigabitEthernet0/0/1] shutdown
[Access-SW-GigabitEthernet0/0/1] quit
# 步骤2：在边缘端口启用 BPDU 保护
[Access-SW] stp bpdu-protection
[Access-SW] interface range GigabitEthernet 0/0/1 to GigabitEthernet 0/0/24
[Access-SW-Port-range] stp edged-port enable
[Access-SW-Port-range] quit
# 步骤3：在核心交换机的所有下行端口配置根保护
[Core-SW] interface range GigabitEthernet 1/0/1 to GigabitEthernet 1/0/4
[Core-SW-Port-range] stp root-protection
[Core-SW-Port-range] quit
# 根保护下端口即使收到更优 BPDU，也不会改变端口角色
# 步骤4：对 PC 进行安全检查（杀毒、删除异常工具）
4.4 案例四：MSTP 负载分担失效
故障现象：MSTP 配置后，VLAN 10/20 和 VLAN 30/40 的流量全部走 Core-A，Core-B 的链路闲置。
# 检查 Core-B 的 MST 实例信息
<Core-B> display stp instance 1
Root Bridge:
Bridge ID: 4096.00e0.fc12.0001 ← 实例1的根桥是 Core-A（正确）
<Core-B> display stp instance 2
Root Bridge:
Bridge ID: 4096.00e0.fc12.0001 ← 实例2的根桥也是 Core-A（错误！）
# 实例2的根桥应是 Core-B
# 排查 Core-B 的配置
<Core-B> display current-configuration | include stp instance
# 没有发现 instance 2 root primary 的配置
# 结论：Core-B 没有指定自己是实例 2 的根桥
# 两台设备在实例 2 中都是 Core-A 为主根，链路负载分担自然失败
# 修复
[Core-B] stp instance 2 root primary
# 验证
<Access-1> display stp brief
MSTID PortName PortRole PortSt
0 GE0/0/25 M-RP Forwarding
1 GE0/0/25 M-RP Forwarding ← 实例1走 Core-A
2 GE0/0/26 A-RP Forwarding ← 实例2走 Core-B（已恢复）
五、总结
| 故障类型 | 症状 | 排查方法 | 预防措施 |
|---|---|---|---|
| 根桥抢占 | 根桥位置异常、路径改变 | 检查优先级配置 | 手动指定根桥优先级 |
| STP 抖动 | 频繁断网、拓扑变更计数大 | 检查链路质量、光功率 | 环路保护、TC 保护 |
| BPDU 攻击 | 异常 Bridge ID、根桥被劫持 | 追踪 BPDU 来源 | BPDU 保护、根保护 |
| 负载分担失效 | 多 VLAN 共走同一条链路 | 检查 MSTI 配置、根桥选举 | MSTP 配置检查清单 |
| 端口被阻塞 | 终端端口无法通信 | 检查边缘端口配置 | 接入端口设为边缘端口 |
| 保护机制 | 配置位置 | 阻止场景 |
|---|---|---|
| BPDU 保护 | 边缘端口 | BPDU 攻击、用户私接交换机 |
| 根保护 | 核心侧下行端口 | 非预期设备成为根桥 |
| 环路保护 | 所有非边缘端口 | 单向链路或 BPDU 丢失 |
| TC 保护 | 全局 | 频繁拓扑变更导致 MAC 表清空 |
| 排错命令 | 用途 |
|---|---|
display stp brief |
快速查看端口角色和状态 |
display stp |
查看完整 STP 信息 |
display stp topology-changes |
排查抖动 |
display stp region-configuration |
检查 MST 区域配置 |
display stp instance X |
查看特定实例状态 |
display logbuffer \| include STP |
查看 STP 相关日志 |
思考
- 根保护（root-protection）配置在核心交换机的下行端口上，如果该端口收到一个优先级更低的 BPDU，会发生什么？端口会关闭吗？
- TC 保护限制了每分钟处理的拓扑变更次数，超出限制的拓扑变更会被丢弃吗？丢弃后会产生什么影响？
- 在一个部署 MSTP 的园区网中，发现只有接入交换机的端口配置了 BPDU 保护，而核心交换机没有配置。核心交换机是否仍会受到 BPDU 攻击的影响？
下篇预告：第21篇：链路聚合 Eth-Trunk：手工模式与 LACP 模式