交換機端口假死恢復
交換機正在工作的端口，突然變成關閉狀態的假死現象，可以用重啓交換機來解決，但這並非長久之計，當“假死”現象蔓延的時候，我們不得尋找根治的辦法！
交換機端口假死 用“重啓”來應付
“假死”現象蔓延 不得不根治？
拯救步驟1：查看日誌/端口的狀態
拯救步驟2：將端口從錯誤狀態中恢復回來
拯救步驟3：顯示被置於錯誤狀態端口的恢復情況
交換機端口假死 用“重啓”來應付
單位中有若干臺CISCO3550的交換機，分別放在相應的網絡中擔當着骨幹交換機的角色，有一臺用在單位上互聯網的局域網中，還有一臺則用在單位的數字電視前端系統的局域網中。不知道大家有沒有遇見過跟我一樣的現象，即CISCO交換機上的某些正在工作的端口，突然變成關閉狀態了，該端口上即使插着網線，端口上的指示燈仍然不亮（這種故障往往是在下面所連接的網絡出現故障的時侯出現）。以前這種情況多出現在位於單位上互聯網的那臺交換機上，當這種情況發生時，爲了迅速排除故障，我們會先調整一個端口，即將網線從有問題的端口上撥下來，再插到一個空閒的端口上，這時一般網絡故障就排除了。
而且時間一長我們發現，那個處於關閉狀態的端口並不是真正損壞了，當我們重新啓動一下交換機後，那個端口又“復活”了。由於那臺上互聯網的交換機還有一些空閒端口，而且我們可以指定這臺交換機在一個網絡使用相對較少的時間重啓（比如凌晨4點），所以端口“假死”這個故障雖然存在，但由於我們一般可以通過重啓交換機的方法解決，所以也就沒有放在心上。
“假死”現象蔓延 不得不根治？
但是最近幾天單位那臺連接數字電視前端系統的交換機上也出現了端口“假死”的現象，故障原因很快查清了：是因爲該端口下面連接的一臺交換機出現了環路，這臺CISCO交換機上相應的端口就被系統自動關閉了，這種措勢是必要的，因爲可以防止環路的擴散，但是當下面的交換機環路故障解除後，該端口並沒有又恢復到正常工作狀態，更要命的是：一、更換端口; 二、重啓交換機都無法實現，因爲一來這臺交換機上空閒端口很少了，二來這臺交換機需要始終處於工作狀態，如果一旦重新啓動，這幾分鐘的網絡中斷就會影響到數字電視的播出，所以是絕對不能重啓的。
出現了這個問題，我們不得不重視起交換機端口“假死”的現象，尋求在交換機不重啓的狀態下將該端口“拯救”回來的方法。
拯救步驟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 inter fa0/20 status
Port Name Status Vlan Duplex Speed Type
Fa0/20 link to databackup err-disabled 562 auto auto 10/100BaseTX
這條信息更加明確的表示了該端口處於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 loopback
是啊，就這麼簡單的一條命令，就把困撓我們很長時間的問題解決了，真的就這麼神奇。那麼如何驗證這條命令是生效了呢？
拯救步驟3：顯示被置於錯誤狀態端口的恢復情況
Switch# show errdisable recovery
ErrDisable Reason Timer Status
----------------- --------------
udld Disabled
bpduguard Disabled
security-violatio Disabled
channel-misconfig Disabled
vmps Disabled
pagp-flap Disabled
dtp-flap Disabled
link-flap Disabled
gbic-invalid Disabled
l2ptguard Disabled
psecure-violation Disabled
gbic-invalid Disabled
dhcp-rate-limit Disabled
unicast-flood Disabled
loopback Enabled
Timer interval: 300 seconds
Interfaces that will be enabled at the next timeout:
Interface Errdisable reason Time left(sec)
--------- ----------------- --------------
Fa0/8 loopback 276
Fa0/17 loopback 267
Fa0/20 loopback 250
從以上顯示的信息可以看出，這臺交換機有三個端口（Fa0/8、Fa0/17、Fa0/20）會分別在276、267、250秒之後恢復爲正常的狀態，實際情況也是這樣，等了幾分鐘以後，我們找了一臺筆記本電腦，分別接到這幾個端口上試了一下，端口都可以正常工作了。這下總算在不重交換機的情況下，將幾個處於“假死”狀態的
交換機正在工作的端口，突然變成關閉狀態的假死現象，可以用重啓交換機來解決，但這並非長久之計，當“假死”現象蔓延的時候，我們不得尋找根治的辦法！
交換機端口假死 用“重啓”來應付
“假死”現象蔓延 不得不根治？
拯救步驟1：查看日誌/端口的狀態
拯救步驟2：將端口從錯誤狀態中恢復回來
拯救步驟3：顯示被置於錯誤狀態端口的恢復情況
交換機端口假死 用“重啓”來應付
單位中有若干臺CISCO3550的交換機，分別放在相應的網絡中擔當着骨幹交換機的角色，有一臺用在單位上互聯網的局域網中，還有一臺則用在單位的數字電視前端系統的局域網中。不知道大家有沒有遇見過跟我一樣的現象，即CISCO交換機上的某些正在工作的端口，突然變成關閉狀態了，該端口上即使插着網線，端口上的指示燈仍然不亮（這種故障往往是在下面所連接的網絡出現故障的時侯出現）。以前這種情況多出現在位於單位上互聯網的那臺交換機上，當這種情況發生時，爲了迅速排除故障，我們會先調整一個端口，即將網線從有問題的端口上撥下來，再插到一個空閒的端口上，這時一般網絡故障就排除了。
而且時間一長我們發現，那個處於關閉狀態的端口並不是真正損壞了，當我們重新啓動一下交換機後，那個端口又“復活”了。由於那臺上互聯網的交換機還有一些空閒端口，而且我們可以指定這臺交換機在一個網絡使用相對較少的時間重啓（比如凌晨4點），所以端口“假死”這個故障雖然存在，但由於我們一般可以通過重啓交換機的方法解決，所以也就沒有放在心上。
“假死”現象蔓延 不得不根治？
但是最近幾天單位那臺連接數字電視前端系統的交換機上也出現了端口“假死”的現象，故障原因很快查清了：是因爲該端口下面連接的一臺交換機出現了環路，這臺CISCO交換機上相應的端口就被系統自動關閉了，這種措勢是必要的，因爲可以防止環路的擴散，但是當下面的交換機環路故障解除後，該端口並沒有又恢復到正常工作狀態，更要命的是：一、更換端口; 二、重啓交換機都無法實現，因爲一來這臺交換機上空閒端口很少了，二來這臺交換機需要始終處於工作狀態，如果一旦重新啓動，這幾分鐘的網絡中斷就會影響到數字電視的播出，所以是絕對不能重啓的。
出現了這個問題，我們不得不重視起交換機端口“假死”的現象，尋求在交換機不重啓的狀態下將該端口“拯救”回來的方法。
拯救步驟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 inter fa0/20 status
Port Name Status Vlan Duplex Speed Type
Fa0/20 link to databackup err-disabled 562 auto auto 10/100BaseTX
這條信息更加明確的表示了該端口處於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 loopback
是啊，就這麼簡單的一條命令，就把困撓我們很長時間的問題解決了，真的就這麼神奇。那麼如何驗證這條命令是生效了呢？
拯救步驟3：顯示被置於錯誤狀態端口的恢復情況
Switch# show errdisable recovery
ErrDisable Reason Timer Status
----------------- --------------
udld Disabled
bpduguard Disabled
security-violatio Disabled
channel-misconfig Disabled
vmps Disabled
pagp-flap Disabled
dtp-flap Disabled
link-flap Disabled
gbic-invalid Disabled
l2ptguard Disabled
psecure-violation Disabled
gbic-invalid Disabled
dhcp-rate-limit Disabled
unicast-flood Disabled
loopback Enabled
Timer interval: 300 seconds
Interfaces that will be enabled at the next timeout:
Interface Errdisable reason Time left(sec)
--------- ----------------- --------------
Fa0/8 loopback 276
Fa0/17 loopback 267
Fa0/20 loopback 250
從以上顯示的信息可以看出，這臺交換機有三個端口（Fa0/8、Fa0/17、Fa0/20）會分別在276、267、250秒之後恢復爲正常的狀態，實際情況也是這樣，等了幾分鐘以後，我們找了一臺筆記本電腦，分別接到這幾個端口上試了一下，端口都可以正常工作了。這下總算在不重交換機的情況下，將幾個處於“假死”狀態的