[c-nsp] Weird Traceroute Issue to Specific Destination

[Phil Mayers]

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)