multicast-6 dense-mode
Dense mode 详解
密集模式
只用到了源树,SPT,
使用(S,G)表项转发数据
PIM对dense 和sparse都支持
如何构建路由表?
*,G表项创建原因
1 收到了IGMP report (当然只会在最末跳路由器才会出现,连接着组成员)
2 或者是收到组播数据,为了创建S,G转发数据而先创建了*,G
这里也是和单播最大的一个区别 ,在转发单播数据时,如果没有目的地址,那么直接丢弃,而组播不同,它可以先创建这个条目S,G,然后再转发。
*,G 表项创建规则
Incoming interface : Null 因为对源的未知,因此无法获知RPF接口
OIL
A 运行了dense mode 的接口
B 该接口收到了igmp report 或者是存在pim neighbor
A,B 必须同时满足
S,G创建原因
当接收到了实际的组播数据,才会出现S,G表项
S,G创建规则
1 incoming interface: RPF接口,到达源的
2 outgoing interface list :
1) 直接复制*,G表项的OIL,并且排除incoming interface接口
由PC申请加入239.1.1.1这个组,然后将report消息发送到了R7
R7查看自己的Mroute 时,会看到*,G类型的条目
请问是满足发哪个条件形成了*,G的表项了呢?
是接收到了来自于组成员的report消息了
此时,*,G的条目中,是没有RP的,因为是dense模式,
入接口也没有,是空的,在dense 模式中,*,G的表这个项都是空的,因为不知道源是谁,
Outgoing interface 是出口,之前说过,可以有多个
但也要按照*,G表项的建立原则来看,只有F0/1接口收到了IGMP的REPORT 消息,并且该接口运行了dense mode
现在让SERVER来Ping 一下这个组播地址239.1.1.1
看看会有什么反应
通是可以通的,然后我们到R7上再看一下发生了什么变化
由于出现了源,所以现在S,G条目也出现了,
S 192.168.1.10,是server
G,239.1.1.1 这个组
Incoming interface 就是RPF接口,F0/0. RPF邻居是100.1.1.6,也就是R6
另外,OIL会直接复制*,G的,但是有一条要求 ,
会将incoming interface 从中排除出去.
Outgoing interface 现在是f0/1接口,状态为转发,模式为dense
也就是说,当源为192.168.1.10,组为239.1.1.1的组播数据,需要转发时,是从f0/0口进来,然后从f0/1口转发出去的.
再来看一下R4,来巩固一下技术点
结合拓扑图来看,
首先接收到了组播数据,为了创建S,G而形成了*,G的表项,incoming 为空,
然后它的OIL中包含了所有的接口
S,G表项根据*,G表项而来,复制OIL
此时R3-R4有两条线,该选择哪一个呢?
因为RPF校验中明确指出,RPF接口在一台设备的一个组里 有且只有一个
那么两个接口就要进行比较,看谁的IP地址大,就选择谁为成RPF接口
34.0.0.3 对比43.0.0.3,谁大就选谁,
那肯定是43大了,
而43对应的接口就是R4的f0/1口
所以F0/1为rpf 接口,对应的RPF neighbor 也就是43.0.0.3
其它的都是forward 接口,
但如果按照这个逻辑还是存在问题
如果f0/0接口也是forward接口的话,会不会出现环路呢?
会的,所以系统直接将这个接口给prune了 修剪了,[dense 模式周期性30s泛洪+修剪](因为下面没有人需要接收组播流量)
改的是状态,并不会将条目删除
各种消息
Join / prune 消息
1) (*,G) join
2) (*,G) prune
3) (S,G) Join
4) (S,G) Prune
在dense 中只会用到(3)(4)两种
Assert 消息
这个是干架的消息,谁赢了,就会在接口条目后面加上一个A
肯定是有两条或以上
Graft / graft ack消息
Graft 请求组播
ACK 确认给你组播
(S,G)Prune
什么时候会发送prune呢?又是谁发的呢?发送的类型是什么?
当我设备上的OIL,为空时(这也就意味着没有接收者了)
是路由器发的,当它检测到自己后方没有组成员的话,会向上级发着prune消息,
发送的是S,G的prune消息,从S,G 表项的incoming interface 接口向上发送,
而且修剪的是上游设备的S,G 的OIL 转换为prune状态
如果说我有OIL,但是我所有的OIL都被prune了呢?
就是我下游的设备没有需要组播流量的,所以就会给我发送prune消息,我会将所有的OIL 都置为prune 状态
来看一下purne消息的表现形态吧
PC申请加入绷239.1.1.1,R7上形成了*,G的表项
Server ping 239.1.1.1 ,R7上形成了组播S,G的表项
然后我们将PC退出该组,看看R7上面的接口变化
这是原有正常情况下,S,G表项中有OIL,
再看一 下组成员退出后的结果
表项不会立即被清楚,要等三分钟,
而这不是主要的,我们要看prune消息
由于R7下方的组成员PC,发着了离组消息,那么R7将不会再往下发放组播数据,
也就导致了S,G的表项中OIL为空,(当S,G为空,或者是全部为prune时)
既然不需要组播数据,也就意味着R7将顺着RPF接口向上游设备发送(S,G)prune消息,现在可以看到rpf neighbor 是100.1.1.6 R6,
那就到R6上抓包看一下
里面有一个标记,
Upstream-neighbor 100.1.1.6, 其意思就是发给我的RPF neighbor R6
并且在ip address 中显示的是192.168.1.10 是源,
只要是这里显示的是源IP,那么就是S,G的消息
如果显示的是RP的地址,那就代表的是*,G的消息
为什么?
为什么不直接发送给R6,以单播的形式?还要以组播的形式发呢?
因为此时不仅仅是R6可以看到,R5也可以看到,仅此而已,
牵扯到另外一个消息,Assert消息
R6上看一下组播路由表,
可以看到,由于R7给我发送了prune消息后,我所对OIL所执行的动作
那么此时R6会不会继续往上发呢?
当然会,
它会将这个消息发送给它的上游 R4,
那么R4上看到的接口也变成prune状态了
以此类推
直到R1
Assert消息
这时我们到R5上来看一下,
R5为什么会prune ?
它又没有接收到实际的prune消息,
还记得选择RPF接口时的比较吗?
当出现多个RPF接口时,会进行比较,会选择对端 IP地址大的那个做为RPF接口
而这个过程,发送的就是assert 消息
R5-R6对比
1 对比AD值 谁小谁优
2 对比METRIC 值 谁小谁优 前两个是遵循IGP协议的
3 对比IP地址,越大的越优
前两个都比不出来,那就比第三个,更加直接
其实看到这里,明白一个点,
就是可以通过修改AD值 ,或者是metric来修改组播RPF接口的选举,从而影响选路
通过assert 消息对比出来的结果,类mroute表中也会有所体现
Assert winner 对比胜利者
而为什么现在也是PRUNE了呢?
因为我把下面的PC从组中拿掉了,
而R5这边就没有
Assert 最终对比后的动作,
R5由于是输了,会直接 将这个接口Prune掉
而R6,不会马上prune掉接口,会等3S时间,等什么呢?
在等S,G的join消息,如果3S内没有收到该消息,那么就会像上图所示,给prune掉
收到了(S,G)join消息后,马上改变状态为forward状态
说白了就是这么一个过程
再来看一下(S,G)join消息的小例子,来熟悉一下,它在里面的做用
什么意思呢,
其实看图应该就能理解 ,
R1上面的源发送数据到组中,R1会发给R2,R3,
而此时R3下面并没有接收者,肯定会给R1回复一个PRUNE消息的,这没毛病
但是它不是单独回复给R1,而是回复的224.1.1.13,是所有运行了PIM的组播路由器都会收到,包括R2,
这倒底有什么用?
假设R2不知道,会发生什么,
R1收到了这个消息,由于下面只有一个接口,那么他将直接将这个接口给PRUNE了,这时做为R2是不是死的很冤?都不知道咋回事儿。
所以规定,在R3发送prune消息时,发送到组播地址,224.1.1.13
这样了来,R2也收到了,(R3说。我这边儿没有组成员,修剪了吧)R2一急眼了,(不行,还有我呢,我这边儿有组成员,我需要组播流量)
就这样两个消息到达了R1,
R1先是收到了R3的prune 消息,等待3S,看有没有人发送Join消息,如果有,那么就不修剪,如果没有就修剪 接口
就在此时,R2的(S,G)join消息发过来了,那么这个接口最终被置为forward状态。
【其实对于R2而言,它并不知道实际的网络拓扑是什么样儿的,但它只知道一点,它收到了这个消息,但为什么能收到这个消息呢?因为这个消息在广播域中传递,无法穿越路由器,因为它的TTL=1,所以也就很简单的可以推断出有交换机的存在
Graft /graft ack
由来的组成员所请求的是239.1.1.1的组播流量
现在由SERVER 向224.1.1.1组发送数据,
肯定是不通的,并且没有人会给它回复,
但是R1收到了这个组播数据,肯定会建立 自己S,G表项
R2也不例外,
但是他们的OIL都是空的,因为就没有真正的组成员需要这些流量
此时让PC申请这个组的流量
会发生什么呢?
PC
Ip igmp join-group 224.1.1.1
马上R2就会收到report消息,
并且R2会顺着自己的S,G表项的rpf 接口发送一个graft消息给谁呢?给R1
R1收到这个消息后,会马上给予回复,一个graft-ack
其实从抓包中可以看得出来,这个graft 消息就是一个单播的S,G join 消息,只不过就是叫法不同而已 (可以看到单播目标地址123.1.1.1)直接发送给rpf neighbor
有去有回,下游请求graft 上游回复graft-ack
小节
到此,应该可以掌握的东西有哪些呢?
1 哪些接口会被prune
2 prune的根源有哪几种?
3 S,G join 消息
4 assert 消息
5 graft/graft-ack消息
*,G的消息只会修改*,G的条目
S,G的消息只会修改S,G的条目
虽然这两个条目,在逻辑上存在着父子的关系,(也就是出接口会复制)但是彼此又是独立的。
dense整理
最后再通过一张图来理解整个dense的过程
首先确认使用的模式为dense,
另外使用的树结构为SPT
源树,最短路径树
一,
1 source 发送组播数据给A.B
2 A收到数据会向外泛洪,B也一样
3 此时C收到组播数据之后,由于有两个RPF 接口,为了避免重复数据,必须要进行RPF校验,只保留一个,(假设最终留下的是A方向的,那么连接B方向的就会被prune)
4 此时recelver 1 发送了IGMP的report 消息,C上也有了*,G的表项,同时也接收到了组播数据,那么这时就行成了S,G的表项,数据得以传递到recelver 1
二,
1 source 发送给播数据,给A,B
2 此时观察recelver 2 ,已经发送了igmp 的report 消息
3 在F上形成了*,G表项
4 从源发出来的数据到达D上,同时也到达了C设备上,
5 此时二人都会发给E ,E 收到了两个,那么这时C,D两台设备就要干架了,
Assert 消息干架,决定最终由谁来进行转发(假设最终由D设备胜利了)那么此时C上的接口就应该被prune ,但是由于C设备下面还有组成员,肯定是不可以被prune的,然后回到E上,E此时将收到的组播数据进行泛洪,到了F,F已经等待多时了,发送S,G的join 消息,顺理成章的接收了组播数据,
而这一路下来的接口状态,OIL 分别是谁,RPF接口又是谁?~有没有想明白?
三,最后的recelver 3 想要接收组播数据,都经过了哪些步骤呢?
这个不妨通过实验来自己验证一下,更加的直观,看看自己分析的对不对,
记住,一定是自己先分析,然后再来配置,
用实验的效果来验证我们的分析结果。
有助于对技术点的理解
------------------------------------
CCIE成长之路 --- 梅利