逆向转发
![本页使用了标题或全文手工转换](http://upload.wikimedia.org/wikipedia/commons/thumb/c/cd/Zh_conversion_icon_m.svg/35px-Zh_conversion_icon_m.svg.png)
![]() | 此条目可参照外语维基百科相应条目来扩充。 (2015年7月16日) |
此条目没有列出任何参考或来源。 (2015年7月16日) |
逆向路径转发(英语: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 (页面存档备份,存于互联网档案馆)