[c-nsp] Weird Traceroute Issue to Specific Destination

[Paul Stewart]

We did reboot the equipment and no difference - it's also older sup2 based
6500 there....;)

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Phil Mayers
Sent: September-22-10 3:40 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Weird Traceroute Issue to Specific Destination

On 09/21/2010 08:48 PM, Paul Stewart wrote:
> Ok... so here's the latest.
>
> I put a static route at our Internet edge - we redistribute static into
OSPF
> so now this /32 destination is able to be seen in the routing table (other
> than the default originated route).  This solves the issue if I statically
> assign it the next hop (which is their ISP that we peer directly with via
> LINX exchange point).  I don't like this solution though because if there
> was ever an issue with the static next-hop it would never fail over ...
plus
> I don't see *why* I should have to do this in order to find the problem ;)
>
> I pulled the static out and same problem re-occurs... any thoughts?

That smells awfully like hardware FIB corruption. Have you / can you 
reload the box? Or get a TAC engineer on the line - I've had pretty good 
results with that; they usually ELAM the faulty traffic, then inspect 
the ELAM headers to tell them what FIB entry is really matching the 
traffic, then work from there. Slow process, though...

Actually clearing FIB corruption on the PFC3 platform seems to be 
tricky; the things you think would work (clear ...) never seem to. I've 
only ever managed to clear it by "shut/no shut" of the suspect SVIs, and 
even then only some of the time.

(We've seen 4-5 FIB corruption issues on sup720 w/ recent IOSes, on 
different routers)
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/