過節不求人 Cisco路由器故障診斷技術詳解

最新 02-04

過年過節也是網路管理員、工程師最忙的時候，偏偏在這種時候，網路設備不聽話，動不動就故障。小編搜羅了一些Cisco路由器故障診斷技術，包括常用命令的使用，以及如何根據錯誤消息查找故障，希望在您的網路環境出現故障時，及時定位故障並解決故障...

1 引言

本文以CISCO路由式網路為基礎，介紹使用診斷工具對Cisco路由器進行故障診斷的方法。限於篇幅，我們所介紹的內容和示例主要是基於IP報文的，基於IPX和Appletalk等協議的診斷技術與此類似。

2 故障診斷與排除命令

Cisco ISO操作系統軟體提供了一組功能豐富的命令，可以用來進行故障查找與排除、問題診斷以及性能檢測。命令大致可以分為兩類：show命令和debug命令。同時，還包含一組用於連接這兩類命令的clear命令。下面我們分別講解各命令

2.1 show命令

在這一節中，我們將講述最常用的show命令，闡述這些命令的輸出以及這些命令適用於解決的故障類型。為了敘述清楚，這些命令被分為全局系統命令、與介面相關的命令和與協議相關的命令。我們僅討論最常使用的命令。

全局系統命令

本節將列出與路由器軟體和硬體相關的輸出命令，其中包括存儲區和電源。show version命令是最基本的命令之一，它顯示路由器本身以及其所使用的軟、硬體的基本信息。show hardware命令的功能與show version命令類似。

命令的輸出信息包括：IOS的版本、路由器持續運行的時間約23周、最近一次重啟動的原因、路由器主存的大小、共享存儲器的大小、快閃記憶體的大小、IOS映像的文件名，以及路由器從何處啟動等信息。show version命令顯示了路由器的許多非常有用的信息。在解決問題時，通常應該從這個命令開始收集數據。

如果路由器的多個介面同時丟失報文，則可能由於路由器內存不足或者CPU過載。用戶可以使用show memory命令檢查內存利用率(如下所示)。CPU利用率可以使用show process命令檢查。

show memory的前兩行顯示了存儲器的一般信息，它表明系統有足夠可用的內存。同時它還顯示內存中沒有碎片，因為在13.03兆位元組可用內存中最大的可用塊接近11.25兆位元組。內存碎片表明內存被劃分為了許多不連續的塊。它將導致內存的利用率降低，嚴重時可能產生內存錯誤從而也嚴重影響路由器的性能。

現在看一看路由器中有許多內存碎片的情形(如下所示)。此時我們有足夠多的可用內存(8.4兆位元組)，但是其中最大的塊僅為0.5兆位元組。連續內存中沒有足夠大的可用塊，這有可能導致嚴重的內存分配問題。這些問題有時表現為一個或多個介面間歇性的丟失報文。此時路由器產生內存碎片錯誤消息。

使用命令show memory free，用戶可以看到可用內存被劃分為許多很小的碎片。需要注意的是，路由器中存在一定數量的內存碎片是正常的。雖然並沒有一個很嚴格的界限來劃分內存碎片的可接受程度，但是可用塊的大小至少應該不小於可用內存的一半。用戶可以通過重新啟動路由器來解決這個問題。在重新啟動時，系統重新分配內存和緩存空間。此時，用戶應該監視內存分配的過程。如果再次發生類似的情況，則應該諮詢Cisco TAC。

用戶可以使用show process cpu命令檢查路由器的CPU是否過載。該命令將給出路由器CPU的利用率，同時顯示路由器中不同進程的CPU佔用率。在下述示例中，路由器的CPU工作正常。在通常情況下，在5分鐘內CPU的平均利用率小於60%是可以接受的。如果懷疑CPU利用率出現了問題，則需要不斷地監視這一參數，因為它可能在短時間內發生變化。最好每10秒鐘使用一次該命令。通過這種方法，可以清楚地了解CPU利用率的波動情況。

如果CPU的平均利用率超過了80%，則表明路由器過載。下一步需要檢測那一些進程導致了CPU利用率過高。在上面的顯示中，我們可以看到進程IPX SAP佔用了絕大部分的CPU處理能力，但是它還在可以接受的範圍之內。有時候，如果SRB background參數持續過高，則表明發生了路由網橋風暴。

show process memory命令可以用來給出路由器可用內存的一般信息，然後顯示每一個進程所佔用的內存空間的詳細信息。

如果路由器由於臨時重啟動而完全崩潰，則相應的錯誤消息將包含在show version命令的輸出中。show stack命令用於跟蹤路由器的堆棧，提供路由器臨時重新啟動的原因。如果由於錯誤而導致重新啟動，堆棧記錄將在輸出的末尾顯示。為了抽取與故障相關的信息，堆棧記錄需要解碼。這一工作通常由Cisco TAC工程師完成。此外，擁有相應CCO登錄ID的用戶可以通過將show stack命令的輸出發送到CCO而獲得解碼信息。堆棧記錄解碼的結果有時與Cisco路由器的bug有關。

當用戶向Cisco TAC報告故障時，支持技術人員通常要求用戶發送show tech_support命令的輸出結果。這個命令將導致下述命令的按序執行：Show version、Show controllers、Show buffers、Show interface、Show stack、Show process cpu、Show process memory和Show running-config。這些命令的組合將給出路由器配置以及大多數關鍵性能參數的詳細信息。show tech_support命令的輸出對於Cisco TAC技術人員解決複雜網路問題是十分有用。

與介面相關的命令

下面我們將闡述一些直接與路由器活躍介面相關的命令。show ip interface brief將顯示每一個路由器介面的IP地址信息以及第二層的狀態信息(如下所示)。其他與IP對應的協議的相關性信息可以通過相應命令屬性獲得，比如show ipx interface brief。

