组播——PIM-Dense Mode PIM密集模式

验证理论：

PIM协议报文直接采用IP封装，目的地址224.0.0.13，IP协议号103

PIM上下游接口：

　　入接口：必须为RPF校验通过接口，连接RPF邻居。

　　　　（S,G）参考组播源确定

　　　　（*，G）参考RP确定

　　下游接口生成方式：接收到（*，G）加组报告；接收（S,G）加组报告；接收IGMP加组报告

　　下游接口移除方式：接收到PIM Prune信息；接收到IGMP Leave信息；接收SPT切换产生的（S,G）修剪

PIM DM数据包类型：

PIM-DM工作机制：

　　1.当一台路由器收到组播报文后，先执行RPF检查，通过检查后建立（S,G）表项，然后将报文向所有其他有PIM邻居或者IGMP接收者的接口泛洪（组播地址224.0.0.13）

　　2.当最后一跳路由器收到组播包文后，由于其没有PIM邻居或没有IGMP接受者，组播表项下游接口列表为空，路由器会向上游邻居发送剪枝报文，通知上游邻居不要再继续将组播报文转发下来；上游邻居收到剪枝报文后，会将收到剪枝报文的接口从其组播表项下有接口列表中减除

　　3.至此组播分发树建立成功，后续组播流量参考组播路由条目（即（S,G）表项）进行转发

　　4.若之前不在组播网络中的接收者又上线了，则由最后一跳路由器发送嫁接报文到上游路由器上，上游路由器会将该最后一跳路由器添加进下游接口中并回复确认报文

应用场景：

PIM-DM模式主要用于组成员较少且相对密集的组播网络中，该模式建立组播分发树的基本思路是：“扩散——剪枝”，即将组播流量全网扩散，然后剪枝没有组成员的路径，最终形成组播分发树

实验拓扑：

初始配置：

AR45的0/0/1均未加入ISIS，其余底层打通

AR1-5上使能组播，AR4上0/0/1口加入PIM，AR5上0/0/1口未加入PIM,其余所有接口上配置PIM，以AR1为例：

[AR1]multicast routing-enable
[AR1]int g 0/0/0
[AR1-GigabitEthernet0/0/0]pim dm
[AR1-GigabitEthernet0/0/0]int g 0/0/1
[AR1-GigabitEthernet0/0/1]pim dm

实验步骤：

第一步：建立邻居

使能了PIM的路由器之间没30s交互发送一次hello包，如果在105S的超时时间之前收到邻居的hello包，就认为邻居正常

[AR2]dis pim neighbor
VPN-Instance: public net
Total Number of Neighbors = 3

Neighbor Interface 　　 Uptime　　 Expires 　　 Dr-Priority 　　 BFD-Session
155.1.12.1 GE0/0/0 　　 00:05:38 　　00:01:31 　　1 　　　　　　　　 N
155.1.23.3 　 GE0/0/1 　　 00:05:11 　　00:01:34 　　1 　　　　　　　 N
155.1.24.4 　 GE0/0/2 　　 00:04:34 　　00:01:41 　　1 　　　　　　　　 N

查看有哪些接口加入了PIM

[AR2]dis pim interface

VPN-Instance: public net

Interface State NbrCnt HelloInt DR-Pri DR-Address

GE0/0/0 up 1 　　30 1 　　155.1.12.2 (local)

GE0/0/1 up 1 　　30 1 　　155.1.23.3

GE0/0/2 up 1 　　 30 1 　　 155.1.24.4

第二步：构建组播路由表

在没有设置组播源之前，没有组播业务流来提供组播源和组播组的信息，所以组播路由表为空

[AR2]dis pim routing-table
[AR2]

在AR45的0/0/1口上使能IGMPv2

[AR4-GigabitEthernet0/0/1]igmp enable

[AR5-GigabitEthernet0/0/1]igmp enable

此时AR4上是查看组播路由表可以看到（*，G）表项，因为终端加入携带了组信息，通过IGMP，AR4可以学习到

PIM-DM模式整个网络中除了最后一跳路由器之外找不到（*，G）表项。（S,G）表项由组播业务流维护，（*，G）表项由IGMP维护

