Feed Facebook

A-A+

交換機頻繁中斷 禍起系統版本低下

交換機,故障現象,故障排查

交換機設備作為局域網中的一種很重要交通“樞紐”設備,它的工作狀態的好壞直接決定著整個局域網的執行穩定性。一般來說,在自身品質比較過硬的情況下,交換機設備是很少容易出現故障現象的;當然,這並不能說明交換機設備能一直穩定地工作,伴隨著其“服役”時間的推移,交換機的工作穩定性也會不斷下降,這除了是其內部的元氣件性能不斷老化造成的外,還有可能是交換機系統的版本低下引起的。這不,筆者曾經遭遇到的一則交換機頻繁中斷故障現象,就是由於交換機系統版本低下引起的!考慮到由這種因素引起的網路故障現象發生機率不是非常高,解決起來可能會走一些彎路,為此本文現在就將該故障的具體解決過程還原出來,供各位朋友借鑒參考!

故障現象

最近一段時間,單位局域網中的某一彙聚層交換機頻繁發生網路中斷故障現象;每次發生這種故障現象時,筆者都需要趕到故障現場,採用手工斷開電源的辦法進行重新啟動交換機設備,或者遠端登錄到故障交換機上聯的核心設備,將連接交換機的那個下行埠重新啟動一次,才能將網路故障恢復正常。目標故障交換機平時連接兩個虛擬工作子網,這兩個工作子網日常的網路傳輸流量並不是很大,即使不在上班訪問高峰期,該故障交換機也會莫名其妙地發生中斷現象,因此筆者基本排除了網路流量過大造成故障交換機不能正常工作的因素,同時也排除了網路病毒從中搗亂的可能。

故障排查

考慮到這台故障交換機是通過寬頻光纖與上行核心設備保持連接的,於是筆者擔心該寬頻光纖線路的穩定性存在問題,於是特意請當地的電信技術人員使用專業工具對寬頻光纖線路進行了測試,經過多次測試,證明寬頻光纖線路的工作狀態是正常的。就在自己毫無頭緒的情況下,筆者偶然發現有一層厚厚的灰塵覆蓋在故障交換機的外殼上,這時筆者頭腦中才想到該故障交換機已經持續為單位“服役”了有將近4年的時間了,並且該交換機的後臺管理系統版本也比較低,目前仍然還是沿用傳統的舊命令行,而且局域網曾經發生過的一則網路故障就與交換機系統的BUG有關,難道這一次頻繁發生的網路中斷故障也是由於交換機系統版本較低引起的?為了驗證自己的分析是否正確,筆者立即以telnet命令遠端登錄進故障交換機系統的後臺管理介面,在該介面的命令行提示符下執行“dis cpu”字串命令,發現該交換機的系統CPU資源始終處於95%以上的佔用率,這顯然是不正常的,因為在正常工作狀態下,交換機設備的CPU資源消耗率應該在50%以下,超過這個數值交換機的反應能力就會明顯下降;後來,筆者又執行了字串命令“dis ver”,從其後返回的結果資訊中筆者發現該故障交換機使用的VRP平臺軟體版本比較低,難道本文中提到的故障現象真的是由於交換機系統軟體版本較低引起的?


故障解決

考慮到連接交換機的物理線路經過詳細檢查是沒有任何問題的,而當交換機發生網路中斷故障現象時,筆者只是簡單地重新啟動一下故障交換機設備或對應的連接埠,故障交換機的工作狀態就能在短時間內恢復正常,這說明該故障現象的確與交換機自身有一定關係。為了排除交換機系統軟體版本較低的因素,筆者打算對該故障交換機的VRP平臺軟體進行一次線上升級,將其更新到最新版本狀態。

在對交換機系統進行線上升級時,筆者先查看了該故障交換機的具體型號,之後到對應品牌產品的官方網站中,下載得到最新版本的VRP升級檔以及 Bootrom升級檔;為了方便操作,筆者選用了FTP方式進行升級,也就是說將保存有VRP升級檔以及Bootrom升級檔的本地普通工作站作為 FTP伺服器,而將故障交換機作為FTP用戶端系統,這樣操作的好處就是步驟簡單,不需要對交換機設備進行任何複雜的設定操作;

下面從交換機系統中通過FTP命令連接到保存有VRP升級檔以及Bootrom升級檔的FTP伺服器上,從中下載得到升級包檔;當然,在下載升級包檔之前,筆者先對FTP伺服器進行了適當配置,讓其與故障交換機位於相同的工作子網中,確保交換機與FTP伺服器之間可以相互順利訪問;同時,筆者還直接將VRP升級檔以及Bootrom升級檔保存到FTP伺服器的主目錄下,這樣一來交換機系統通過FTP命令與FTP伺服器成功建立連接之後,就能直接查閱到需要的升級包檔;此外,為了方便記憶,筆者又將下載得到的VRP升級檔換名保存為aaa.bin,將Bootrom升級檔換名保存為bbb.btm。

