风暴打的不只是带宽
风暴发生时，链路被占满只是第一层可见的后果。第二层影响是上送 CPU 的协议报文被挤占：BPDU 丢失会导致拓扑计算异常并频繁收敛，ARP 处理被挤压会造成通信异常，管理协议报文排队则表现为设备「失联」。所以风暴现场常常同时出现拓扑震荡、学习异常和管理响应变慢，看起来像多个独立故障。
基本信息
| 连锁反应 | BPDU 丢失引发拓扑计算异常，ARP 处理被挤压，管理响应变慢 |
|---|---|
| 相关机制 | 协议报文限速与风暴抑制配合保护 CPU |
| 观测手段 | 整体与任务级 CPU 占用、日志中的超限告警 |
| 恢复特点 | 风暴消除后 CPU 回落，但表项与拓扑需重新收敛 |
典型现象
- 设备 CPU 长时间高位，管理命令行响应明显变慢
- 日志中大量出现协议报文超限与拓扑变化记录
- 终端时通时断，ARP 学习异常或频繁重新请求地址
- 同一交换机上多个不相关业务同时异常
- 风暴停止后业务没有立即恢复，需要等表项与拓扑重新收敛
CPU 观测
CPU 观测
display cpu-usage # 华为：整体与任务级占用
display cpu-usage timeline # 华为：按时间看 CPU 变化趋势
display cpu-defend statistics # 华为：协议报文上送与丢弃统计
display logbuffer | include CPU # 华为：找超限告警
display interface brief # 华为：哪个端口速率异常
show processes cpu sorted # 思科：按占用排序的任务
display storm-constrain # H3C：确认抑制是否已触发影响链
| 环节 | 表现 | 排查入手 |
|---|---|---|
| 协议报文被挤占 | BPDU 丢失、拓扑反复收敛 | 查协议报文上送与丢弃统计 |
| ARP 与地址协议异常 | 终端时通时断 | 查地址学习与广播速率 |
| 管理面阻塞 | 命令行响应慢或超时 | 查 CPU 任务占用 |
| 转发资源受限 | 表项学习异常、丢包 | 查端口速率与 MAC 表变化 |
CPU 高是结果不是根因：先看流量与端口计数，找到速率异常的端口，再回头看它对协议学习造成了多大影响。按结果去查原因，顺序反了会一直在 CPU 指标上打转。
只对 CPU 上送报文做限速而不治理风暴，会让协议学习长期处于异常状态：BPDU 参与不了计算，拓扑就一直不稳定。