怀疑风暴时的查看顺序
广播风暴的表现是整网变慢、终端掉线、设备 CPU 飙升，但真正的原因往往是某个接入环、某台故障网卡或某个私接设备。查看顺序应当是：先确认是哪类风暴（广播、组播还是未知单播），再看抑制功能是否已经触发以及触发在哪个端口，最后从端口速率与 MAC 表异常里找出源头。同时要意识到抑制阈值本身也可能误伤正常业务广播。
基本信息
| 适用平台 | 华为 VRP、思科 IOS、H3C Comware 交换机 |
|---|---|
| 命令族 | storm-constrain（华为/H3C）、storm-control（思科） |
| 观察指标 | 端口速率与广播包速率、CPU 占用、MAC 表项数量与漂移 |
| 权限要求 | 查看类命令用户视图即可 |
| 配套机制 | 生成树、环路检测与边缘端口的 BPDU 保护可减少风暴源头 |
典型使用场景
- 全网变慢或终端集体掉线：先看是否有风暴并定位源端口
- 抑制功能频繁触发：判断阈值是否过严，避免正常广播被压掉
- DHCP 或 ARP 异常：确认是否因抑制把必要广播丢弃
- 接入安全改造：用 BPDU 保护与端口安全减少风暴发生条件
- 故障复盘：确认风暴源头设备与端口，形成可追溯记录
华为 VRP
华为 VRP
<Huawei> display storm-constrain # 查看抑制配置与触发状态
<Huawei> display interface GigabitEthernet0/0/1 # 看广播包速率与总速率
<Huawei> display cpu-usage # CPU 是否被协议报文抬高
<Huawei> display mac-address summary # MAC 表项数量是否异常膨胀思科 IOS
思科 IOS
SW-CORE-01# show storm-control broadcast
SW-CORE-01# show interfaces GigabitEthernet0/1 | include broadcast
SW-CORE-01# show processes cpu sorted
SW-CORE-01# show mac address-table count # 表项数量与阈值对比H3C Comware
H3C Comware
<H3C> display storm-constrain
<H3C> display interface GigabitEthernet1/0/1
<H3C> display cpu-usage观察项与判断
| 观察项 | 正常表现 | 异常信号 |
|---|---|---|
| 端口广播速率 | 平稳且占带宽比例小 | 占比持续飙升，接近抑制阈值 |
| 抑制触发状态 | 未触发或偶发 | 同一端口反复触发，触发时间点集中 |
| CPU 占用 | 平稳 | 随广播速率同步升高 |
| MAC 表项 | 数量与终端规模匹配 | 数量暴涨或同一 MAC 在不同端口出现 |
| 上联口与接入口对比 | 上联口速率明显更高 | 接入口速率反常升高，说明源头在其下 |
注意厂商命令名差异：H3C 使用 storm-constrain 而非 storm-control；华为在不同平台分别提供 storm-constrain 与 storm-control 形态，具体以本机命令帮助为准。查错命令名会得到空输出，容易被误判为「没有配置抑制」。