应立即排查广播风暴：先用ip link show和/proc/net/dev确认本机是否被冲击或成为源头，再用tcpdump抓包和tshark分析定位高频源MAC，最后在交换机上关闭对应端口并验证rx_bytes回落。
当Linux服务器所在局域网突发全网卡顿、ping丢包严重、交换机端口灯狂闪且CPU飙升时，必须立即排查是否由广播风暴引发——这类故障不会只影响单台机器，而是表现为整个二层域内所有设备同步异常。
确认本机是否被卷入风暴
执行 ip link show，观察所有接口的 rx_packets 和 rx_dropped 值。若某接口（如 eth0）在10秒内 rx_packets 暴涨数万甚至十万级，而 rx_dropped 同步激增，说明该接口正被海量广播帧冲击，已无法正常处理。
运行 cat /proc/net/dev，重点对比 eth0: rx_bytes 与 tx_bytes。若 rx_bytes 在30秒内增长超500MB，而 tx_bytes 几乎不变，基本可判定本机处于风暴接收侧而非源头。
这一步不能跳过：如果本机网卡驱动异常或固件bug，它自己就可能成为广播源。先排除自身问题，再查网络。
抓包定位广播帧爆发点
方法一：用 tcpdump 快速过滤广播流量
执行 tcpdump -i eth0 -c 100 'ether dst host ff:ff:ff:ff:ff:ff' -w storm.pcap。该命令仅捕获目标MAC为全F的帧，100包后自动停止。若不到2秒就满100包，说明广播帧密度极高。
方法二：实时统计广播包速率
执行 watch -n 1 'cat /proc/net/dev | grep eth0 | awk '\''{print $3}'\''，观察第三列（接收字节数）每秒增幅。持续高于8MB/s（约64Mbps）即超出正常ARP/DHCP负载，属危险阈值。
【注意】不要在风暴高峰期用 wireshark 图形界面抓全量包——GUI进程会抢占CPU，加剧系统卡死。
追踪风暴源头设备
第一步：从抓包文件提取高频源MAC
执行 tshark -r storm.pcap -T fields -e eth.src | sort | uniq -c | sort -nr | head -20。输出中排名第一的MAC地址极大概率是风暴源头——比如某IP电话固件bug导致的持续ARP广播，其MAC会反复出现在前三位。
第二步：反向定位物理端口
登录接入层交换机（如Cisco 2960），执行 show mac address-table address 。返回结果中的 Port 字段即为该设备所连交换机端口，立刻关闭该端口：interface fa0/7 → shutdown。
第三步：验证隔离效果
回到Linux服务器，再次运行 watch -n 1 'cat /proc/net/dev | grep eth0 | awk '\''{print $3}'\''。若rx_bytes增速在10秒内回落至每秒低于50KB，说明风暴已被切断。
