[c-nsp] N7K, SUP1, M1/M2/F2E, 6.2(10)

[Pete Lumbis]

My experience would match yours. Most of the time it seems that whatever
code path was taken by the misprogrammed route stays that way and the only
way to fix it is to reset the logic from scratch (until whatever triggered
it happens again). If you are lucky the code path isn't stuck and it was
just bad timing for the one update.

On Thu, Dec 4, 2014 at 3:49 PM, Phil Mayers <p.mayers at imperial.ac.uk> wrote:

> On 04/12/2014 18:51, Pete Lumbis wrote:
>
>>
>>
>> On Tue, Dec 2, 2014 at 7:45 AM, Phil Mayers <p.mayers at imperial.ac.uk
>> <mailto:p.mayers at imperial.ac.uk>> wrote:
>>
>>
>>     What I find most frustrating is that you can't "clear [mls|hardware]
>>     ..." when these occur. There seem to be no way of resetting it to
>>     known-good state and reprogramming from scratch short of a reload; I
>>     would rather a 10 second outage whilst PFC is cleared and
>>     reprogrammed compared to 180 second as the box is reloaded :o/
>>
>>
>> You can issue a "clear ip route x.x.x.x" to force a hardware
>> reprogramming. It won't work every time, but you might get lucky.
>>
>
> I must have done that, and various other "maybe" commands, a dozen or two
> times in the last 7 years. Not once has it worked.
>
> The only time I've seen a 6500/sup720 recover from a FIB misprogram
> without power-cycling the affected linecard or entire chassis was after 90
> minutes of work by a TAC engineer, who ended up manually poking the CAM
> entries in via debug commands. His signing off recommendation was
> "obviously reboot the box asap to get it into a clean state".
>
> This tells me all I need to know, I'm afraid! ;o)
>
> Cheers,
> Phil
>
>
>