交換機頻繁中斷 禍起系統版本低下
交換機設備作為局域網中的一種很重要交通“樞紐”設備，它的工作狀態的好壞直接決定著整個局域網的運行穩定性。一般來說，在自身質量比較過硬的情況下，交換機設備是很少容易出現故障現象的;當然，這并不能說明交換機設備能一直穩定地工作，伴隨著其“服役”時間的推移，交換機的工作穩定性也會不斷下降，這除了是其內部的元氣件性能不斷老化造成的外，還有可能是交換機系統的版本低下引起的。這不，筆者曾經遭遇到的一則交換機頻繁中斷故障現象，就是由于交換機系統版本低下引起的!考慮到由這種因素引起的網絡故障現象發生機率不是非常高，解決起來可能會走一些彎路，為此本文現在就將該故障的具體解決過程還原出來，供各位朋友借鑒參考!
故障現象
最近一段時間，單位局域網中的某一匯聚層交換機頻繁發生網絡中斷故障現象;每次發生這種故障現象時，筆者都需要趕到故障現場，采用手工斷開電源的辦法進行重新啟動交換機設備，或者遠程登錄到故障交換機上聯的核心設備，將連接交換機的那個下行端口重新啟動一次，才能將網絡故障恢復正常。目標故障交換機平時連接兩個虛擬工作子網，這兩個工作子網日常的網絡傳輸流量并不是很大，即使不在上班訪問高峰期，該故障交換機也會莫名其妙地發生中斷現象，因此筆者基本排除了網絡流量過大造成故障交換機不能正常工作的因素，同時也排除了網絡病毒從中搗亂的可能。
故障排查
考慮到這臺故障交換機是通過寬帶光纖與上行核心設備保持連接的，于是筆者擔心該寬帶光纖線路的穩定性存在問題，于是特意請當地的電信技術人員使用專業工具對寬帶光纖線路進行了測試，經過多次測試，證明寬帶光纖線路的工作狀態是正常的。就在自己毫無頭緒的情況下，筆者偶然發現有一層厚厚的灰塵覆蓋在故障交換機的外殼上，這時筆者頭腦中才想到該故障交換機已經持續為單位“服役”了有將近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%左右，這說明升級之后的交換機運行性能還是十分穩定的。 #p#
故障總結
從上面的解決過程來看，我們不難發現交換機頻繁中斷的故障現象真的是由于其后臺管理系統的版本太低引起的，但是由于系統版本太低這個因素不常出現，所以很多網絡管理員在實際解決故障的過程中很少會注意到這個因素，這樣一來故障解決起來自然就容易走彎路了。事實上，我們可能會遭遇各式各樣的網絡故障，當我們在嘗試了很多辦法都無法成功解決目標故障現象時，不妨靜下心來多想想自己平時很少注意到的一些細節因素。
一般來說，我們只要掌握了合理的故障排除順序，完全能夠有效地提高交換機的故障排除效率：
首先按照由遠到近的線路連接順序進行排查，因為交換機存在的多數故障往往都是通過與其直接相連的工作站而發現的，所以我們在排查故障時盡可能地按照“終端工作站-連接線纜-端口模塊-網絡跳線-交換機”這樣的順序依次檢查。
按照上面的順序排查之后，如果確認交換機的確存在故障的話，那我們接著就要按照由外而內的順序來檢查交換機設備了。我們不妨先從交換機控制面板中的各種信號燈來辨別，并依照信號燈的故障指示，檢查交換機內部對應部件是否發生了故障。例如，交換機的Link信號燈要是處于熄滅狀態，那就表明對應端口沒有連接好或者該端口存在問題，要是Link信號燈處于綠色閃爍狀態，那就表示交換機當前處于100 Mb/s數據傳輸狀態，要是Link信號燈處于黃色閃爍狀態，那就說明交換機此刻正處于10 Mb/s數據傳輸狀態;要是交換機的Power信號燈處于綠色常亮狀態，那就表示交換機的電源供應一切正常，要是處于熄滅狀態就說明沒有電源供應。
當確認交換機內部存在故障時，我們肯定不會輕易地動手去拆卸交換機，因此在檢查內部故障時，我們應該先從系統程序或參數配置上著手來排查。要是參數配置或系統程序沒有問題的話，那幾乎就能斷定是硬件有問題了。比方說，某個端口不能正常使用時，那我們不妨先檢查一下指定工作站所連的端口是否在對應的VLAN中，或者檢查一下指定端口是否已經被其他的管理員關閉掉了等。
當然，在實際排查交換機故障的過程中，我們常常會遇到一些相當復雜的故障，此時我們盡量按照先易后難的順序，來從系統配置或簡單操作下手，來逐步分析、排查故障，相信這樣能夠提高故障的解決速度和故障排除效率。
【編輯推薦】
