当前位置：首页 > TCP/IP > 正文

【NE探秘】一个报文的路由器之旅-(10) IP组播转发流程

TCP/IP
2022-10-13
2481
更新：2022-10-14 09:30:07

> 本帖介绍IP组播的转发流程，先介绍IP组播基础知识。
>

# **IP组播快速入门**

## **单播、组播、广播**

IP通信有三种方式：

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">第二种是广播（broadcast），在一台源IP主机和网络中所有其它的IP主机之间进行。广播属于一对所有的通讯方式，无路由过程，中间的交换机和路由器对数据进行无条件的复制和转发，所有主机都可以接收到（不管是否需要）。广播不仅会将信息发送给不需要的主机而浪费带宽，也可能由于路由回环引起严重的广播风暴，所以广播数据被限制在二层交换的局域网范围内，禁止其穿过路由器，防止广播数据影响大面积的主机。但IP网络中，广播也是不可少的，如客户机通过DHCP自动获得IP地址的过程，通过ARP请求获得某IP地址对应的MAC地址的过程，都需要使用广播。
</span>

可能有读者会有疑问，网页浏览和网络视频点播，虽然不是所有人都想看，但观看的人数不少，假设有1000个人想看同一个网页/视频，采用单播，服务器就得逐一传送，重复1000次相同工作，那为什么采用单播不是组播呢？

那是因为，不是所有客户都是同一时间想看同一内容，单播能够针对每个客户的及时响应；如果采用组播，用户便有“过了这个村就没那个点“的烦恼。视频/音频会议、股票行情发布，实时性很高，用户在同一时间看同一内容，就很适合采用组播。

组播对于网络而言还是很有魅力的，比如下图所示场景，一目了然，组播比单播更能节约网络资源，也极大减轻了服务器的负担。

## **组播分发树**

上图右侧所示的网络流量转发路径，像不像一棵倒长的树？这棵树称为”组播分发树“，树根是服务器（称为组播源）；树叶是客户端（称为组播接收者）。只是，组播分发树有个特别之处，从根到叶子都是一样粗，也就是说，网络负载不会随着组播接收者（客户端）数量的增加而增加，这就是组播的魅力所在。

那么，IP网络是如何将报文从组播源沿着组播分发树发送给众多接收者呢？如下图中的Router-X收到组播数据后，该如何转发呢？

按照传统IP的寻址转发机制，首先Router-X要到转发表去匹配目的接收者的地址，找到对应的出接口。上图中，组播的目的地址是组播接收者1、接收者2、……，接收者7；出接口是接口A、接口B。那么，Router-X在转发组播数据时，是拿数据包去逐一匹配目的地址（组播接收者1、接收者2、……，接收者7）吗？这显然效率太低了。如果组播接收者的数量非常巨大，尤其是越靠近组播源的节点，其组播接收者越多。这么大量的组播接收者，如果都在组播转发表项中都列出来，转发时逐一去匹配，是不大现实的。为此，诞生了“组播组“这个词。

## **组播组**

“组播组“用来表示一群组播接收者，即**组播接收者的集合**。组播组并不代表网络上的具体主机，仅仅代表相应的接收者组成的集合，只用于组播报文从组播源往接收者方向发送，是单向的。“组播组”如同电视频道，组播源如同电视台。电视台向某频道内发送数据；观众想看该频道的节目，就打开电视机切换到该频道即可。

### **组播组地址**

为了让组播数据在网络中能被正确的寻址转发，需要给“组播组”分配地址。

组播报文在三层（IP）层转发时，使用的是D类IP地址，即224.0.0.0至239.255.255.255之间的IP地址。协议规定，其中的224.0.0.0至224.0.0.255为保留的组播地址，给本地网络协议使用，比如224.0.0.5和224.0.0.6这两个是OSPF协议使用的组播地址，路由器对收到的目的地址在此范围内的报文，不管报文的TTL值是多少，都不能进行转发。

当组播报文在以太二层网络转发时，需要用到组播MAC地址。组播MAC地址同单播MAC地址一样，都是48bit，一般用6字节的十六进制来表示，如XX-XX-XX-XX-XX。IEEE 802.3规定，MAC的第0字节的末位（Thelast bit of the first byte）用于表示这个地址是组播/广播地址还是单播地址，如果这一位是0，表示此MAC地址是单播地址，如果这位是1，表示此MAC地址是多播地址或广播地址。其中，广播地址只有一个，即FF-FF-FF-FF-FF-FF。到目前为止，大部分组播MAC地址都是以0x01-00-5E开头，即01-00-5E-XX-XX-XX。

### **组播转发表四要素**

如下图，按照传统IP的寻址转发机制，Router-X收到组播数据，到转发表去匹配目的接收者的地址，找到对应的出接口。根据前面描述，组播转发表的目的接收者的地址是“组播组地址”，出接口列表为{出接口A、出接口B}。如果有匹配的组播组地址，则将组播数据从出接口A和出接口B发送。这样就完美了吗？

