三类泛洪抑制的差异
广播、组播、未知单播在二层都表现为泛洪，但成因与治本手段完全不同。广播主要来自 ARP、DHCP 与服务发现；组播来自组播业务与协议，治本靠 IGMP Snooping 建立成员表；未知单播来自 MAC 未学习或表项不足，抑制过强会丢弃正常首包。把三类流量打包用一个参数处理，往往顾此失彼。
基本信息
| 广播 | 目的 MAC 全 F，来源是 ARP、DHCP、服务发现协议 |
|---|---|
| 组播 | 目的 MAC 为 01:00:5e 或 33:33 前缀，来源是组播业务与协议 |
| 未知单播 | 目的 MAC 未在表中学习到，或表项已满无法写入 |
| 抑制手段 | 分开配置速率门限，动作可选丢弃或阻塞 |
| 治本方向 | 广播看广播域大小，组播靠监听，未知单播查学习路径 |
典型使用场景
- 接入端口按业务特征分别设定三类流量的抑制门限
- 排查广播占比升高时区分是广播域过大还是存在环路
- 组播业务上线后配合 IGMP Snooping 降低组播泛洪量
- 未知单播升高时先核对 MAC 表学习是否正常，再考虑抑制
- 服务器虚拟化环境按未知单播特征单独设计门限
分类型配置与观察
分类型配置与观察
interface GigabitEthernet0/0/1
storm-control broadcast min-rate 2000 max-rate 3000 # 广播
storm-control multicast min-rate 3000 max-rate 4000 # 组播
storm-control unicast min-rate 5000 max-rate 6000 # 未知单播
display mac-address # 先看学习是否正常
display storm-control interface brief # 触发与丢弃统计流量类型对照
| 类型 | 典型成因 | 抑制注意 |
|---|---|---|
| 广播 | ARP、DHCP、服务发现泛洪 | 阈值过低会压制正常地址发现 |
| 组播 | 组播业务与协议报文 | 配合 IGMP Snooping 才能治本 |
| 未知单播 | MAC 未学习、表项已满 | 抑制过强会丢弃正常设备首包 |
未知单播抑制的影响最隐蔽：新设备上线时的首包可能被丢弃，表现为偶尔连不上、重试又好，排查时容易被完全忽略。
未知单播持续升高先查 MAC 表学习是否正常、表项是否接近上限，直接加大抑制只是压住现象，源头可能是环路或私接设备。