Cisco 交換機端口err-disable 解決方法

我的一台2960GG透過多模 10G SFP-10GBase-LRM光纖接核心3850交換機，今天早上之間網絡不通，3850G和2960上的SFP子產品訓示燈都不亮，檢視CISCO 2960G端口有如下提示：

#show int status err-disabled

Port      Name                               Status            Reason               Err-disabled Vlans

Te6/0/1   [TRUNK] swi-core01    err-disabled    link-flap

解決如下：

conf t

int Te6/0/1

shut

no shut

end

OK!!!

查閱關于link-flap及err-disable的資料如下：http://www.net130.com/cms/Pub/Tech/tech_zh/2010_11_07_20606.htmhttp://shanliren.blog.51cto.com/159454/165595

Cisco網站上關于link-flap的說明：

Link-flap error

Link flap means that the interface continually goes up and down. The interface is put into the errdisabled state if it flaps more than five times in 10 seconds. The common cause of link flap is a Layer 1 issue such as a bad cable, duplex mismatch, or bad Gigabit Interface Converter (GBIC) card. Look at the console messages or the messages that were sent to the syslog server that state the reason for the port shutdown.

我的翻譯：

Link flap的意思是接口持續性的up和down。如果一個接口在10秒内發生超過5次up/down，将被置為errdisable狀态。link-flap的原因為layer-1層的諸如網線問題、雙工不比對或者故障的千兆GBIC卡。可以檢視console或者syslog伺服器下的log日志，擷取端口shutdwn的原因。出現了這個問題，我們不得不重視起交換機端口“假死”的現象，尋求在交換機不重新開機的狀态下将該端口“拯救”回來的方法。

拯救步驟1：檢視日志/端口的狀态

 登入進入交換機後，執行show log，會看到如下的提示：

21w6d: %ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected on FastEthernet0/20.

21w6d: %PM-4-ERR_DISABLE: loopback error detected on Fa0/20, putting Fa0/20 in err-disable state

以上資訊就明确表示由于檢測到第20端口出現了環路，是以将該端口置于了err-disable狀态。

 檢視端口的狀态

 Switch

#show int te6/0/1 status

Port      Name               Status       Vlan       Duplex  Speed Type

Te6/0/1   [TRUNK] swi-core01 err-disabled 1            full    10G SFP-10GBase-LRM

這條資訊更加明确的表示了該端口處于err-disabled狀态。

既然看到了該端口是被置于了錯誤的狀态了，我們就應該有辦法将其再恢複成正常的狀态。

拯救步驟2：将端口從錯誤狀态中恢複回來

 進入交換機全局配置模式，執行errdisable recovery cause ?，會看到如下資訊：

Switch(config)#errdisable recovery cause ?

all                 Enable timer to recover from all causes

bpduguard           Enable timer to recover from BPDU Guard error disable state

channel-misconfig   Enable timer to recover from channel misconfig disable state

dhcp-rate-limit     Enable timer to recover from dhcp-rate-limit error disable state

dtp-flap            Enable timer to recover from dtp-flap error disable state

gbic-invalid        Enable timer to recover from invalid GBIC error disable state

l2ptguard           Enable timer to recover from l2protocol-tunnel error disable state

link-flap           Enable timer to recover from link-flap error disable state       鍊路報錯修複

loopback            Enable timer to recover from loopback detected disable state   環路報錯修複

pagp-flap           Enable timer to recover from pagp-flap error disable state

psecure-violation   Enable timer to recover from psecure violation disable state

security-violation Enable timer to recover from 802.1x violation disable state

udld                Enable timer to recover from udld error disable state

unicast-flood       Enable timer to recover from unicast flood disable state

vmps                Enable timer to recover from vmps shutdown error disable state

 從列出的選項中，我們可以看出，有非常多的原因會引起端口被置于錯誤狀态，由于我們明确的知道這台交換機上的端口是由于環路問題而被置于錯誤狀态的，是以就可以直接鍵入指令：

 Switch(config)#errdisable recovery cause link-flap

是啊，就這麼簡單的一條指令，就把困撓我們很長時間的問題解決了，真的就這麼神奇。那麼如何驗證這條指令是生效了呢？

拯救步驟3：顯示被置于錯誤狀态端口的恢複情況

switch#show errdisable recovery

ErrDisable Reason            Timer Status

-----------------            --------------

arp-inspection               Disabled

bpduguard                    Disabled

channel-misconfig (STP)      Disabled

dhcp-rate-limit              Disabled

dtp-flap                     Disabled

gbic-invalid                 Disabled

inline-power                 Disabled

link-flap                    Enabled

mac-limit                    Disabled

loopback                     Disabled

pagp-flap                    Disabled

port-mode-failure            Disabled

pppoe-ia-rate-limit          Disabled

psecure-violation            Disabled

