[c-nsp] uRPF inside of a VRF

[Phil Mayers]

Justin Shore wrote:
> Last night we ran into some trouble with some of our VRFs.  When I 
> examined all interfaces related to the service I noticed significant 
> numbers of verification drops.  uRPF was recently configured on the 
> interfaces.  Does uRPF and VRFs not play nice together?
> 
> Here's one of the SVIs with a problem:
> 
> interface Vlan2102
>   description dc-categroup inside firewall
>   ip vrf forwarding dc-categroup
>   ip address 172.17.0.2 255.255.255.0
>   ip verify unicast source reachable-via rx allow-default 150
>   no ip redirects
>   no ip unreachables
>   no ip proxy-arp
>   standby version 2
>   standby 2102 ip 172.17.0.1
>   standby 2102 priority 255
>   standby 2102 preempt
> 
> That SVI is attached to the inside of the FWSM context that serves that 
> customer.  The SVI on the outside of the FWSM context doesn't have any 
> verification drops and neither does another SVI that's used for client 
> VPN termination.  Access-list 150 was created some time back to 
> troubleshoot a different issue, a DHCP issue.  It's supposed to drop and 
> log hits.
> 
> access-list 150 remark uRPF DENY & LOG-INPUT
> access-list 150 permit udp any eq bootpc any eq bootps
> access-list 150 deny   ip any any log-input

We have no problems with uRPF and SVIs inside a VRF (but we're not using 
FWSMs) on our 6500s.

One thing you should note - by default, when adding an ACL to the uRPF 
command, packets matching "deny" ACEs are forwarded in software - that 
is, for your ACL above, the process is:

   * if traffic matches 1st ACE (a permit) permit in hardware
   * else if traffic matches 2nd ACE (deny) punt to MSFC for RPF check
     * this will obviously be most packets, and will go slow

See:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/secure.html#wp1088735

There's a global command "mls ip cef rpf hw-enable-rpf-acl" to invert 
this behaviour (punt the denies to MSFC). This is a pretty stupid 
default IMHO, and I wonder if it's that behaviour causing your uRPF 
counters to mis-report?

The other obvious suggestion is to fire up an xSPAN session to see if 
you are actually getting RPF-invalid packets - we get quite a lot of 
invalid DHCP renews for example, as clients move between wireless and 
wired, or different wired subnets, or as things acquire 169.254. addresses.