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