组播在机房里为什么会变成「谁都收得到」：IGMP Snooping 失效后，整段二层网都在替你付费

故障现象先摆出来：只有几台机器订阅，整个 VLAN 一起抖

先把现象摆清楚。一个行情分发系统，真正订阅组播组的机器只有个位数，可同一 VLAN 里十几台跟这个业务毫无关系的机器，网卡指示灯一起狂闪，系统负载莫名其妙往上走。运维的第一反应通常是被人打了，或者哪台机器在跑什么不该跑的东西。查了一圈，攻击没有，异常进程也没有，最后在交换机上看端口计数才发现：组播帧被当作未知组播，在 VLAN 内泛洪了。

这类故障最难的地方在于症状长得太像性能问题。机器慢、负载高、软中断时间占比上升，看上去就是"这台机器不行"。但真正的账单不在这些机器上，在网络上。把组播当成省带宽的手段，前提是交换机真的知道谁在订阅；这个前提一旦不成立，组播的行为就退化成广播，而且退化得悄无声息。

所以本文只回答一个问题：组播省流量这件事，成立的前提到底是什么；前提破了以后会发生什么；又该怎么确认、怎么处置、什么时候干脆别用。

组播在二层到底怎么转发：没有订阅表的时候只能泛洪

交换机转发单播帧靠的是 MAC 地址表，这张表是怎么来的？靠学习。交换机收到一个帧，看它的源 MAC，记下"这个 MAC 从这个端口进来"，下次要去这个 MAC 就从这端口出去。学习的前提是：这个 MAC 会作为源地址出现在帧里。

组播 MAC 永远不会作为源地址出现。没有主机会以一个组播地址的身份往外发帧，交换机也就永远学不到组播 MAC 对应的端口。学不到，转发表里就没有这一项。那交换机怎么处理目的 MAC 是组播地址的帧？默认行为是在 VLAN 内泛洪，也就是从这个 VLAN 的其他端口都复制一份发出去。

泛洪在行为上跟广播非常接近，差别只在于动机：广播是设计上就要所有人收，组播泛洪是交换机"我不知道谁要，那就都发一份"。IPv4 组播地址对应的二层 MAC 以 01:00:5e 开头，交换机看到这个 OUI，如果没开 snooping 或者表里没有对应项，就走泛洪这条路。

这就是为什么组播在二层很容易变成"谁都收得到"。它不是攻击，也不是配置错误引发的异常行为，它是交换机在没有订阅信息时的默认且正确的行为。想改变这个行为，必须给它订阅信息。

IGMP Snooping 是怎么让交换机"知道谁要"的

IGMP Snooping 解决的就是"交换机不知道谁要"这件事。主机加入一个组播组时，会主动发出 IGMP 成员报告；离开时，IGMPv2 之后的版本会发出离开报文。交换机开启 snooping 后，会监听（snooping，探听）这些报文，据此维护一张"哪个端口属于哪个组播组"的转发表。

有了这张表，交换机的行为就变了：一个组播帧进来，先查表，只向那些确实有订阅者的端口转发，其他端口不复制。这才是组播省带宽的版本。省下来的那部分，本质上就是"本来要发给所有人，现在只发给需要的人"的差额。

注意这张表的维护方式是被动监听加老化。它不是一次配置永久有效的静态表，而是靠报文持续刷新。报文断了，表项会老化；老化之后，交换机并不认为"订阅者走了"，而是回到"我不知道谁要"的状态，于是退回泛洪。这两种状态在运维眼里差别巨大，但在交换机眼里只是"有表项"和"没表项"的区别。

还有一点容易被忽略：snooping 的粒度是端口，不是主机。一个接入端口下如果挂了二层交换机或者虚拟化宿主，下面有多台虚拟机，那这个端口只要有任何一个订阅者，整条链路都会收到流。接入层的级联设备本身也要支持并正确配置 snooping，否则省流量的效果在最靠近服务器的一跳就漏光了。

Querier 缺失时，snooping 会退回什么状态

主机不会无缘无故周期性汇报自己的成员关系。触发它汇报的，是 IGMP Querier 周期性发出的查询报文。Querier 在 VLAN 内发通用查询，主机收到后回应成员报告；这些报告既是给 querier 看的，也被交换机探听到，用来刷新 snooping 表项。

