【组播】【答疑】一个组播实验引发的思考

测试描述：

在R3上ping FF04::1，出接口为Fa0/0

测试现象：

无法ping通。

现象分析：

R3直接产生组播数据，这些组播数据的源IP为R3 Fa0/0的接口IP，目的IP为组播组地址FF04::1。这些组播数据是直接发送给了R2，此时此刻，R2是First-hop路由器。那么当R2收到这些组播数据的时候，由于是在一个多路访问网络中收到的（在自己的Fa1/0口），而自己的Fa1/0口又不是该LAN内的DR，既然不是DR，就无权向RP发起register。因此，R2只是简单的创建一个IPv6组播转发表项而已（且outgoing interface list为空），不会做进一步的处理。于是这些组播数据在R2处被丢弃。

【测试2】

测试描述：

在R3上ping FF04::1，出接口为本地的Loopback0

测试现象：

能够ping通

现象分析：

这次环境跟前面就不大一样了。首先组播数据是来自R3的Loopback0口，那么First-hop路由器就变成了R3，而不是R2了。那么R3作为第一跳路由器，在收到组播源（也就是自己的LO0）发出的组播数据后，R3将触发Register过程，register过程的详细内容，大家都非常熟悉了，这里就不罗嗦了，最终的结果是，R3到R1构建了一个SPF，于是乎来自R3 Loopback0口、发向组播组FF04::1的组播数据可以沿着这可途径R2到R1的SPF进行转发。

(2033::3, FF04::1), 00:00:04/00:03:24, flags: ST

Incoming interface: FastEthernet1/0

RPF nbr: FE80::CE02:1BFF:FE54:0

Immediate Outgoing interface list:

FastEthernet0/0, Forward, 00:00:04/00:03:24

(2033::3, FF04::1), 00:00:16/00:03:13, flags: SFT

Incoming interface: Loopback0

RPF nbr: FE80::CE02:1BFF:FE54:0

Immediate Outgoing interface list:

FastEthernet0/0, Forward, 00:00:15/00:03:14

【测试3】

测试描述：

在R2上ping FF04::1，出接口为Fa1/0

测试现象：

能够ping通

现象分析：

R2产生的这些组播数据包，源地址为R2的Fa1/0口地址，目的地就不说了铁定是组播组的IP。这些组播数据到了R3，由于R3是第一跳路由器，并且R3的Fa0/0口又是本LAN的DR，因此R3将向RP发起Register，组播数据被送到了R1。这时候实际上组播数据是到了R1也就是到了接收者了，但是实际上，底下还在发生着一些更复杂的事情。R1在收到Register之后，会有意愿与源形成SPT，因此它向R2发了一个SPT的join消息，R2收到之后将自己的Fa0/0口添加到对应组播表项的outgoing interface list中。但是，由于组播数据始终是从R2的Fa1/0口发出（因为我们测试的时候，指定的outgoing接口为Fa1/0），因此R1不断的收到R3发来的、封装了组播数据的Register，却没有收到沿着SPT传下来的组播数据，因此，R1不会向R3发送register-stop，R3的注册过程只能反复的进行，组播数据将一直被封装在Register消息中传给R1。

【测试4】

测试描述：

在R2上ping FF04::1，出接口为Fa0/0

测试现象：

能够ping通

现象分析：

这个应该说没任何难度了，此时此刻R2就是一个组播源，将组播数据直接发送给R1。