未知组播泛洪拖垮接入交换机：IGMP 侦听缺位

Mon, 05 Oct 2026 09:00:00 +0800

问题背景

公司三楼是营销部门集中办公区，约 120 个信息点，由两台接入交换机汇聚上联。9 月底，IT 按业务需求在三楼部署了一套分布式视频分发系统：6 间会议室各装一台视频终端，用于播放总部推送的培训与晨会直播流，视频源以组播方式(239.x.x.x 段)发送，设计意图是"一路流、全网订阅、节省骨干带宽"。

设备上线第一天下午，三楼陆续有员工反馈网络卡顿;两小时后，两台接入交换机的管理 IP 开始间歇 ping 丢，部分桌面终端掉线重连。网管平台告警显示两台接入交换机 CPU 利用率从常态的 5% 飙到 95% 以上——一个按"省带宽"设计的方案，第一天就把接入层打瘫了。

故障现象

两台接入交换机 CPU 持续 90%+,show processes cpu 里流量复制相关进程占大头；管理平面响应迟缓，SSH 经常超时。
三楼终端(有线+无线)集体症状：网页转圈、视频会议卡花屏、ping 网关丢包 30%~70%,越靠近视频终端的端口越严重。
上联口出向流量异常巨大：一台接入交换机的上联口持续 700Mbps+ 出流量，而三楼正常业务出向总和不超过 100Mbps。
视频本身反而"能播"——会议室画面正常，牺牲的是同交换机上其他所有人的流量。
抓包确认视频流目的地址是 239.255.0.100~103(组播段)，并非广播地址——排除了"广播风暴"的第一直觉。

排查过程

第一步先解释 CPU 飙高的去向。登录交换机看 CPU 排布，高耗进程是组播复制与 VLAN 泛洪相关任务；再对上联口抓包统计，发现同一路 239.255.0.100 的视频流，在每一个接入端口上都有副本——包括根本没有任何设备加入该组播组的空端口。这就是"泛洪"的直接证据：交换机把组播当成来者不拒的流量，从 VLAN 内所有端口复制出去。

第二步定位为什么会被泛洪。组播要"按需转发"依赖 IGMP 侦听(IGMP snooping):交换机监听终端的 IGMP join 报文，只向"声明过要看的端口"转发。检查配置，这两台接入交换机的 ip igmp snooping 处于启用状态(默认开启)，但 VLAN 里没有 IGMP 查询器(querier)——没有设备周期性发 IGMP General Query,视频终端发出的 join 没有被维护成组成员表项，超时后表项清空，交换机对该组退化为"未知组播"处理；而默认行为下未知组播在 VLAN 内泛洪。视频终端为了保活持续重发 join,但查询器缺位使表项始终建不起来，泛洪就 permanent 化了。

第三步核实 querier 缺位的原因。该网络的组播路由规划中，核心三层交换机本应启用 PIM 充当 querier,但视频系统设计文档里写的是"二层直连即可，无需三层组播路由"——实施时核心交换机的 PIM 没开，接入 VLAN 里也没有手动指定 IGMP querier,整条组播链路从设计起就缺了"管理者"这一环。三楼只是第一个受害者，四楼会议室挂着同一 VLAN 的另一台测试终端，只是流量小还没触发感知。

第四步排除其他嫌疑：终端 ARP 表正常无环路；STP 稳定无拓扑变更风暴；端口广播抑制阈值未触发(因为流量是组播不是广播)——这也是为什么传统的"广播风暴"排查思路在这里全数落空。

解决方案

立即止血：在两台接入交换机上对视频 VLAN 配置 ip igmp snooping querier(交换机自身担任查询器，地址用 VLAN SVI),并启用 ip igmp snooping 的未知组播抑制(unknown-multicast 转发改为丢弃+向 querier 汇报)。生效后 CPU 五分钟内回落到 15%,掉线终端全部自愈。
架构补位：核心三层交换机为视频 VLAN 启用 PIM Sparse-Mode,由核心担任正式 querier 与 RP,接入层配置固定 ip pim query-interval;视频源所在 VLAN 与接收 VLAN 间打通组播路由，保证日后跨楼层扩展不再依赖"碰运气"。
防御性配置：接入端口启用风暴控制，把组播也纳入抑制阈值(此前只配了广播)；对未知组播统一配置丢弃策略，白名单只放行经审批的组播段。
流程修正：组播类应用上线 checklist 增加三项——querier 归属确认、未知组播处置策略确认、接入层 snooping 状态确认；视频系统的设计文档同步更正"无需三层组播路由"的错误结论。

根因分析

直接根因是组播链路缺少 IGMP 查询器，组成员表项无法建立，视频流退化为未知组播被交换机在 VLAN 内全端口泛洪，接入交换机 CPU 被流量复制打满。深层根因是设计文档里"二层直连即可"的错误假设贯穿了实施与验收——组播不是"发出去就完"的单向流量，它依赖查询器、成员报告、表项维护这套持续运转的订阅机制；这套机制里缺任何一环，流量模型就从"精准投递"退化为"全楼广播"，而且退化得悄无声息：视频播得越好，泛洪越严重。

预防措施

全网交换机审计：核对每个 VLAN 的 IGMP snooping 与 querier 状态，输出基线报表入监控；
风暴控制阈值覆盖组播维度，未知组播默认丢弃；
组播应用上线必过三项检查(querier/未知组播策略/snooping 状态)，写入变更评审单；
与视频系统的厂商确认保活与 join 周期参数，避免终端行为放大表项老化问题。

总结

这次故障最容易误判的地方在于"视频明明能播"。组播的可怕之处恰恰在此：订阅机制失效时，它不报错、不中断，只是把"精准投递"静默降级成"全员广播"，用接入层的 CPU 和带宽为设计缺陷买单。排查二层流量问题时，广播风暴之外还要多问一句——组播的 querier 在哪、未知组播去哪，这两个问题答不上来，下一个被打瘫的接入交换机只是时间问题。

泛洪 on Zero Day Notes