[c-nsp] Any way to disable crashdump on Catalyst 35xx/37xx?

[Mike]

On 03/27/2011 08:42 AM, David DeSimone wrote:
> This is a stupid problem, and I feel stupid for asking this, but here it
> is.
>
> We have some switches that sometimes have their TCAM overloaded, and
> this causes them to thrash their CPU's.  Sometimes the thrashing gets
> so bad that the devices crash.  Sometimes they crash so badly that they
> don't reload, and we must manually power-cycle the devices to revive
> them.
>
> Obviously the right thing to do is to remove the sources of overload,
> and for various reasons, things are not proceeding at a good pace
> towards that solution.  In the meantime, I am trying to find ways to
> keep downtime to a minimum.  A reloading switch gives us about 5 minutes
> of downtime, but a switch that won't reload often goes 30 minutes before
> an operator can reach it and lay hands upon it.  I'm trying to see
> if I can improve the probability of the switch reloading, instead of
> freezing, when it crashes.
>
I have to disagree. It is not acceptable for the gear to lockup or 
crash, end of statement. I agree that advanced configurations and such 
can really tax the underuilized/tested software paths, but if you have 
crashing happening that needs to be addressed as a bug. Otherwise, 
you're saying that I as a bad guy will have a vector to wipe out any 
data center or other intstallation just by spewing packets and that the 
world should just be defenseless against me because Im just causing too 
much tcam thrashing and that rather than fixing the bug, well, I just 
shouldn't do that because it's not nice.

	Shorter term, you have crashing switches. Are these AC or DC powered? 
Any chance you can just get a remote reboot bar installed there? Some of 
these have automatic ping with reboot, and usually also remote serial 
console access to the individual outlets so you can manually kick one if 
necessary.


Mike