Ed,
http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip has quite a bit more info on this an other very useful features.
Unicast RPF drops are counted today by the router under 'sho ip traffic'. Per interface counters are coming RSN, CSCdk70183. Probably 12.0(9)S/T
RPF checks incoming unicast traffic to insure that the 'best' path back to the source is the input interface. Do not use this command were asymmetric routing can occur, esp in your core network. This commands is most useful at the edge of your network as an automatic anti-SMURF measure. RPF requires that CEF be running in the router, but CEF need not be in use on the input interface. It uses an additional lookup in the FIB to validate the source IP in incoming traffic.
A quick test reveals that unicast RPF occurs before input ACL evaluation, which is just what I had expected.
BTW, CSCdk65684 was opened to get the documentation added.
Cheers,
Bruce
At 01:45 PM 1/5/00 -0600, Edward Henigin wrote:
> Running 12.0S here, and I see that 'ip verify unicast
>reverse-path' is an option in interface configuration mode. I
>haven't entered it, but I think I will.
>
> I noticed that it is *not* documented in the IOS 12.0 master
>index:
>
>http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/cbkixol.htm
>
> Also I did a Google search on "verify reverse path cef
>cisco", and this was one of the returned documents:
>
>http://www.cisco.com/warp/public/707/21.html
>
> Here's the blurb about this feature:
>
> Anti-spoofing with RPF checks
>
> In almost all Cisco IOS software versions that support Cisco
> Express Forwarding (CEF), it's possible to have the router
> check the source address of any packet against the interface
> through which the packet entered the router. If the input
> interface isn't a feasible path to the source address according
> to the routing table, the packet will be dropped.
>
> This works only when routing is symmetric. If the network is
> designed in such a way that traffic from host A to host B may
> normally take a different path than traffic from host B to host
> A, the check will always fail and communication between the
> two hosts will be impossible. This sort of asymmetric routing
> is common in the Internet core. You should make sure that your
> network doesn't use asymmetric routing before enabling this
> feature.
>
> This feature is known as a reverse path forwarding (RPF) check,
> and is enabled with the command /ip verify unicast rpf/. It is
> available in Cisco IOS software 11.1CC, 11.1CT, 11.2GS, and
> all 12.0 and later versions, but requires that CEF be enabled
> in order to be effective.
>
>
> Ok, since I can't find official documentation in the 12.0
>series for this feature, the above is the best I have, even though
>the documented command has a different syntax.
>
> I have a specific question. It says "If the input interface
>isn't a feasible path to the source address according to the routing
>table...." I assume this means that the router must have a *route*
>to the source address going out the interface on which the packet
>arrived. Am I correct? This is different from saying the router
>must have a *path* to the source address going out the interface
>on which the packet arrived. path != route. This would be why it
>would be inappropriate to run this feature on interfaces which take
>in packets from the world at large, if you're multihomed and running
>BGP.
>
> My second question is, how can I tell what packets were
>dropped due to ip verify unicast reverse-path ? If I enable this,
>I'd like to have some way of verifying that it works as desired,
>and that I'm not dropping packets that I really don't want to be
>dropping.
>
>
> Hrmm.. another question is, does the reverse-path verification
>occur before or after matching against access lists?
>
>
> Ok, I think that's enough for now :) TIA for any insight.
>
> Ed
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:08 EDT