Everyone remembers the original movie TRON where the character Flynn, played by Jeff Bridges, is sucked into the microscopic world of computer games.  In the movie the villain was the Master Control Program or MCP who would take programs OFFLINE if they misbehaved.

Switches have their own MCP (of sorts) which takes network switch ports OFFLINE if they misbehave or have a security violation.  This switching MCP is known as ERRDISABLE.

How to troubleshoot network switch ports that are errdisabled

Network switches can be increadibly helpful and frustrating devices, especially when you find a switch port in an err-disabled state. And the first time you see a port err-disabled can be a little scary. Not knowing what causes this condition can make troubleshooting a network issue very frustrating.

So why is a switch port errdisabled?

Before we can understand why a port is err-disabled we must understand what is the purpose of this switch function.

The Purpose of an Errdisabled State

Switch ports can be in various different states, disabled, connected, notconnect, monitoring, and err-disable. If the status of a switch port shows it to be up and enabled (not admin down) but the switch has detected and abnormal condition, the switch with automatically shutdown the port and put it in an err-diabled state.

When a network switch port is errdisabled it is shut down and no frames will be sent or received on that port. As a visual indication on the outside of a Cisco switch (other vednor switches may vary), the LED on the port maybe lit orange or turned off completely.

When you issue the “show interface status” command, the port will show err-disabled.

Here is an example of what an error-disabled port looks like from the command-line interface (CLI) of a Cisco network switch:

switch#show interfaces status

Port Name Status Vlan Duplex Speed Type
Gi1/1 connected trunk full 1000 1000BaseSX
Gi1/2 err-disable 1 full 1000 1000BaseSX
Gi1/3 disabled 1 full 1000 No Transceiver
Gi1/4 disabled 1 full 1000 No Transceiver
Gi1/5 connected 1 full 1000 unknown
Gi1/6 monitoring 1 a-full a-1000 10/100/1000BaseT
Gi1/7 notconnect 1 full 1000 No Transceiver

If you look in the logs for a switch that has a port in an err-disabled state you can get a bit more information about why the switch put the port in err-disabled. You might see messages that are similar to the following n both the console and the syslog:

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

In this example, the log message displays an access port that has received a bridge protocol data unit (BPDU) when BPDU gaurd was enabled on the port. The actual message will be different depending on the reason for the error disable state.

Why do we have errdisable?

Though finding ports randomly shutdown in an errdisabled state can be frustrating at times, it is actually a good thing.
The whole prupose of errdisable is to let network engineers know when there’s an issue on a port and to prevent a cascading effect across all ports or the rest of your network. If the switch did not put ports in an errdisabled state, you could run the risk of having problems with other ports or worse an entire switch module failure.

What Causes Errdisable?

Errdisable was originally created to handle collisions between brdige ports where bridge/switch detected excessive or late collisions on a port. If the switch encountered 16 collisions in a row, the frame would be dropped. A late collisions is when devices on the wire should have recognized the wire was in use but didn’t.

Things that can cause a network switch port to go into an errdiable state:

• A cable that is out of specification (too long, defective, bad pin-out, wrong type)
• A bad NIC (either NIC driver or physical interface problems)
• Duplex mismatch (one of the most common cause)
• Port channel misconfiguration
• BPDU guard violation
• UDLD condition
• Constant Port flapping
• Port Security violation (too many mac addresses on a port)
• PAgP flapping
• L2TP guard
• DHCP snooping rate-limit
• Wrong or faulty GBIC
• PoE power issue
• ARP issue

Note: Switches normally have err-disable enabled by default but can be turned off.  We highly recommend that you do not turn off err-disable unless you know exactly how this can effect your network.

Use the command “show errdisable detect” to display all of the err-disable detection statuses.

The following is the output of “show errdisable detect”

switch#sh errdisable detect
ErrDisable Reason Detection status
----------------- ----------------
udld Enabled
bpduguard Enabled
security-violatio Enabled
channel-misconfig Enabled
psecure-violation Enabled
mac-limit Enabled
unicast-flood Enabled
pagp-flap Enabled
dtp-flap Enabled
link-flap Enabled
l2ptguard Enabled
gbic-invalid Enabled
dhcp-rate-limit Enabled
arp-inspection Enabled
inline-power Enabled
packet-buffer Enabled
transceiver-incom Enabled

Err-disable recovery

Switches can also automatically reenable ports after an err-disable condition has occured. This is typically controlled through the errdisable recovery timer. To see the errdisable recovery timer use the command “show errdisable recovery”. You can also use this command to see a list of ports scheduled to be re-enabled.

The following is the output of the “show errdisable recovery” command

switch#sh errdisable recovery
ErrDisable Reason Timer Status
----------------- --------------
udld Enabled
bpduguard Enabled
security-violatio Disabled
channel-misconfig Disabled
pagp-flap Disabled
dtp-flap Disabled
link-flap Disabled
l2ptguard Disabled
psecure-violation Disabled
gbic-invalid Disabled
dhcp-rate-limit Disabled
mac-limit Disabled
unicast-flood Disabled
arp-inspection Disabled

Timer interval: 3600 seconds

Interfaces that will be enabled at the next timeout:

Errdisable on loopback interfaces

Up until now we have been discussing physical switch ports that could be in an err-disable state. But what if you find your loopback interface in an err-disable state? As strange as it seems this can happen. This is mainly seen on switches running older IOS code (prior to 12.1EA)

From Cisco’s website:
A loopback error occurs when the keepalive packet is looped back to the port that sent the keepalive. The switch sends keepalives out all the interfaces by default. A device can loop the packets back to the source interface, which usually occurs because there is a logical loop in the network that the spanning tree has not blocked. The source interface receives the keepalive packet that it sent out, and the switch disables the interface (errdisable). This message occurs because the keepalive packet is looped back to the port that sent the keepalive:

%PM-4-ERR_DISABLE: loopback error detected on Gi4/1, putting Gi4/1 in err-disable state

Keepalives are sent on all interfaces by default in Cisco IOS Software Release 12.1EA-based software. In Cisco IOS Software Release 12.2SE-based software and later, keepalives are not sent by default on fiber and uplink interfaces.

Summary

Just like the MCP from TRON, the errdisable function plays a very important role on your switches, but if left unchecked could wreak havoc to your network.   The errdisabled state on a network switch port is a handy tool to have that can help you detect problems, keep your network secure, and protect your network from trouble that could escallate into a much worse condition.  Armed with knowing why switch ports go into an err-dsabled state will improve your understanding of your network and help speed up your troubleshooting of network switch port issues.

Have you had a strange experience with switch ports being put into an err-disable state? Let us know, leave a comment below!