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接口

什么情況下會使用靜態組播路由靜態檢測？

拓撲

如圖：

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協議

配置截圖

配置截圖

配置截圖

接下來，用SER去ping224.1.2.3做測試，會發現不通

配置截圖

那么到底是什么原因導致了不通呢？在R4上查看針對于源12.1.1.0條目的RPF接口：

配置截圖

可以看到，現在針對于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接口

配置截圖

查看RPF接口

接下來用SER去ping224.1.2.3做測試：

測試截圖

可以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上寫關于源的組播靜態路由（從哪兒來的）

配置截圖

以上這條命令的意思是，當有通過24.1.1.1來自于12.1.1.0的組播數據的時候，RPF鄰居為24.1.1.1，RPF接口為和24.1.1.1這個ip地址直連的自己本地的tunnel接口

接下來查看RPF接口：

配置截圖

最后測試：

測試

可以看到，組播的數據可以發過去，下一步，查詢單播路由表，并作traceroute測試：

測試

可以看到，PC單播的數據走的是OSPF的路徑

組播路由也是有管理距離的：

查看組播路由管理距離

將組播靜態路由的管理距離修改為111

修改管理距離后RPF接口的變化

RPF接口切換到了從OSPF學習到的接口

那么如果管理距離一樣呢，管理距離一樣還是會選擇組播靜態路由的接口作為RPF接口

查看RPF接口

但是需要注意的是，不同于單播路由表，組播靜態路由在這兒的作用僅僅是讓PRF校驗成功，并不再實際的組播靜態路由表中顯示。

組播路由表

--------------------------------------------------------以上是通過組播靜態路由來進行RPF檢驗的方法

下期將帶來關于基于IPV4 BGP組播路由的RPF檢測，謝謝！

總結

以上是生活随笔為你收集整理的未指定发送trap的源接口_组播之RPF接口检测的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。