很多网络工程师在第一次接触 IPTV、视频监控或者校园直播时，都会遇到一个很诡异的现象。

网络明明设计得很好，链路带宽也很充裕，但只要有用户打开 IPTV，整个接入交换机的流量就突然飙升，甚至有时候整栋楼网络都会变慢。

抓包一看才发现——

交换机里到处都是 224.x.x.x 的组播流量。

有的端口根本没人看电视，却在疯狂收视频流。

如果没有做过组播优化，这种情况其实很常见。因为在默认情况下，交换机并不知道哪些端口真的需要组播流量，于是最简单粗暴的做法就是——像广播一样泛洪出去。

于是，问题就来了。

今天这篇文章，我们就系统地聊一聊 二层组播技术，包括网络工程师最常见的几项能力：

IGMP SnoopingIGMP ProxyFast LeaveMVS（Multicast VLAN Switching）

如果理解了这几样东西，你基本就能搞明白 IPTV网络、视频监控网络、直播网络背后的二层逻辑。

为什么二层网络会“泛洪组播”

先理解一个基础事实。

以太网交换机在二层其实并不理解 IP 组播。

交换机认识的是：

单播 MAC广播 MAC未知 MAC

而 IPv4 组播地址（224.0.0.0～239.255.255.255）在二层会被映射成一个特殊的 MAC 地址：

01:00:5E:xx:xx:xx

问题就在这里。

对于普通交换机来说，这种 MAC 地址通常 不会学习到 MAC 表里。

结果就是：

交换机不知道这个组播流量应该发给谁。

于是只好采用最简单的策略：

像广播一样泛洪到所有端口

这就是为什么：

一个用户看 IPTV整个接入交换机端口都在收视频流

如果是 20M 一路视频流，几十个端口同时收到，很容易就把交换机带宽打满。

这就是早期网络部署 IPTV 时常见的灾难。

解决这个问题的关键，就是：

让交换机知道谁需要组播。

于是，IGMP Snooping 登场了。

IGMP Snooping

IGMP Snooping 的名字其实很有意思。

Snooping = 偷听

它的核心思想非常简单：

交换机不参与 IGMP，但会“偷听” IGMP 报文，从而知道哪些端口加入了组播组。

IGMP 是什么？

IGMP（Internet Group Management Protocol）是 主机和路由器之间的组播管理协议。

当一台电脑想看 IPTV 时，它会发送一个报文：

IGMP Join

意思是：

我要加入 239.x.x.x 这个组播组。

传统交换机对这个报文是无感的，但 IGMP Snooping 交换机会解析它。

于是交换机就会在内部维护一张表：

组播地址

端口

239.1.1.1

GE1/0/10

239.1.1.1

GE1/0/12

以后只要收到 239.1.1.1 的组播流量：

交换机只会发给：

GE1/0/10GE1/0/12

其他端口不再泛洪。

这样网络瞬间就干净了。

很多人第一次看到这个机制时都会觉得：

原来交换机可以这么“聪明”。

但实际上它只是做了一件事：

监听 IGMP。

为什么网络里必须有 IGMP Querier

IGMP Snooping 虽然好用，但它有个前提。

网络中必须有一个设备定期问一句话：

还有人要这个组播吗？

这个角色叫：

IGMP Querier（查询者）

一般由三层设备承担，比如：

核心路由器三层交换机BRASIPTV 网关

Querier 会定期发送：

IGMP Query

意思是：

还在看的用户报个到。

用户如果还在看 IPTV，就会回复：

IGMP Report

交换机继续更新 Snooping 表。

如果长时间没有回复：

交换机就会认为：

这个端口已经不需要组播了。

然后把它从表里删除。

这个机制其实很像：

点名。

老师（Querier）定期点名 学生（用户）回应 班长（交换机）记笔记

Fast Leave

很多人第一次部署 IPTV 时会发现一个奇怪问题。

用户关闭 IPTV 后：

组播流量还会持续几十秒。

原因其实很简单。

