Errdisable autorecovery

There are a number of events which can disable a link on a Catalyst switch, such as the detection of a loopback, UDLD failure, or a broadcast storm. One of the most common causes of error disabling I've seen isn't technically an error, but a violation of a port security policy. Port security is a feature which allows for the restriction of incoming MAC addresses on a layer two switched interface. This is handy for mitigating the use of rogue devices customers purchase at Best Buy to help out with your network infrastructure design. In aggressive configurations, only a single MAC address (corresponding to the attached workstation) will be allowed inbound on a port; any other MAC address will trigger an error and the port will subsequently be disabled.

A default port security policy has been applied to FastEthernet0/1 in this example:

interface FastEthernet0/1
 switchport access vlan 10
 switchport mode access
 switchport port-security
 spanning-tree portfast

We can verify that the port is currently up and associated with a MAC address. Note that the violation mode is "shutdown."

Switch# show port-security interface f0/1
Port Security              : Enabled
Port Status                : Secure-up
Violation Mode             : Shutdown
Aging Time                 : 0 mins
Aging Type                 : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 1
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 0
Last Source Address:Vlan   : 001d.60b3.0add:10
Security Violation Count   : 0

When a violation is detected, the switch automatically places the port in the "err-disabled" shutdown state.

%PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address
 001d.60b3.0aff on port FastEthernet0/1.

Switch# show interface f0/1
FastEthernet0/1 is down, line protocol is down (err-disabled)
...

By default, manual intervention by an administrator is necessary to restore the interface to working order; this can be done by issuing shutdown followed by no shutdown on the interface. The idea behind requiring administrative action is so that a human engineer can intercede, assess, and (ideally) correct the issue. However, some configurations may be prone to accidental violations, and a steady recurrence of these can amount to a huge time sink for the administrative staff.

This is where autorecovery can be of great assistance. We can configure the switch to automatically re-enable any error-disabled interfaces after a specified timeout period. This gives the offending issue a chance to be cleared by the user (for example, by removing an unapproved device) without the need for administrative intervention.

Switch(config)# errdisable recovery cause psecure-violation
Switch(config)# errdisable recovery interval 300

The above configuration enables autorecovery for port security violations after five minutes. As evident in the list, autorecovery can apply to far more than just port security violations.

Switch# show errdisable recovery 
ErrDisable Reason            Timer Status
-----------------            --------------
arp-inspection               Disabled
bpduguard                    Disabled
channel-misconfig            Disabled
dhcp-rate-limit              Disabled
dtp-flap                     Disabled
gbic-invalid                 Disabled
inline-power                 Disabled
l2ptguard                    Disabled
link-flap                    Disabled
mac-limit                    Disabled
link-monitor-failure         Disabled
loopback                     Disabled
oam-remote-failure           Disabled
pagp-flap                    Disabled
port-mode-failure            Disabled
psecure-violation            Enabled
security-violation           Disabled
sfp-config-mismatch          Disabled
storm-control                Disabled
udld                         Disabled
unicast-flood                Disabled
vmps                         Disabled

Timer interval: 300 seconds

Interfaces that will be enabled at the next timeout:

Now when we force a violation on FastEthernet0/1, we see that it has been placed in the queue for automatic recovery:

Switch# show errdisable recovery
...

Interfaces that will be enabled at the next timeout:

Interface       Errdisable reason       Time left(sec)
---------       -----------------       --------------
Fa0/1          psecure-violation          237

And two hundred and thirty-seven seconds later...

%PM-4-ERR_RECOVER: Attempting to recover from psecure-violation err-disable
 state on Fa0/1

Switch# show interface f0/1
FastEthernet0/1 is up, line protocol is up (connected)
...