其实不然。组播报文是发送给一组接收者的，如果转发了不该转发的数据，造成的影响很大，比如下图中，正确的组播转发应该是蓝色箭头所示的方向。如果由于某种原因，Router-X把组播数据错发了一份给RouterY（入红色箭头标识的流量），那么就会多出好多流量，浪费大量网络资源。如果存在路由环路，影响则更大。

为了能确保正确发送组播数据，组播必须严格沿着组播分发树转发，即，沿着远离组播源的方向进行转发。为了做到这点，组播技术引入了**RPF（Reverse Path Forwarding，逆向路径转发）检查机制**，路由器转发组播数据时，执行RPF检查，确保组播数据流能够沿组播转发树正确的传输，同时可以避免转发路径上环路的产生。RPF检查的过程是：在接收到报文后，在单播转发表中，查找到组播源地址的路由，如果该路由的出接口就是报文的入接口，则检查通过，否则不通过。也就是说，组播转发时，不仅要关心数据要到哪里去，**还要关心它从哪里来**。

但在实际组播数据转发过程中，如果对每一份接收到的组播数据报文都通过查找单播路由表进行RPF检查，会给路由器带来很大负担。因此，URPF检查应该放在转发表项生成之前进行，也就是路由器在生成路由表的过程中进行URPF检查，得到“组播源”及“到组播源的接口”，并将这两个信息也放入转发表项。这样，在转发组播报文时，匹配组播报文的源地址是否为转发表的“组播源”，报文的目的地址是否为转发表的“组播组地址”，如果匹配上，则判断接收报文的入接口是否就是“到组播源的接口”，如果是，表面数据是安全无误的，可以转发，如果接收报文的入接口不是“到组播源的接口”，则丢弃报文。

所以，组播转发表有**四要素：“组播源”、“组播组”、“到组播源的接口”、“出接口列表”**，其中组播源和组播组作为匹配对象，是个组合，通常表示为（S,G）。其中，S是Source首字母，表示组播源；G是Group的首字母，表示组播组。如下图的Router-X的组播转发表项为：（10.1.1.1, 255.1.1.1）, GE1/0/0, {GE2/0/0, GE3/0/0}。

那么，这么复杂的组播转发表项是如何生成的呢？这需要路由器解决如下问题：

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">有哪些组播组？
</span>
<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">组播组包含哪些接收者（这决定了出接口列表）？
</span>
<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">组播组对应的组播源在哪里？
</span>

### **有哪些组播组？**

回忆下单播场景下路由器是如何得知有哪些目的IP地址，也就是回忆下单播IP地址的发布过程：在接口上配置IP地址或者由DHCP服务器动态分配IP地址给主机，然后通过路由协议等将这些IP地址发布到网络中，网络中的路由器通过运行路由协议，收集全网拓扑，然后进行路由选择，生成到这些IP地址的路由表和对应的转发表。报文转发时通过匹配转发表中的目的IP地址来查找对应出接口，从出接口发送报文。

然而，组播报文的“目的地址“是**组播组地址，仅代表一个“接收者的集合”，并不代表具体主机**，所以组播组地址不可能分配给主机，也不可能配置在某个接口下，那么组播地址配置在哪呢？

实际上，**组播组是组播源和组播接收者之间的约定，如同电视频道**。在组播源和连接电视机的机顶盒上已有节目单，即“频道“和组播组地址的对应表，如下图所示。

由此可见，组播源和组播接收者都事先配置了组播组地址。

### **组播组包含哪些接收者？**

组播组包含哪些接收者？组播组成员是通过互联网组管理协议IGMP（Internet Group Management Protocol）来管理的。**IGMP**是运行在主机-路由器之间的协议，用于建立直连网段内的组成员关系信息，具体地说，就是哪个接口下有哪个组播组的成员。

下面以IPTV为例，IGMP主要实现过程是：

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">路由器发送查询消息并接收主机反馈的Report消息和Leave消息，了解接口连接的网段上有哪些组播组存在接收者，也就是组成员。
</span>

机顶盒可以在任意时间、任意位置、不受限制地加入或离开组播组。就像电视频道，观众可以随时控制电视机的开关和频道间的切换。

通常，为了提高可靠性，同一个局域网通常使用两台或多台路由器接入网络，所以IGMP协议还需要选举出一台“代表”，称为**接收者DR（Designed Router，指定路由器）**。接收者都通过这台DR接收和发送组播数据。

现在，组播组地址有了，组播组的成员有了，剩下的问题是：组播组地址和对应的成员信息如何发布到网络的每台组播路由器？这是通过**组播路由协议**来实现的。

