1. 广播风暴的成因：从一次网络瘫痪说起

我记得刚入行那会儿，接手过一个写字楼的网络故障。整栋楼一到上午十点就断网，过了中午又自己好了。排查了三天，最后发现是 DHCP 地址池耗尽加上一台傻瓜交换机环路——说白了，就是广播风暴把网络给“撑死”了。

从那以后，我对广播帧、ARP 请求这些东西就特别敏感。你想想看，一个本来只在本地传播的广播帧，一旦在二层网络里转起圈来，那破坏力可不小。

1.1 广播帧的定义：到底什么是“广播”？

广播帧，就是目的 MAC 地址全为 FF:FF:FF:FF:FF:FF 的以太网帧。交换机收到这种帧，会把它从除了接收端口以外的所有端口转发出去。

说白了，广播帧就是“喊一嗓子，所有人都得听”。但问题也出在这里——如果所有人都同时喊，网络就乱了。

1.2 ARP 请求与 DHCP 发现：最常见的广播源

实际网络中，广播帧主要来自两个协议：ARP 和 DHCP。我做过统计，一个中等规模的办公网络里，ARP 广播能占到总广播量的 60% 以上。

协议	广播类型	触发场景	频率
ARP	ARP 请求	主机需要知道目标 IP 对应的 MAC	高（每次通信前都可能触发）
DHCP	DHCP Discover	客户端获取 IP 地址	低（仅设备接入时）
NetBIOS	名称查询	Windows 网络发现	中（取决于配置）

ARP 请求的工作流程：

主机A（192.168.1.10）想给主机B（192.168.1.20）发数据
→ 主机A检查 ARP 缓存，没有 B 的 MAC
→ 主机A发送广播帧："谁是 192.168.1.20？请告诉 192.168.1.10"
→ 所有主机都收到这个广播，但只有 B 回复
→ 主机A收到回复，更新 ARP 缓存，开始通信

DHCP 发现的过程：

客户端开机 → 发送 DHCP Discover（广播，源 IP 0.0.0.0）
→ DHCP 服务器收到后回复 DHCP Offer
→ 客户端发送 DHCP Request（广播）
→ 服务器确认 DHCP ACK

你可能会问：为什么 DHCP 也要用广播？因为客户端这时候还没有 IP 地址，它只能用广播来“喊”服务器。

1.3 二层网络中的广播域

广播域，就是广播帧能到达的范围。在二层网络中，所有连接在同一台交换机（或通过级联/堆叠连接的交换机）上的设备，都属于同一个广播域。

我个人的经验是，当广播域内的设备超过 200 台时，就应该考虑用 VLAN 来分割了。否则，一次 ARP 泛洪就能让全网响应变慢。

1.4 环路与广播风暴的触发机制

好了，前面都是铺垫。现在来说最核心的问题：环路是怎么导致广播风暴的？

假设有三台交换机连成了一个三角形环路：

    [Switch A]
    /        \
[Switch B]——[Switch C]

当某台主机发送一个广播帧时：

1. Switch A 收到广播帧，从所有其他端口转发出去
2. Switch B 和 Switch C 都收到了这个帧
3. Switch B 又把帧转发给 Switch C 和 Switch A
4. Switch C 同样转发给 Switch B 和 Switch A
5. 帧开始在环路里无限循环，而且每经过一台交换机就复制一份

这就是广播风暴的触发机制。帧的数量呈指数级增长，几分钟内就能把交换机的背板带宽和 CPU 全部耗尽。

我曾经在测试环境里故意制造过一次环路——嗯，就为了给新同事演示。结果不到 30 秒，整个机房的网络就卡死了，连 SSH 都连不上。最后还是拔线解决的。

1.5 核心逻辑：广播风暴的完整链路

下面这张图把整个因果关系串起来了：

从这张图可以看得很清楚：广播帧本身不是问题，ARP 和 DHCP 也是正常协议行为。但一旦广播域内出现环路，这些正常的广播帧就会变成“网络杀手”。

1.6 小结：记住这三句话

• 广播帧是必要的——没有广播，ARP 和 DHCP 就没法工作
• 环路是致命的——哪怕只有一条冗余链路没配 STP，风暴就可能发生
• 预防比治理重要——等风暴起来了再拔线，网络已经瘫痪了