[c-nsp] uRPF and IPSec SPA compatibility issues? part 2

[Justin Shore]

Whoops.  I somehow told Thunderbird to send the message (ctrl-enter I 
think) and couldn't find a way to stop it.  Here's the uRPF config:

ip verify unicast source reachable-via rx 150

ACL 150 has a permit for DHCP traffic and a deny any w/ log-input for 
everything else.

So I was troubleshooting the problem today, now that I'm back in the 
office.  I could VPN in and successfully authenticate.  I got the 
expected routes and everything looked fine.  However I couldn't ping 
anything.  Looking at the IPSec counters on the primary 7600 showed 0 
packets in or out and no errors for my VPN connection.  I assumed that 
the IPSec SPA was hosed again and in need of some TLC with a hammer but 
before I reset it I thought I'd look for another possible cause. 
Looking back through my RANCID logs the only things that changed on the 
7600s last week prior to Friday (problem was reported Thursday) was the 
uRPF changes I made.  I couldn't imagine that being the cause but for 
grins I decided to try it anyway.  I removed the uRPF config from the 
corporate LAN SVI and ping across my connected VPN session started 
working instantly.

I can not for the life of me figure out why uRPF was causing the packets 
to be dropped.  The verification drop counters were incrementing so I 
think it's safe to assume that this is where the traffic went.  Actually 
I can think of a possible cause.  What is the order of operation for 
processing frames coming in a SVI when crypto is configured on the 
interface?  If the IPSec payload was decrypted first and then the 
packets were placed back in the interface's buffer to be run through the 
uRPF checks then the decrypted payload is what uRPF would see and in 
that case it should drop the packets.

My understanding of the IPSec SPAs running in VRF mode is that uRPF and 
all the other normal interface actions (QoS, netflow, ACLs, etc) would 
happen and then the encrypted packets would be sent over to the ingress 
interface of the IPSec SPA for processing.  Coming out the backside of 
the SPA the traffic would be dropped into the appropriate inside VPN 
VLAN that's associated with the VRF in question.  That's how I thought 
it was supposed to work but clearly that's not what's happening, or I'm 
missing something.

Any thoughts?  We're nearing the end of our SmartNet renewal process so 
next week I should be able to ask TAC.  I thought I'd check here first.

Thanks
  Justin