标签：static col 周期性 基于 auto 转发 成员 动态 ida
RP的选举
1 static RP selection 静态， 公有方法，支持pimv1 pimv2
2 BSR bootstrap router 公有方法，只支持pimv2
3 AUT0 rp cisco 私有，支持PIMV1 PIMV2
1 static
ip pim rp-address 4.4.4.4 全网所有路由器都要配置
命令格式
Ip pim rp-address [rp ip address ] [acl num] [override]
1 static RP 不需要依赖于任何的组播路由协议，而是手动的在路由器上配置，
2 该命令在全网所有的组播路由器上都需要手动配置，包括RP自己本身
3 RP地址所在的接口不需要运行组播路由协议，静态的无所谓，是手动指定的
4 ACL用于限制RP为哪些组地址进行服务，//如果什么都不加那就代表为所有组服务
5 override 用于让static RP 优于动态RP， （默认情况下是）auto>BSR> static
6 static RP 无法设置备份RP，同一个组只能设置一个可以工作的RP，
Show ip pim rp mapping //查看RP表项
clear ip pim rp-mapping //清空重建 RP表项
R2(config)#ip pim rp-address 2.2.2.2 1 override R2(config)#access-list 1 per 239.1.1.1
此时就代表了R2这台RP，只会对239.1.1.1 这个组有效
那么此时让PC加组，但不是加的这个组
pc(config-if)#ip igmp join-group 224.1.1.1
再用源去发送数据
可以说，这辈子都别想通了，
源向224.1.1.1 ,239.1.1.1 都发送了流量，但就是不通，为什么？
很好理解吧，
组成员想要的是224.1.1.1 ,而此时RP路由器需要指定的组是239.1.1.1
肯定是不可以的，因为都没有在一个组内，肯定不OK呀，
其实手动静态的RP，配置和理解 起来都很简单、对吧，但和静态路由一样，很容易出错
2 BSR 自动选举
Boot strap router
主动申请我想当BSR
Ip pim bsr-candidate [int] [hash mask length] [priority value]
1 BSR 接口必须要运行PIMV2， 依赖于224.0.0.13这个地址来进行选举的
2 BSR 接口与RP接口中可以相同
3 hash mask length 用于完成C-RP的轮询选择，默认是0 即没有轮询
4 priority value 用于设置该BSR的优先级，便于多个BSR之间开启主备关系。
两种角色
BSR 自举路由器,负责收集RP信息的
CRP candidate 候选者RP,就是想当RP的设备
BSR的工作过程
需要先设置某一台的某一个接口设置为BSR，当然这个接口要开启PIMv2 可以有多个，实现备份，当然也可以 BSR 和CRP共用，一个接口身兼数职，都没有问题
1 BSR周期性的产生bootstrap message （60S/次）,发送给自己的所有邻居，邻居收到后，帮助BSR产生相同的消息通告给各自己的邻居，从而使得消息能到达全网，
2 CRP在收到消息后，获了BSR的信息，因此产生单播的CRP advertisementmessage 发送给BSR,BSR收到后在bootstrap message当加添加CRP 信息发给全网组播路由器
3 C-RP-advertisement Iith周期性的从CRP发送到BSR,默认周期为60S，如果150S内BSR没有收到该CRP的下一个通告，则BSR认为该CRP已经死了，在后续的BSR消息中将删除该CRP的信息，
4 因为BSR的所有消息都依赖于PIMV2 message 因此BSR只支持PIMV2
其实就如图所示的这么一个过程。
如何保证全网都知道RP是谁呢？因为发送的地址是224.0.0.13，是所有运行PIMV2的路由器都可以监听的
BSR的主要作用就是负责收集所有的CRP信息，然后再将这些信息通告给全网路由器，就是采集信息用的
BSR消息的产生
1 有两个原因，一是固定的周期性更新，大概60S/次，二是触发更新，即收到了CRP-advertisement 后立刻发送下一个BSR message
2 在BSR message 里可以携带一个组的多个CRP 信息，BSR不会帮助其它组播路由器完成选择过程，而是全网组播路由器收到消息后，按照共同的规则来选择
3 BSR的对于CRP信息的获知，信息源是CRP，但是其它组播路由器对于CRP信息的获知，）源是BSR，（这句话也很好理解 ，因为CRP会以单播的形式发送通告消息给BSR，而只有BSR才会将携带了CRP信息的bootstrap消息泛洪全网）
实例
我们让R3成为BSR 并且是通过BSR 的方式进行配置的
R3(config)#ip pim bsr-candidate loopback 1
然后它就会向外发送bootstrap 消息，发送源是23.0.0.3 目标地址是224.0.0.13PIMv2 的组播地址
而现在并没有RP 给它回复，
而且当R2收到这个bootstrap 消息之后也会进行向外扩散
源是12.0.0.2 目标是224.0.0.13 BSR 是3.3.3.3 ，多么的无私啊~（眼自己毛关系都没有）
现在年R1成为RP ,
并且是自己的环回口(注意，此时的Loopback 接口也必须要开启Pimv2)
ip pim rp-candidate lo 1
可以加group-list 就没是ACL ,来限制为哪些组转发流量
Interval 延时
Priority 优先级
当然也可以什么都不加
输入完成后，R1会马上回复BSR 一个消息，candidate-rp-advertisement 消息，说 RP是1.1.1.1 组是224.0.0.0/4
并且是以单播形式发的，看目标地址是多少？3.3.3.3对吧，直接发给的BSR
而BSR收到这个消息之后，会继续再向外发送一个bootstrap消息，并且这个消息中包含了RP的信息
RP 0 就是代表第一个，这是老外的一个思维
hold time 是150
此时来看一下 rp mapping
在R1上可以看到，RP 是1.1.1.1
另外这个information 的源是3.3.3.3 ，是一个bootstrap消息，
并且此时可以让PC加组，就会形成*,G表项
S,G表项呢？
只有当产生组播数据时，才会产生S,G表项
多台BSR选举
BSR可以有多台，并且他们会根据priority 的值来选举出谁是主BSR
越大越优，取值范围是0-255
现在R2啥也不是，我们让它成为主BSR，把priority 设置为100, 比R3的0 要大，来看下效果
R2(config)#ip pim bsr-candidate lo 1 0 100
可以看到，原有的BSR现在变成的2.2.2.2
BSR 的选举规则
1 首先比较BSR priority 选择优先级最大的做为主BSR，默认优先级为0
2 如果priority 相同，则直接 比较BSR接口IP ,选择地址大的做为主BSR
3 一旦选出主BSR，备份BSR 则不再发送BSR message
4 如果120S内没有收到主BSR 发出的消息，则备份BSR 接替开始工作
R2发出自己的bootstrap消息，
优先级为100
那么R3，也就是原有的BSR收到这个消息后会做出怎样的动作呢？
收到由R2 发来的这个消息，并没有看到有什么反应，而是直接将这个主权拱手相让了，
因为priority 真的比不过人家
CRP的选举
CRP也可以有多台，但是他们对比的是优先级越小越优，默认是0
那这样儿的话，我们先把R1的priority 改大一些，
再将R2 设置的CRP
来看看效果
R1(config)#ip pim rp-candidate lo 1 priority 10 R2(config)#ip pim rp-candidate lo 1 //后面不加参数 ，默认就是0
R1上再查看RP，现在就是2.2.2.2 了，
但是在rp mapping 中可以看到两个
R3上可以收到来自于R2发往224.0.0.13的组播bootstrap消息，
显示了此时有两个RP
0 ——2.2.2.2
1 ——1.1.1.1
但此时需要注意的是，
现在的RP 是2.2.2.2 不再是1.1.1.1 了
那么R2就是共享树的顶端，
也就意味着R1将看不到*，G表项，在没有收到组播数据时，
CRP的选举原则
1 针对相同的CRP才能进行比较选择,为相同的组播地址提供服务的RP
2 首先比较CRP priority 选择优先级小的一方做为主RP，优先级默认是0
3 当优先级相同时，比较HASH 运算结果，选择结果大的一方做为主RP
4 HASH运行需要 用到的3个变量，[C-RP, GROUP , HASH mash length长度]
1) 当hash mask length 为0 时，等于整个组地址都不能与hash 运算,此时hash结果只取决于RP地址本身，因此每个组选择的RP都是相同的，
2) 当hash mask length 不为0 时，G 地址被掩码掩盖的bits 需要参与hash 运算，此时hash 结果既受到RP地址的影响，也受到了G地址的影响，因此导致了不同的组地址可能自动选择不同的CRP,，使CRP之间既能备份又能分摊
3) 检查方法，show ip pim rp-hash [group address]
Hash 掩码长度
说白了0-32位的掩码，有多少位掩码需要进行hash 运算
如224.1.1.1 /32就是32位需要能与运算
Rp ,group 掩码长度 三个值一起进行hash 运算
而如果掩码长度为0时，那么也就意味着所有的组都没有意义，所有的组不参与hash 运算，每个组都一样。RP为所有的组服务就可以了
可以看到现在的mask 是0.0.0.0 是0 时，组根本就不参与hash
也就意味着所有的组都是一样的hash
而现在我们将掩码长度改为32,看效果
优先级我不动，直接改BSR的掩码长度即可
R3(config)#ip pim bsr-candidate lo 1 32
//设置掩码长度一定是在设置BSR时设置
首先，看到两个不同的组，他们的掩码长度都是32位的，也就意味着32位的掩码都需要进行hash运算，而这个运算结果肯定也是不一样的，
并且，地址不同，RP的身份也有可能不相同，
如图1 显示的是R2 为224.1.1.0 做为RP服务
图2 中显示的是R1 为224.1.1.10 做为RP服务
这也就实现了分摊
不同的RP 形成不同的共享树顶端，形成不同的*,G表项
此时如果将掩码长度设置为31位呢？
那就是每两个连续的地址使用一个RP，
0,1 2,3 4,5 两个地址共用一个RP
这一点如果不明白的话，可以回看一下子网掩码划分，回顾一下去吧~
但是需要注意的是组播中没有网络地址和 广播的概念，所以0算是第一个
Auto RP
1 Auto RP 的工作依靠真正的组播数据包来完成信息的交互，不依赖于任何的message ，因此auto RP 既支持PIMV1也支持PIMv2
2 Auto RP工作依赖于两个组地址224.0.1.39 和224.0.1.40
3 以上两个组地址不是保留组播地址，因此可以为其构建组播路由表项，并且转发组播数据
4 构建组播路由表要么是依靠dense mode , 要么是依靠sparse mode 规则
而此时因为RP信息本就不存在，因此组播路由表在构建时只能依靠dense mode
Auto RP 的两种角色
1 MA （mapping agent 映射代理）--类似BSR里的BSR
2 CRP 候选者 RP
工作原理
由MA来收集CRP 信息，
另外MA既负责收集信息，还负责选举CRP
这一点和BSR里的BSR不一样，只能收集，
可以说权力大大的
1 所有的CRP都会把自己的消息发送到224.0.1.39这个组播地址，
2 谁能监听这一个组呢？只有MA可以监听，
3 收到了这些CRP的消息之后，MA负责选举，选出来一个最优的，然后发送到224.0.1.40
4 所有的CRP都会监听这个224.0.1.40，
从而完成整个过程
224.0.1.40，这个地址还记得吗？
所有的组播路由表中都会默认存在着这么一个玩意，
今天终于见到了，就是干这个用的。明白了吧
熟悉吧，嘿嘿~
首先，想要往这两个组地址里发送数据，再由于我们现在是spares 模式，就必须要有RP
而我现在就是要选择PR,
那要怎么办呢？
矛盾了是吧~
解决方法有
三种
第一种
全网组播路由器单独为224.0.1.39 和224.0.1.40 设置静态RP 用sparse mode 来构建组播路由表转发这两个组的数据
Ip pim rp-address x.x.x.x 10 override
Access-list 10 per 224.0.1.39
Access-list 10 per 224.0.1.40
但这样写就太麻烦 了，
并且没有办法为这两个组进行备份
第二种
全网组播路由器接口全部运行ip pim sparse-dense-mode 用dense mode 来构建组播路由表转发这两个组的数据(这什么意思呢，如果此时有RP就用sparse 发数据，如果没有RP就用DENSE模式泛洪数据),先用sparse 后用dense
但是如果此时RP失效后，肯定使用DENSE 模式，而DENSE 模式最大的特点就是泛洪，
如何保证不泛洪呢？
这时需要 另外一条命令 no ip pim dm-falback 防止这种情况的发生
防止从SPARSE 回退到DENSE 模式，防止泛洪，即便是断网。
第三种
全网所有组播路由器接口 全部运行ip pim sparse-mode 并且全局设置命令
ip pim autorp listener
该命令可以让所有的接口自动对224.0.1.39 和224.0.1.40按照dense mode 来构建组播路由表
该命令在某些IOS环境下属于隐藏命令
我们先使用第三种，来看一下
R1(config)#ip pim autorp listener
R2(config)#ip pim autorp listener
R3(config)#ip pim autorp listener
这条命令和auto-rp的选举没有真正关系，它的作用就是构建组播路由表，来实现可以向224.0.1.39和224.0.1.40发送数据用的。仅此而已
然后我们将R2做为RP
输入一条命令
R2(config)#ip pim send-rp-announce lo 1 scope 10
前面的ip pim send-rp-announce 不变，后面是指定接口，
再后面的scope 指的是跳数，
按图中所示，如果说你将跳数设置为4跳，那么右侧下方的CRP2将无法收到消息
这样一来，就无法保证全网路由器都收到这个消息了，就无法构建表项了
所以尽可能的将这个值设置的大一些即可，不成就直接255，一劳永逸了
输入完命令之后，就可以抓包看到这个消息
由crp 2.2.2.2 向224.0.1.39发送一个rp announcement 消息，RP是2.2.2.2 o 224.0.0.0组提供服务，并且这个消息是基于UDP的，端口号496
并且此时所有的路由器上已经有了*,G表项
但为什么oil 是Null 呢？
因为下面没有接收者啊~
好，现在我们让R3配置成MA
R3(config)#ip pim send-rp-discovery lo 1 scope 255
注意，LO 1 接口必须启用pim 并且是sparse 模式的
当R3被配置为MA后，接收到了R2发来的announcement 消息后，会给予回复一个 rp mapping 消息
说的是什么呢？
RP 是2.2.2.2 为224.0.0.0/4所有的组播地址服务
注意，这不是给2.2.2.2 单播回复的，而是向224.0.1.40这个地址发送的，
由于现在只有2.2.2.2 一个RP，所以现在看不到选举的内容
可以说现在根据这两个组地址就构建了*,G和S,G.
现在让PC加组，224.1.1.1
然后分析一下*,G表项是什么样的？
R3有没有？
肯定有，
*,224.1.1.1
In – f0/0 连接着RP,RP是R2
oil – f0/1 因为F0/1口收到了组成员发来的 IGMP
report 消息
R2有没有？
肯定也有
*.224.1.1.1
In- null 因为自己就是RP
OIL- F0/1 收到了*,G 的join消息
此时让R1也成为RP 发送announsement 消息
但是R3 MA 映射代理收到这个消息后，会向224.0.1.40地址发送一个消息rp mapping
这个消息是已经选举完成的。
还是R2是主RP
MA 可以有多个
RP 也可以有多个
RP选举原则
很简单，
直接比较IP地址的大小，谁的地址大，谁就是主RP
主RP 如果在181秒之内不向MA产生下一个数据包，则宣布该RP失效
MA选举原则
MA不存在选举，如果有多个MA，那么他们将一同工作，都是提供相同的服务，负责收集并且选举CRP的
我们来验证一下CRP的选举，现在将R1的lo1 接口IP地址改为10.10.10.10，来看看RP的身份是否会变
看来是没有问题的，就是得等一段时间，要等它的这个消息发送周期完成才OK
PS
AUTO RP 相比较BSR 收敛速度要慢，并且没有RP轮询机制
AUTO RP 对于组播模式有一定的要求 和规则
AUTO RP 可以支持PIMV1 还支持PIMV2
--------------------------------------------------
CCIE成长之路 --- 梅利
标签：static col 周期性 基于 auto 转发 成员 动态 ida
原文地址：https://www.cnblogs.com/meili333/p/13876731.html
