CCNP Reference

 errDisable

Platforms Using errDisable

The errDisable feature is supported on Catalyst switches running CatOS (Catalyst 2948G, 4500/4000, 5500/5000 & 6500/6000) as well as Catalyst switches running Cisco IOS (Catalyst 2900XL/3500XL, 2950, 2970, 3550, 4500 & 65000).

The way the errDisable is implemented varies between platforms. This document will specifically focus on error-disable for the switches running CatOS software.

Function of errDisable

The errDisable feature was first implemented in CatOS release 3.2(2). If the configuration showed a port to be enabled, but software on the switch detected an error situation on the port, the software would shut down that port.

In other words, the port was automatically disabled by the switch operating system software because of an error condition encountered on the port.

When a port is error-disabled, it is effectively shut down and no traffic is being sent or received on that port. The port LED is set to the color orange and when you enter the show port command, the port status shows errdisable. Here is an example of what an error-disabled port would look like from the command line interface of the switch.

Cat5500> (enable) show port 11/1
Port  Name               Status     Vlan       Level  Duplex Speed Type
----- ------------------ ---------- ---------- ------ ------ ----- ------------
11/1              errdisable   1 normal   auto  auto 10/100BaseTX

The error-disable function serves two purposes. First, it lets the administrator know when and where there is a port problem. Second, it eliminates the possibility that this port could cause other ports on the module (or the entire module) to fail due to buffers being monopolized by the bad port, port error messages monopolizing inter-process communications on the card, even ultimately causing serious network issues. The error-disable feature helps prevent these situations.

Causes of errDisable

At first, this feature was implemented to handle special collision situations where the switch detected excessive or late collisions on a port. Excessive collisions occur when a frame is dropped because of encountering 16 collisions in a row. Late collisions occur after every device on the wire should have recognized that the wire was in use.

These types of errors could be caused by a cable that is out of specification (too long, wrong type, defective), a bad network interface card (NIC) card (with physical problems, or driver problems), or a port duplex misconfiguration.

This last cause is common because of failures to negotiate the speed and duplex properly between two directly connected devices (for example, a NIC card connected to a switch). Only half-duplex connections should ever have collisions in a LAN; due to the Carrier-Sense Multi-Access (CSMA) nature of Ethernet, collisions are normal for half-duplex, as long as they do not exceed a small percentage of traffic.

As the capabilities of the CatOS grew, there were more ways that a port could become error-disabled. For example on the catalyst 6500 running catOS, the Errdisable feature is supported for these connectivity issues:

• ARP inspection
• Broadcast suppression
• BPDU port-guard
• Channel misconfiguration
• Crossbar failure
• Duplex mismatch
• Layer 2 protocol tunnel misconfiguration
• Layer 2 protocol tunnel threshold exceeded
• UDLD

The error-disable function allows the switch to shut down a port when it encounters any of these situations. Remember, a port being error-disabled is not by itself a cause for alarm, as long as one determines and resolves its root cause. An error-disabled port is a symptom of a deeper problem that must be resolved.

Recovery from errDisable

In order to recover from errDisable you should do two things:

1. Identify and fix whatever caused the ports to become error-disabled (cable, NICs, EtherChannel, and so on).
2. If you do not identify and fix the underlying issue that caused the ports to be error-disabled, then the ports will just become error-disabled again when the problem reoccurs. Some errors can occur quite often (an example is the error detected by BPDU portguard, which can occur every two seconds). If you tried to reenable the ports without fixing the source of the problem they would just become error-disabled again.
3. Reenable the port.
4. Just fixing the source of the problem will not cause the ports to become enabled again. Once you fix the source of the problem, the ports are still disabled (and the port LEDs are still orange); the ports must be reenabled before they will become active. At first the only way to reenable the port was to manually enter the set port enable command for the ports in question. Over time there have been optional extensions added to the error-disable feature to make it more flexible and automatic.

Note: An error-disabled port is not the only reason a port LED could go orange; it is only one of the reasons. That is why it is always good to check the port status with the show port command.




http://itprostuff.blogspot.com/search/label/CCNP