security-violation           Disabled

sfp-config-mismatch          Disabled

small-frame                  Disabled

storm-control                Disabled

udld                         Disabled

vmps                         Disabled

psp                          Disabled

dual-active-recovery         Disabled

evc-lite input mapping fa    Disabled

Recovery command: "clear     Disabled

Timer interval: 300 seconds

Interface       Errdisable reason       Time left(sec)

---------       -----------------       --------------

Interfaces that will be enabled at the next timeout:

Te6/0/1                link-flap          222

 從以上顯示的資訊可以看出，這台交換機有一個端口（Te6/0/1）會222秒之後恢複為正常的狀态，實際情況也是這樣，等了幾分鐘以後。這下總算在不重交換機的情況下，将幾個處于“假死”狀态的端口“拯救”了回來。

 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~·

 以上是一網友提供的解決cisco交換機端口假死的辦法，雖然辦法可行，但是每次假死後都要手動去恢複有些麻煩

 為了讓交換機出現此假死故障後能自動恢複，我們也有相應幫忙來解決

 在這裡我就上面網友的内容進行補充，用于cisco交換機自動恢複端口假死的故障

 在特權模式下配置如下：

 errdisable recovery cause udld

errdisable recovery cause bpduguard

errdisable recovery cause security-violation

errdisable recovery cause channel-misconfig

errdisable recovery cause pagp-flap

errdisable recovery cause dtp-flap

errdisable recovery cause link-flap

errdisable recovery cause sfp-config-mismatch

errdisable recovery cause gbic-invalid

errdisable recovery cause l2ptguard

errdisable recovery cause psecure-violation

errdisable recovery cause dhcp-rate-limit

errdisable recovery cause unicast-flood

errdisable recovery cause vmps

errdisable recovery cause storm-control

errdisable recovery cause inline-power

errdisable recovery cause arp-inspection

errdisable recovery cause loopback

 以上這些都是導緻端口假死的條件，配置上述可以

%PM-4-ERR_DISABLE: link-flap error detected on Gi4/1, putting Gi4/

 1 in err-disable state

Issue this command in order to view the flap values:

 cat6knative#show errdisable flap-values

 !--- Refer to show errdisable flap-values for more information on the command.

 ErrDisable Reason    Flaps    Time (sec)

-----------------    ------   ----------

pagp-flap              3       30

dtp-flap               3       30

link-flap              5       10

讓端口在出現假死後自動恢複；關于接口處于err-disable的故障排查

故障症狀：

線路不通，實體訓示燈滅或者顯示為橙色(不同平台訓示燈狀态不同)

show interface 輸出顯示接口狀态：

FastEthernet0/47 is down, line protocol is down (err-disabled)

接口狀态是err-disable。

sw1#show interfaces statusPort Name Status Vlan Duplex Speed Type

Fa0/47 err-disabled 1 auto auto 10/100BaseTX

如果出現了接口狀态為err-disable，show interfaces status err-disabled指令能檢視觸發err-disable的原因。

下面示例原因為bpduguard，在連接配接了交換機的端口配置了spanning-tree bpduguard enable。

sw1#show interfaces status err-disabled

Port Name Status Reason

Fa0/47 err-disabled bpduguard

接口産生err-disable的原因可以由以下的指令來檢視，系統預設的配置是所有列出的原因都能導緻接口被置為err-disable。

sw1#show errdisable detect

ErrDisable Reason Detection status

----------------- ----------------

udld Enabled

bpduguard Enabled

security-violatio Enabled

channel-misconfig Enabled

psecure-violation Enabled

dhcp-rate-limit Enabled

unicast-flood Enabled

vmps Enabled

pagp-flap Enabled

dtp-flap Enabled

link-flap Enabled

l2ptguard Enabled

gbic-invalid Enabled

loopback Enabled

unicast-flood Enabled 從清單中，我們可以看出常見的原因有udld，bpduguard，link-flap以及loopback等。 具體由什麼原因導緻目前接口err-disable可以由show interface status err-disable來檢視。

在接口模式下采用shutdown,no shutdown進行手動的激活。

在預設配置下，一旦接口被置為err-disable，IOS将不會試圖恢複接口。

這個可以由show errdisable recovery來檢視，timer status下面所有的值都是disable。

下面的示例中，由于手工配置了bpduguard恢複，是以timer status的值變為Enable。

sw1#show errdisable recovery

ErrDisable Reason Timer Status

----------------- --------------

udld Disabled

security-violatio Disabled

channel-misconfig Disabled

vmps Disabled

pagp-flap Disabled

dtp-flap Disabled

link-flap Disabled

l2ptguard Disabled

psecure-violation Disabled

gbic-invalid Disabled

dhcp-rate-limit Disabled

unicast-flood Disabled

loopback Disabled

