3. 二层环路排查：STP/RSTP状态异常导致广播风暴
大家好，我是老张。今天咱们聊聊二层环路里最让人头疼的一种情况——STP或RSTP状态异常引发的广播风暴。
说实话，干网络这么多年，广播风暴我见过不少。但最让我印象深刻的，是有一回在某数据中心，半夜三点被值班电话叫醒。说整个二层网络瘫痪了，交换机CPU跑到100%，所有业务全断。我远程一看，广播包数量直接爆表。嗯，典型的广播风暴。
为什么会这样？说白了，就是STP没把环路堵住。
3.1 广播风暴是怎么产生的？
先简单回顾一下原理。二层网络里，如果存在物理环路，广播帧就会在交换机之间无限转发。你想想看，一个广播帧从交换机A发出去，从B绕一圈又回到A，A一看不是自己发的，继续转发。就这样，帧在环路里越积越多，最终把带宽吃光。
正常情况下，STP会阻塞某个端口，把环路逻辑上切断。但如果STP状态异常，该堵的端口没堵住，那广播风暴就来了。
核心判断依据：当交换机CPU利用率持续超过80%，且广播/组播报文占比异常高（比如超过50%），基本可以锁定是广播风暴。
3.2 STP/RSTP状态异常常见原因
我在项目中遇到过几种典型情况，给大家列一下：
- BPDU报文丢失：链路质量差，或者中间设备过滤了BPDU，导致交换机收不到对方的BPDU，误以为自己是根桥。
- 端口角色计算错误：比如优先级配置冲突，或者链路聚合配置不一致，导致STP算错了阻塞端口。
- STP收敛时间过长：RSTP虽然快，但如果链路频繁抖动，端口状态在Learning和Forwarding之间反复切换，也会出问题。
- 人为配置失误：这个最常见。我曾经见过有人把端口STP给关了，结果环路一出现，整个网络直接崩了。
注意：不要以为RSTP就万无一失。RSTP的快速收敛依赖于点对点链路和边缘端口的正确配置。如果配置不当，RSTP退化成STP，收敛时间长达30-50秒，这期间广播风暴完全可能发生。
3.3 排查步骤：从现象到根因
好，现在假设你接到告警，网络卡死了。怎么查？我个人的排查习惯是这样的：
- 第一步：确认风暴现象
登录核心交换机，执行
display interface看端口流量。如果某个端口入方向广播包速率异常高（比如每秒几万个），基本就是风暴入口。<Huawei> display interface gigabitethernet 0/0/1 Input: broadcast packets: 56789 packets/sec Output: broadcast packets: 12345 packets/sec注意看广播包速率。正常网络广播包每秒几十到几百个，如果上万甚至几十万，那肯定有问题。
- 第二步：检查STP状态
用
display stp brief查看所有端口的STP角色和状态。重点关注那些应该是阻塞（Alternate或Backup）但实际是转发（Forwarding）的端口。<Huawei> display stp brief MSTID Port Role State 0 GigabitEthernet0/0/1 DESI FORWARDING 0 GigabitEthernet0/0/2 ROOT FORWARDING 0 GigabitEthernet0/0/3 ALTE FORWARDING <-- 这里有问题！你看，端口0/0/3角色是Alternate（备用端口），按理应该是Discarding状态，但它却是Forwarding。这就是环路点。
- 第三步：定位根桥和BPDU问题
执行
display stp查看本机是否是根桥。如果多台交换机都认为自己是根桥，那BPDU肯定丢了。<Huawei> display stp CIST Bridge :32768.4c1f-cc12-3456 CIST Root/ERPC :32768.4c1f-cc12-3456 <-- 本机是根桥 <Huawei2> display stp CIST Bridge :32768.4c1f-cc12-7890 CIST Root/ERPC :32768.4c1f-cc12-7890 <-- 这台也认为自己是根桥两台交换机都认为自己是根桥，说明它们之间没有正常交换BPDU。这时候要检查链路和中间设备。
- 第四步：抓包确认
在怀疑的端口上抓包，过滤BPDU（目的MAC 01-80-c2-00-00-00）。如果长时间抓不到BPDU，或者BPDU的根桥ID不一致，问题就清楚了。
3.4 实战案例：一次RSTP边缘端口配置错误
我记得有一次，一个园区网升级，把接入层交换机全换了。结果上线后，每隔半小时就出现一次广播风暴，持续十几秒又自己恢复。
排查过程很有意思。我登录核心交换机，发现风暴发生时，某个接入端口突然从Forwarding变成Discarding，然后又变回来。反复看日志，发现这个端口配置了 stp edged-port enable，但实际连接的是一台普通交换机，不是终端设备。
问题就在这里。RSTP的边缘端口一旦收到BPDU，会立即重新参与STP计算，导致端口状态抖动。每次抖动都会触发拓扑变更，广播包就趁机泛滥。
避坑指南：我曾经吃过这个亏。边缘端口一定要确认连接的是终端设备（PC、服务器、IP电话等），不要想当然。如果连接的是交换机，必须去掉边缘端口配置，或者使用 stp bpdu-filter 配合使用。
3.5 快速恢复手段
如果网络已经瘫痪，业务优先。我建议按以下顺序操作：
| 操作 | 说明 | 风险 |
|---|---|---|
| 手动shutdown风暴端口 | 找到广播包速率最高的端口，直接shutdown | 低，但会断业务 |
| 开启风暴控制 | 配置广播风暴抑制阈值，比如 broadcast-suppression 80 |
低，可能误杀正常流量 |
| 强制指定根桥 | 手动配置根桥优先级，避免BPDU丢失后多根桥 | 中，需确认拓扑 |
| 重启交换机 | 最后手段，重启后STP重新收敛 | 高，全断 |
我个人习惯是先shutdown风暴端口，等业务恢复后，再慢慢排查根因。别急着重启，重启解决不了配置问题。
3.6 预防建议
最后说几句预防的事。广播风暴其实完全可以避免：
- 开启BPDU保护：在接入端口配置
stp bpdu-protection，一旦收到伪造BPDU，端口自动error-down。 - 开启环路检测：很多厂商支持
loopback-detection，能自动发现环路并关闭端口。 - 合理规划STP优先级：核心交换机优先级设低（比如4096），汇聚层设中等，接入层保持默认。这样根桥稳定，不容易漂移。
- 定期检查STP状态：用脚本每天检查一遍所有交换机的STP端口角色，发现异常及时处理。
总结一句话：STP/RSTP状态异常导致的广播风暴，排查核心就三步——看端口流量、查STP角色、抓BPDU报文。只要思路清晰，半小时内肯定能定位问题。
好了，这一章就到这里。下一章咱们聊聊三层环路，也就是路由黑洞的问题。那个更刺激，到时候见。