4、环路与广播风暴：二层环路产生原因、STP协议基础、环路导致广播风暴的机制

说到广播丢包，有一个场景我印象特别深。几年前帮一家公司排查网络故障，整个办公区断断续续掉线，ping网关延迟从1ms跳到3000ms。我登录交换机一看，CPU占用率飙到99%，广播包每秒几十万个。说白了，这就是典型的广播风暴。而广播风暴的根源，十有八九是二层环路。

这一章我们就聊聊环路怎么产生的，STP怎么破，以及环路怎么把网络搞垮的。

4.1 二层环路是怎么来的？

二层网络里，交换机靠MAC地址表转发帧。正常情况下，一个MAC地址对应一个端口。但如果你在交换机之间连了多条路径，问题就来了。

举个例子：两台交换机SW1和SW2，用两根网线连起来。SW1从端口1收到一个广播帧，它会从所有其他端口转发出去，包括连SW2的那两个端口。SW2收到后，又会从自己的端口转发回SW1。SW1再转发……帧就在这两台交换机之间来回跑，永远不会停。

为什么会这样？因为交换机不关心帧是不是已经来过。它只负责：收到帧，查MAC表，找不到就广播，找到就单播。环路一出现，广播帧就变成了永动机。

我遇到过最夸张的一次，一个客户把三台交换机用网线连成了一个三角形。结果整个二层网络在10秒内彻底瘫痪，所有终端都拿不到IP地址。嗯，这就是环路的力量。

4.2 STP协议基础——破环的利器

STP（Spanning Tree Protocol）就是用来解决环路问题的。它的核心思想很简单：在物理上保留冗余链路，但在逻辑上切断环路，只留一条无环的树形路径。

STP的工作原理可以概括为四个步骤：

1. 选根桥：所有交换机比较桥ID（优先级+MAC地址），最小的成为根桥。
2. 选根端口：非根桥上，到根桥路径成本最小的端口成为根端口。
3. 选指定端口：每条链路上，到根桥路径成本最小的端口成为指定端口。
4. 阻塞剩余端口：既不是根端口也不是指定端口的，进入阻塞状态。

你看，STP通过选举机制，把冗余链路变成了备份链路。平时只有一条路走，主链路断了，STP重新计算，把备份链路激活。

我个人习惯把STP的端口状态变化记成四个阶段：阻塞（Blocking）→ 监听（Listening）→ 学习（Learning）→ 转发（Forwarding）。从阻塞到转发，默认要30秒。这个时间在现网里其实挺要命的。

4.3 环路导致广播风暴的机制

好，现在我们把环路和广播风暴串起来讲。你想想看，一个广播帧进入环网后会发生什么？

假设SW1从端口A收到一个ARP请求（广播帧）。SW1查MAC表，没找到目标，于是从所有其他端口转发出去，包括连SW2的端口B和端口C。SW2从端口B和C分别收到这个帧，然后SW2也做同样的事——从所有其他端口转发。于是SW1又从端口B和C收到SW2转发回来的帧……

这个循环每秒钟重复成千上万次。每个帧都在消耗交换机的CPU资源和端口带宽。很快，交换机的CPU就被广播帧占满了，没空处理正常的业务流量。终端设备也被迫处理海量广播帧，导致响应变慢甚至断连。

我曾经帮一个客户排查过这样的问题：他们的监控网络每隔半小时就卡死一次。我登录交换机一看，广播包数量从正常时的每秒几百个，飙升到每秒几十万个。顺着链路一查，发现一根网线被机柜门夹住了，形成了环路。拔掉那根线，网络立刻恢复。

4.4 环路与广播风暴的关系图

下面这张图展示了环路如何一步步演变成广播风暴：

4.5 环路排查的实用方法

如果你怀疑网络里有环路，别慌。我一般按这个顺序排查：

步骤	操作	预期结果
1	登录交换机，查看CPU利用率	正常应低于30%，风暴时接近100%
2	查看端口流量统计	风暴时所有端口广播包数量异常高
3	检查STP状态	确认所有端口处于正确状态（转发/阻塞）
4	逐根拔线测试	拔掉某根线后广播包数量骤降
5	启用环路保护	配置STP、loopguard、bpduguard

4.6 如何预防环路？

预防永远比排查省事。我总结了几个实用建议：

• 永远启用STP：不管网络多简单，STP必须开。我见过太多人觉得“就两台交换机，不会环”，结果一根网线插错端口就炸了。
• 配置BPDU Guard：在接入端口上启用BPDU Guard，一旦收到BPDU就自动关闭端口。这能防止用户私接交换机导致环路。
• 配置Loop Guard：防止STP单向链路故障导致的环路。
• 端口安全：限制每个端口的MAC地址数量，防止环路扩散。
• 定期巡检：用SNMP监控交换机的CPU利用率和广播包数量，设置告警阈值。

嗯，环路这东西，说白了就是网络设计时没考虑冗余和防环的平衡。STP给了我们冗余，也给了我们安全。但前提是——你得把它配好。