但是在AR5上，可以看到IGMP Group里面已经有终端了，但是由于没有使能PIM，下游接口无法学习到，开启PIM之后正常

不使能PIM无法处理组播流量，组播路由表出不来，所以配置组播时建议所有接口都使能PIM

配置组播源并播放视频，组播流量自动泛洪给了所有PIM邻居，这些邻居收到流量之后根据流量里面的S和G信息构建（S,G）表项。此时就可以看到路由表里面自动生成了(S,G)表项

第三步：剪枝

触发修剪信息通告的条件：

不存在下游接收者
不存在PIM邻居（连接的终端或者是路由器没有使能pim）
非RPF接口接收到组播流量(比如断言失败者AR3正常从连接源的接口0/0/1获取流量，但是如果从连接断言成功者AR4的接口0/0/0收到了流量就会发送剪枝消息，而断言失败的路由器本身也会发送1个剪枝包，所以断言过程中会发送2个剪枝包)

首先播放视频触发组播路由表，然后将PC1离组，此时可以看到AR5向上游发送了剪枝报文

此时AR5上的（S,G）表项还在，但是已经没有下游接口了。如果一直有组播流量可以到达AR5,那么（S,G）表项可以一直都在，但是如果收不到组播流量了，则(S,G)表项210s超时

此时可以看到AR5选择的上联邻居时155.1.0.4。3,4都可以发送组播包，AR5为什么选择了AR4呢？这里涉及到断言机制

接收到下游剪枝消息：

若下游为P2P环境

　　接收下游设备修剪prune信息，上游响应修剪确认继续向上修剪

若下游为MA环境

　　存在3S修剪延迟（等待其他成员join信息（MA网络交换机广播组播报文，其他终端收到你的修剪信息，如果他下面还有接受者，那么他会马上发一个修剪否决）），等待其他下游发送剪枝信息，以确认下游无其他接收者

　　3S=LAN Delay500ms+剪枝否决2500ms

验证：

仅将PC1加入组中，设置AR3上10.1.1.0/24的优先级为10使得AR3成为断言成功者（原因查看第四步断言机制）：

ip ip-prefix NET10 index 10 permit 10.1.1.0 24

route-policy SET-PRI permit node 10
if-match ip-prefix NET10
apply preference 10

route-policy SET-PRI permit node 20

isis 1
preference route-policy SET-PRI

此时将AR4的0/0/2down掉，然后PC2也加入组中，然后让PC2离线，抓包，可以看到AR4发送剪枝之后，AR5立刻就反对了，此时AR30/0/0口没有被修剪

第四步;断言机制

　　当一个网段内有多个相连的PIM路由器向该网段转发组播报文时，需要通过断言机制（Assert）来保证只有一个PIM路由器向该网段转发组播报文

　　通过断言机制的选举规则将决定组播路由器的转发行为：

　　获胜一方的下游接口称为Assert Winner,将负责后续对该网段组播报文的转发
　　落败一方的下游接口称为Assert Loser,后续不会对该网段转发组播报文（这种抑制转发的状态将保持assert保持时间，默认180s，assert保持时间超时后，竞选失败的设备会恢复转发从而触发新一轮竞选），PIM路由器也会将其从(S,G)表象下游接口列表中删除

　　PIM路由器在接收到邻居路由器发送的相同组播报文后，会向该网段发送断言（Assert）报文，进行Assert选举。Assert报文内会携带到组播源的单播路由前缀，路由优先级与开销。选举规则如下：

　　单播路由协议优先级较高者获胜
　　如果优先级相同，则到组播源的开销较小者获胜
　　如果以上都相同，则下游接口IP地址最大者获胜

　　当前拓扑中，底层用的是ISIS优先级都是15，到组播源的开销也都相同。

由于AR4的下游接口地址155.1.0.4大于AR3的下游接口地址155.1.0.3，所以AR4成为winner,向AR5转发组播流量，AR3上则将AR5从（S,G）表项下游接口列表中删除。将PC1重新加入组中：