组播路由协议有很多种，最普遍使用的是PIM（Protocol Independent Multicast，协议无关组播）协议。“协议无关”的意思是：单播路由是什么都没关系！
PIM协议有两种，PIM-DM和PIM-SM，下面简单介绍这两种协议的基本实现原理。

# **PIM-DM的实现**

如下图，观众（接收者A）打开电视机选择收看某频道的节目，机顶盒就会通过IGMP协议向接收者DR（Router-1）报告它需要接收组播组G的数据。这样，Router-1就得到了组播组G的地址，但Router-1这时还不知道组播源在哪，因此暂时生成的是（\*,G）表项，\*表示任意组播源。

当组播源将组播报文发布到网络时，网络中支持组播的路由器都将报文复制转发，这样Router-1、Router-2和Router-3都收到了组播数据。由于接收者A有需求，于是Router-1把报文发送给接收者A；接收者B和接收者C没有接收需求，因此Router-2和Router-3不转发数据给接收者。

组播数据在网络传递过程中，组播路由器可获得组播源的IP地址，到组播源的入接口，以及组播组地址，其出接口列表包含了所有连接下游组播路由器的接口，这样就可以生成组播转发表项（S,G）。而接收者DR路由器可以得知自己有哪些接收者，因此更新出接口列表，把没有接收者的出接口删除，这样就得到了正确的组播转发表项了。

上述过程中，Router-2和Router-3并没有任何接收者，为了节约资源，通知上游路由器把连接自己的接口从出接口列表删除，不要再发组播数据给自己了，该过程称为“剪枝”，如下图所示。这样，网络上的所有路由器都得到了正确的转发表项。

此外，组播源可能通过多台路由器接入网络，所以PIM-DM会选举其中一台路由器作为源DR，组播源通过源DR收发组播数据。

上面过程有个问题：虽然进行了剪枝，但是有的路由器即使没有任何组播接收者，但仍然有（S,G）表项，只是出接口列表为空。于是，更优秀的PIM协议出现了，那就是PIM-SM。

## **PIM-SM的实现**

### 选”中介“

首先，PIM-SM协议在网络中选择一台组播路由器作为RP(Rendezvous Point)，相当于“中介”。网络中所有路由器都知道RP在哪。此外，组播源可能通过多台路由器接入网络，所以PIM-SM会选举其中一台路由器作为源DR，组播源通过源DR收发组播数据。

### 建”共享树“

接着，接收者DR向RP发送加入（Join）消息，于是，从接收者DR到RP及中间的路由器便可得到（*,G）表项，这样就形成了一棵以RP为根的树，这棵树被称为“共享树”。

同PIM-DM中的实现一样，接收者通过IGMP向接收者DR路由器加入组播组G，该路由器生成（*,G）表项。

### 组播源注册”报到“

当源DR接收到组播源发来的组播数据时，由于没有组播转发表项，因此源DR把收到的组播数据包封装在注册（Register）消息中发送给向RP，即向RP注册报到，并在本地创建（S,G）转发表项，出接口列表为空。

RP收到Register消息，解封装，并将封装在其中的组播报文沿着共享树转发给接收者，沿途每台路由器便可正确生成(S,G)表项，其出接口列表从（*,G）表项复制。

如果RP收到Register消息时还没有共享树，则丢弃组播包。

### 建”源树“

如果有相当多的组播流量要发给RP，源DR要不断的把组播数据封装在Register消息里再发送，RP还得解封装，效率很低。因此，RP准备在自己和源DR之间建立一棵最短路径树SPT（Shortest Path Tree），这样它就可以通过SPT直接接收组播数据。于是，RP在组播表里建立一个（S，G）表项，入口为收到Join消息的接口，并向源DR发送Join消息，这样，RP上游所有组播路由器就可以得到正确的（S,G）表项，这就形成了以源DR为根的一棵SPT树，这棵树被称为“源树”。

源DR收到RP的Join消息后，且得到了正确的（S,G）表项，此后，源DR就可以通过（S,G）表项转发组播数据。在（S,G）表项形成之前，源DR会一直将收到的组播数据通过Register消息发给RP。

SPT建立后，RP能通过树收到组的流量，RP将（S,G）表项的入口信息改为收到组播包的接口（之前为收到Register消息的接口，这两个接口不一定是相等的）。现在，再从Register消息接收被封装的组播数据就没有意义了，因此RP向源DR发送Register Stop消息，告诉它停止在Register消息中发送组播包。之后，源DR只从SPT发送组播包，不再通过Register消息发送组播包。