在將升級檔aaa.bin、bbb.btm下載保存到交換機的Flash緩存中後,現在筆者就能正式開始交換機系統線上升級操作了。當然,為了穩妥起見,筆者對目標交換機的舊配置檔進行了備份操作,以防止升級過程中出現意外,而不能恢復交換機的工作狀態;備份好舊的配置檔後,筆者立即在交換機的後臺命令行模式狀態下,執行字串命令“boot aaa.bin”,在該命令被成功執行後,筆者又重新啟動了一次交換機系統,在啟動過程中交換機會自動調用aaa.bin檔,這麼一來交換機的VRP平臺軟體就能被成功升級到最新版本了,當然這個操作過程也可以通過遠端登錄的方式來完成;

接下來,我們需要通過Console連接到交換機,以便在本地完成Bootrom檔的升級操作,這是因為在更新了VRP平臺後,新平臺的部分配置命令與舊平臺有些不同,這時該交換機往往無法通過網路進行管理;按照同樣的操作方法,我們再執行字串命令“boot bbb.btm”,之後重新啟動交換機系統,如此一來交換機的升級操作就算成功了。這時,筆者再嘗試通過“dis ver”字串命令觀察交換機的系統版本狀態時,發現該系統果然已經被升級到最新版本了。

在確認交換機升級操作成功後,筆者又根據以前的舊配置,對交換機的上網參數進行了重新更新配置,並且將交換機的工作狀態恢復到正常;經過一段時間的實踐測試,筆者發現這台交換機之後再也沒有發生過網路中斷的故障現象,並且筆者經過不間斷的檢查,發現升級之後的交換機CPU消耗率始終為25%左右,這說明升級之後的交換機執行性能還是十分穩定的。

故障總結

從上面的解決過程來看,我們不難發現交換機頻繁中斷的故障現象真的是由於其後臺管理系統的版本太低引起的,但是由於系統版本太低這個因素不常出現,所以很多網路管理員在實際解決故障的過程中很少會注意到這個因素,這樣一來故障解決起來自然就容易走彎路了。事實上,我們可能會遭遇各式各樣的網路故障,當我們在嘗試了很多辦法都無法成功解決目標故障現象時,不妨靜下心來多想想自己平時很少注意到的一些細節因素。

一般來說,我們只要掌握了合理的故障排除順序,完全能夠有效地提高交換機的故障排除效率:

首先按照由遠到近的線路連接順序進行排查,因為交換機存在的多數故障往往都是通過與其直接相連的工作站而發現的,所以我們在排查故障時盡可能地按照“終端工作站-連接線纜-埠模組-網路跳線-交換機”這樣的順序依次檢查。

按照上面的順序排查之後,如果確認交換機的確存在故障的話,那我們接著就要按照由外而內的順序來檢查交換機設備了。我們不妨先從交換機控制面板中的各種信號燈來辨別,並依照信號燈的故障指示,檢查交換機內部對應部件是否發生了故障。例如,交換機的Link信號燈要是處於熄滅狀態,那就表明對應埠沒有連接好或者該埠存在問題,要是Link信號燈處於綠色閃爍狀態,那就表示交換機當前處於100 Mb/s資料傳輸狀態,要是Link信號燈處於黃色閃爍狀態,那就說明交換機此刻正處於10 Mb/s資料傳輸狀態;要是交換機的Power信號燈處於綠色常亮狀態,那就表示交換機的電源供應一切正常,要是處於熄滅狀態就說明沒有電源供應。

當確認交換機內部存在故障時,我們肯定不會輕易地動手去拆卸交換機,因此在檢查內部故障時,我們應該先從系統程式或參數配置上著手來排查。要是參數配置或系統程式沒有問題的話,那幾乎就能斷定是硬體有問題了。比方說,某個埠不能正常使用時,那我們不妨先檢查一下指定工作站所連的埠是否在對應的VLAN 中,或者檢查一下指定埠是否已經被其他的管理員關閉掉了等。

當然,在實際排查交換機故障的過程中,我們常常會遇到一些相當複雜的故障,此時我們儘量按照先易後難的順序,來從系統配置或簡單操作下手,來逐步分析、排查故障,相信這樣能夠提高故障的解決速度和故障排除效率。

標籤:

給我留言