AR34之间互发断言数据包进行选举携带有协议优先级，到组播源的cost，接口IP地址

AR4胜出之后AR3向AR4发送剪枝报文，另外由于AR3作为失败者从非RPF端口也就是连接AR4的接口收到了流量，也触发了一次剪枝，所以发送了2次

此时AR3,5上的组播路由表如下图

看似没有问题，但是存在一种这样的可能性：流量由断言获胜的AR4发送，但是AR5不一定认为从AR4发过来的组播流量是正确的。也就是说RPF校验得出的结论可能与断言机制得出的结论相悖，此时会出现无法通信的情况

今天上面分析没有问题是因为恰巧RPF校验也认为从AR4过来的是正确的

优选RPF路有原则：

掩码最长匹配
路由最优优先级
组播静态路由>MBGP路由>单播路由

断言机制选举原则：

单播路由协议优先级较高者获胜
如果优先级相同，则到组播源的开销较小者获胜
如果以上都相同，则下游接口IP地址最大者获胜

手动在AR5上增加组播静态路由，掩码增加到25位，希望AR5去往组播源AR3可以RPF选举获胜，AR4可以断言获胜

开启视频构建组播表并抓包后发现，正如所料，AR4断言获胜，AR3发送了剪枝包

但是此时的AR5上对于组239.1.1.1的RPF接口却被修改到了AR4上

[AR5]dis multicast rpf-info 10.1.1.0
VPN-Instance: public net
RPF information about source: 10.1.1.0
RPF interface: GigabitEthernet0/0/0, RPF neighbor: 155.1.0.3
Referenced route/mask: 10.1.1.0/25
Referenced route type: mstatic
Route selection rule: preference-preferred
Load splitting rule: disable

[AR5]dis pim routing-table
VPN-Instance: public net
Total 1 (*, G) entry; 1 (S, G) entry

(10.1.1.1, 239.1.1.1)
Protocol: pim-dm, Flag:
UpTime: 00:05:02
Upstream interface: GigabitEthernet0/0/0
Upstream neighbor: 155.1.0.3
RPF prime neighbor: 155.1.0.4
Downstream interface(s) information:
Total number of downstreams: 1
1: GigabitEthernet0/0/1
Protocol: pim-dm, UpTime: 00:05:02, Expires: -

原因：断言会修改下一跳的RPF邻居向断言结果看齐

第五步：嫁接

　　当有新成员加入组播组后，组播网络需要更新组播分发树，才能将组播数据发往组成员。PIM-DM模式在使用“扩散——剪枝”的方式建立组播分发树后，通过状态刷新机制，使下行接口一旦被抑制就无法自动恢复

　　因此需要一些机制来更新组播分发树，一般PIM-DM模式更新组播分发树的方法有两种：

　　等待组播路由表超时后，全网重新泛洪，该方法不可控，在现网中无法实现

　　使用嫁接（Graft）机制，当新成员加组后，主动反向建立组播分发路径。现网中一般使用嫁接机制来实现新成员加组。

　　叶子路由器通过IGMP了解到与其相连的用户网段上，组播组G有新的组成员加入。随后叶子路由器会基于本地的组播路由器上被状态刷新机制维护的（S,G）表项向上游发送Graft报文，请求上游路由器恢复相应出接口转发，（上游路由器）将其添加在（S,G）表项下游接口列表中

前提条件：通过前面的设置使得AR3打败AR4成为了断言机制winner，所以到PC1的数据走向是AR1235-》PC1

在AR24之间增加路由器AR6,修改AR6上流量入接口ISIS开销为1，使得AR4仍然认为0/0/2口到达组播源最近为RPF接口。PC2离组的状态下再加组

加组之前：

[AR4]dis pim routing-table
VPN-Instance: public net
Total 0 (*, G) entry; 1 (S, G) entry

(10.1.1.1, 239.1.1.1)
Protocol: pim-dm, Flag: ACT
UpTime: 00:00:49
Upstream interface: GigabitEthernet0/0/2
Upstream neighbor: 155.1.46.6
RPF prime neighbor: 155.1.46.6
Downstream interface(s) information: None

加组之后：