环路与广播风暴是怎么发生的
二层网络没有 TTL，广播与未知单播会从所有端口转发出去。一旦存在物理环路而 STP 未能阻断，同一个帧就会在环上不断复制：每秒包量迅速打满链路，交换机 CPU 被广播与 STP 计算占满，正常业务丢包、延迟暴涨，但设备管理地址可能仍然可达。现场特征是「全网同时变慢」而不是某个应用报错，识别它要看得下去指标而不是抓包内容。
基本信息
| 作用范围 | 同一 VLAN 的广播域，跨 VLAN 不受影响 |
|---|---|
| 典型指标 | 广播与组播包速率、交换机 CPU、端口收发速率、输入错误计数 |
| 快速判据 | tcpdump 数广播包一秒内上千，即已进入风暴状态 |
| 常见根因 | 私接路由器、双头网线、冗余链路未启用 STP 或配置错误 |
| 缓解手段 | 风暴抑制（storm control）、BPDU Guard、端口环路检测 |
典型使用场景
- 办公网突然全体卡顿：先确认是否为广播风暴而不是出口带宽问题
- 新接一根网线后网络瘫痪：检查是否形成环路
- 交换机 CPU 告警：区分是管理面攻击还是二层泛洪
- 变更后验证：启用冗余链路前确认 STP 状态正常，端口角色符合设计
- 定位环路入口：结合 MAC 漂移告警与端口流量异常缩小到具体端口
主机侧快速识别
主机侧快速识别
tcpdump -i eth0 -nn -c 1000 'broadcast or multicast' 2>/dev/null | wc -l # 短时间上千即风暴
ip -s link show eth0 | head -5 # RX 包速率异常且 errors/drop 增长
arping -c 2 -I eth0 10.0.0.1 # 二层被淹时通常失败
watch -n 1 "ip -s link show eth0 | grep -A1 RX" # 观察包计数是否线性暴涨
# 交换机侧（华为 VRP 示例）：display cpu-usage 与 display interface brief 看端口速率
# 思科 IOS 示例：show processes cpu sorted 与 show interfaces | include rate现场特征对照
| 观察点 | 风暴表现 | 正常表现 |
|---|---|---|
| 链路速率 | 成员链路接近线速且持续 | 随业务波动 |
| 广播包量 | 每秒数千以上 | 每秒个位到几十 |
| 交换机 CPU | 管理面 CPU 高，协议报文丢 | 随流量平稳 |
| 业务表现 | 整体丢包延迟上升 | 局部或与应用相关 |
| MAC 表 | 同一 MAC 在多端口反复出现 | MAC 位置稳定 |
风暴期间登录交换机可能极慢甚至超时，动手前准备好带外通道；逐段拔线会中断业务，属于需要授权的高影响操作。