RPF,reverse path forwarding.網絡
是組播轉發的一個重要基礎。只有當RPF檢測成功之後,組播流量才能正確的在網絡中進行轉發。ide
當在baidu或者google裏面查詢關鍵字 "CISCO RPF檢測機制和工做原理",咱們會輕易獲得下面的原理:oop
RPF檢查的原理:路由器在單播路由表中查找源地址以肯定數據包到達的接口是否位於返回信源的的反向路徑上,若是是則RPF檢查成功,若是不是則標記「RPF失敗丟棄」並丟棄數據包。簡單來講就是根據去的數據路由表項來檢查回來的包,肯定去回在一線上。google
做用:對於多播,能防止環路(多播RPF檢查是默認開啓且不能關閉的);對於單播,能防止IP欺騙***(須要手工配置RPF檢查)spa
就這麼簡單的一句話,其實我看了不少次都沒有真正理解其中的意義在於哪裏。cisco也有一個專門的ppt來說解這個問題,可是最後我仍是很模糊。不知所云,可是我記住了一個概念,組播流量來的方向或者接口,在本臺路由器上面show ip route x.x.x.x回去的單播路由表必須也要一致,不然的話就是RPF失敗,而後把組播流量丟棄。orm
今天從同事那裏找了一個實驗,作完之後,我發現RPF也不是那麼神祕,下面就是實驗過程,咱們能夠一塊兒來驗證一下是否是上面我理解的:blog
在該拓撲圖中,R1-R4分別按照拓撲圖中的標示,配置接口IP地址,而且在每一臺路由器上面使能ip multicast-routing,而後在每一個接口下面配置ip pim sparse-mode.接口
R2的F0/0做爲rp 候選和bsr 候選。ip
這個時候,整個網絡的單播和組播部分就已經齊活了。ci
組播的配置很簡單,就幾條命令,該拓撲圖的配置若是有疑問能夠參考附件,這裏就不用多的篇幅去說如何配置組播了。
這個時候,在R4上面起一個loopback接口做爲模擬鏈接組播客戶端(接收方)的接口,在接口下面使能命令ip igmp join 224.1.1.1.
而後R4的loopback0接口就會向RP發送(*,G)的join報文進行加入.
而後再從R1路由器上面ping 224.1.1.1,來模擬R1做爲組播源在發送224.1.1.1的組播數據。
這裏能夠看到。R1去ping224.1.1.1是通的,由於R1是組播源,會發送(S,G)註冊到RP,而後R4是組播客戶端,會發(*,G)到rp,而後rp把S迴應給R4,最後創建SPT(最短路徑樹),R4從R1那裏得到組播流量。
好了,重點在於RPF是如何工做的。前面看了網上查的原理。這裏用實驗來證實。
在拓撲圖中,從R1到R4實際上是又兩條工做路徑的。
R2和R3之間,以太口相互鏈接,串口也相互鏈接。
整網啓用ospf,這個時候根據ospf最短路徑優先,確定是走的cost小的,因此從R4到R1,走的都是以太接口。
實驗這裏就開始了,假如在R3的f1/0接口下面,no ip pim sparse-mode,那麼組播流量會從棕色的路徑發送給R3,可是在R3上面回去的路由是紅色的線路,這個時候RPF檢測就失敗了,由於接收組播流量的接口和回去的單播路由的接口不是同一個接口。
在R3上面,咱們能夠看到:
原本之前在R3上面沒有再接口f1/0刪除命令ip pim sparse-mode以前:
R3#show ip rpf 1.1.1.1
RPF information for ? (1.1.1.1)
RPF interface: FastEthernet1/0
RPF neighbor: ? (3.1.1.1)
RPF route/mask: 1.1.1.0/24
RPF type: unicast (ospf 1)
RPF recursion count: 0
Doing distance-preferred lookups across tables
當刪除之後,再去看看rpf的檢測:
R3#show ip rpf 1.1.1.1
RPF information for ? (1.1.1.1) failed, no route exists
緣由在於,由於R3在f1/0移除了pim協議,因此和對端f1/0創建不起來鄰居,天然組播流量不會通過以太口進行轉發,R3只有從s2/0收到組播流量,可是,在R3上面的路由表因爲是ospf會選擇最短的路徑,因此回去的時候走的是以太口,路徑不匹配,丟包...
R3#show ip route 1.1.1.1
Routing entry for 1.1.1.0/24
Known via "ospf 1", distance 110, metric 2, type intra area
Last update from 3.1.1.1 on FastEthernet1/0, 00:04:10 ago
Routing Descriptor Blocks:
* 3.1.1.1, from 3.1.1.1, 00:04:10 ago, via FastEthernet1/0
Route metric is 2, traffic share count is 1
在RPF的源檢測標準中,只能有一個輸入接口,選舉方法以下:
lower AD>longest match>lower metric>higher ip