正常情况下，用户离开组播组会发送：

IGMP Leave

但交换机不会立刻停止转发。

它会再问一遍：

还有人看这个组吗？

如果没人回答，才会删除。

这个过程通常要 10~30秒。

问题来了。

在家庭网络或者宿舍网络中，常常是：

一个端口只有一个用户。

这时候再去确认就显得多余。

于是厂商提供了一个优化功能：

Fast Leave

开启之后逻辑变成：

用户发出 Leave

交换机立刻认为：

好，你不看了。

然后 马上删除端口的组播成员关系。

效果就是：

组播流量瞬间停止频道切换更快网络更干净

但这里有个前提。

端口必须是单用户端口。

如果一个端口后面接的是：

HUB二层交换机AP

那就不能开 Fast Leave。

否则可能会把其他用户误踢下线。

IGMP Proxy

在运营商网络里，还有一个常见技术：

IGMP Proxy

这个技术通常出现在：

家庭网关宽带接入设备ONUBRAS

Proxy 的逻辑其实很有意思。

它的角色像一个 秘书。

比如家里有三台电视：

客厅卧室书房

三台电视都看同一个频道。

如果没有 Proxy：

设备会上报三次 IGMP Join。

但 Proxy 会这样处理：

用户 → Proxy → 网络

三台电视的请求被合并成 一次 Join。

于是运营商网络只需要发送：

一份组播流。

Proxy 再在本地复制给三台电视。

这样做有两个巨大好处：

减少网络 IGMP 报文数量

运营商网络中可能有：

几百万用户

如果每个电视都发 IGMP：

核心设备压力会非常大。

Proxy 可以大幅减少 IGMP 信令。

第二个好处是：

减少组播状态数量

核心设备维护的组播成员会更少。

网络更稳定。

MVS：运营商 IPTV 网络的关键技术

如果你做过运营商网络，就会听过一个词：

MVS（Multicast VLAN Switching）

很多人第一次听到这个功能时都会疑惑：

为什么组播还要和 VLAN 扯上关系？

原因其实很现实。

在运营商接入网络中，每个用户通常是：

独立 VLAN

比如：

用户

VLAN

用户A

100

用户B

101

用户C

102

这样做是为了隔离用户。

但 IPTV 组播流来自同一个源。

如果每个 VLAN 都单独复制一份组播流：

网络带宽会被迅速放大。

于是运营商提出一个思路：

IPTV 组播统一在一个 VLAN 中传输。

这就是：

组播 VLAN

比如：

VLAN 4000 = IPTV Multicast VLAN

然后用户 VLAN 通过 MVS 机制：

共享这个组播流。

这样做的好处非常明显。

不管有多少用户 VLAN：

网络只需要一份组播流。

带宽利用率极高。

MVS 的工作原理

MVS 的核心逻辑其实可以简单理解为：

跨 VLAN 的组播复制

用户 VLAN：

VLAN 100 VLAN 101 VLAN 102

组播 VLAN：

VLAN 4000

当用户加入组播组时：

交换机会做两件事：

第一步：

把 Join 信息映射到 Multicast VLAN。

第二步：

在用户 VLAN 和 Multicast VLAN 之间建立转发表。

于是数据流路径变成：

组播源 ↓ Multicast VLAN ↓ 用户 VLAN

这样：

网络只需要 一份组播源流量。

所有用户共享。

这也是为什么 IPTV 网络能支撑 几十万用户同时看电视。

在真实网络里，这几项技术往往是组合使用的。

一个典型的 IPTV 网络结构可能是：

视频源 ↓ 核心路由器（PIM） ↓ 汇聚交换机（IGMP Snooping） ↓ 接入交换机（IGMP Snooping + Fast Leave） ↓ 家庭网关（IGMP Proxy） ↓ 电视机

如果是运营商接入网络，还会加入：

MVS Multicast VLAN

于是整个网络的组播逻辑就变成：

核心负责路由

接入负责监听

终端负责加入

每一层都有明确职责。