Cisco - ip verify unicast reverse-path
This command has been mentioned numerous times during the DDoS discussion. I, for one, don't have a good idea of how it works. Perhaps someone can enlighten us? Cisco's web site certainly doesn't do much to help the situation. I found it mentioned in the guide (not the reference) for the Cat 6000 (http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/ios127xe/config/...) - no description of syntax, let alone what it does. And then there is http://www.cisco.com/warp/public/707/newsflash.html. It says that the RPF check is based on CEF. I'm not familiar with CEF and want to clarify something about unicast RPF. If the source address of a packet arrived on an interface that would not be the preferred route for that address but is one of the less-preferred routes would the packet get dropped? If, as I hope, it would not, I don't understand the argument that it doesn't work for multi-homed connections. Such systems should be advertising their routes over all connections - thus the routes should appear on all paths outbound from the multi-homed systems (less any long prefix filtering being done by the upstreams). Another issue is why has Cisco made this such a stealth feature? Is it still buggy? Are the side-effects of using it so negative that hardly anyone can use it? If any such speculation is true, the folks advocating the use of this feature should also be pointing out the downside. Tony Rall
Tony, At 02:54 PM 02/12/2000 -0800, trall@almaden.ibm.com wrote:
This command has been mentioned numerous times during the DDoS discussion. I, for one, don't have a good idea of how it works. Perhaps someone can enlighten us?
The "ip verify unicast reverse-path" interface command (also known as Unicast RPF, or Reverse-Path Forwarding check) requires CEF to be in used in order to use this feature. This is because CEF separates the RIB and FIB, and the FIB check is used that ensure that packets received on an interface with this feature enabled are not forwarded unless a valid path on the same interface exists back to the originating source. See also: "Essential IOS" - Features Every ISP Should Consider http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip and Craig Huegen's very useful web page on minimizing the effects of DoS attacks: http://users.quadrunner.com/chuegen/smurf.cgi
Another issue is why has Cisco made this such a stealth feature?
It's not a stealth feature -- it's just not well documented yet. It was only introduced in 11.1(17)CC release image, which is a specialized service provider code base. We are working to get it documented in the traditional ways as it gets integrated into mainline code releases. - paul
On Sat, Feb 12, 2000 at 06:35:50PM -0500, Paul Ferguson wrote: ==>The "ip verify unicast reverse-path" interface command (also known ==>as Unicast RPF, or Reverse-Path Forwarding check) requires CEF to ==>be in used in order to use this feature. This is because CEF separates ==>the RIB and FIB, and the FIB check is used that ensure that packets ==>received on an interface with this feature enabled are not forwarded ==>unless a valid path on the same interface exists back to the originating ==>source. Sometimes saying "a valid path" is confusing. For an incoming packet, the router checks to make sure that it will route back to the packet's source address through the interface it came in on. /cah
And then there is http://www.cisco.com/warp/public/707/newsflash.html. It says that the RPF check is based on CEF. I'm not familiar with CEF and want to clarify something about unicast RPF. If the source address of a packet arrived on an interface that would not be the preferred route for that address but is one of the less-preferred routes would the packet get dropped? Nope it has to be the preferred route. If, as I hope, it would not, I don't understand the argument that it doesn't work for multi-homed connections. Such systems should be advertising their routes over all connections - thus the routes should appear on all paths outbound from the multi-homed systems (less any long prefix filtering being done by the upstreams). I agree it would be more helpful if the test was "a route exists" instead of "the best route" as I have seen it cause havoc with customers who have multiple links to us and get the MEDs wrong. Mark.
participants (4)
-
Craig A. Huegen -
Mark Prior -
Paul Ferguson -
trall＠almaden.ibm.com