other os和windows uefi mode_multicast-6 dense-mode - 梅利333

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申请加入这个组，然后将report消息发送到了R7

R7查看自己的Mroute 时，会看到*,G类型的条目

请问是满足发哪个条件形成了*,G的表项了呢？

是接收到了来自于组成员的report消息了

 

 此时，*,G的条目中，是没有RP的，因为是dense模式，

入接口也没有,是空的，在dense 模式中，*，G的表这个项都是空的，因为不知道源是谁，

Outgoing interface 是出口，之前说过，可以有多个

但也要按照*,G表项的建立原则来看，只有F0/1接口收到了IGMP的REPORT 消息，并且该接口运行了dense mode 

现在让SERVER来Ping 一下这个组播地址

看看会有什么反应

通是可以通的，然后我们到R7上再看一下发生了什么变化

 

 

 由于出现了源，所以现在S,G条目也出现了，

S ,是server

G, 这个组

Incoming interface 就是RPF接口，F0/0. RPF邻居是，也就是R6

另外,OIL会直接复制*,G的，但是有一条要求 ，

会将incoming interface 从中排除出去.

Outgoing interface 现在是f0/1接口，状态为转发，模式为dense

也就是说，当源为，组为的组播数据，需要转发时，是从f0/0口进来，然后从f0/1口转发出去的.

再来看一下R4，来巩固一下技术点

 

结合拓扑图来看，

首先接收到了组播数据，为了创建S,G而形成了*,G的表项，incoming 为空，

然后它的OIL中包含了所有的接口

S,G表项根据*,G表项而来，复制OIL

此时R3-R4有两条线，该选择哪一个呢？

因为RPF校验中明确指出，RPF接口在一台设备的一个组里 有且只有一个

那么两个接口就要进行比较，看谁的IP地址大，就选择谁为成RPF接口

对比,谁大就选谁，

那肯定是43大了，

而43对应的接口就是R4的f0/1口

所以F0/1为rpf 接口，对应的RPF neighbor 也就是

其它的都是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申请加入绷,R7上形成了*,G的表项

Server ping ，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 是 R6，

那就到R6上抓包看一下

 

里面有一个标记，

Upstream-neighbor ， 其意思就是发给我的RPF neighbor R6

并且在ip address 中显示的是 是源，

只要是这里显示的是源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，而是回复的，是所有运行了PIM的组播路由器都会收到，包括R2,

这倒底有什么用？

假设R2不知道，会发生什么，

R1收到了这个消息，由于下面只有一个接口，那么他将直接将这个接口给PRUNE了，这时做为R2是不是死的很冤？都不知道咋回事儿。

所以规定，在R3发送prune消息时，发送到组播地址，

这样了来，R2也收到了，(R3说。我这边儿没有组成员，修剪了吧)R2一急眼了，(不行，还有我呢，我这边儿有组成员，我需要组播流量)

就这样两个消息到达了R1，

R1先是收到了R3的prune 消息，等待3S，看有没有人发送Join消息，如果有，那么就不修剪，如果没有就修剪 接口

就在此时，R2的(S,G)join消息发过来了，那么这个接口最终被置为forward状态。

【其实对于R2而言，它并不知道实际的网络拓扑是什么样儿的，但它只知道一点，它收到了这个消息，但为什么能收到这个消息呢？因为这个消息在广播域中传递，无法穿越路由器，因为它的TTL=1，所以也就很简单的可以推断出有交换机的存在

Graft /graft ack

 

由来的组成员所请求的是的组播流量

现在由SERVER 向组发送数据，

肯定是不通的，并且没有人会给它回复，

但是R1收到了这个组播数据，肯定会建立 自己S,G表项

R2也不例外，

但是他们的OIL都是空的，因为就没有真正的组成员需要这些流量

此时让PC申请这个组的流量

会发生什么呢？

PC

Ip igmp join-group

马上R2就会收到report消息，

并且R2会顺着自己的S,G表项的rpf 接口发送一个graft消息给谁呢？给R1

R1收到这个消息后，会马上给予回复，一个graft-ack

其实从抓包中可以看得出来，这个graft 消息就是一个单播的S,G join 消息，只不过就是叫法不同而已 (可以看到单播目标地址)直接发送给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成长之路  --- 梅利