[c-nsp] uRPF bug on C6k SXI1?

[Peter Rathlev]

Hi,

I've discovered what seems to be a bug on C6k at least in SXI1. I
haven't been able to find anything about it in the bug toolkit. It might
be related to CSCsk65860 though.

If I configure a SVI in a VRF and add "ip verify source reachable-via
any" and afterwards enable "ip verify source reachable-via any
allow-default" the switch seems to drop a lot of traffic, something like
every 12th packet.

If I remove the "ip verify"-command and then add the version with
"allow-default" directly, I have no problems. Without uRPF there's no
problem either. Only when first entering the command without
"allow-default" and then adding "allow-default" does the problem appear.

Have anybody seen anything like this? Would anybody know how to debug
this?

When the problem appears, the "show ip interface VlanX" aren't showing
any uRPF drops:

R1#sh ip int vlan 901                                   
Vlan901 is up, line protocol is up
[...]
  IP verify source reachable-via ANY, allow default
   0 verification drops
   0 suppressed verification drops
  IP multicast multilayer switching is disabled
R2#

Sending traffic out of this interface gives the errors:

R2#ping vrf RM03313 10.100.28.1 so 10.100.141.2 re 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 10.100.28.1, timeout is 2 seconds:
Packet sent with a source address of 10.100.141.2 
!!!!!!!!!!!.!!!!!!!!!!!.!!!!!!!!!!!.!!!!!!!!!!!.!!!!!!!!!!!.!!!!!!!!!!
!!.!!!!!!!!!!!.!!!!!!!!!!!.!!!
Success rate is 92 percent (92/100), round-trip min/avg/max = 1/1/4 ms
R2#

When removing/re-adding the uRPF command the forwarding works fine:
R2#ping vrf RM03313 10.100.28.1 so 10.100.141.2 re 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 10.100.28.1, timeout is 2 seconds:
Packet sent with a source address of 10.100.141.2 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/1/4 ms
R2#

We're glad we found a fix, but maybe others have been pulling out hair
over this one. :-)

-- 
Peter