1staticRPselection静态，公有方法，支持pimv1pimv2
2BSRbootstraprouter公有方法，只支持pimv2
3AUT0rpcisco私有，支持PIMV1PIMV2
1static
ippimrp-address4.4.4.4全网所有路由器都要配置
命令格式
Ippimrp-address[rpipaddress][aclnum][override]1staticRP不需要依赖于任何的组播路由协议，而是手动的在路由器上配置，
2该命令在全网所有的组播路由器上都需要手动配置，包括RP自己本身
3RP地址所在的接口不需要运行组播路由协议，静态的无所谓，是手动指定的
4ACL用于限制RP为哪些组地址进行服务，//如果什么都不加那就代表为所有组服务
5override用于让staticRP优于动态RP，（默认情况下是）auto>BSR>static
6staticRP无法设置备份RP，同一个组只能设置一个可以工作的RP，
Showippimrpmapping//查看RP表项
clearippimrp-mapping//清空重建RP表项
R2(config)#ippimrp-address2.2.2.21overrideR2(config)#access-list1per239.1.1.1此时就代表了R2这台RP，只会对239.1.1.1这个组有效
那么此时让PC加组，但不是加的这个组
pc(config-if)#ipigmpjoin-group224.1.1.1
再用源去发送数据
可以说，这辈子都别想通了，
源向224.1.1.1,239.1.1.1都发送了流量，但就是不通，为什么？
很好理解吧，
组成员想要的是224.1.1.1,而此时RP路由器需要指定的组是239.1.1.1
肯定是不可以的，因为都没有在一个组内，肯定不OK呀，
其实手动静态的RP，配置和理解起来都很简单、对吧，但和静态路由一样，很容易出错
2BSR自动选举
Bootstraprouter
主动申请我想当BSR
Ippimbsr-candidate[int][hashmasklength][priorityvalue]1BSR接口必须要运行PIMV2，依赖于224.0.0.13这个地址来进行选举的
2BSR接口与RP接口中可以相同
3hashmasklength用于完成C-RP的轮询选择，默认是0即没有轮询
4priorityvalue用于设置该BSR的优先级，便于多个BSR之间开启主备关系。
两种角色
BSR自举路由器,负责收集RP信息的
CRPcandidate候选者RP,就是想当RP的设备
BSR的工作过程
需要先设置某一台的某一个接口设置为BSR，当然这个接口要开启PIMv2可以有多个，实现备份，当然也可以BSR和CRP共用，一个接口身兼数职，都没有问题
1BSR周期性的产生bootstrapmessage（60S/次）,发送给自己的所有邻居，邻居收到后，帮助BSR产生相同的消息通告给各自己的邻居，从而使得消息能到达全网，
2CRP在收到消息后，获了BSR的信息，因此产生单播的CRPadvertisementmessage发送给BSR,BSR收到后在bootstrapmessage当加添加CRP信息发给全网组播路由器
3C-RP-advertisementIith周期性的从CRP发送到BSR,默认周期为60S，如果150S内BSR没有收到该CRP的下一个通告，则BSR认为该CRP已经死了，在后续的BSR消息中将删除该CRP的信息，
4因为BSR的所有消息都依赖于PIMV2message因此BSR只支持PIMV2
其实就如图所示的这么一个过程。
如何保证全网都知道RP是谁呢？因为发送的地址是224.0.0.13，是所有运行PIMV2的路由器都可以监听的
BSR的主要作用就是负责收集所有的CRP信息，然后再将这些信息通告给全网路由器，就是采集信息用的
BSR消息的产生
1有两个原因，一是固定的周期性更新，大概60S/次，二是触发更新，即收到了CRP-advertisement后立刻发送下一个BSRmessage
2在BSRmessage里可以携带一个组的多个CRP信息，BSR不会帮助其它组播路由器完成选择过程，而是全网组播路由器收到消息后，按照共同的规则来选择
3BSR的对于CRP信息的获知，信息源是CRP，但是其它组播路由器对于CRP信息的获知，）源是BSR，（这句话也很好理解，因为CRP会以单播的形式发送通告消息给BSR，而只有BSR才会将携带了CRP信息的bootstrap消息泛洪全网）
实例
我们让R3成为BSR并且是通过BSR的方式进行配置的
然后它就会向外发送bootstrap消息，发送源是23.0.0.3目标地址是224.0.0.13PIMv2的组播地址
而现在并没有RP给它回复，
而且当R2收到这个bootstrap消息之后也会进行向外扩散
源是12.0.0.2目标是224.0.0.13BSR是3.3.3.3，多么的无私啊~（眼自己毛关系都没有）
现在年R1成为RP,
并且是自己的环回口(注意，此时的Loopback接口也必须要开启Pimv2)
ippimrp-candidatelo1
可以加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的信息
RP0就是代表第一个，这是老外的一个思维
holdtime是150
此时来看一下rpmapping
在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要大，来看下效果
可以看到，原有的BSR现在变成的2.2.2.2
BSR的选举规则
1首先比较BSRpriority选择优先级最大的做为主BSR，默认优先级为0
2如果priority相同，则直接比较BSR接口IP,选择地址大的做为主BSR
3一旦选出主BSR，备份BSR则不再发送BSRmessage
4如果120S内没有收到主BSR发出的消息，则备份BSR接替开始工作
R2发出自己的bootstrap消息，
优先级为100
那么R3，也就是原有的BSR收到这个消息后会做出怎样的动作呢？
收到由R2发来的这个消息，并没有看到有什么反应，而是直接将这个主权拱手相让了，
因为priority真的比不过人家
CRP的选举
CRP也可以有多台，但是他们对比的是优先级越小越优，默认是0
那这样儿的话，我们先把R1的priority改大一些，
再将R2设置的CRP
来看看效果
R1(config)#ippimrp-candidatelo1priority10R2(config)#ippimrp-candidatelo1//后面不加参数，默认就是0R1上再查看RP，现在就是2.2.2.2了，
但是在rpmapping中可以看到两个
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首先比较CRPpriority选择优先级小的一方做为主RP，优先级默认是0
3当优先级相同时，比较HASH运算结果，选择结果大的一方做为主RP
4HASH运行需要用到的3个变量，[C-RP,GROUP,HASHmashlength长度]
1)当hashmasklength为0时，等于整个组地址都不能与hash运算,此时hash结果只取决于RP地址本身，因此每个组选择的RP都是相同的，
2)当hashmasklength不为0时，G地址被掩码掩盖的bits需要参与hash运算，此时hash结果既受到RP地址的影响，也受到了G地址的影响，因此导致了不同的组地址可能自动选择不同的CRP,，使CRP之间既能备份又能分摊
3)检查方法，showippimrp-hash[groupaddress]
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)#ippimbsr-candidatelo132//设置掩码长度一定是在设置BSR时设置
首先，看到两个不同的组，他们的掩码长度都是32位的，也就意味着32位的掩码都需要进行hash运算，而这个运算结果肯定也是不一样的，
并且，地址不同，RP的身份也有可能不相同，
如图1显示的是R2为224.1.1.0做为RP服务
图2中显示的是R1为224.1.1.10做为RP服务
这也就实现了分摊
不同的RP形成不同的共享树顶端，形成不同的*,G表项
此时如果将掩码长度设置为31位呢？
那就是每两个连续的地址使用一个RP，
0,12,34,5两个地址共用一个RP
这一点如果不明白的话，可以回看一下子网掩码划分，回顾一下去吧~
但是需要注意的是组播中没有网络地址和广播的概念，所以0算是第一个
AutoRP
1AutoRP的工作依靠真正的组播数据包来完成信息的交互，不依赖于任何的message，因此autoRP既支持PIMV1也支持PIMv2
2AutoRP工作依赖于两个组地址224.0.1.39和224.0.1.40
3以上两个组地址不是保留组播地址，因此可以为其构建组播路由表项，并且转发组播数据
4构建组播路由表要么是依靠densemode,要么是依靠sparsemode规则
而此时因为RP信息本就不存在，因此组播路由表在构建时只能依靠densemode
AutoRP的两种角色
1MA（mappingagent映射代理）--类似BSR里的BSR
2CRP候选者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用sparsemode来构建组播路由表转发这两个组的数据
Ippimrp-addressx.x.x.x10override
Access-list10per224.0.1.39
Access-list10per224.0.1.40
但这样写就太麻烦了，
并且没有办法为这两个组进行备份
第二种
全网组播路由器接口全部运行ippimsparse-dense-mode用densemode来构建组播路由表转发这两个组的数据(这什么意思呢，如果此时有RP就用sparse发数据，如果没有RP就用DENSE模式泛洪数据),先用sparse后用dense
但是如果此时RP失效后，肯定使用DENSE模式，而DENSE模式最大的特点就是泛洪，
如何保证不泛洪呢？
这时需要另外一条命令noippimdm-falback防止这种情况的发生
防止从SPARSE回退到DENSE模式，防止泛洪，即便是断网。
第三种
全网所有组播路由器接口全部运行ippimsparse-mode并且全局设置命令
ippimautorplistener该命令可以让所有的接口自动对224.0.1.39和224.0.1.40按照densemode来构建组播路由表
该命令在某些IOS环境下属于隐藏命令
我们先使用第三种，来看一下
R1(config)#ippimautorplistenerR2(config)#ippimautorplistenerR3(config)#ippimautorplistener这条命令和auto-rp的选举没有真正关系，它的作用就是构建组播路由表，来实现可以向224.0.1.39和224.0.1.40发送数据用的。仅此而已
然后我们将R2做为RP
输入一条命令
前面的ippimsend-rp-announce不变，后面是指定接口，
再后面的scope指的是跳数，
按图中所示，如果说你将跳数设置为4跳，那么右侧下方的CRP2将无法收到消息
这样一来，就无法保证全网路由器都收到这个消息了，就无法构建表项了
所以尽可能的将这个值设置的大一些即可，不成就直接255，一劳永逸了
输入完命令之后，就可以抓包看到这个消息
由crp2.2.2.2向224.0.1.39发送一个rpannouncement消息，RP是2.2.2.2o224.0.0.0组提供服务，并且这个消息是基于UDP的，端口号496
并且此时所有的路由器上已经有了*,G表项
但为什么oil是Null呢？
因为下面没有接收者啊~
好，现在我们让R3配置成MA
R3(config)#ippimsend-rp-discoverylo1scope255
注意，LO1接口必须启用pim并且是sparse模式的
当R3被配置为MA后，接收到了R2发来的announcement消息后，会给予回复一个rpmapping消息
说的是什么呢？
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是R2oil–f0/1因为F0/1口收到了组成员发来的IGMPreport消息
R2有没有？
肯定也有
*.224.1.1.1
In-null因为自己就是RP
OIL-F0/1收到了*,G的join消息
此时让R1也成为RP发送announsement消息
但是R3MA映射代理收到这个消息后，会向224.0.1.40地址发送一个消息rpmapping
这个消息是已经选举完成的。
还是R2是主RP
MA可以有多个
RP也可以有多个
RP选举原则
很简单，
直接比较IP地址的大小，谁的地址大，谁就是主RP
主RP如果在181秒之内不向MA产生下一个数据包，则宣布该RP失效
MA选举原则
MA不存在选举，如果有多个MA，那么他们将一同工作，都是提供相同的服务，负责收集并且选举CRP的
我们来验证一下CRP的选举，现在将R1的lo1接口IP地址改为10.10.10.10，来看看RP的身份是否会变