抑制是止损，不是治本
风暴抑制的作用是在环路或攻击已经存在时把流量压住，让业务不至于全面瘫痪。它不消除根因：环路还在，广播依旧在被产生，只是被限住了。正因如此，抑制生效之后故障会变得更隐蔽——端口看起来正常，实际已经在丢弃流量，运维如果不主动监控被抑制端口，问题会长期潜伏。
常见误区
- 误区一：把抑制当防环方案，环路不排，抑制后故障更隐蔽
- 误区二：阈值一刀切，不同端口用途使用同一套参数
- 误区三：只配广播不配组播与未知单播
- 误区四：动作开启后不演练恢复流程，事件来时无从下手
- 误区五：抑制参数上线后不再复核，业务扩容后阈值早已不匹配
误区与后果
| 误区 | 直接后果 | 纠正方式 |
|---|---|---|
| 以抑制代替防环 | 环路存续，故障被掩盖 | 先定位并拆环，抑制只作兜底 |
| 阈值一刀切 | 正常业务被误伤或抑制失效 | 按端口用途分档并做峰值基线 |
| 只限广播 | 组播与未知单播风暴照旧 | 按类型分别配置 |
| 不演练恢复 | 事件期间处置迟缓 | 把恢复步骤写进值守手册 |
| 参数长期不复核 | 业务增长后阈值失真 | 随业务变更同步复核 |
阈值基线做法
阈值基线做法
display interface GigabitEthernet0/0/1 # 华为：先看端口广播速率峰值
display storm-constrain # H3C：查看抑制状态与触发计数
# 先以 monitor 模式运行一到两周，收集业务峰值的广播占比
# 阈值从峰值的数倍起步，逐步收紧，每次收紧后观察一个周期DHCP、ARP、组播发现类协议依赖广播或组播，阈值与动作要与其流量特征匹配。抑制过紧会先打掉这些基础协议，表现为终端批量拿不到地址、网关解析异常。
参数起点：先抓业务峰值广播占比做基线，阈值从基线的数倍起步逐步收紧，比凭印象定值可靠。收紧过程要记录每次的参数与观察结果。