This post will be discussing errdisabled recovery. The error disabled status of a port occurs when unfavourable conditions occur. We’ll discuss the potential reason a port would go into an error disabled mode, and how to get the port back to a functioning state.
The most common reason I’ve found in my experience for an error disabled port is due to a port security or BPDU violation (these will be covered in a separate post in the future), however it can be due to several things. Cisco lists the below as possible reasons:
- Duplex mismatch
- Port channel misconfiguration
- BPDU guard violation
- UniDirectional Link Detection (UDLD) condition
- Late-collision detection
- Link-flap detection
- Security violation
- Port Aggregation Protocol (PAgP) flap
- Layer 2 Tunneling Protocol (L2TP) guard
- DHCP snooping rate-limit
- Incorrect GBIC / Small Form-Factor Pluggable (SFP) module or cable
- Address Resolution Protocol (ARP) inspection
- Inline power
Let’s take a look at a port security scenario and how we can recover the port back to a functional state. Using port 1/0 on the switch, I’ve configured port security as below:
The above configuration tells the switch that no more than 2 MAC addresses can be learned from this individual port (perhaps an IP phone with a PC switched through its PC port). Anything more than this, and the port will use the default violation mode, which in this case will put the port into an error disabled mode. The switchport port-security mac-address sticky command, ensures than any dynamically learned MAC addresses stay in the running configuration and arent forgotten in the event of a reboot (the MAC addresses learned will actually show in the running configuration under that port once learned). As shown in the below topology, we have a standard L2 switch plugged into port 1/0, with 3 PCs plugged into this switch.
Once traffic is generated from all 3 PCs, the Cisco switch will have learned 3 different source MAC addresses from the same port, and as per the port security configuration, the port will (in this case – more about different port security violation modes in a later post) will go into error disabled mode. This should be seen in the IOS terminal as per below:
So now the port has been disabled. What does this mean? It basically just means the port is active, but will not pass any traffic until the port security violation conditions have been resolved and port has been shut and no shut. There is a way to get the switch to automatically enable the err-disabled port by using the err-disable recovery feature. This feature allows you to choose which reasons for err-disabled you want to enable auto recover for, which is pretty cool. If enabled, the timer interval (default 300 seconds) will check to see whether the issue has been cleared on the port. If so, the port will automatically recover without the requirement for manual intervention. Happy days. Lets have a gander at the options:
Here we can see all the reasons a port could go into err-disabled mode. As we can see from the output in debug when the port was disabled, it was a PSECURE-VIOLATION that caused the err-disable. So lets try setting the errdisable autorecover for that reason. We’ll also reduce the interval timer as this is a GNS3 lab, so its not necessary for me to wait 5 minutes…
From the above clip, we can see the psecure-violation autorecover feature being enabled, and the recovery interval timer being reduced to 30 seconds. (Not shown in this clip, but at the bottom of the sh err-disable recovery command, it will list the ports that it will attempt to enable at the next timer interval, along with the time left before it tries) Once this timer has elapsed and the reason for the violation to occur in the first place has been managed, you’ll see the switch trying to recover the port in the terminal as shown below:
Here we can see that the switch has attempted to recover the port and we can see the port coming back online. In the case the violation has not been fixed, the port will go straight back into err-disabled mode. Aaaand that’s errdisable recovery!
Leave A Comment