multicast-7 sparse-mode
SPARSE 模式
稀疏模式，
会用到源树，和共享树，SPT ,RPT都用
基础配置
1 所有设备配置IP地址
2 所有设备启用IGP协议，OSPF,EIGRP,RIP ,都可以
3 所有设备开启组播路由功能，ip multicast-routing
4 开启所有设备接口的pim 功能，使用sparse-mode
5 使用sparse时，必须要指定RP 在全局下输入 ip pim rp-address x.x.x.x（先使用手动指定的模式,其它方式见后文）
构建表项的原因以及规则
(*,G)表项
创建原因
1) 收到了igmp report 这代表是最后一跳路由器，因为只有它才能收到IGMP
2) 收到了(*,G)join/ prune message
3) 为了创建(S,G)而创建的(*,G)
这1和3 和dense模式一样,但是没有任何的关系
(*,G)创建规则
1 incoming interface : to RP RPF interface
RP上为null
//是到RP的，不是到source的
2 OIL:
A 运行了sparse mode 的接口
B 该接口收到了IGMP report 或者是（*,G）join message
A,B必须同时都满足
如此时我让PC加组，
然后会在R7上收到IGMP 的report 消息，
收到了之后，就会创建 *,G表项
而这个表项中，就会有RP的标识
而这时需要注意的是，
Imcoming interface 是F0/0, 这个是通过了RPF校验 到达RP的接口，
OIL是F0/1
因为F0/1口收到了IGMP 的report 消息,此时并没有收到join message
并且运行了pim ,sparse mode,两个条件都满足，所以有了OIL
然后R7会发给R6,R6会发给R5,R5最终会发给R4，也就是到达了RPT中的RP
在这个过程中，你一定要明白，哪些设备上的哪些接口会成为RPF接口，
而哪些接口又会成为OIL
如R6，
为什么现在看到的f0/0口为RPF 接口？
因为现在我只有单播路由来提供RPF校验方式，这个接口上去往R4最近的，（R4是RP）
这个接口也就顺理成章的成为了RPF接口，incoming interface
而在图中可以明确的看到R6有三个接口，除去一个RPF接口还应该有两个OIL
为什么这里只有一个呢？
这要根据它的创建表项规则看，
首先你要运行PIIM,sparse mode 这一点没问题，都运行了,但你只运行了一点，
F0/1口收到了由R7发过来的*,G join 消息，满足条件，
而F1/0接口，毛都没有收到，是不可能成为OIL的，
R5也是同样的道理，
但是在R4上看MROUTE
此时的incoming interface : null
第一个意思，*,G join消息到此结束，不再向下找了，我就是RP，
第二个意思，第一个组播包发下来的时候，不进行RPF校验，直接通过*,G的OIL向下发
也就是说，RP不会再向上发送*,G join消息 因为RPF接口此时是空的，Null
至此，RPT 共享树部份完成
RP 是RPT的顶端
共分为三个部份，现在第一部份的RPT已经完成
接下来是源树 SPT
(S,G)表项创建原因
1 收到了组播数据包
2 收到了S,G join /prune 消息
(S,G)创建规则
Incoming interface to source RPF interface 到源的RPF接口
OIL：
A copy (*,G)OIL 复制*,G的OIL 并排除 rpf接口
B receive(S,G) Join message interface 接收S,G的join 消息
A或B满足即可
实际看一下
现在则server发送组播数据包
当R2收到给播数据包时，一定要会去创建 S,G，但是通用规则中又明确指出，想要创建 S,G就必须要有*,G
但是这时的*,G有所不同，并不是指向source的，而是指向RP的，因为在sparse中所有的组播数据都是则RP统一处理的，所以会发往RP
并且此时注意一下*,G表项的OIL
为什么是空呢？
因为此时在它的接口上没有收到任何的IGMP report 消息或者是*,G的join消息
*,G 表项和S,G表项在sparse中要单独来看
其实在R2上按照S,G表项的创建规则来看，应该也是空的OIL
首先复制*,G的，他爹啥都没有，没有办法复制
另外，它也没有收到S,G的join 消息
那这里为什么还会有呢？
按理说是没有的，
那这里怎么来的呢？
这时需要将组播包封装到一个单播包里，形成一个注册消息（register），发给RP
而R4收到这个单播包之后，由于单播是找我的，所以我会进行解封装，得到里面的组播数据， 发现是去往224.1.1.1 的，
由于此时做为RP的R4，接收到第一个组播数据包时，会根据 *,G表项的OIL直接转发出去，而不用去使用S,G，数据也就到达了组成员
与此同时，R4收到了组播数据，就要来这构建S,G表项
根据规则
S,G 的incoming interface 是F0/0. 到达源最近的
OIL 呢？直接复制他爹的，f0/1，
因为此时并没有收到任何的 S,G join 消息
所以此时应该是这样儿的
R4上有了S,G条目，再加上sparse 模式是显式加入，
这一点之前在构建*,G表项时很明显，创建了*,G表项后都会顺着RPF接口向上发送*,G join 消息
而此时的S,G 也不例外
有了S,G的表项，就会顺着S,G的incoming interface 发送S,G的join 消息给自己的RPF邻居，此时的SPT的RPF邻居就是R3，
而R3收到这个S,Gjoin消息就要创建自己本地的Ｓ,G表项，但是想要创建 S,G 就必须要有*,G
*,G的规则，
去往RP的接口为in 口 也就是f0/1
而此时，做为R3，有收到igmp report 消息或者是 *,G的join 消息吗？显然都没有，所以这时*G的表项中OIL 是null 空的
然后根据规则创建 S,G了，
去往源的 RPF 接口，是F0/0
OIL 要复制*,G 的，显然，他爹啥都没有，怎么办？
分析一下有没有收到S,G的join 消息呢？
当然是有的，(此时创建*,G的原因就是要创建S,G)
那么此时，R3顺着自己的S,G 的RPF 接口，发送S,G join，
当R2收到R3 发来的S,G join 消息后，会完善自己的S,G 表项，
形成了自己现在的S,G表项
将原来的OIL Null 改为了现在的F0/1口
到此 SPT 建立完成
再来回过头看一下
R2发送注册包的过程
Register 消息
可以清楚的看到，由R2 发往224.1.1.1 组播地址的register消息，被4.4.4.4 收到之后给予回复，register-stop(单播回复)
说明，RP已经收到了你的注册消息，回复给我一个注册停止，
但是以后就不注册了吗？
NO
之后不还是会继续发送注册消息
为什么
只不过就是不一样的格式了
为什么要发注册消息
有两个原因
1 可能第一台路由器没有组播路由表
2 让RP收到组播流量，如果RP后面有组成员呢？为了确保组成员可以收到组流量
注册停止消息什么时候发会发呢？
当收到真正的组播流量，也就是说S,G构建成功了，
意思就是告诉R2,不要再将组播流量封装在单播里面了，我收到了组播数据，并且构建了S,G表项
或者说RP 身后就真的没有组成员需要流量了，会告诉注册者，不要再给我发了，我后边没想要这些流量，别费事儿了。
上图是整个的一个过程，
先是构建*,G表项，然后再根据单播注册消息完成RP身后的S,G表项构建，从而达到组播数据的正常传递，后续会再不间断的发送注册消息，而再次发送的注册消息就不再和 第一次一样了，后面发的并没有实际的数据，我们称之为畸形的注册消息
关于注册消息是这样定义的
1 当源持续发送数据时，注册消息 register message 会在收到register-stop之前不断的发送，即便组播路由已经建立好，也可以同时存在单播的register message 与组播数据（也就是说可能同时存在的）
2如果始终没有收到注册停止消息，那么注册消息也会终止封装组播数据发送到RP，因为可能存在一种特殊的模型，即用单播路径 取代了SPT
3 在收到register-stop消息后，注册消息改为周期性发送，每35 S 发送一个无效的畸形注册消息，每70S 发送一个空的注册消息，仅仅携带组播源跟组地址信息， 用于刷新RP上的组播路由表项
4 register 消息产生的条件，从第一跳到RP必须有单播路径 ，并且第一跳的出口和RP的收包接口必须运行PIM（运行PIM是费话，肯定要运行的）
5 register message 是单播数据包转发，因此有可能会出现负载
再来看一个消息*,G prune 消息，
现在将PC离组，然后他会向上游 R7发送离组消息，leave消息，
而R7收到之后会有什么动作呢？
F0/1口将不会再是OIL 了，会从里面删除，
并且R7现在确切的说应该是没有OIL，是null 了
通过这个现象，可以得到一个结论，
就是共享树，就是依赖着组成员的存在而存在的，如果没有组成员，那这棵树就没有了生命
这些设备上的*,G 条目会在三分钟后删除
R4上的S,G 条目会删除吗？
答案是肯定的，不会，
因为R2在不断的向他发送着注册消息，它是不会删除的 ，
还有另外一个原因，就是保证后面的共享树下有组成员需要加组时，可以快速的响应，做为RP消息，可以通过S,G 表项的incoming interface 发S,G join 消息
另外和dense 模式最大的一个区别 ，也是prune 消息
当dense 模式中收到prune消息后，会将这个条目的状态转为prune 而不会删除这个接口
但是在sparse 模式中则不同，
当路由器收到*，G的prune 消息后，会直接将这个接口删除
S,G的prune 也是一样的操作，
switchover
现在的组播路径这样儿的，红色部份，显然是次优的，并不是最短的
怎么办呢？
理论
是否switchover ,由leaf router 来决定，也就是最后一跳路由器来决定
默认情况下
当最后一跳路由器收到大于0K/S的组播流量时，会直接形成S,G表项
S,G 表项的incoming interface 是指向源的接口，到达源最近的接口
Oil 呢？当然是连接组成员的 接口喽
关键字，spt-threshold
如果不配置的话，默认就是0， 当单位时间S内，收到且播数据大于0kb时，就进行switchover
显然，只要是接收到了流量，就会大于0 ，
Infinity 永远，代表着永远不，
如果不想让它进行切换，可以输入 ip pim spt-threshold infinity
当然，也可以根据实际情况，比如说我一S内接收的数据可以控制在100Kb,来进行切换，这种情况只可能出现在多个源时，才会出现。
R7 有了S,G表项，确认好Incoming interface 以及OIL，
In- f0/0 , 收到了组播流量，
OIL F0/1 直接复制 *,G的OIL ,如果此时为空，那么将按照要求来看，F0/1口收到了来自于组成员的igmp report 消息
由于构建了S,G表项，所以会顺着S,G表项的incoming interface 发送 S,G join 消息
一直顺着往上找
到达R8时有些别扭
为什么？
因为之前他这里啥都没有，
这时就要先来创建 *,G，因为这是创建 S,G的前提
*,G 的in 是谁？首先要明确是到哪儿的，是到RP的，因为现在是RPT架构
通过拓扑图分析两侧好像是一样的，那怎么办？RPF校验呗，谁的地址就选择谁，显然下面到达R6的地址更大一些，
那么*,G的in- f0/1 oil ? 显然是没有，运行了pim sparse 模式没有问题，但是既没有收到igmp report 消息，也没有收到*,G的join消息。所以最终*,G 的Oil是null0 的
有了*,G，就可以创建 S,G了，
S,G in-f0/0， 连接源方向的 没有问题
OIL 呢？会复制*,G 的，而*,G是空的，那直接复制即可，但是现在F0/1口收到了来自于R6发送的S,G join 消息 ，顺理成章的就变成了OIL f0/1口
新的路径形成了，
原来的路径还有用吗？
还要往那边儿发送数据吗？
会的，至少要向RP发送，要保证RP知道源在发包的,就发那个单播的注册消息
但是原来的路径凭什么就不用了呢？
由于R6主动发起了prune 消息，
为什么是R6发呢？
因为满足一个条件，就是（*,G）的incoming interface 与对应的(S,G)incoming interface 不一致，因为在新的路径上收到了组播数据包，并且更近。
Switchover后的prune
关于这一部份是这样定义的
1 发起者一定是叶路由器 leaf router 发起的原因是因为组播数据的速率占用带宽超过了叶路由器规定的阈值，（ip pim spt-threhold 0，这个是默认值），也就意味着叶路由器收到了第一个组播数据以后就会开始进行路径切换。
2 切换的发起依赖于(S,G) join 消息，当叶路由器收到组播数据后，便可获知源的信息，因此便可以产生(S,G)表项，并且利用incoming interface 向上游发送(S,G) join 消息，直到这个消息被发送到第一跳路由器
3 当第一跳路由器收到该消息后，则会在对应的(S,G)表项中添加对应的出口，同时意味着从组播源到组成员建立了一条最短路径 ，因为该路径 是针对源地址进行RPF校验完成的。
4 组播源顺着新的路径 转发组播数据到达组成员，并且沿途节点需要修改原有路径
5 发起修剪的设备一定在共享树上并且满足*,G）的incoming interface 与对应的(S,G)incoming interface 不一致，因为在新的路径上收到了组播数据包，并且更近。
6 产生的修剪消息是RP(S,G) prune 消息，因为该消息是S,G Prune 但是却通过了*,G的incoming 接口向上游发送的，因此RP bit 置位 //这是一个非常特殊的修剪
7 该消息顺着*,G的incoming interface 发往RP，但是只删除对应的(S,G)表项中的OIL ,不修改(*,G)表项
8 RP收到后，也会顺着自己的(S,G) IN 口继续向上游发送(S,G) prune 消息，完成对原有SPT的修剪
9 RP上的S,G 表项不会删除，因为只要组播源存在，就会不间断的向RP发送register 注册消息，从而刷新RP上的S,G表项，如果将来有新的组成员出现，RP可以立刻向源发起S，G join 消息来建立 SPT
通过wireshark 可以看到具体的数据包
触发switchover之后，R6发给R5 的修剪消息
多出来一个SR
RP-bit位置位了，
这个非常非常特殊，顺着*,G的IN口向上发送
--------------------------------------------------------
CCIE成长之路 --- 梅利
