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.
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