链条断在 querier 上，后面就全断了。一个 VLAN 里如果没有 querier，或者 snooping 依赖的查询没有配置，主机只在刚加入时发一次报告，之后就不再发。交换机表项超过老化时间被清掉，而订阅者其实还在那儿好好地收着（或者已经收不到了，取决于硬件实现与配置）。

退回的状态就是泛洪。这跟没开 snooping 的结果是一样的，但排查起来更坑：看配置，snooping 是开着的；看现象，流量却在全 VLAN 泛洪。中间缺的那个环节就是 querier。很多"我明明开了 snooping 怎么还是泛洪"的疑问，答案都在这儿。

虚拟化环境里这个问题更常见。宿主上的虚拟交换机可能自己充当 querier，也可能完全不参与；桥接、隧道、SR-IOV 直通又把主机的成员报告路径改得七零八落。结果就是物理交换机上看不到报告，表项建立不起来。判断依据很简单也很实在：去确认这个 VLAN 内到底有没有设备在周期性发查询，别只看 snooping 开关是不是打开的。

开了 snooping 还收到不该收的：32 个 IP 组共用同一个 MAC

还有一种情况更让人困惑：snooping 确认开着，querier 也在，表项也建起来了，可某台机器还是收到了它没订阅的流，而且目的 IP 确实不是它订阅的那个组。这不是 snooping 失效，是 IPv4 组播地址到二层 MAC 的映射本身就有重叠。

映射规则是这样的：组播 IP 的 28 位组地址，被映射进 23 位的 MAC 地址位（配合 01:00:5e 开头的 OUI）。28 位塞进 23 位，高位的 5 位信息丢失了，于是每 32 个 IP 组播组会映射到同一个二层 MAC 地址。

后果很直接。即便开了 snooping，同 VLAN 内的主机仍可能收到地址不同但 MAC 相同的组播流。交换机在二层看到的只是那个 MAC，它分不出这是 32 个组里的哪一个；网卡的 MAC 层过滤同样分不出。这个过滤只能交给上层协议栈，由 IP 层比对目的地址，把不是自己的丢掉。

所以"收到不该收的"要分两种。一种是二层就收下、IP 层丢掉，属于映射重叠带来的固有开销，开销在网卡和内核，量取决于同 VLAN 内有多少撞在同一个 MAC 上的组；另一种是二层转发范围本身就没被收敛，属于 snooping 或 querier 的问题。两种的处置完全不同，混为一谈就会白忙一场。规划组播地址时，把会撞在同一 MAC 上的组尽量错开，也是能提前省掉一部分麻烦的。

一条组播流从订阅到收包，中间要经过哪些环节

把整条链路串起来看，失效点会更容易定位。第一环是主机侧：应用调用加入组播组的接口，内核协议栈发出 IGMP 成员报告，同时网卡开启对应组播 MAC 的接收过滤。这一步不做，后面的交换机再聪明也不知道这台机器要什么。

第二环是接入交换机：它探听到这份报告，在 snooping 表里记下"端口 X 属于组 G"。这一环的失效点最多，snooping 没开、querier 缺位、级联设备不支持、虚拟化宿主的报告没透传上来，都会让它记不下来。

第三环是汇聚与核心：组播流从源进来，需要在这些设备上同样有正确的转发表项。只有接入层开了 snooping、汇聚层没开，流一样会在汇聚层泛洪，只是范围换了个层级。省流量这件事必须整条路径都成立，任何一跳缺位，缺口就在那一跳。

第四环是订阅者的网卡与内核：帧到了网卡，MAC 层过滤决定是否收下，收下之后由 IP 层判断是否属于本机订阅的组，最后才交给应用 socket。前面提过的 MAC 映射重叠就发生在这里，网卡收下、内核丢弃，这份工作量同样真实存在。

这四环是串联关系，不是并联。任何一环断掉，表现都可能是"收不到"或者"全都收到"，但断的位置决定了处置方式。先想清楚流走到哪一环断了，再动手改配置，比从第一台交换机开始挨个试要快得多。

跨三层就断：三层组播路由与机房、云环境的支持边界

IGMP Snooping 只在二层域内有效。它告诉你"这个 VLAN 的这些端口要"，但组播流怎么从另一个网段过来，它管不了。跨三层需要三层组播路由协议配合，比如 PIM，由路由器之间协商出分发树，把流从源所在网段送到有订阅者的网段。

