广播丢包的症状：网络延迟飙升、CPU占用率100%、抓包发现大量广播帧、业务中断特征

说实话，很多刚入行的兄弟遇到广播风暴，第一反应是“是不是有人中病毒了？”其实不全是。广播丢包的症状非常典型，你只要抓住几个关键特征，基本就能锁定问题。我这些年排查过的广播问题不下几十起，症状表现几乎一模一样。

咱们直接进入正题，看看广播丢包到底会表现出哪些“症状”。

症状一：网络延迟突然飙升

这是最直观的感受。你正在远程操作服务器，突然发现ping值从1ms跳到了几百甚至几千毫秒。为什么会这样？

因为交换机CPU被广播帧淹没了。交换机本来要处理正常的业务数据，结果大量广播帧挤占了处理资源。数据包在队列里排队，一等就是几百毫秒。

我记得有一次，客户说他们的ERP系统卡得没法用。我远程一ping网关，延迟直接飙到800ms。当时我就判断，这八成是广播问题。后来抓包一看，果然，广播帧占了总流量的70%以上。

症状二：CPU占用率100%

这个症状在交换机上特别明显。你登录到交换机，敲个show process cpu，会发现CPU占用率直接拉满。

为什么CPU会这么忙？因为交换机收到广播帧后，需要CPU参与处理。正常情况下一秒钟几百个广播帧，CPU轻松应对。但如果一秒钟几万个广播帧，CPU就彻底崩溃了。

CPU占用率100%带来的连锁反应很可怕：

• 管理协议（如SNMP、SSH）响应超时
• 动态路由协议邻居中断
• STP（生成树协议）计算失败
• 交换机最终可能完全“死机”

症状三：抓包发现大量广播帧

这是最直接的证据。你只要在关键节点上抓包，就能看到广播帧像洪水一样涌来。

正常网络里，广播帧的比例应该很低。我一般会看两个指标：

指标	正常范围	异常范围
广播帧占比	< 1%	> 10%
广播帧速率	< 100 pps	> 1000 pps
广播帧源MAC数量	少量固定设备	大量不同MAC

抓包的时候，你重点关注几个特征：

• 目标MAC地址：全是FF:FF:FF:FF:FF:FF
• 协议类型：常见的有ARP、DHCP、NetBIOS
• 发送频率：同一台设备每秒发送成百上千个广播帧

症状四：业务中断特征

业务中断的表现形式很多，但广播丢包导致的业务中断有几个明显特征：

• 间歇性中断：业务时好时坏，不是完全断网。因为广播风暴的强度会有波动。
• 范围广泛：同一个广播域内的所有设备都受影响。不是单台设备的问题。
• 恢复缓慢：即使你拔掉问题设备的网线，网络也需要一段时间才能恢复正常。因为交换机CPU需要慢慢消化积压的队列。

我印象最深的一次，是一家工厂的MES系统突然瘫痪。所有工位的终端都连不上服务器。我赶到现场时，生产已经停了半小时。我一看症状：所有终端ping服务器都超时，但ping网关偶尔能通。这明显是广播域内的问题。后来发现是一台新接入的扫码枪，它的网卡驱动有bug，一直在疯狂发送ARP广播。

知识体系：广播丢包症状全景图

下面这张图，把广播丢包的四大症状以及它们之间的关联关系画出来了。你一看就明白。

如何快速判断是不是广播丢包？

嗯，这里要注意。不是所有网络卡顿都是广播问题。我总结了一个快速判断的方法：

1. 先看延迟特征：如果延迟忽高忽低，而且波动幅度很大，优先怀疑广播问题。
2. 再看CPU：登录交换机，敲show process cpu，如果CPU占用率持续在80%以上，基本可以锁定。
3. 最后抓包确认：在关键端口做端口镜像，抓包分析广播帧的比例和来源。