CISCO3550交換機端口“假死” 如何起死回生?

 

 
 
交換機正在工作的端口,突然變成關閉狀態的假死現象,可以用重啓交換機來解決,但這並非長久之計,當“假死”現象蔓延的時候,我們不得尋找根治的辦法!

  交換機端口假死 用“重啓”來應付

拯救步驟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秒之後恢復爲正常的狀態,實際情況也是這樣,等了幾分鐘以後,我們找了一臺筆記本電腦,分別接到這幾個端口上試了一下,端口都可以正常工作了。這下總算在不重交換機的情況下,將幾個處於“假死”狀態的端口“拯救”了回來。

  作爲一名網絡管理員,除了日常網絡故障的處理外,還會不時碰到自己知識範圍以外的東西,但只要引起足夠的重視,總會找到解決問題的辦法。如果您在工作中也遇到交換機端口“假死”的情況,不妨用這個辦法試一下。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章