问题在于，很多机房或云环境的二层域并不提供组播，或者跨网段之后组播直接不通。这是环境的能力边界，不是配置能绕过的事。订阅者在一个网段、源在另一个网段、中间没有三层组播路由，那现象就是"我明明 IGMP 加入成功了，一个包都收不到"。加入成功只说明本地二层认了，不代表流能跨过来。

这也是为什么组播的可用性必须在签约和验收阶段就问清楚，而不是等应用写完了再试。应用侧的代码、内核参数、网卡配置都能改，网络侧放不放行组播是另一回事。一万网络深耕 IDC 19 年（成立于 2007 年），如果业务真的离不开组播，签约前先问清这一层网络放不放得下，比事后返工便宜得多。

顺带说一句，隧道和叠加网络也救不了底层不支持。组播流要么在叠加层被复制成单播发出去，要么就需要底层承载网真的支持组播。前者本质上是应用层分发换了层皮，后者才是真的组播。

TTL 是组播的范围开关

TTL 在单播里是防环的跳数计数，在组播里多了一个含义：它是范围开关。每经过一次三层转发，TTL 减一，减到零就被丢弃。应用程序的组播 TTL 设得过大，流量会试图跨越本不该跨越的范围；设得过小，又到不了目的地。

这个参数经常被当成默认值一带而过。默认值通常是为"局域网内"设计的，应用在容器里、在虚拟机里、经过了几跳路由，默认 TTL 就可能不够。反过来，一个只在单个机柜内使用的业务把 TTL 设得很大，等于把扩散范围的唯一一道闸门拆了。

TTL 的价值在于它是端到端可控的，不依赖网络设备的配合。即使 snooping 配错了、querier 没配、三层路由存在但范围没收敛，一个收紧的 TTL 仍然能把最坏情况限制在有限跳数内。它是兜底，不是解决方案，但兜底往往能在故障真正发生时决定影响面。

失效之后账单由谁付：整段二层网一起承担

组播省流量成立的时候，账单是"只发给订阅者"；不成立的时候，账单是"发给 VLAN 内所有人"，而且这份账单是被分摊到跟这个业务毫无关系的机器上的。这是组播故障最不公平的地方：产生流量的人不付账，付账的人完全不知道自己为什么忙。

具体到机器上，泛洪让同一 VLAN 内所有机器的网卡都收到全部组播流量，网卡与内核的软中断处理量上升，与业务无关的机器被一起拖累。这些机器上的业务监控会显示负载升高、中断不均衡、网络收发计数异常，但业务量明明没变。症状常被误判为"机器性能差"，于是有人去查 CPU、换内核参数、调中断亲和性，一圈下来什么也没解决。

判断是不是这个原因有个很朴素的角度：看负载升高的机器是不是集中在同一个 VLAN、同一个接入交换机下。如果是，那大概率不是这些机器各自出了问题，是网络给它们统一派了活。这个角度不需要任何工具，只需要把受影响机器的位置画出来。

后果之所以说是"可预测的"，正因为它不是随机的。snooping 失效、querier 缺失、跨三层、MAC 映射重叠，每一种失效都有确定的行为结果，确定了失效模式就能推断出影响面。真正难的是识别失效模式本身，因为现象伪装成了性能问题。

观测与排查的顺序：先看三层，再看表，最后看机器

排查顺序建议从网络往主机走，而不是反过来。先看交换机端口的组播报文计数与 IGMP 表项：计数是否在多个无关端口上一起涨，表项里有没有对应的组。再看服务器网卡的多播/组播包计数与软中断分布：包计数涨了但业务量没涨，那就是在替别人付账。然后确认 VLAN 内是否有 querier，确认组播是否跨了三层，确认 TTL 设置。

这五步的顺序是有道理的。前两步决定"是不是泛洪"，后三步决定"为什么泛洪"。跳过前两步直接改配置，等于在不知道故障模式的情况下碰运气。

处置方向也就对应着几条路：启用并正确配置 snooping 与 querier，把组播业务划分到独立 VLAN，收紧 TTL，或者干脆改成单播、改由应用层分发。选哪条取决于业务能不能改、网络能不能改、以及网络上到底放不放得下。

组播异常现象的确认与处置对照（以下为典型部署思路，并非特指某一真实客户）

哪些业务真的需要组播

组播不是过时技术，它在几类业务里确实合适。第一类是金融行情分发：一份行情要同时给很多个订阅端，内容完全相同，订阅者数量可能很多且动态变化。这种一对多、内容同质、实时性敏感的负载，正是组播设计出来要解决的场景。

