[c-nsp] IPv4 uRPF malfunction when enabling "mls ipv6 vrf" on 6500/sup720/SXI

Phil Mayers p.mayers at imperial.ac.uk
Tue Jan 25 06:20:40 EST 2011


All,

We recently had an irritating incident on a box running 12.2(33)SXI (the 
original release - no number!) where the following sequence of commands:

mls ipv6 vrf
vrf definition SOMETHING
   address-family ipv6
end

...caused IPv4 uRPF to break for all the default VRF interfaces. 
Diagnostics showed:

core#sh mls cef rpf 192.168.118.2

RPF information for prefix 192.195.168.2
uRPF check performed in the hardware for interfaces:
uRPF check punted to software for interfaces:
            Vlan1946
uRPF check disabled for interfaces:

core#sh run int Vl1946
!
interface Vlan1946
  ip address 192.195.168.30 255.255.255.224
  ip access-group EDGE_NET_IN in
  ip verify unicast source reachable-via rx
  no ip proxy-arp
  ip flow ingress
  ip pim sparse-mode
  ip multicast boundary MULTICAST-in
  ip igmp access-group MULTICAST-in
  standby 0 ip 192.195.118.1
  standby 0 priority 103
  standby 0 preempt delay reload 180
  standby 0 authentication Vlan1946
  standby 0 track 100 decrement 4
  standby 0 track 101 decrement 4
  arp timeout 1200
end

TAC have been unable to reproduce this.

There's nothing odd or hard about the uRPF config; I'm aware of the 6500 
limitations but they're not a problem for our topology.

This morning we upgraded a different router with a very similar 
configuration (already working) to SXI5 using RPR+ (i.e. reboot of 
standby SUP and all linecards).

Immediately following the upgrade, the same problems occurred on this 
router, so it's obviously not a bug they've fixed. I'm guessing 
something about the initial enabling of 6vPE, either on a long-running 
or just-booted router, causes some FIB mis-programming.

This was a production router, so a colleague disabled uRPF for the 
really important interface. Unfortunately disabling and re-enabling uRPF 
on *one* default VRF interface caused it to start working for *all* 
default VRF interfaces, and of course destroyed any evidence that TAC 
might have found useful :o(

Has anyone seen similar problems, or can anyone shed any light on what I 
might do next? I'm going to try reproducing it tomorrow, but it seems 
like a bug others might have seen.


More information about the cisco-nsp mailing list