RPF的检测方法:
1.unicast routing table--单播路由表检测
2.multicast route static--组播路由静态检测
3.MBGP(Muiticast Address Family)-基于ipv4的BGP组播路由检测
-----------------------------------------------------
1.unicast routing table--单播路由表检测
通过路由协议学到的单播路由条目的出接口确定RPF接口
2.multicast route static--组播路由静态检测
通过组播的静态路由条目确定RPF接口
什么情况下会使用静态组播路由静态检测?
![1aee4f541bd2999ee57dbff1728f5a67.png](https://i-blog.csdnimg.cn/blog_migrate/5e4a58225fdd4f4758d36f68382f98bf.png)
拓扑
如图:
1.R2和R4开启组播路由功能,并且接口运行PIM协议,中间R3不运行PIM协议
2.R3和R4运行IGMP协议,PC加入组播组224.1.2.3中。
3.R2,R3,R4运行OSPF作为底层协议,用于R2和R4建立tunnel,并在tunnel接口上运行PIM协议
![91d05a917fc72432775268c3b889dd52.png](https://i-blog.csdnimg.cn/blog_migrate/f66efbad7221478742bf76700554182f.png)
配置截图
![aa0e96b7fdaae9a37a5a05d0be355278.png](https://i-blog.csdnimg.cn/blog_migrate/98b2094a51d9a2e0f67d27def050ff72.png)
配置截图
![f91c57ce01e7ec2ffee38eca5be53558.png](https://i-blog.csdnimg.cn/blog_migrate/75cce35083071da1160d86035463cf3a.jpeg)
配置截图
接下来,用SER去ping224.1.2.3做测试,会发现不通
![5f034cd6ecec326e0811ec505a0f5287.png](https://i-blog.csdnimg.cn/blog_migrate/31a4332c1e395111974e5ae967bd58af.png)
配置截图
那么到底是什么原因导致了不通呢?在R4上查看针对于源12.1.1.0条目的RPF接口:
![209ab496ffd8a746eed9a57b54167cbd.png](https://i-blog.csdnimg.cn/blog_migrate/9fe8e124da8babb2739aad3c43c698c9.png)
配置截图
可以看到,现在针对于12.1.1.0的条目,RPF接口为F0/0口,而组播数据是由tunnel口发过来的,由于组播检测到数据的入站接口和通过单播路由学习到的RPF接口不是同一个接口(组播是基于单播的),因为中间设备R3的接口没有开启组播功能且接口没有运行PIM协议,导致来自于12.1.1.0的组播数据无法通过R3进行转发,RPF检验失败,导致组播数据无法发送,那么怎么解决这个问题呢?
接下来可以基于tunnel口运行EIGRP协议,将12.1.1.0网段宣告进EIGRP中,让R4通过tunnel口建立的EIGPR协议学习到来自于12.1.1.0的源的单播路由,也就是让组播数据发送源发送的组播数据的入站接口和通过单播路由条目学习到的入站接口一致(都是tunnel口),这个时候RPF接口就是tunnel接口
![a3ae32ffec65f9857275e8a2740d0e20.png](https://i-blog.csdnimg.cn/blog_migrate/de95ba331e6aa789a97fba56ba15d232.jpeg)
配置截图
![4164af6ccf5bd896ed49bb2f5560d622.png](https://i-blog.csdnimg.cn/blog_migrate/2136b3800acf0151291da898d66fb6bd.png)
查看RPF接口
接下来用SER去ping224.1.2.3做测试:
![8d16eb7b8fc9cb3b4698fe0ff0ad86de.png](https://i-blog.csdnimg.cn/blog_migrate/9bfe6037c2162856ae99f07071965f47.png)
测试截图
可以ping通,测试成功,但是又出现了另外一个问题,那就是当PC有单播的数据要发到SER,这时候会通过哪儿过去呢?答案是tunnel接口,但是由于tunnel这样的虚拟接口只是用于临时的、特殊的数据经过,当单播的数据都经过tunnel口跑的时候,那么tunnel接口的负载会增加,影响其他数据的发送,因此,我们需要让单播的数据通过R4的F0/0出去,也就是走底层OSPF,但是由于R4和R3运行的是EIGRP,EIGRP协议的管理大于OSPF,所以这个时候会优选tunnel口发送单播数据,那么怎样才能既让SER到PC的组播数据走tunnel,PC到SER的数据走底层OSPF呢?
这个时候就需要用到我们的组播路由静态检测了,组播静态路由如何实现呢?
1.先将基于tunnel运行的EIGRP路由协议删除掉
2.在R4上写关于源的组播静态路由(从哪儿来的)
![7897bb53e303ccf1b6e7c0fd07c126ff.png](https://i-blog.csdnimg.cn/blog_migrate/6cf6f14f8a33a52e21ff3b5655b489c5.png)
配置截图
以上这条命令的意思是,当有通过24.1.1.1来自于12.1.1.0的组播数据的时候,RPF邻居为24.1.1.1,RPF接口为和24.1.1.1这个ip地址直连的自己本地的tunnel接口
接下来查看RPF接口:
![d18063b3e981c5d07f6ccdd17fc30e08.png](https://i-blog.csdnimg.cn/blog_migrate/f45336b64e727e146bb090f414c6cd03.png)
配置截图
最后测试:
![42827dd75c03b4dac7dd016977436736.png](https://i-blog.csdnimg.cn/blog_migrate/50bb3f6361ad3d95dd9a9825e81f2e1e.jpeg)
测试
可以看到,组播的数据可以发过去,下一步,查询单播路由表,并作traceroute测试:
![3bf5363c899bcbe32d869e720d340977.png](https://i-blog.csdnimg.cn/blog_migrate/4513fb09778120c67ea33965b45dd78e.jpeg)
测试
可以看到,PC单播的数据走的是OSPF的路径
组播路由也是有管理距离的:
![364fca6f6c0577214502b134658e84e2.png](https://i-blog.csdnimg.cn/blog_migrate/466d26b65a32e51259742b07966e30da.png)
查看组播路由管理距离
将组播静态路由的管理距离修改为111
![0b4f1bcb0f294f5764ede6101c751a30.png](https://i-blog.csdnimg.cn/blog_migrate/f1d2d7fc6f8460c30af675b82f4bc3d9.jpeg)
修改管理距离后RPF接口的变化
RPF接口切换到了从OSPF学习到的接口
那么如果管理距离一样呢,管理距离一样还是会选择组播静态路由的接口作为RPF接口
![7d19577c9cf6faf62a1bb298cbf8f01d.png](https://i-blog.csdnimg.cn/blog_migrate/925dabba9eb5b6f53a5b5e34908ca019.png)
查看RPF接口
但是需要注意的是,不同于单播路由表,组播静态路由在这儿的作用仅仅是让PRF校验成功,并不再实际的组播静态路由表中显示。
![ecafa265a022509ab874c77c56abb475.png](https://i-blog.csdnimg.cn/blog_migrate/973fac60a06fa50c9b4ff57a5f6aa79b.png)
组播路由表
--------------------------------------------------------以上是通过组播静态路由来进行RPF检验的方法
下期将带来关于基于IPV4 BGP组播路由的RPF检测,谢谢!