第二类是 IPTV 与内网视频分发。一个频道一个组播组，用户换台就是离开一个组、加入另一个组，网络侧只需要在有观众的端口上复制流。用单播做同样的事，链路带宽会随观众数量线性增长，组播则不会。

第三类是集群心跳与成员管理。部分集群软件使用组播做心跳与服务发现，成员之间互相知道彼此还在，靠的就是往一个组里发、大家都收。这类流量的特点是小、频繁、成员固定，组播在这里的价值更多是"一次发送全员可见"的语义，而不是省带宽。

第四类是某些服务发现机制。设备或服务上线后往组里宣告自己，需要的人监听。这类用法对可靠性要求通常不高，丢一两个包无所谓，但对"能不能发出去、能不能被听到"是有硬要求的，一旦环境不放行组播，这类机制会静默失败。

反过来看，不适合组播的也很清楚：订阅者就一两台的、内容因人而异的、要求可靠不丢包的、跨公网传输的。这些场景硬上组播，除了给自己增加一层排障难度，没有别的好处。说实话，很多"我们要用组播"的需求，问两句就发现订阅者只有两台机器，那直接单播最省事。

改单播或应用层分发，成本怎么变

改单播的成本不是凭空多出来的，它只是把原来由网络承担的复制工作搬到了发送端或者中间节点上。组播省的是链路带宽和发送端出口，代价是依赖网络设备的正确配合；单播省的是这份依赖，代价是带宽随订阅者数量增长。

换成应用层分发，比如用消息代理转发，本质上是把复制逻辑上移到应用层。发送端只发一份给代理，代理负责复制给每个订阅者。这条路的带宽账单跟单播一样随订阅者增长，但换来的是：不需要网络支持组播、不需要 snooping、不需要 querier、不需要三层组播路由，跨网段跨机房都不成问题。

代价要算清楚。多了一跳转发，延迟会上去；代理本身成了新的容量瓶颈和单点，需要冗余；可靠性模型从"网络尽力而为"变成"代理可以做确认、重传、堆积"，这既是好事也是新的运维对象。订阅者规模小的时候，这笔账非常划算；规模大到一定程度，链路复制的成本优势又会重新倾向于组播。

判断标准可以很简单：先看订阅者数量级和跨网段需求，再看网络侧能不能配合。网络侧放不下，讨论组播就是浪费时间；网络侧放得下但订阅者就几台，也没必要上组播。两个条件都满足，才值得认真做。

还有一个隐性成本常常被漏算：排障能力。组播一旦出问题，能查的手段比单播少得多，能看懂 IGMP 表项和端口组播计数的人也比会看流量图的人少。单播出问题，抓包、看连接、看路由，套路是通用的；组播出问题，要先懂 snooping 和 querier 才能开始查。把团队能力算进成本，很多中小型业务会直接倒向单播，这不是技术保守，是对运维时间的合理定价。

迁移路径上也有个务实做法：把分发层抽象出来，先跑单播或应用层分发，等订阅者规模和网络条件都到位了，再在分发层内部换成组播，对上层业务透明。这样组播是可选优化项而不是架构前提，环境不放行也不影响交付。

VLAN 划分与广播域边界：把组播关进笼子

不管 snooping 配得多好，广播域本身就是影响面的上限。一个 VLAN 里塞了两百台机器，组播业务一旦出问题，最坏情况就是这两百台一起扛；把它划到一个只有十几台机器的独立 VLAN，最坏情况也就是这十几台。这是不需要任何技术优化就能拿到的收益。

划分的粒度要按业务来，不要按部门或者按机柜位置。组播源和它的订阅者放进同一个 VLAN，其他机器一律不放进去。订阅者分散在多个位置的，就要考虑是不是该放弃二层组播、改走三层或者应用层，而不是为了迁就组播把不该在一起的机器塞进同一个广播域。

顺带一提，广播域收缩还有个附带好处：泛洪范围小了，排查范围也小了。受影响机器集中在一个小 VLAN 里，一眼就能看出这是网络问题而不是机器问题。大二层看起来省事，出事的时候格外费事。

云环境为什么常常不放行组播

在云上用组播，大多数时候会碰壁。原因不神秘：云网络的底层大多是为单播设计的虚拟化转发面，组播需要在虚拟交换机、隧道封装、物理承载多个环节上都有对应实现，还要处理租户隔离下的一对多复制，工程复杂度和收益不成比例。于是很多云环境干脆不提供组播，或者只在非常有限的范围内提供。

