Causes and Solutions of err-disable on the switch

Several common causes of err-disable on the vswitch interface:

Reference

1. EtherChannel misconfiguration

2. Duplex mismatch

3. BPDU port guard

4. UDLD

5. Link-flap error

6. Loopback error

7. Port security violation

The first one will show err-disable when the configuration at both ends of f ec does not match. Assume that Switch A configures the FEC mode to on. In this case, Switch A does not send the PAgP packet and the connected Switch B to negotiate with FEC. It assumes that Switch B has configured FEC. But in fact Swtich B does not configure FEC. When the status of Switch B exceeds one minute, Switch A's STP considers that there is A loop, so err-disable occurs. The solution is to set the FEC mode to channel-group 1 mode desirable non-silent. This means that the channel is established only after the FEC negotiation is successful. Otherwise, the interface is still in normal state.

The second reason is that the duplex does not match. After the end is configured as half-duplex, he will check whether the peer is transmitting data. Only when the peer stops transmitting data will he send packets similar to ack to make the link up, however, when the peer end is configured with full-duplex, no matter whether the link is idle or not, he will only keep sending requests to make the link up, the link status changes to err-disable.

3. The third reason is BPDU, which is related to portfast and BPDU guard. If portfast is configured for an interface, this interface should be connected to a pc, and the pc will not send the spanning-tree BPDU frame, therefore, this port also receives BPDU to generate the spanning-tree. The Administrator also configures BPDU guard on the same interface to prevent unknown BPDU frames for enhanced security, however, he accidentally connected a vswitch to which both the portfast and BPDU guard interfaces are configured. Therefore, this interface is connected to the BPDU frame because BPDU guard is configured, this interface naturally enters the err-disable state. Solution: no spanning-tree portfast bpduguard default, or directly disable portfast.

The fourth reason is UDLD. UDLD is a cisco proprietary Layer 2 protocol used to detect one-way link problems. Sometimes the physical layer is up, but the link layer is down. In this case, you need UDLD to check whether the link is up. After both ends of AB are configured with UDLD, A sends a udld frame containing its own port id to B, and B returns A UDLD frame after receiving it, it also contains the received A port id. When A receives the frame and finds that its port id is also in it, it is considered that this link is good. Otherwise, it becomes err-disable. Assume that A is configured with UDLD, while B is not configured with UDLD: A sends A frame containing its own port id to B, and B does not know what the frame is after receiving it, in this case, a udld frame containing the port id of A is not returned. At this time, A considers this link as A one-way link, which naturally changes to the err-disable state.

The fifth reason is the link jitter. When the link is up or down five times in 10 seconds, it enters the err-disable state.

The sixth reason is keepalive loopback. Before 12.1EA, the switch will send keepalive information on all interfaces by default. Because some switches fail to negotiate with the spanning-tree, the same interface may receive its own keepalive message, then this interface will become err-disable. The solution is to disable keepalive. Or upgrade ios to 12.2SE.

The last reason is that port-security violation shutdown is configured. This is too simple to explain.