Reverse-path forwarding: Difference between revisions

Revision as of 19:39, 11 May 2020

Revision as of 20:20, 22 July 2020

Line 26:

Unfortunately, it is often the case on the larger Internet backbone that routing is asymmetric and the routing tables cannot be relied upon to point to the best route for a source to get to a router. Routing tables specify the best forward path and only in the symmetric case does that equate to the best reverse path. It is important when implementing uRPF to be aware of the potential for asymmetry to prevent accidental filtering of legitimate traffic.

RFC 3704 gives more details on how to extend strict reverse-path forwarding to include some more relaxed cases that can still be of benefit while allowing for at least some asymmetry.<!--[[User:Kvng/RTH]]-->

===Strict mode===

In strict mode, each incoming packet is tested against the FIB and, if the ''incoming'' interface is not the best reverse path, the packet check will fail. By default failed packets are discarded.{{efn|name=command|Example command on Cisco devices: ip verify unicast source reachable-via {rx} - Strict mode, {any} - loose mode}}

* example command on Cisco devices: ip verify unicast source reachable-via {rx} - Strict mode, {any}- loose mode

===Feasible mode===

Line 36 ⟶ 35:

===Loose mode===

In loose mode each incoming packet's source address is tested against the FIB. The packet is dropped only if the source address is not reachable via ''any'' interface on that router.{{efn|name=command}}<!--[[User:Kvng/RTH]]-->

== {{anchor|Filtering}}Unicast RPF confusion ==

Line 48 ⟶ 47:

== See also ==

* [[Flooding (computer networking)]]

==Notes==

{{Notelist}}

==References==