广播风暴的排查顺序
广播风暴定位有固定顺序：确认现象与影响面、量化广播速率、按端口对比找出异常源、隔离验证、再处理根因并恢复。先隔离后分析是因为风暴扩散期间链路已被占满，抓包工具本身也会丢帧，拿不到完整证据。
基本信息
| 触发原因 | 二层环路、异常终端、故障网卡等 |
|---|---|
| 量化手段 | 端口广播与组播速率、CPU 占用 |
| 关键动作 | 先隔离异常端口，再分析根因 |
| 对控制面的影响 | 转发面风暴会同时冲击 CPU 与协议邻居 |
| 收尾要求 | 恢复后复测速率基线 |
排查步骤
- 步骤一：从用户侧与监控确认发生时间与影响范围
- 步骤二：逐口对比广播与组播速率，找出明显异常的口
- 步骤三：隔离该端口，验证业务是否随之恢复
- 步骤四：分析环源或故障源，明确根因后再恢复接线
- 步骤五：复测速率基线，确认没有残留震荡
常用观测命令
常用观测命令
display interface brief # 端口流量概览
display interface GigabitEthernet0/0/1 # 单口广播与组播速率
show interfaces counters broadcast # Cisco 广播计数
display cpu-usage # 控制面是否被拖累
show processes cpu # Cisco CPU 占用速率对比要点
| 观察项 | 正常表现 | 异常表现 |
|---|---|---|
| 端口广播速率 | 接近基线，波动小 | 某个口远高于其他端口 |
| 端口组播速率 | 平稳 | 突发增长并伴随未知单播激增 |
| CPU 占用 | 平稳 | 转发与控制面同时升高 |
| MAC 表变化 | 平稳 | 表项频繁老化或地址漂移 |
| 链路利用率 | 有合理峰谷 | 多条链路同时接近饱和 |
隔离与恢复
确认异常端口后先隔离再分析：风暴期间抓包往往因为丢帧而得不到完整证据，隔离后速率回落，再从容对故障终端或接入设备取证。根因处理完成后复测速率基线并保留数据，用来判断网络中是否还有较低速率的残留震荡。
恢复正常不等于问题解决：风暴停止后网络可能仍处于不健康状态，残留环路或异常终端会以较低速率持续制造广播，只有在基线数据上才能看出差异，所以复测这一步不能省。