[c-nsp] Strangeness with eFlexwan POS ports on 7600

[Hank Nussbacher]

On Mon, 19 May 2008, Hank Nussbacher wrote:

Cisco TAC found that the one interface that worked didn't have uRPF 
enabled whereas the others did:
ip verify unicast source reachable-via rx allow-default 170
What is amazing is that this caused deterministic pkt loss.  I have 
removed it and pkt loss went away.  Reapplied the ip verify and pkt loss 
still was 0!  Truly amazing.

Any clues why this would happen?

Thanks,
Hank

> We are encountering some very strange behavior on POS interfaces seated 
> inside eFlexwans on a 7613 with SUP720.  On a 7613 running 12.2(18)SXE6b we 
> do not see any of this strangeness.  On a 7613 running 12.2(18)SXF11 - we do.
>
> The strangeness is hard to define.  It appeared first when we tried to bring 
> up a backup STM-1 circuit which hadn't been used in a year and would only 
> pass about 700kbps.  We blamed the carrier but now suspect a subtle bug in 
> IOS.  Other POS interfaces also show pkt loss, whereas one other POS 
> interface - which happened to be the only live one with constant moving 
> traffic does not show any strangeness.
>
> When doing ping from the router to the other side of the interface, we see 
> deterministic pkt loss like this:
> POS3/0/1
> Sending 10000, 100-byte ICMP Echos to xxx.139.237.2, timeout is 2 seconds:
> !!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!
> !!!!!.!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!
> !!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!
>
> The drop on this link is periodic, it's not random, every 14th packet is 
> dropped.  We have no rate limiting enabled.  Depending on packet size of ping 
> - we get different deterministic results.
>
> After playing with the bad interface for a while (shut, no shut, sdh parms, 
> moved to another free POS port, SDH tester equipment, loopbacks, etc.), it 
> suddenly came alive and no longer lost any packets.
>
> Has anyone encountered anything similar to this?
>
> Otherwise, this is gonna be hell to debug with TAC.
>
> Thanks,
> Hank
>