Those of you “new” to the Cisco world, or those who simply don’t have experience in the layer 2 world may not have heard of errdisable (or simply might refer to it as the proper term, error-disable)- but any seasoned tech knows what a pain it is to check your port and see errdisable. Back when I was a network technician for the Air Force, I remember going to a building on a trouble ticket, only to find a couple of cisco 4500 (if I recall correctly), with no less than 200 cables running to them..you literally could not see the ports themselves, or the RJ-45 connectors. After digging around, I did indeed find a switch hidden back there. After seeing the dreaded orange light on the port LED (signaling errdisable), I consoled into the switch. At the time, I knew errdisable was bad, but that’s about it. This article would have helped tremendously if I had seen it already. Hopefully someone out there reads it in time!
What IS errdisable?
Errdisable, or error-disable, is a feature that allows the switch to detect certain error conditions on interfaces and disable them before the particular condition has a chance to affect the rest of the network. Basically, Errdisable says “Wait, something isn’t right..I’m going to shut this down so it doesn’t break anything else.” An example of some of the errdisable conditions(but not a comprehensive list) can be found below. For a more thorough list, check out cisco.com, and search for errdisable.
- Port-security violation
- Etherchannel flapping
- Invalid GBIC
- DTP flapping (trunk negotiation)
As I said, there’s more reasons, but those are some of the more common violations. In my experience, Port-security has been the largest- although you can configure error-disable to do what you want after noticing the “error condition”, this action it takes AFTER the error condition is known as the method of recovery. There are two types- manual, and automatic. Manual requires a shut/no shut on the interface; automatic recovery can recover the port itself after a specified interval.
How to tell if a port is in errdisable:
To tell if a port is in errdisable or not, do a show int status, or you can do a “show int fx/x status”. You should see “err-disable” if it is indeed, disabled. From here, depending on your recovery method, you either enable it with a shut/no shut, or let it recover automatically.
ErrDisable key commands:
Enable errdisable (already enabled by default for UDLD/Port-security):
Switch(config)#errdisable detect cause {all | arp-inspection | dhcp-rate-limit | dtp-flap | gbic-invalid | l2ptguard | link-flap | pagp-flap}
Configure automatic recovery from errdisable:
Switch(config)# errdisable recovery cause {all | arp-inspection | bpduguard | channel-misconfig | dhcp-rate-limit | dtp-flap | gbic-invalid | l2ptguard | link-flap | pagp-flap | pesecure-violation | security-violation | storm-control | udld | unicastflood | wmps}
Configure recovery interval (only applies to conditions for which automatic recovery is enabled):
Switch(config)#errdisable recovery interval 120 (seconds)
To check Errdisable config:
Switch(config)#Show errdisable detect
ErrDisable Reason Detection Status
——————— ——————
udld Enabled
bpduguard Enabled
security-violation Enabled
psecure-violation Enabled
…and so on
Switch(config)#Show errdisable recovery
ErrDisable Reason Timer status
——————— —————
udld Enabled
bpduguard Enabled
……………..
Timer interval: 120 seconds
Interfaces that will be enabled at the next timeout:
Interface ErrDisable reason Time left(sec)
———- ——————— —————
f1/1 security-violation 34
Final point
ErrDisable is a good mechanism to help you find problems in your network- and to protect it- however, you should ultimately search for the root cause if you experience recurring errdisable conditions on certain ports. This is key, or your network will certainly not be operating efficiently.


Discussion
Comments are disallowed for this post.
Comments are closed.