局域网广播风暴排查实录,我是怎么发现的

2025.7.2 杂七杂八 1746
33BLOG智能摘要
周三上午10点左右,公司网络出现剧烈卡顿,内网传输速度骤降,而外网速度基本正常。技术人员发现交换机CPU利用率仅为15%,排除硬件故障。抓取数据包后发现大量ARP广播包由同一MAC地址发出,锁定了一个新安装的4K摄像头为故障源。摄像头因NTP服务器不可达产生的固件Bug导致频繁发送ARP请求,引发广播风暴。事件后网络设备被安置在独立VLAN,交换机启用了广播风暴抑制功能,并设置了广播包监控告警。该问题强调了网络隔离与监控的重要性。
— 此摘要由33BLOG基于AI分析文章内容生成,仅供参考。

那个诡异的网络卡顿:我的局域网广播风暴排查实录

局域网广播风暴排查实录,我是怎么发现的

大家好,我是33blog的技术编辑老王。上周公司网络突然变得奇慢无比,连内网传输文件都像在用拨号上网。作为公司”首席背锅侠”,我被迫开始了这场惊心动魄的排障之旅。今天就把这个典型的广播风暴案例分享给大家,希望能帮到遇到类似问题的朋友。

一、症状:网络突然变得像老牛拉破车

周三上午10点左右,陆续有同事反映网络异常:

  • OA系统加载需要30秒以上
  • 内网文件传输速度从100MB/s降到不足1MB/s
  • 奇怪的是外网速度基本正常

最诡异的是,这种现象时好时坏,就像网络在”抽风”。我第一反应是核心交换机出了问题,但登录管理界面发现CPU利用率只有15%,似乎不太像硬件故障。

二、初诊:抓包发现异常流量

在核心交换机上抓了个包,看到这样的景象:

No.     Time        Source          Destination     Protocol Info
1       0.000000    00:1A:2B:XX:XX  Broadcast       ARP      Who has 192.168.1.1?
2       0.000100    00:1A:2B:XX:XX  Broadcast       ARP      Who has 192.168.1.1?
3       0.000200    00:1A:2B:XX:XX  Broadcast       ARP      Who has 192.168.1.1?
...(每秒上千条类似记录)

看到这个数据我头皮都麻了 – 整个网络充斥着ARP广播包,而且源MAC地址居然都是同一个!这明显是某台设备在疯狂发送广播包。

三、追凶:锁定罪魁祸首

根据MAC地址前缀00:1A:2B查到是某国产摄像头的厂商代码。跑到监控室一看,果然发现:

  • 新装的4K摄像头直接接在了办公网交换机上
  • 摄像头网络指示灯疯狂闪烁
  • 拔掉网线后网络立即恢复正常

后来联系厂商才得知,这批摄像头固件有bug,当NTP服务器不可达时会疯狂发送ARP请求。真是活久见,一个摄像头差点搞垮整个公司网络!

四、经验总结

这次事件给我上了宝贵的一课:

  1. 网络隔离很重要:IoT设备必须放在独立VLAN
  2. 广播风暴防护:交换机要开启广播风暴抑制
  3. 监控不能少:现在我在Zabbix里加了广播包数量告警

最后分享个实用命令,快速检查广播流量:

# Cisco交换机
show interface | include broadcasts

# Linux服务器
ifconfig | grep RX | grep packets

这次排障经历让我明白,网络问题有时候就像侦探破案,需要耐心和技巧。大家如果遇到类似问题,欢迎在评论区交流讨论!

评论

  • 看完惊出一身汗,摄像头竟然能搞出这么大问题!感谢分享经验

  • 我们公司最近也遇到类似问题,改天试试作者说的方法👏

  • 这种排障经验太有用了,建议多出这种实操性强的技术文章

  • 学到了!原来广播风暴是这么回事,一直以为是交换机问题

  • 哈哈,首席背锅侠这个自称太真实了,IT人的日常啊😂

  • 请问下要是交换机上开了storm-control,这种问题是不是就能避免了?