PIM-DM简介（2）

PIM-DM扩散示例

组网拓扑

如下图所示的网络中，

1. 我们首先在每台路由器上部署了OSPF，使得它们都能够通过OSPF学习到去往全网各个网段的路由，
2. 随后又在每台路由器的相关接口上激活了PIM-DM。
3. R2及R4都在其连接终端网段的接口上激活了IGMPv2。
   
4. PC1及PC2是组播组239.1.1.15的成员，它们通过发送IGMPv2成员关系报告宣告自己加入该组播组。
5. R2及R4将分别收到PC1及PC2发送的IGMP报文并创建相关IGMP组表项和IGMP路由表项。
6. 以R2为例，其维护的IGMP路由表项如下：
   

PIM-DM组播流量扩散过程

（1）组播源和组播接受者的准备工作：

• Source开始向组播组239.1.1.15发送组播流量，这些组播流量其实就是大量的组播报文。（以多媒体直播为例，Source通过软件直播多媒体影像，影像内容被软件编码并在Source的网卡上形成一个个组播报文。）
• 组播报文大多采用UDP封装。假设Source所产生的组播报文的源IP地址为10.1.1.1，也即Source的地址，而目的IP地址为239.1.1.15。需要注意的是，在实际应用中，UDP目的端口号以及组播地址通常都是可以自定义的。
• PC1、PC2作为接收者，也需要开启相应的软件（比如软件直播多媒体APP），并侦听对应的UDP端口及组播地址。

（2）第一跳路由器处理流程：

• 当一个组播报文到达R1的GE2/0/0接口时，R1首先对报文进行RPF检查。由于报文的源地址是10.1.1.1，该IP地址在R1的GE2/0/0接口的直连网段中，因此在该接口到达的组播报文通过RPF检查。
• R1在其PIM路由表中创建一个(10.1.1.1, 239.1.1.15)表项（(S，G)组播路由表项），并将直连Source的GE2/0/0接口指定为该表项的上游接口，同时将所有连接PIM邻居的接口(GE0/0/0, GE0/0/1及GE0/0/2)都指定为该表项的下游接口。
• 最后R1将组播报文进行拷贝，并从下游接口转发出去，如图下图所示。
  
• R1的PIM路由表项如下：
  

问题背景

R1并不是每次在GE2/0/0接口上收到组播报文都执行RPF检查，因为这样处理报文效率太低了，同时也增加了R1的负担。但是如果不做RFP检查，如何确定组播是从正确的接口上接收的呢？如何预防组播防护呢？

解决方法

实际上，当首个(10.1.1.1, 239.1.1.15)组播报文到达GE2/0/0接口时，R1将会执行RPF检查，检查通过后创建(10.1.1.1, 239.1.1.15)表项，并在该表项中标记上游接口GE2/0/0，后续的(10.1.1.1, 239.1.1.15)组播报文到达R1的GE2/0/0接口后，R1将首先查询组播转发表，由于这些报文就是在(10.1.1.1, 239.1.1.15)表项的上游接口到达的，因此R1直接根据该表项的指引将报文从下游接口转发出去，而不用再次执行RPF检查。

（3）最后一跳路由器处理流程：

• R2在GE0/0/0接口收到(10.1.1.1，239.1.1.15)组播流量后，首先进行RPF检查，通过查询单播路由表，R2发现到达组播源10.1.1.1的出接口是GE0/0/0，因此从该接口到达的组播流量被认为通过RPF检查。
• 因为通过RPF检查，R2在PIM路由表中创建(10.1.1.1，239.1.1.15)表项，将GE0/0/0接口指定为上游接口，同时将所有连接PIM邻居的接口都指定为该表项的下游接口。
• 在上图中，R2除了在GE0/0/0接口上维护着PIM邻居之外，没有在其他PIM邻居，但是本地IGMP路由表中存在(*，239.1.1.15 )IGMP路由表项，而且该表项中包含下游接口GE0/0/1（IGMP路由表项可以做为组播路由表项下游接口的扩展），于是R2将GE0/0/ 1接口添加到组播路由表项(10.1.1.1，239.1.1.15)的下游接口列表中。
• 最后，R2将(10.1.1.1，239.1.1.15)组播流量从GE0/0/1接口转发出去，如此一来，PC1便获得了该组播流量，如下图所示。
  
• R2的PIM路由表项和组播路由表项如下：
  
  

（4）R4和R2都属于最后一跳路由器，组播报文处理流程类似，过程不再赘述。最终，它将创建(10.1.1.1，239.1.1.15)组播路由表项，并将(10.1.1.1，239.1.1.15 )组播流量转发到GE0/0/1接口。

（5）中间组播路由器处理流程：

• R3在GE0/0/0接口收到(10.1.1.1，239.1.1.15)组播流量后，首先进行RPF检查，通过查询单播路由表，R3发现到达组播源10.1.1.1的出接口是GE0/0/0，因此从该接口到达的组播流量被认为通过RPF检查。
• 通过RPF检查之后，R3在PIM路由表中创建(10.1.1.1，239.1.1.15)表项，将GE0/0/0接口指定为上游接口，同时将所有连接PIM邻居的接口都指定为该表项的下游接口。在上图中，R3的GE0/0/1接口将被添加到(10.1.1.1，239.1.1.15)表项的下游接口列表中。
• 最后，R3将(10.1.1.1，239.1.1.15)组播流量从GE0/0/1接口转发出去，如上图所示。

PIM-DM剪枝过程

问题背景

在上图中，当Source开始发送(10.1.1.1，239.1.1.15)组播流量后，开始时这些组播流量将被PIM-DM扩散到全网。PC1及PC2需要这些组播流量，因此它们可以在第一时间接收该流量。然而，R5并不直连任何239.1.1.15组成员，因此它并不需要这些流量。

解决方法

因为R5的(10.1.1.1，239.1.1.15)表项的下游接口列表为空，它将通过向上游PIM邻居发送PIM剪枝报文，将自己从SPT上剪除，如下下图所示。

如下图所示，展示的是R5发送的PIM剪枝报文。该报文的源地址是R5的接口地址，目的地址是224.0.0.13，并且在报文的载荷中记录着R5剪枝的组播地址239.1.1.15和组播源10.1.1.1。

如上图所示：

1. R3在GE0/0/1接口收到该剪枝报文后，在其(10.1.1.1，239.1.1.15)表项中将该接口从下游接口列表中移除，
2. 同时为该接口的剪枝状态启动一个计时器，当该计时器超时的时候，接口的剪枝状态将被取消，然后R3又将继续从该接口下发(10.1.1.1，239.1.1.15)组播流量，在计时器超时之前，如果接口再次收到R5发送过来的剪枝报文，那么计时器将会重置。
3. R5将周期性地向R3发送剪枝报文，以便持续刷新R3的GE0/0/1接口的剪枝状态。

引入问题

如果PIM路由器不得不在无需组播流量的链路上持续周期性地发送剪枝报文，这个操作显然有些多余，而且是低效的，如何解决这个问题？

解决方法

状态刷新(State Refresh)机制可以优化这个过程。

4. 因为R3的(10.1.1.1，239.1.1.15)表项中下游接口列表为空，因此它意识到自己并不需要(10.1.1.1，239.1.1.15)的组播流量，于是它从上游接口向上游PIM邻居发送剪枝报文。
5. R1在GE0/0/1接口上收到R3发送的剪枝报文后，将该接口从(10.1.1.1，239.1.1.15)表项的下游接口列表中删除。
6. 完成修剪过程后，R1只会将(10.1.1.1，239.1.1.15)组播流量转发给R2及R4，而R3及R5则不会再收到该组播流量。