PIM SM + IGMP Snooping 适用性测试（二） ttl 问题

PIM SM + IGMP Snooping 适用性测试（二） ttl 问题

简介

上节的两个问答是基于理论分析与实验验证得出的，这节描述一下实验与实验中遇到的问题。

测试拓扑

图1

实验描述

做实验验证技术问题前首先要明确实验目的，再详细规划搭建实验步骤，然后列出用于验证实验的步骤。最后很重要的一步是实验推演，实验前要利用理论对实验的过程、现象做一个大致的推演，才能保证对实验过程的把控。

实验目的

该实验的目的主要是为了测试:
1)Bootstrap协议BSR是否抢占；
2)IGMP Snooping 如何处理下行二层冗余链路的故障切换问题。

搭建实验步骤

我用少量的设备搭建了实验拓扑，如图1，实验设备有 一台Cisco C2800 路由器（rp_bsr）、一台HUAWEI S5720 三层交换机(huiju)、一台华为S5700 二层交换机（jieru）以及两台笔记本电脑安装有VLC media player。
1)rp_bsr 与huiju 之间通过OSPF 实现全网路由可达;
2)rp_bsr 与 huiju 建立PIM SM 邻居,注意：rp_bsr f0/1 一定要开启PIM,不然rp_bsr无法转发组播报文;
3)rp_bsr 配置C-RP for 224.0.0.0/4、C-BSR source lo0 priority 2501;
4)huiju 上配置C-BSR source lo0 priority 0;
5)huiju 上 SVI VLAN 100 开启IGMP ,VLAN 100 开启IGMP Snooping;
6)组播源用VLC 准备发起流视频，目的地址224.1.1.1 ，组成员用VLC 准备接受来自224.1.1.1的udp 流视频
。

验证实验步骤

1）待bootstrap 协议收敛后（130s），rp_bsr、huiju 上查看BSR的选举结果；
2）将候选BSR的priority 改大（大于当前BSR）,rp_bsr、huiju 上查看BSR的选举结果；
3）huiju和jieru 之间的两条链路利用stp协议冗余；
4）组播源开始播放，组成员开始接收；
5）断开huiju和jieru 之间的fowarding 链路，组成员上抓包观察现象；
6）更改huiju和jieru 之间的链路冗余协议，重复5）。

实验现象推演

1）如图1 配置完成后，huiju和rp_bsr 会尝试成为BSR, rp_bsr 的priority比huiju的大，huiju收到rp_bsr的bootstrap消息后，会重置引导计时器，保持监听状态，而rp_bsr会持续发送BSR,130s引导计时器超时后，rp_bsr 成为BSR,rp_bsr 同时为C-RP,rp_bsr 成为BSR 后会向全网泛洪RP-set,huiju和rp_bsr 会认为rp_bsr 是224.0.0.0/4组的RP;2
2）将huiju的C-BSR priority 改为255 ，huiju会发现自己的优先级更高，130s后会抢占为BSR,rp_bsr和huiju上 可以看到huiju成为BSR,rp_bsr 会向huiju发送候选RP声明，huiju向全网泛洪RP-set,huiju和rp_bsr 会认为rp_bsr 是224.0.0.0/4组的RP;
3）组播源开始播放后，会发送目的地址为224.1.1.1的组播流，rp_bsr收到组播包后会建立一个（S,G）条目(10.10.10.2,224,1,1,1)3，Incoming接口为F0/1，Outgoing接口为null;此时组成员开始接收，组成员为发送IGMP Membership Report 报文告知huiju 其要加入224.1.1.1 组，huiju 会生成一条（*,G）条目（*， 224.1.1.1)，将去往RP的接口设成Incoming接口，vlanif 100 设置成Outgoing接口,并且向RP发送join 消息，与此同时IGMP Snooping 将g0/0/14加入到224.1.1.1的链路层转发表上5；rp_bsr 收到join 消息后会将f0/0 设置成(10.10.10.2,224,1,1,1)的Outgoing接口，并向f0/0发送组播流，成员组VLC上开始收到视频。
4）当断开link1 后，组成员上组播视频会断，但是会不会恢复，如何恢复需要看现象，并分析。

实验验证

前面背景介绍完了，实验结果已经在《PIM SM + IGMP Snooping 适用性测试》小节中详细的阐述了，这里就不在赘述。该谈本节的关键内容了。实际上实验验证过程并没有像实验现象推演那么顺利，过程出了一个很隐秘的问题，这节重点谈如何发现并解决该问题。

问题描述

当我搭建好实验环境准备测试后，我发现组成员VLC无论如何也不能收到视频，组成员上抓包也没有任何来自组播源的组播包，我在rp_bsr 上也看不见(10.10.10.2,224,1,1,1)的（S,G）条目，但我在组播源pc上ping 224.1.1.1 ,rp_bsr 确实建立了（S,G）条目；在S5700（图1中虚线所示交换机）上通过交换机端口镜像抓包，发现组播源确实将组播流发送给了rp_bsr。为什么路由器偏偏不转发VLC发来的组播包呢，实在让我百思不得其解。

问题解决

当我分析PING 与 UDP 组播包有何不同时，我突然想到会不会是TTL在作怪，我在组播源PC上抓包发现VLC发出的组播包IP头上的TTL 果然是1 （见图2 ），也就是说默认该组播流只能在局域网内传播而不能通过路由器。

图2
知道问题的原因便好解决了，我上网查到可以通过命令行的形式手动指定VLC 发送数据包的TTL值，类似于下面这样：

vlc -vvv D:\test.mkv --sout udp:224.1.1.1:1234 --ttl 10

问题就解决了。

后续

实际上实验的结果也是我通过抓包分析出来的。在实验之前我也没完全想清楚IGMP Snooping 如何处理下行二层冗余链路故障切换，包括IGMP如何工作。通过实验可以看到IGMP Snooping 自己并没有机制感知到下行二层链路是否冗余，而是依靠IGMP本身自有的机制。通过抓包能看到路由器IGMP接口每60s向子网内发送一条Membership query ,组成员响应Membership report。此时IGMP Snooping 可以学习到新的下行接口。因此我就想到可以通过改小路由器IGMP Membership query的时间间隔从而缩短组播流的中断时间,结果真的奏效 如图3所示：

图3
这里肯定有人有疑问，既然IGMP Snooping 这么不智能，为什么还要坚持用它？问题很简单，当huiju与jieru 之间的链路是租用运营商的专线，带宽有限时，IGMP Snooping 还是很有效的。

1. BSR priority 取值0~255 ，priorty 相同比较IP地址，越大越优先； ↩
2. Bootstrap 的原理详见《PIM SM + IGMP Snooping 适用性测试》小节； ↩
3. 组播源不与RP直连时，还会涉及到源注册和RPT切换SPT的问题； ↩
4. 图1 所示的拓扑，假设huiju为STP根桥，jieru上STP会选择g0/0/1
   作为根端口（因为对端huiju的g0/0/1 id小），阻塞g0/0/2,因此IGMP Membership Report 会从link1 发送； ↩
5. 这张表在《PIM SM + IGMP Snooping 适用性测试》小节中有； ↩