交換機正在工作的埠,突然變成關閉狀態的假死現象,可以用重啟交換機來解決,但這並非長久之計,當「假死」現象蔓延的時候,我們不得尋找根治的辦法!
交換機埠假死 用「重啟」來應付
「假死」現象蔓延 不得不根治?
拯救步驟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 statusPortName StatusVlan DuplexSpeed TypeFa0/20link to databackup err-disabled 562auto auto10/100BaseTX |
這條信息更加明確的表示了該埠處於err-disabled狀態。
既然看到了該埠是被置於了錯誤的狀態了,我們就應該有辦法將其再恢復成正常的狀態。
拯救步驟2:將埠從錯誤狀態中恢復回來
進入交換機全局配置模式,執行errdisable recovery cause ?,會看到如下信息:
Switch(config)#errdisable recovery cause ?all Enable timer to recover from all causesbpduguard Enable timer to recover from BPDU Guard error disable statechannel-misconfig Enable timer to recover from channel misconfig disable statedhcp-rate-limit Enable timer to recover from dhcp-rate-limit error disable statedtp-flapEnable timer to recover from dtp-flap error disable stategbic-invalidEnable timer to recover from invalid GBIC error disable statel2ptguard Enable timer to recover from l2protocol-tunnel error disable statelink-flap Enable timer to recover from link-flap error disable stateloopbackEnable timer to recover from loopback detected disable statepagp-flap Enable timer to recover from pagp-flap error disable statepsecure-violation Enable timer to recover from psecure violation disable statesecurity-violationEnable timer to recover from 802.1x violation disable stateudldEnable timer to recover from udld error disable stateunicast-flood Enable timer to recover from unicast flood disable statevmpsEnable timer to recover from vmps shutdown error disable state |
從列出的選項中,我們可以看出,有非常多的原因會引起埠被置於錯誤狀態,由於我們明確的知道這臺交換機上的埠是由於環路問題而被置於錯誤狀態的,所以就可以直接鍵入命令:
Switch(config)#errdisable recovery cause loopback |
是啊,就這麼簡單的一條命令,就把困撓我們很長時間的問題解決了,真的就這麼神奇。那麼如何驗證這條命令是生效了呢?
拯救步驟3:顯示被置於錯誤狀態埠的恢復情況
Switch# show errdisable recoveryErrDisable ReasonTimer Status-------------------------------udld DisabledbpduguardDisabledsecurity-violatioDisabledchannel-misconfigDisabledvmps Disabledpagp-flapDisableddtp-flap Disabledlink-flapDisabledgbic-invalid Disabledl2ptguardDisabledpsecure-violationDisabledgbic-invalid Disableddhcp-rate-limitDisabledunicast-floodDisabledloopback EnabledTimer interval: 300 secondsInterfaces that will be enabled at the next timeout:InterfaceErrdisable reasonTime left(sec)----------------------------------------Fa0/8loopback276Fa0/17 loopback267Fa0/20 loopback250 |
從以上顯示的信息可以看出,這臺交換機有三個埠(Fa0/8、Fa0/17、Fa0/20)會分別在276、267、250秒之後恢復為正常的狀態,實際情況也是這樣,等了幾分鐘以後,我們找了一臺筆記本電腦,分別接到這幾個埠上試了一下,埠都可以正常工作了。這下總算在不重交換機的情況下,將幾個處於「假死」狀態的埠「拯救」了回來。
作為一名網絡管理員,除了日常網絡故障的處理外,還會不時碰到自己知識範圍以外的東西,但只要引起足夠的重視,總會找到解決問題的辦法。如果您在工作中也遇到交換機埠「假死」的情況,不妨用這個辦法試一下。
【相關文章】
【責任編輯:
王健楠TEL:(010)68476606】