Interface Errdisable reason Time left(sec)

--------- ----------------- --------------

Fa0/47 bpduguard 217

配置IOS重新激活errdisable的接口，使用以下指令：

sw1(config)#errdisable recovery cause bpduguard

sw1(config)#errdisable recovery cause ?

all Enable timer to recover from all causes

bpduguard Enable timer to recover from BPDU Guard error disable state

channel-misconfig Enable timer to recover from channel misconfig disable state

dhcp-rate-limit Enable timer to recover from dhcp-rate-limit error disable state

dtp-flap Enable timer to recover from dtp-flap error disable state

gbic-invalid Enable timer to recover from invalid GBIC error disable state

l2ptguard Enable timer to recover from l2protocol-tunnel error disable state

link-flap Enable timer to recover from link-flap error disable state

loopback Enable timer to recover from loopback detected disable state

pagp-flap Enable timer to recover from pagp-flap error disable state

psecure-violation Enable timer to recover from psecure violation disable state

udld Enable timer to recover from udld error disable state

unicast-flood Enable timer to recover from unicast flood disable state

vmps Enable timer to recover from vmps shutdown error disable配置完上述指令後，IOS在一段時間後試圖恢複被置為err-disable的接口，這段時間預設為300秒。

但是，如果引起err-disable的源沒有根治，在恢複工作後，接口會再次被置為err-disable。

調整err-disable的逾時時間，可以使用以下指令：

sw1(config)#errdisable recovery interval ?

<30-86400> timer-interval(sec) 可以調整在30－86400秒，預設是300秒。

如果産生err-disable的原因是udld，下面有一條指令非常管用：sw1#udld resetNo ports are disabled by UDLD.

同時，接口在被置為err-disable的時候，通常有一系列的日志産生，如下：

*Mar 15 15:47:19.984: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port FastEthernet0/47 with BPDU Guard enabled. Disabling port.

sw1#

*Mar 15 15:47:19.984: %PM-4-ERR_DISABLE: bpduguard error detected on Fa0/47, putting Fa0/47 in err-disable state

*Mar 15 15:47:21.996: %LINK-3-UPDOWN: Interface FastEthernet0/47, changed state to down

收集這些日志也非常管用。

是以建議配置一個syslog server，收集log資訊。

 sw1#show interfaces status

Port Name Status Vlan Du...

開啟errdisable功能，這樣可以使用show errdisable來檢視引發errdisable的原因是什麼，再更加資訊内容進行解決。

你要是想不影響使用的話，先用 no errdisable detect cause loopback 執行一下，将已經死掉的端口，no sh 一下 如果沒問題，肯定是環路了，你可再找時間，對懷疑有問題的switch用拔插法，一個一個拔掉網線去查，當然，有更有效的方法，你可檢視有問題的switch的所有rj45和gi口的狀态，哪個有errdisable資訊哪個就有問題。

switch#show interfaces status err-disabled

Fa0/22 err-disabled link-flap

Fa0/37 For office in 100K err-disabled link-flap

Fa0/41 unknow err-disabled link-flap

Fa0/42 Training Dc066 err-disabled link-flap

Fa0/45 Production line VM err-disabled link-flap

switch#show errdisable detect

----------------- ---------------- pagp-flap 3 30

dtp-flap 3 30

link-flap 5 10

( link-flap 這就是因為鍊路品質不好導緻的)

關閉errdisable detectswitch

#no errdisable detect cause all

導緻交換機接口出現err-disable的幾個常見原因： 

    1. EtherChannel misconfiguration

    2. Duplex mismatch

    style="TEXT-INDENT： 2em">3. BPDU port guard

    4. UDLD

    5. Link-flap error

    6. Loopback error

    7. Port security violation

    第一個當F EC兩端配置不比對的時候就會出現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，否則接口還處于正常狀态。

    第二個原因就是雙工不比對。一端配置為half-duplex後，他會檢測對端是否在傳輸資料，隻有對端停止傳輸資料，他才會發送類似于ack的包來讓鍊路up，但對端卻配置成了full-duplex，他才不管鍊路是否是空閑的，他隻會不停的發送讓鍊路up的請求，這樣下去，鍊路狀态就變成err-disable了。

    三、第三個原因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關了。

    第四個原因是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狀态了。

    第五個原因就是鍊路的抖動，當鍊路在10秒内反複up、down五次，那麼就進入err-disable狀态。

    第六個原因就是keepalive loopback.在12.1EA之前，預設情況下交換機會在所有接口都發送keepalive資訊，由于一些不通交換機協商spanning-tree可能會有問題，一個接口又收到了自己發出的keepalive，那麼這個接口就會變成err-disable了。解決辦法就是把keepalive關了。或者把ios升到12.2SE.

    最後一個原因，相對簡單，就是由于配置了port-security violation shutdown