Errdisable Recovery-Best Practices?

[Miss_Understood]

I am re-configuring several switches on a small network.(catalyst 3750,3560) A previous employee configured the 3750 stack with all of the errdisable recovery options enabled, even for some items that we are not running like vmps. I am trying to decide what to do with these settings. I understand WHAT errdisable recovery does and WHY, but I don't understand WHEN to to allow automatic recovery and when not to. I have looked everywhere for Cisco's "Best Practices" on this subject but can't manage to track anything down. Any help would be appreciated!

[Jason Fraioli]

I enable auto recovery on my LAN, but I also send a trap when a port goes errdisable. That way I get a log/email.

[franklinbrown749628471]

I was looking at the same thing for basic switch best practices using err disable recovery. Here is what I found.

Try to minimize or refrain from using "errdisable recovery" option.  This is even more important when used on a chassis-based system like the 6500/6800 and/or 4500 systems. If the ports went into error-disable this means something is wrong and is worth investigating.  To use "errdisable recovery" is akin to sweeping a potential problem under the carpet and is not a good practice.  This option only works well in a lab environment

[paul driver]

Hello
I personally wouldn’t errdisable recovery on BPDU-Guard or UDLD as I would want to investigate further as to why those ports errored in the first place.

BPDU-guard may mean you have end users unwittingly attaching unauthored switches to the network and you need to track them down

UDLD because if you do have a faulty port/module you wouldn’t want it to constantly flap maybe causing unwarranted stp recalculations and network re-convergence