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