Cisco Err-Disable: Causes, Recovery and Fixes

2026年9月19日 LOG admin

An error-disabled port is the switch telling you it protected the platform from something on that link. The port is administratively enabled and operationally down, with an orange LED and a err-disabled status — a state the switch will not leave on its own unless you configure a recovery timer. This guide covers identifying the cause, recovering the port, and configuring automatic recovery without turning a security feature into a way of hiding a real fault.

Identify the cause before you touch anything

switch# show interfaces gigabitethernet 1/0/4 status
Port      Name    Status        Vlan   Duplex  Speed Type
Gi1/0/4           err-disabled  100    full    1000  1000BaseSX

switch# show interfaces status err-disabled
Port      Name    Status        Reason
Gi1/0/4           err-disabled  bpduguard

switch# show errdisable detect

The switch also logs the reason with a message pair that is worth knowing by shape:

%SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Gi1/0/4 with BPDU Guard enabled. Disabling port.
%PM-4-ERR_DISABLE: bpduguard error detected on Gi1/0/4, putting Gi1/0/4 in err-disable state

show interfaces status err-disabled prints a Reason column — that single field saves more time than any other command in this workflow.

The common causes

Reason	What triggered it	Real fix
bpduguard	A BPDU arrived on a portfast/edge port	Remove the switch, loop or rogue device at the end of that cable
psecure-violation	Port security saw an unexpected MAC	Identify the device; fix or clear the sticky MAC entry
security-violation	802.1X authentication failure	Fix the supplicant or the RADIUS policy
link-flap	Link bounced repeatedly in a short window	Replace the cable/optic; check the far-end NIC
udld	UDLD detected a unidirectional link	Repair the physical path; often a bad fibre strand
channel-misconfig	EtherChannel member negotiated incompatibly	Align channel-group mode and configuration on both ends
dhcp-rate-limit	DHCP snooping rate limit exceeded	Fix the looping/Rogue DHCP source
storm-control	Broadcast/multicast storm exceeded threshold	Find the loop or the misbehaving host
loopback / gbic-invalid	Loopback detected; unsupported transceiver	Remove the loop; install a supported optic

The pattern to internalise: err-disable reasons are protective. Clearing the state without addressing the reason simply re-triggers it, usually within seconds.

Recover the port

switch(config)# interface gigabitethernet 1/0/4
switch(config-if)# shutdown
switch(config-if)# no shutdown
switch(config-if)# end
switch# show interfaces status err-disabled      ! should now be empty

If the port drops straight back into err-disabled, stop cycling it and fix the cause. A flapping port in a loop is worse than a disabled one.

Automatic recovery, configured carefully

switch(config)# errdisable recovery cause bpduguard
switch(config)# errdisable recovery cause link-flap
switch(config)# errdisable recovery cause psecure-violation
switch(config)# errdisable recovery interval 300     ! range 30-65535 s, default 300

switch# show errdisable recovery
ErrDisable Reason            Timer Status
-----------------            ------------
bpduguard                    Enabled
link-flap                    Enabled
psecure-violation            Enabled
udld                         Disabled
...
Timer interval: 300 seconds
Interfaces that will be enabled at the next timeout:
Gi1/0/4

Automatic recovery is disabled by default and, when enabled, retries after 300 seconds (Nexus uses the same default with a range of 30–65535 s). Practical guidance:

Enable it for reasons that are genuinely transient and self-correcting — a far-end NIC that took long to boot, an optic that needed reseating during maintenance.
Think twice for bpduguard and security-violation. These indicate a policy event; automatic recovery can flap a security boundary every five minutes instead of raising an alert.
Set the interval long enough to be visible in monitoring and short enough to satisfy the service SLA — 300–600 seconds is typical.
Alert on the transition, not on the recovery. If the same port recovers twice a day, you have a fault, not a nuisance.

Verification and monitoring

switch# show errdisable recovery
switch# show errdisable detect
switch# show interfaces status err-disabled
switch# show logging | include ERR_DISABLE

Track the log pattern rather than the port state: a rising count of ERR_DISABLE messages on one port tells you where to spend the next hour, even when automatic recovery keeps the port usable in between. Configure SNMP traps (or your telemetry equivalent) for the err-disable events so the first person to notice is the monitoring system, not the user whose printer stopped working.