> 说明：
>
> 为什么SPT建立后，源DR要继续发Register消息，同时通过SPT发组播数据，即同一份组播消息发两份，直到收到Register Stop消息才停止？
>
> 那是因为，Join消息是以组播形式发送的，其源IP地址为本地接口地址，目的地址为224.0.0.13，TTL值为1。RP发的Join消息逐跳向上游发布，到达源DR时，消息的源IP已经不是RP了，源DR无法识别Register消息是RP始发的还是接收者DR始发的（见下文，接收者DR也会发Join消息逐跳转发到源DR），所以源DR无法确定它发的组播报文能否正确被RP接收，只能通过接收到Register Stop消息才能确认。
>
> 那源DR为什么需要确认它发的组播报文能正确被RP接收呢？因为，之前源DR发Register消息给RP，RP生成（S,G）表项的入接口为收到Register消息的接口。源DR后续发的组播报文到达RP的接口不一定和Register消息的接口一致，如果不一致，RP进行组播转发时Register Stop消息PF检查失败，组播报文会被丢弃。所以，源DR需要确认它发的组播报文能正确被RP接收才能停止发送Register消息。
>

### SPT切换

上述过程中，组播数据都要通过RP中转，当组播报文速率逐渐较大时，对RP形成巨大的负担。为了解决此问题，PIM-SM允许在组播报文速率较大时，当接收者DR收到组播数据时，沿着源DR的最短路径发送Join消息，生成从接收者DR到源DR的最短路径树SPT（Shortest Path Tree），接着，接收者DR向RP发送剪枝消息，剪掉原来的共享树，接着，RP再向源DR发送剪枝消息，剪掉源树。后续组播数据沿着SPT转发，不再通过RP中转，该过程称为”SPT切换“。

现在，全网的转发表项已经有了，下文将描述一台路由器上的组播转发详细流程。

#  **IP组播转发流程**

IP组播转发流程如下图所示。需要关注的地方在于查表转发环节（其他环节在本系列的前1~6贴中已描述，不再赘述）。

## **查表转发流程：**

步骤1、判断报文的目的MAC是否为组播MAC，如果不是，则做单播转发；是则继续下一步骤。

步骤2、判断报文的协议类型是否为IP，如果不是，则进入其他转发流程；是则继续下一步骤。

步骤3、检查报文的长度、IP地址、Checksum字段是否正确，如果不正确，则丢弃报文，否则继续下一步骤。

步骤4、判断是否为组播IP地址，如果不是组播则丢弃报文，是则进入继续下一步骤。

步骤5、检查入接口是否使能IP组播，如果不是则丢弃报文，是则继续下一步骤。

步骤6、在组播FIB（MFIB）表（如果是公网的报文，查公网MFIB表，如果是VPN报文，则查对应VPN的MFIB表）查找是否存在匹配的（S，G）表项：

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">如果存在匹配的（S，G）表项，并且接收该报文的接口与转发表项的入接口一致，则继续步骤7的处理。特殊地，对于Register状态的出接口，表明本设备为源DR但还没收到RP的Register-Stop消息，这时需要将收到的组播上送CPU（的组播协议模块），将组播报文封装在注册消息发送给RP。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">如果存在匹配的（S，G）表项，但入接口不一致，将报文上送CPU处理。CPU进行RPF检查：对照单播路由表，若到组播源的接口与(S,G)表项的入接口一致，则说明（S，G）表项正确，报文来源路径错误，将报文丢弃；否则说明（S，G）表项已过时，于是根据单播路由表更新（S，G）表项中的入接口，并刷新转发表。然后再检查收到报文的接口是否就是更新后的接口，是则继续步骤7的处理，否则将其丢弃。
</span>

一种场景是本路由器是源DR，收到组播源发送的第1个组播报文，此时还没有（S,G）表项，需要将报文上送CPU处理，将报文封装成Register消息发给RP，同时CPU下发出接口为空的（S,G）表项，等收到RP的注册报文再添加出接口。如果注册失败，则为了减少上报对CPU的负担，后续的组播数据流就会进行转发，但是因（S,G）表项出接口为空，实际上是把报文丢弃了。

另一种场景是组播组的第1个报文从RP向接收者方向发送时，由于共享树上（除RP外）的路由器只有（*，G）表项，没有(S,G)表项，此时收到的组播报文也上送CPU处理，CPU生成(S,G)表项，其出接口列表从（*，G）表项拷贝。接着CPU对报文进行RPF检查，如果检查失败则丢弃报文，否则继续步骤7的处理。

步骤7、检查匹配的（S,G）表项是否有对应的组成员，即检查对应的出接口列表是否为空，如果为空，则报文丢弃；，否则继续下一步骤。

步骤8、检查报文的入接口与（S,G）表项的入接口是否一致，如果不一致则丢弃报文，否则继续下一步骤。

步骤9、进行组播复制等后续处理，如上行TM进行板间组播复制，下行TM进行板内组播复制，详细处理过程在本系列的前1~6贴中已描述，不再赘述。

> 声明：本文素材来源于网络，仅供学习使用，如有侵权请联系网站删除(ngdcn_admin@163.com)。

TCP/IP