租户隔离是另一道坎。组播的一对多语义在共享物理网络上是危险的——如果复制逻辑没有严格的租户边界，一个租户的组播流理论上可能扩散到别人的链路上。与其承担这个风险，不如不支持。

所以在云上做架构，默认假设就应该是"组播不可用"，然后在这个假设上设计。行情分发、视频分发、集群心跳这些原本依赖组播的组件，在云上通常都要换成单播或者应用层分发。这不是退而求其次，是环境决定技术选型，硬要在云上把组播跑通，后续每一次网络变更都可能把它打回原形。

自建机房和托管环境的情况不一样，物理交换机是真的交换机，snooping、querier、三层组播路由都是能配的。但"能配"不等于"已经配好"，更不等于"默认配好"。托管环境下网络设备通常由机房侧管理，能不能配、配成什么样，得提前谈。一万网络深耕 IDC 19 年（成立于 2007 年），如果业务真的离不开组播，签约前先问清这一层网络放不放得下，比事后返工便宜得多。

验收前该向网络方问清哪些问题

组播相关的坑，大部分可以在签约和验收阶段问掉。以下是几个值得逐条确认的问题，问清楚了能省掉后面大量的返工：

第一，这个二层域内是否启用 IGMP Snooping，是全局启用还是按 VLAN 启用，我业务所在的 VLAN 在不在其中。第二，这个 VLAN 内有没有 IGMP Querier，谁在充当 querier，查询间隔是多少，如果我这边接入的是虚拟交换机，它和物理交换机的 querier 角色会不会冲突。

第三，组播是否需要跨三层，跨三层的话是否部署了 PIM 之类的三层组播路由，哪些网段之间可以通。第四，环境对组播有没有范围限制，比如 TTL 上限、可加入的组地址范围、单个端口的组播组数量限制。第五，接入层如果还要往下级联交换机，那些设备是否也支持并启用了 snooping。

第六，出问题的时候我能看到什么：能不能查端口组播报文计数、能不能看 IGMP 表项、出故障时能不能提供这些排障信息。第七，如果将来订阅者规模扩大或者要跨机房，组播这条路的边界在哪里，什么时候必须改架构。

这些问题看着琐碎，但每一条都对应着一个具体的失效模式。问不清就上线，等于把排障的时间成本提前预支给了未来。网络设备不是黑盒，只是很多人没在合适的时候去敲它。

组播省流量的前提是交换机知道谁在订阅，否则整段二层网都在替你付费

回到开头那个现象：几台机器订阅，十几台无关机器跟着抖。它的根因不是网络攻击，不是机器不行，而是交换机不知道谁订阅了，于是按默认行为在 VLAN 内泛洪。组播省带宽的前提从来不是"用了组播这个协议"，而是"交换机真的知道谁在订阅"。

一旦 snooping 失效、querier 缺失或者跨了三层，组播就退化成广播，账单由整个二层域一起承担。这份账单不会出现在任何一张流量报表里，它分散在十几台毫不相关的机器的软中断里，看上去像性能问题，实际上是网络问题。

所以结论不需要复杂：先确认网络侧放不放得下组播，配好 snooping 与 querier，把广播域收小，把 TTL 收到够用为止；做不到这些，就别用组播，改成单播或者应用层分发。技术选型上最贵的从来不是选错方案，是选了一个环境撑不住的方案，然后在排障上无限期地付利息。

数据来源与核验说明：组播与 IGMP Snooping 的公开机制口径

本文内容基于以太网二层转发、IGMP Snooping、IGMP Querier、IPv4 组播地址到 MAC 映射、三层组播路由等公开机制描述，涉及的行为结论均来自这些机制的既定定义：未知组播在 VLAN 内泛洪、snooping 通过监听成员报告与离开报文维护端口与组的转发表、querier 缺失导致表项老化后退回泛洪、28 位组地址映射进 23 位 MAC 地址位因而每 32 个 IP 组播组共用同一二层 MAC、跨三层需要 PIM 等三层组播路由协议配合、TTL 决定组播的扩散范围。文中出现的场景均为典型部署思路，并非特指某一真实客户；文中未引用任何实测、压测数据，未给出精确的带宽、包速率与资源占用数值，相关趋势描述需以自有业务的实际观测为准。