show interface命令可以獲得更多的信息。我們以乙太網為例來討論這些通用介面參數。

其中：

Ethernet 1/0 is up 表明OSI模型的第一層成功啟動。

Line protocol up 表明第二層成功啟動。

Description 用戶自定義的描述。使用這一功能給出介面準確的描述是十分重要的。在一個大型組織中，一個局部網路的工程師很難定位發生故障的路由器。

MTU 指定最大傳輸單元，用戶可以配置。

BW、Dly、rely、load(帶寬、延遲、可靠性和負載)：這些參數與IGRP/EIGRP標準有關。帶寬和延遲的配置可以影響到路由選擇。在工作正常的介面中，可靠性的值為255。除非在十分繁忙的條件下，否則負載通常不應超過150/255。

Encapsulation 它指在介面的第二層封裝。在乙太網中，對於IP，Cisco的預設設置為ARPA，而IPX的預設設置為Novell-Ether。

從輸出中還能獲取哪些其他的信息呢?讀者可以看到，ARP cache timeout的值為4小時(該值為預設設置)。從路由器介面輸入到輸出的時間不到1秒鐘。輸出從未被掛起。介面計數器最後一次被清0是在5個星期以前。在評估介面的統計信息時，這些數據是十分有用的。在通常情況下，可以將計數器清0以便作進一步的監視。

介面所採用的是FIFO排隊規則。輸出隊列和輸入隊列的預設長度分別為40和75。隊列中都不包含報文。在計數器最後一次被清0後，輸入隊列丟失了許多報文。但是，正如我們前面所說的，計數器5個星期未被清0;因此，該值不能說明一定發生了網路故障。在這種情況下，應該首先將計數器清0，然後再監視輸出隊列的丟失報文數。

同時，命令的輸出中還顯示每1秒鐘通過路由器介面的平均信息量(以位元組為單位)以及報文數。這些參數的總量信息、路由器介面觀測到的所有廣播報文的數量也在命令的輸出中顯示。如果廣播報文的數量增長非常迅速，尤其是如果相對於輸入報文的數量非常高，則表明在區域網段中有廣播風暴。由於某些特定的應用程序需要頻繁使用廣播報文，因此確定廣播報文的數量閥值是很困難的。但是，如果廣播報文的數量超過了整個輸入報文的30%，則需要使用區域網協議分析儀進一步檢測網路。

我們還可以獲取介面的下列錯誤檢測信息：

Runts 是指大小小於最小值的報文。在示例的乙太網中，該值為64。乙太網中指定最小報文大小大小是由於在這種傳輸模式下的工作站需要檢測碰撞。如果乙太網段中包含乙太網中繼器並且其距離符合規定的標準，最小報文大小大小可以使處在這種傳輸模式下的工作站檢測線路中的任何碰撞。

Giants 指大小超過線路可以承受的最大報文大小的報文。乙太網的MTU通常為1500位元組，或者最大的封裝數據為1500位元組。

Input errors 指到達報文中檢測到的錯誤，也可能表明網段本身發生了錯誤。

Output errors 指輸出報文中的錯誤，它可能表明路由器介面本身發生了故障。

CRCs 由於報文不正確的乙太網校驗和而檢測到的循環冗餘校驗錯。它可能由於網段的雜訊引起，或者由於網卡故障、報文衝突引發。CRC的頻率應是每100000個輸入報文中發生一次。

Frame errors 指接收到的幀的類型與路由器乙太網幀類型(IP協議幀類型為ARPA)不匹配。

Aborts 在碰撞檢測中過度的重傳而導致的問題。在乙太網中，重傳的最大次數不超過15次。

Dribble condition 指接收到的幀比MTU大，但不屬於Giants。

Babble 是指持續接收到可疑的幀。

Deferred 如果線路繁忙，報文在傳輸時將被延緩發送。

Interface resets 在檢測到過多的錯誤時，路由器將重置介面。這些錯誤可能存在於區域網段中，也可能是介面本身的錯誤。在此不能夠判斷具體是那兒發生故障，但是，如果伴隨著大量的輸出錯誤，則表明路由器介面本身發生故障。

Collisions 在乙太網中，衝突被分為兩大類：early和late。early collision 由發送方在幀的前64個位元組進入線路之前檢測到的衝突。early collision是乙太網CSMA/CD訪問方法中的組成部分。early collision通常導致小的被中斷的幀或稱為runt。Late collision發生在幀的多個位元組(大於64)被發送到線路中時產生的衝突。在理論上，乙太網不會產生此類衝突。產生late collision的原因包括：

1、電纜違反了距離規則。

2、發生故障的NIC卡不正確地監聽線路。

Lost carrier 表明在計數器最後一次清0後，載波和線路協議發生的故障。此類故障通常與路由器無關。例如，載波丟失可能是因為路由器與集線器之間的電纜連接中斷。

Buffer parameters show interface命令還提供與緩衝區分配有關的故障信息，它包括no buffer、overruns、ignored、underruns、buffer failures和swapped out buffers等。

上面，我們詳細討論了show interface命令的用法。這些命令的輸出提供了與路由器介面相關以及與傳輸介質相關的參數等有價值的信息。

show controller命令提供連接到路由器介面物理線路以及傳輸介質的詳細信息。並且提供狀態的歷史信息。其中一些詳細信息很少被使用，它們一般僅被TAC技術人員用於解決十分複雜的問題。

與協議相關的命令

本節將討論如何使用與不同協議相關的顯示命令。

show protocol命令給出了路由器運行的協議信息以及路由這些協議的每一個介面的地址信息(如下所示)。