从论坛学到不少好的经验，实在不好意思只看不贡献了，所以也把自己在运维中碰到的问题写下来和大家交流一下。

昨天一个用户反映上不了网，这个用户的网络是这样接入的，用户——〉思科2950——〉思科3560..... ，以下不提，登陆2950发现端口处于err-disable状态，在2950上重起端口发现错误包和碰撞异常严重，不到5秒就重新err-diable了，重起多次都是如此，使用show interfaces status err-disabled命令，发现错误原因为loopback，很不明白，所以使用show log命令查看日志，发现如下记录：

  Half-duplex loopback detected, collision threshold exceeded on FastEthernet0/3.
loopback error detected on Fa0/3, putting Fa0/3 in err-disable state
Line protocol on Interface FastEthernet0/3, changed state to down
Interface FastEthernet0/3, changed state to down

实在无奈，只好去了用户侧，发现光猫状态很不正常，数据线侧的指示灯常亮，说明流量异常大，拔下网线，在光猫上做单机测试，让同事重起端口后网络恢复正常，再把用户交换机的网线插上后再次异常。重起交换机故障依旧，最后怀疑是某个端口下联的主机出了问题，把交换机上所有网线拔除，一根一根接上，最后发现问题果然在一台主机上，只要接上这台主机的网线网络马上出现异常（延时非常大），发现这是一台视频监控的主机，嘱咐用户自己检查网络后离开。


这个问题不知道各位大虾有没有见到过，大家可以交流一下，一直很感谢网上的各路大虾分享的经验，我是新手，以后还请各位大虾多多指教~

好贴，我以前也遇到过类似

划分pvlan的时候遇到过这个问题，要注意操作顺序

看log 2950 F0/3端口应该工作在半双工模式，用户内网某台电脑流量异常导致冲突过大达到2950 error-disable的阀值。应该断开那台问题电脑，或者尝试使F0/3成为全双工都能解决。

导致交换机接口出现err-disable的几个常见原因：

1. EtherChannel misconfiguration

2. Duplex mismatch

3. BPDU port guard

4. UDLD

5. Link-flap error

6. Loopback error

7. Port security violation

1 当FEC两端配置不匹配的时候就会出现err-disable。假设Switch A把FEC模式配置为on，这时Switch A是不会发送PAgP包和相连的Switch B去协商FEC的，它假设Switch B已经配置好FEC了。但实事上Swtich B并没有配置FEC，当Switch B的这个状态超过1分钟后，Switch A的STP就认为有环路出现，因此也就出现了err-disable。解决办法就是把FEC的模式配置为channel-group 1 mode desirable non-silent这个意思是只有当双方的FEC协商成功后才建立channel，否则接口还处于正常状态。


2 第二个原因就是双工不匹配。一端配置为half-duplex后，他会检测对端是否在传输数据，只有对端停止传输数据，他才会发送类似于ack的包来让链路up，但对端却配置成了full-duplex，他才不管链路是否是空闲的，他只会不停的发送让链路up的请求，这样下去，链路状态就变成err-disable了。


3 第三个原因BPDU，也就是和portfast和BPDU guard有关。如果一个接口配置了portfast，那也就是说这个接口应该和一个pc连接，pc是不会发送spanning-tree的BPDU帧的，因此这个口也接收BPDU来生成spanning-tree，管理员也是出于好心在同一接口上配置了BPDU guard来防止未知的BPDU帧以增强安全性，但他恰恰不小心把一个交换机接到这个同时配置了portfast和BPDU guard接口上，于是这个接口接到了BPDU帧，因为配置了BPDU guard，这个接口自然要进入到err-disable状态。解决办法：no spanning-tree portfast bpduguard default，或者直接把portfast关了。


4 第四个原因是UDLD。UDLD是cisco的私有2层协议，用于检测链路的单向问题。有的时候物理层是up的，但链路层就是down，这时候就需要UDLD去检测链路是否是真的up的。当AB两端都配置好UDLD后，A给B发送一个包含自己port id的UDLD帧，B收到后会返回一个UDLD帧，并在其中包含了收到的A的port id，当A接收到这个帧并发现自己的port id也在其中后，认为这链路是好的。反之就变成err-disable状态了。假设A配置了UDLD，而B没有配置UDLD：A给B发送一个包含自己port id的帧，B收到后并不知道这个帧是什么，也就不会返回一个包含A的port id的UDLD帧，那么这时候A就认为这条链路是一个单向链路，自然也就变成err-disable状态了。


5 第五个原因就是链路的抖动，当链路在10秒内反复up、down五次，那么就进入err-disable状态。


6 第六个原因就是keepalive loopback。在12.1EA之前，默认情况下交换机会在所有接口都发送keepalive信息，由于一些不通交换机协商spanning-tree可能会有问题，一个接口又收到了自己发出的keepalive，那么这个接口就会变成err-disable了。解决办法就是把keepalive关了。或者把ios升到12.2SE


7 最后一个原因，相对简单，就是由于配置了port-security violation shutdown。

不错啊