逆向轉發

逆向路徑轉發（英語：Reverse path forwarding，簡稱RPF）是為路由器傳輸多播封包時確保一個無迴圈環境、以及在傳輸單播封包時防止IP位址欺騙的一種技術。

廣播模式

當一個廣播分組到達一個路由器的時候，該路由器對他進行檢查，看它到來的線路是否是通常用來給廣播源傳送分組的線路。 如果是，則有可能此分組是沿着最佳線路被轉發過來，路由器將該分組轉發到除到來的那條線路之外的所有其他線路。 否則，此分組被當作一個可能的重複分組被丟棄。 通常[匯集樹]被用作來判斷是否是最佳線路。

多播RPF

多播RPF，也通常被直接了當地被稱呼作RPF， 配合MSDP及PIM等多播路由協定以確保無迴圈地傳遞多播封包。在多播路由中，用作決定轉遞封包的是來源地址，而非像單播中使用目的地地址。

當一個多播封包進入路由器介面，路由器會檢視該介面可到達的網絡的清單，意即：路由器檢查封包的逆向路徑。如果路由器找到一個符合該來源地址的路由表條目，RPF檢查通過，並且分組被轉發到參與該多播組多播的所有其他介面。如果RPF檢查失敗，則該封包被丟棄。因此，分組轉發的結果基於分組的反向路徑而不是前向路徑。RPF路由器只會轉遞那些路由表中有與來源地址所相應條目的封包，以確保不會產生任何迴圈。

這對有冗餘連接的多播環境來說是致命性地必要。因為同一個多播封包可以從不同的介面進入同一隻路由器，RPF測試是決定該封包繼續轉送與否時不可劃缺的一部份。如果路由器傳送所有來自介面A的多播封包到介面B，而同時傳送所有來自介面B的包封到介面A，兩個介面都可能會收到同一個封包，這將會產生很典形的路由迴圈因為封包只會一直被傳輸下去直到其TTL欄位到期。但即使考慮到TTL過期，任何類形的路由迴圈都理應盡可能地避免，因為這都會短暫地大幅減低網絡的可用性。

單播RPF（uRPF）

嚴格模式

在嚴格模式下，每個傳入封包都根據FIB進行測試，如果「傳入」介面不是最佳反向路徑，則封包檢查失敗。預設情況下，失敗的封包被丟棄。

• Cisco裝置上的範例命令：ip verify unicast source reachable-via {rx} - 嚴格模式, {any}- 寬鬆模式

可能模式

在可能模式中，FIB維護到給定IP位址的備用路由。如果「傳入」介面與任何與該IP位址相關聯的路由匹配，則該分組被轉發。否則，封包被丟棄。

寬鬆模式

在寬鬆模式，每個進入的單播封包的來源地址同樣會被檢查。如果來源地址是無經由該介面的路徑到達，檢查將失敗。

單播RPF混淆

RPF通常被錯誤地定義為反向路徑過濾，特別是當涉及單播路由。這是一個可以理解的首字母縮寫誤解，當RPF與RFC 3704中的單播路由一起使用時，則基於RPF檢查的通過或失敗來允許或拒絕流量。這種想法是，RPF檢查失敗並因此被過濾則流量被拒絕，然而根據RFC 3704，正確的解釋是：如果通過RPF檢查，則流量被「轉發」。正確使用的幾個例子可以在許多文件的範例中找到，諸如Juniper （頁面存檔備份，存於互聯網檔案館）、Cisco （頁面存檔備份，存於互聯網檔案館）、 OpenBSD （頁面存檔備份，存於互聯網檔案館），最重要的是RFC 3704，其定義了單播中RPF的使用。

雖然uRPF用作入口「過濾」機制，但是它受到反向路徑「轉發」的影響。

外部連結

• RFC 2827
• RFC 3704
• Juniper - Configuring uRPF （頁面存檔備份，存於互聯網檔案館）
• Brocade - Configuring uRPF （頁面存檔備份，存於互聯網檔案館）
• Cisco - Understanding uRPF （頁面存檔備份，存於互聯網檔案館）
• Multicast Reverse Forwarding(RPF)
• OpenBSD - Enabling uRPF in pf （頁面存檔備份，存於互聯網檔案館）
• Linux - Enabling RPF in kernel （頁面存檔備份，存於互聯網檔案館）
• Juniper Networks on multicast RPF （頁面存檔備份，存於互聯網檔案館）