導致交換機接口出現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幀以增強http://.安全性,但他恰恰不小心把一個交換機接到這個同時配置了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
交換機出現err-disable原因及解決