網(wǎng)絡(luò)故障處理概述

網(wǎng)絡(luò)設(shè)備故障排除華為技術(shù)1內(nèi)容提要網(wǎng)絡(luò)故障處理技術(shù)概述一般網(wǎng)絡(luò)故障的解決步驟Quidway中低端路由器產(chǎn)品介紹路由器常用診斷工具介紹故障處理常用方法故障處理對網(wǎng)絡(luò)維護和管理人員的要求華為技術(shù)2網(wǎng)絡(luò)故障處理技術(shù)概述當今的網(wǎng)絡(luò)互連環(huán)境是復雜的，而且其復雜性的還在日益增長，主要原因如下：現(xiàn)代的因特網(wǎng)絡(luò)要求支持更廣泛的應(yīng)用，包括數(shù)據(jù)、語音、視頻及它們的集成傳輸；新業(yè)務(wù)開展使網(wǎng)絡(luò)帶寬的需求不斷增長，這就要求新技術(shù)的不斷出現(xiàn)。例如：十兆以太網(wǎng)向百兆、千兆以太網(wǎng)的演進；MPLS技術(shù)的出現(xiàn)；提供QoS能力等。新技術(shù)的應(yīng)用同時還要兼顧傳統(tǒng)的技術(shù)。例如，傳統(tǒng)的SNA體系結(jié)構(gòu)仍在某些場合使用，DLSw作為通過TCP/IP承載SNA的一種技術(shù)而被應(yīng)用。華為技術(shù)3網(wǎng)絡(luò)故障處理技術(shù)概述能夠正確地維護網(wǎng)絡(luò)盡量不出現(xiàn)故障，并確保出現(xiàn)故障之后能夠迅速、準確地定位問題并排除故障，對網(wǎng)絡(luò)維護和管理人員來說是個挑戰(zhàn)。這不但要求對網(wǎng)絡(luò)協(xié)議和技術(shù)有著深入的理解，更重要的是要建立一個系統(tǒng)化的故障處理思想并合理應(yīng)用于實際中，以將一個復雜的問題隔離、分解或縮減排錯范圍，從而及時修復網(wǎng)絡(luò)故障。華為技術(shù)4網(wǎng)絡(luò)故障的一般分類連通性問題硬件、媒介、電源故障配置錯誤不正確的相互作用性能問題網(wǎng)絡(luò)擁塞到目的地不是最正確路由供電缺乏路由環(huán)路網(wǎng)絡(luò)錯誤華為技術(shù)5一般網(wǎng)絡(luò)故障的解決步驟故障處理系統(tǒng)化是合理地一步一步找出故障原因并解決的總體原那么。它的根本思想是系統(tǒng)地將由故障可能的原因所構(gòu)成的一個大集合縮減〔或隔離〕成幾個小的子集，從而使問題的復雜度迅速下降。華為技術(shù)6網(wǎng)絡(luò)故障解決的處理流程華為技術(shù)7網(wǎng)絡(luò)故障解決的處理流程該處理流程是網(wǎng)絡(luò)維護人員所能夠采用的排錯模型中的一種，如果你根據(jù)自己的經(jīng)驗和實踐總結(jié)了另外的排錯模型并證明是行之有效的，請繼續(xù)使用它——網(wǎng)絡(luò)故障解決的處理流程是可以變化的，但故障處理有序化的思維模式是不可變化的。下面我們以一個故障處理的實例來學習如何應(yīng)用這些步驟。華為技術(shù)8故障處理的實例該案例組網(wǎng)如上：某校園網(wǎng)的三個局域網(wǎng)，其中為一個用戶網(wǎng)段，為一個日志效勞器；是一個集中了很多應(yīng)用效勞器的網(wǎng)段。用戶網(wǎng)段播送包過多造成該網(wǎng)段的效勞器FTP業(yè)務(wù)傳輸速度慢

網(wǎng)云ETHERNETETHERNETETHERNET華為技術(shù)91.故障現(xiàn)象描述要想對網(wǎng)絡(luò)故障做出準確的分析，首先應(yīng)該了解故障表現(xiàn)出來的各種現(xiàn)象用戶反映“日志效勞器與備份效勞器間備份發(fā)生問題。〞這就是一個不完整不清晰的故障現(xiàn)象描述。因為這個描述沒有講述清楚以下問題：這個問題是連續(xù)出現(xiàn)，還是間斷出現(xiàn)的？是完全不能備份，還是備份的速度慢〔即性能下降〕？哪個或哪些局域網(wǎng)效勞器受到影響，地址是什么？正確的故障現(xiàn)象描述是：在網(wǎng)絡(luò)的頂峰期，日志效勞器到集中備份效勞器之間進行備份時，F(xiàn)TP傳輸速度很慢，大約是0.6Mbps。華為技術(shù)102.相關(guān)信息收集搜集有助于查找故障原因的詳細信息：向受影響的用戶、網(wǎng)絡(luò)人員或其他關(guān)鍵人員提出問題；根據(jù)故障描述性質(zhì)，使用各種工具搜集情況，如網(wǎng)絡(luò)管理系統(tǒng)、協(xié)議分析儀、相關(guān)display和debug命令等；測試性能與網(wǎng)絡(luò)正常情況下的記錄進行比較。如上述案例，可以向用戶提問或自行收集以下相關(guān)信息：網(wǎng)絡(luò)結(jié)構(gòu)或配置是否最近修改正，即問題出現(xiàn)是否與網(wǎng)絡(luò)變化有關(guān)？是否有用戶訪問受影響的效勞器時沒有問題？在非頂峰期日志效勞器和備份效勞器間FTP傳輸速度是多少？通過該步驟，我們收集到了下面一些相關(guān)信息：最近網(wǎng)段的客戶機不斷在增加；網(wǎng)段的機器與備份效勞器間進行FTP傳輸時速度正常為7Mbps，與日志效勞器間進行FTP傳輸時速度慢，只有0.6Mbps；在非頂峰期日志效勞器和備份效勞器間FTP傳輸速度正常，大約為6Mbps；華為技術(shù)113.經(jīng)驗判斷和理論分析利用前兩個步驟收集到的數(shù)據(jù)，并根據(jù)自己以往的故障處理經(jīng)驗和所掌握的的知識，確定一個排錯范圍。通過范圍的劃分，就只需注意某一故障或與故障情況相關(guān)的那一局部產(chǎn)品、介質(zhì)和主機。如上述案例，我們現(xiàn)在能夠確定是一個網(wǎng)絡(luò)性能下降問題。那么，是網(wǎng)段的性能問題？是中間網(wǎng)絡(luò)的性能問題？還是網(wǎng)段的性能問題呢？根據(jù)網(wǎng)段的機器與備份效勞器間進行FTP傳輸時速度正常為7Mbps這一事實，我們可以排除掉網(wǎng)段的性能問題。華為技術(shù)124.各種可能原因列表該步驟列出根據(jù)經(jīng)驗判斷和理論分析后總結(jié)的各種可能原因。如上述案例，可能原因如下：網(wǎng)段的性能問題，其原因可能為：日志效勞器A的性能問題網(wǎng)絡(luò)的網(wǎng)關(guān)性能問題網(wǎng)絡(luò)本身的性能問題中間網(wǎng)絡(luò)性能問題，主要是到網(wǎng)絡(luò)的路由不是最正確路由華為技術(shù)135.對每一原因?qū)嵤┡佩e方案根據(jù)所列出的可能原因制定故障排查方案，分析最有可能的原因，確定一次只對一個變量進行操作，這種方法使你能夠重現(xiàn)某一故障的解決方法。如果有多個變量同時被改變，而問題得以解決，那么如何判斷哪個變量導致了故障發(fā)生呢？華為技術(shù)146.觀察故障排查結(jié)果當我們對某一原因執(zhí)行了排錯方案后，需要對結(jié)果進行分析，判斷問題是否解決，是否引入了新的問題。如果問題解決，那么就可以直接進入文檔化過程；如果沒有解決問題，那么就需要再次循環(huán)進行到故障排查過程。華為技術(shù)157.循環(huán)進行故障排查過程在進行下一循環(huán)之前必須做的事情就是將網(wǎng)絡(luò)恢復到實施上一方案前的狀態(tài)。如果保存上一方案對網(wǎng)絡(luò)的改動，很可能導致新的問題。循環(huán)排錯可以有兩個切入點：當針對某一可能原因的排錯方案沒有到達預期目的，循環(huán)進入下一可能原因制定排錯方案并實施；當所有可能原因列表的排錯方案均沒有到達排錯目的，重現(xiàn)進行故障相關(guān)信息收集以分析新的可能原因。如上述案例，我們在列出了可能原因列表后，開始制定方案進行故障處理：華為技術(shù)167.循環(huán)進行故障排查過程可能原因1：網(wǎng)絡(luò)到網(wǎng)絡(luò)的路由不是最正確路由。制定的方案：在網(wǎng)段的網(wǎng)關(guān)上使用“tracert53〞命令，發(fā)現(xiàn)探測報文返回時長僅為10ms，說明該可能原因并不是造成故障的原因。我們進入循環(huán)排錯過程。華為技術(shù)177.循環(huán)進行故障排查過程可能原因2：日志效勞器A的性能問題。制定的方案：測試同一網(wǎng)段的主機C和日志效勞器間的FTP傳輸速度，是6Mbps，正常?？梢妴栴}與效勞器A無關(guān)。華為技術(shù)187.循環(huán)進行故障排查過程可能原因3：網(wǎng)絡(luò)的網(wǎng)關(guān)性能問題。制定的方案：測試主機C和備份效勞器B間FTP傳輸速度是7Mbps，正常。排除了網(wǎng)關(guān)因素，因為B、C在不同網(wǎng)段上而速度正常。華為技術(shù)197.循環(huán)進行故障排查過程可能原因4：網(wǎng)絡(luò)本身的性能問題。制定的方案：在網(wǎng)段的以太網(wǎng)交換機上使用命令“showmac〞，輸出如下：PortRcv-UnicastRcv-MulticastRcv-Broadcast----------------------------------------------------------------6/321031781208665PortXmit-UnicastXmit-MulticastXmit-Broadcast----------------------------------------------------------------6/3266679872866522474038(輸出的播送：輸出的單播比例為1：3，太大了。)PortRcv-OctetXmit-Octet---------------------------------------------------------------在網(wǎng)段上的以太網(wǎng)交換機上使用命令“showmac〞輸出如下：PortRcv-UnicastRcv-MulticastRcv-Broadcast-------------------------------------------------------------6/36557802870285PortXmit-UnicastXmit-MulticastXmit-Broadcast--------------------------------------------------------------6/3627879749190257119430〔播送：單播比例＝1：270，屬于正常。〕PortRcv-OctetXmit-Octet---------------------------------------------------------------6/36671725870814998816809由此得知，網(wǎng)段上播送包和單播包比例為1:3，確實太大了。再次詢問用戶該網(wǎng)段主要運行的業(yè)務(wù)是什么，而得出了故障最終原因如下：是普通用戶網(wǎng)段，由于業(yè)務(wù)原因每個用戶需要發(fā)送大量播送包和多播包，隨著近期越來越多的用戶接入該網(wǎng)絡(luò)，在這個網(wǎng)段上的效勞器需要花費更多的資源來處理越來越多的播送和多播包，因此其效勞的傳輸速度自然減慢。這是一個網(wǎng)絡(luò)布局不恰當?shù)膯栴}，需要重新安排效勞器的位置，將效勞器移動網(wǎng)段后，故障解決。華為技術(shù)208.故障處理過程文檔化當最終排除了網(wǎng)絡(luò)故障后，流程的最后一步就是對所做的工作進行文字記錄。文檔化過程決不是一個可有可無的工作，原因如下：文檔是排錯珍貴經(jīng)驗的總結(jié)，是“經(jīng)驗判斷和理論分析〞這一過程中最重要的參考資料；文檔記錄了這次排錯中網(wǎng)絡(luò)參數(shù)所做的修改，這也是下一次網(wǎng)絡(luò)故障應(yīng)收集的相關(guān)信息。文檔記錄主要包括以下幾個方面：故障現(xiàn)象描述及收集的相關(guān)信息網(wǎng)絡(luò)拓撲圖繪制網(wǎng)絡(luò)中使用的設(shè)備清單和介質(zhì)清單網(wǎng)絡(luò)中使用的協(xié)議清單和應(yīng)用清單故障發(fā)生的可能原因?qū)γ恳豢赡茉蛑贫ǖ姆桨负蛯嵤┙Y(jié)果本次排錯的心得體會其他：如排錯中使用的參考資料列表等華為技術(shù)21路由器常用診斷工具介紹ping命令tracert命令display命令reset命令debug命令華為技術(shù)22PING命令命令ping用于檢查IP網(wǎng)絡(luò)連接及主機是否可達?！皃ing〞這個詞源于聲納定位操作，指來自聲納設(shè)備的脈沖信號。ping命令的思想與發(fā)出一個短促的雷達波，通過收集回波來判斷目標很相似；即源站點向目的站點發(fā)出一個ICMPEchoRequest報文，目的站點收到該報文后回一個ICMPEchoReply報文，這樣就驗證了兩個節(jié)點間IP層的可達性－－表示了網(wǎng)絡(luò)層是連通的。由于ping和tracert命令不僅是Quidway系列路由器VRP平臺的常用網(wǎng)絡(luò)命令，也是windows平臺上常用的網(wǎng)絡(luò)命令，下面對兩種平臺下的命令使用均進行介紹。華為技術(shù)23PING命令在Quidway系列路由器上，ping命令的格式如下：ping[-Rdnqrv][-ccount][-ppattern][-spacketsize][-ttimeout]host-aping報文中使用的源IP地址-cping報文的個數(shù)，缺省值為5；-t設(shè)置ping報文的超時時間，單位為毫秒，缺省值為2000；-s設(shè)置ping報文的大小，以字節(jié)為單位，缺省值為56。華為技術(shù)24PING命令在PC機上或WindwosNT為平臺的效勞器上，ping命令的格式如下：ping[-nnumber][-t][-lnumber]ip-address-nping報文的個數(shù)，缺省值為5；-t持續(xù)地ping直到人為地中斷，Ctr+Breack暫時中止ping命令并查看當前的統(tǒng)計結(jié)果，而Ctr+C那么中斷命令的執(zhí)行。-l設(shè)置ping報文所攜帶的數(shù)據(jù)局部的字節(jié)數(shù)，設(shè)置范圍從0至65500。華為技術(shù)25用ping命令進行故障處理

案例一連通性問題還是性能問題？

工程師小L，在配置完一臺路由器之后執(zhí)行ping命令檢測鏈路是否通暢。發(fā)現(xiàn)5個報文都沒有ping通，小L斷定是連通性問題。檢查雙方的配置命令并查看路由表，卻一直沒有找到錯誤所在。最后又重復執(zhí)行了一遍相同的ping命令，發(fā)現(xiàn)這一次5個報文中有1個ping通了－－原來是線路質(zhì)量不好存在比較嚴重的丟包現(xiàn)象。華為技術(shù)26用ping命令進行故障處理

案例一連通性問題還是性能問題？工程師小L又配置了一臺路由器，然后執(zhí)行ping命令訪問Internet上某站點的IP地址，但沒有ping通。有了上次的教訓小L，再一次ping了20個報文，仍舊沒有響應(yīng)。于是這次小L覺得能夠斷定是連通性故障。在費力周折檢查了配置鏈路之后仍沒有發(fā)現(xiàn)任何可疑之處，最后小L采取逐段檢測的方法對鏈路中的網(wǎng)關(guān)進行逐級測試，發(fā)現(xiàn)都可以ping通，但是響應(yīng)的時間越來越長，最后一個網(wǎng)關(guān)的響應(yīng)時間在1800ms左右。會不會是由于超時而導致顯示為ping不同呢？受此啟發(fā)，小L將ping命令報文的超時時間改為4000ms，這次成功ping通了，顯示所有的報文響應(yīng)時間都在2200ms左右。華為技術(shù)27用ping命令進行故障處理

案例一連通性問題還是性能問題？建議和總結(jié)：真的是ping不通嗎？這個問題需要定位清楚，因為連通性問題和性能問題排錯的關(guān)注點是不一樣的――問題定位錯誤必然會導致排錯過程的周折。使用一般的ping命令，缺省是發(fā)送5個報文的，超時時長是2000ms。如果ping不通情況發(fā)生，最好能夠再用帶參數(shù)-c和-t的ping命令再執(zhí)行一遍，如：ping-c20-t4000ip-address，即連續(xù)發(fā)送20個報文，每個報文的超時時長為4000ms，這樣一般可以判斷出到底是連通性問題還是性能問題。華為技術(shù)28用ping命令進行故障處理

案例二使用大包ping對端進行MTU不一致的故障處理？某次開局，使用Quidway路由器與其他廠商的某路由器互連，并運行OSPF協(xié)議。數(shù)據(jù)配置完畢后，一切正常，并在今后相當長的時間內(nèi)設(shè)備運轉(zhuǎn)穩(wěn)定。但兩個月后，用戶反響網(wǎng)絡(luò)中斷。華為技術(shù)29用ping命令進行故障處理

案例二使用大包ping對端進行MTU不一致的故障處理？相關(guān)信息顯示：登錄到兩臺路由器上，發(fā)現(xiàn)雙方連接正常，可以相互ping通對端地址。但OSPF協(xié)議中斷；登錄Quidway路由器查看鄰居狀態(tài)，發(fā)現(xiàn)鄰居狀態(tài)機處于Exstart狀態(tài)。翻開相應(yīng)的debug開關(guān)查看相應(yīng)的報文信息，發(fā)現(xiàn)雙方都可以收到Hello報文，但Quidway路由器發(fā)送DD報文后，一直沒有收到對方回應(yīng)的DD報文；登錄其他廠商的那臺路由器，翻開相應(yīng)的debug開關(guān)，發(fā)現(xiàn)對方收到Quidway路由器發(fā)送的DD報文后，已發(fā)送了相應(yīng)的DD報文予以回應(yīng)。華為技術(shù)30用ping命令進行故障處理

案例二使用大包ping對端進行MTU不一致的故障處理？原因分析：初步斷定，Quidway路由器沒有收到DD回應(yīng)報文，但對方確實發(fā)出來了。既然可以接收到HELLO報文說明鏈路是通暢的，而且多播報文的收發(fā)也沒有問題。那么有可能是對方發(fā)送的DD報文有錯誤導致Quidway路由器拒收，但查看相應(yīng)的信息，并沒有報告接收到錯誤的DD報文。仔細查看某廠商路由器的調(diào)試信息發(fā)現(xiàn)這個DD報文很大有2000多字節(jié)。會不會是由于報文太大導致的問題呢？試著ping了一個2000字節(jié)的報文，結(jié)果不通。那么故障原因很可能是－－由于雙方的MTU不一致導致大包不通。華為技術(shù)31用ping命令進行故障處理

案例二使用大包ping對端進行MTU不一致的故障處理？處理過程：檢查配置，發(fā)現(xiàn)對方路由器的MTU設(shè)置為4000多而Quidway路由器的MTU設(shè)置為1500，于是修改對端路由器的MTU為1500。故障消除。那么為什么工程初期沒有問題呢？這是因為前期DD報文長度小于1500字節(jié)，而后來網(wǎng)絡(luò)擴容導致路由信息過多使DD報文的長度超過了1500字節(jié)。華為技術(shù)32用ping命令進行故障處理

案例二使用大包ping對端進行MTU不一致的故障處理？建議和總結(jié)：由于ping缺省報文是56個字節(jié)，所以顯示的ping通信息只是表示56字節(jié)的報文可以通而并不一定表示其他大小的報文仍舊可以通。所以，應(yīng)當善于使用ping的其他參數(shù)來進行故障處理。華為技術(shù)33用ping命令進行故障處理

案例三A能ping通B，B就一定能ping通A嗎？在RouterA上配置一條指向的靜態(tài)路由：

[Quidway]ip在RouterA上ping路由器RouterB的以太網(wǎng)地址，顯示可以正常ping通；但是在RouterB上ping路由器RouterA的以太網(wǎng)地址，卻無法ping通。

E0:/8E0:/8S0:/8S0:/8RouterARouterB華為技術(shù)34用ping命令進行故障處理

案例三A能ping通B，B就一定能ping通A嗎？原因分析：由于在RouterB上沒有相應(yīng)的配置到路由，所以在RouterB上ping不通RouterA的以太網(wǎng)口。但是為何在A上可以ping通呢？同樣是沒有回程路由。翻開路由器上的IP報文調(diào)試開關(guān)發(fā)現(xiàn)，原來從RouterA上發(fā)出的ICMP報文的源地址填寫的是而不是，由于兩臺路由器的s0口處于同一網(wǎng)段，所以響應(yīng)報文可以順利到達RouterB。華為技術(shù)35用ping命令進行故障處理

案例三A能ping通B，B就一定能ping通A嗎？建議和總結(jié)：A能夠ping通B那么B一定能夠ping通A〔不考慮防火墻的因素〕,這句話的對錯取決于A和B到底是指主機還是指路由器。如果是指兩臺主機，那么這句話就是正確的。如果是指兩臺路由器那就是錯誤的，因為路由器通常會有多個IP地址?，F(xiàn)在就有如下問題：當從一臺路由器上執(zhí)行ping命令它發(fā)出的ICMPEcho報文的源地址究竟選擇哪一個呢？實際情況是路由器選擇發(fā)出報文的接口的IP地址。華為技術(shù)36TRACERT命令tracert命令用于測試數(shù)據(jù)報文從發(fā)送主機到目的地所經(jīng)過的網(wǎng)關(guān)，主要用于檢查網(wǎng)絡(luò)連接是否可達，以及分析網(wǎng)絡(luò)什么地方發(fā)生了故障。tracert利用IP報文的TTL域在每經(jīng)過一個路由器的轉(zhuǎn)發(fā)后減一，當TTL=0時那么向源節(jié)點報告TTL超時這個的特性。tracert首先發(fā)送一個TTL為1的UDP報文，因此第一跳發(fā)送回一個ICMP錯誤消息以指明此數(shù)據(jù)報不能被發(fā)送〔因為TTL超時〕，之后tracert再發(fā)送一個TTL為2的報文，同樣第二跳返回TTL超時，這個過程不斷進行，直到到達目的地，此時由于數(shù)據(jù)報中使用了無效的端口號〔缺省為33434〕此時目的主時機返回一個ICMP的目的地不可達消息，說明該tracert操作結(jié)束。tracert記錄下每一個ICMPTTL超時消息的源地址，從而提供給用戶報文到達目的地所經(jīng)過的網(wǎng)關(guān)IP地址。華為技術(shù)37TRACERT命令在華為Quidway系列路由器上，tracert命令的格式如下：tracert[-aip-address][-f

first_TTL][-mmax_TTL][-pport][-q

nqueries][-w

timeout]host-a指定一個發(fā)送UDP報文的源地址；-f指定初始報文的TTL大小，缺省值為1；-m指定最大TTL大小，缺省值為30；-p目的主機的端口號，缺省值為33434；-q每次發(fā)送的探測報文的個數(shù)，缺省值為3；-w指明UDP報文的超時時間，單位為毫秒，缺省值為5000。華為技術(shù)38TRACERT命令在PC機上或WindwosNT為平臺的效勞器上，tracert命令的格式如下：tracert[-d][-hmaximum_hops][-jhost-list][-wtimeout]host-d不解析主機名；-h指定最大TTL大??；-j設(shè)定松散源地址路由列表；-w用于設(shè)置UDP報文的超時時間，單位毫秒；華為技術(shù)39使用tracert命令進行故障處理

案例一使用tracert命令定位不當?shù)木W(wǎng)絡(luò)配置點某校園網(wǎng)中，RouterB和RouterC同屬于一個運行RIPv2路由協(xié)議的網(wǎng)絡(luò)，主機訪問數(shù)據(jù)庫效勞器，用戶抱怨訪問性能差。網(wǎng)云RIP域RouterARouterBRouterC華為技術(shù)40使用tracert命令進行故障處理

案例一使用tracert命令定位不當?shù)木W(wǎng)絡(luò)配置點相關(guān)信息顯示登錄到RouterC，使用帶參數(shù)的ping遠端效勞器，顯示如下：[RouterC]PING:4000databytes,pressCTRL_CtobreakReplyfrom:bytes=4000Sequence=0ttl=249time=552msReplyfrom:bytes=4000Sequence=1ttl=249time=5733msReplyfrom:bytes=4000Sequence=2ttl=249time=552msReplyfrom:bytes=4000Sequence=3ttl=249time=5714msReplyfrom:bytes=4000Sequence=4ttl=249time=552msReplyfrom:bytes=4000Sequence=5ttl=249time=5711msReplyfrom:bytes=4000Sequence=6ttl=249time=552msReplyfrom:bytes=4000Sequence=7ttl=249time=5709msReplyfrom:bytes=4000Sequence=8ttl=249time=552msReplyfrom:bytes=4000Sequence=9ttl=249time=5710ms華為技術(shù)41使用tracert命令進行故障處理

案例一使用tracert命令定位不當?shù)木W(wǎng)絡(luò)配置點原因分析上面的ping顯示出一個規(guī)律：奇數(shù)報文的返回時長短，而偶數(shù)報文返回時長很長〔是奇數(shù)報文的10倍多〕?？梢猿醪脚袛嗥鏀?shù)報文和偶數(shù)報文是通過不同的路徑傳輸?shù)摹，F(xiàn)在我們需要使用tracert命令來追蹤這不同的路徑。在RouterC上，tracert遠端RouterA的以太網(wǎng)接口。[RouterC]tracerttracerouteto()30hopsmax,40bytespacket16ms4ms4ms4ms4ms4ms4ms4ms……520ms16ms15ms16ms16ms16ms16ms16ms630ms278ms25ms279ms25ms278ms25ms277msRouterC(config)# 從上面的顯示可看到，直至，UDP探測報文的返回時長都根本一致，而到時，那么發(fā)生明顯變化，呈現(xiàn)奇數(shù)報文時長短，偶數(shù)報文時長長的現(xiàn)象。于是判斷，問題發(fā)生在RouterB和RouterA之間。 華為技術(shù)42使用tracert命令進行故障處理

案例一使用tracert命令定位不當?shù)木W(wǎng)絡(luò)配置點原因分析通過詢問該段網(wǎng)絡(luò)的管理員，得知這兩路由器間有一主一備兩串行鏈路，主鏈路為2.048Mbps〔s0口之間〕，備份鏈路為128Kbps〔s1口之間〕。網(wǎng)絡(luò)管理員在此兩路由器間配置了靜態(tài)路由。RouterB上如下配置：[RouterB]ip[RouterB]ipRouterA上如下配置：[RouterA]ip[RouterA]ip于是問題就清楚了。例如RouterB，由于管理員配置時沒有給出靜態(tài)路由的優(yōu)先級，這兩條路由項的優(yōu)先級就同為缺省值60，于是就同時出現(xiàn)在路由表中，實現(xiàn)的是負載分擔，而不能到達主備的目的。

華為技術(shù)43使用tracert命令進行故障處理

案例一使用tracert命令定位不當?shù)木W(wǎng)絡(luò)配置點處理過程，可以有兩種處理方法：繼續(xù)使用靜態(tài)路由，進行配置更改RouterB上進行如下更改：[RouterB]iproute-static〔主鏈路仍使用缺省優(yōu)先級60〕[RouterB]iproute-static100〔備份鏈路的優(yōu)先級降低至100〕RouterA上進行如下更改：[RouterA]ip[RouterA]iproute-static100這樣，只有當主鏈路發(fā)生故障，備份鏈路的路由項才會出線在路由表中，從而接替主鏈路完成報文轉(zhuǎn)發(fā)，實現(xiàn)主備目的。在兩路由器上運行動態(tài)路由協(xié)議，如OSPF等，但不要運行RIP協(xié)議〔因為RIP協(xié)議僅以hop作為Metric的〕華為技術(shù)44使用tracert命令進行故障處理

案例一使用tracert命令定位不當?shù)木W(wǎng)絡(luò)配置點建議和總結(jié)本案例的目的不是為了解釋網(wǎng)絡(luò)配置問題，而是用來展示ping命令和tracert命令的相互配合來找到網(wǎng)絡(luò)問題的發(fā)生點。尤其在一個大的組網(wǎng)環(huán)境中，維護人員可能無法沿著路徑逐機排查，此時，能夠迅速定位出發(fā)生問題的線路或路由器就非常重要了。華為技術(shù)45使用tracert命令進行故障處理

案例二使用tracert命令發(fā)現(xiàn)路由環(huán)路三臺路由器均配置靜態(tài)路由，完成后，登錄到RouterA上ping主機，發(fā)現(xiàn)不通。RouterARouterBRouterC華為技術(shù)46使用tracert命令進行故障處理

案例二使用tracert命令發(fā)現(xiàn)路由環(huán)路相關(guān)信息顯示[RouterAPING:56databytes,pressCTRL_CtobreakRequesttimeoutRequesttimeoutRequesttimeoutRequesttimeoutRequesttimeoutRequesttimeout[RouterA]tracerttracerouteto()30hopsmax,40bytespacket16ms4ms4ms〔RouterB〕28ms8ms8ms〔RouterA〕312ms12ms12ms〔RouterB〕416ms16ms16ms〔RouterA〕……華為技術(shù)47使用tracert命令進行故障處理

案例二使用tracert命令發(fā)現(xiàn)路由環(huán)路原因分析從上面的tracert命令的顯示可以立即發(fā)現(xiàn)，在RouterA和RouterB間產(chǎn)生了路由環(huán)路。由于是配置的是靜態(tài)路由，根本可以斷定是RouterA或RouterB的靜態(tài)路由配置錯誤。檢查RouterA的路由表，配置的是缺省靜態(tài)路由：ip，沒有問題。檢查RouterB的路由表，配置到網(wǎng)絡(luò)的靜態(tài)路由為：iproute-static――下一跳配置的是，而不是。這正是錯誤所在。 華為技術(shù)48使用tracert命令進行故障處理

案例二使用tracert命令發(fā)現(xiàn)路由環(huán)路處理過程修改RouterB的配置如下：[RouterB]

noip[RouterB]

ip故障處理完成。華為技術(shù)49使用tracert命令進行故障處理

案例二使用tracert命令發(fā)現(xiàn)路由環(huán)路建議和總結(jié)tracert命令能夠很容易發(fā)現(xiàn)路由環(huán)路等潛在問題。當路由器A認為路由器B知道到達目的地的路徑，而路由器B也認為路由器A知道目的地時，就是路由環(huán)路發(fā)生了。使用ping命令只能知道接收端出現(xiàn)超時錯誤，而tracert能夠立即發(fā)現(xiàn)環(huán)路所在――如果tracert命令兩次或者屢次顯示同樣的接口。當通過tracert發(fā)現(xiàn)路由環(huán)路后，如果配置為：靜態(tài)路由：幾乎可以肯定是手工配置有問題。單動態(tài)路由協(xié)議：可能是地址聚合產(chǎn)生的問題。多動態(tài)路由協(xié)議：可能是路由引入產(chǎn)生的問題。華為技術(shù)50DISPLAY命令display命令是用于了解路由器的當前狀況、檢測相鄰路由器、從總體上監(jiān)控網(wǎng)絡(luò)、隔離因特網(wǎng)絡(luò)中故障的最重要的工具之一。幾乎在任何故障處理和監(jiān)控場合，display命令都是必不可少的。這里僅介紹局部最常用的、全局性的display命令，而與各協(xié)議相關(guān)的display命令，將在后面章節(jié)相應(yīng)的協(xié)議故障處理中詳細介紹。華為技術(shù)51DisplayVersion該命令將幫助用戶收集以下信息：VRP軟件版本是哪一系列的路由器設(shè)備運行時間處理器的信息RAM的容量配置存放器的設(shè)置固件的版本引導程序的版本不同型號的設(shè)備顯示的內(nèi)容可能會略有差異[Quidway]displayversionHuaweiVersatileRoutingPlatformSoftwareVRP(tm)software,Version1.44Release0006Copyright(c)1997-2002HUAWEITECHCO.,LTD.Compiled20:42:52,Jun122003,QuidwayR2511uptimeis0days7hours40minutes13seconds,SystemreturnedtoROMbypower-on.QuidwayR2511with168360ProcessorRouterserialnumberis00E0FC05D5C76A4016MbytesDRAM4608KbytesFlashMemoryhardwareversionis1.0華為技術(shù)52displaycurrent-configuration

與displaysaved-configurationDisplaycurrent-configuration用于查看當前的配置信息。Displaysaved-configuration用于顯示NVRAM或Flash中的路由器配置文件，即路由器下次上電啟動時所用的配置文件。Current-configuration是路由器目前正在運行的配置文件，當更改某一配置時，current-configuration會立即改變；如果不使用save命令將改變保存到啟動配置文件saved-configuration中，路由器重啟時該改動將喪失。因此請注意到修改運行配置并驗證正確后，應(yīng)當將之保存到啟動配置文件中。華為技術(shù)53displaycurrent-configuration

與displaysaved-configuration強烈建議網(wǎng)絡(luò)維護或管理人員保存一份啟動配置文件的拷貝存放到路由器以外的其他設(shè)備上。這有幾點好處：這將使維護人員能夠迅速配置一個替代的路由器；這個保存在外部的文本文件也可以按上述規(guī)定的格式脫機編輯然后使用Downloadconfig命令加載到路由器上；可以將該配置文件通過E-mail形式發(fā)給華為技術(shù)支持人員以幫助定位配置問題。華為技術(shù)54Displayinterfacesdisplayinterfaces命令可以顯示所有接口的當前狀態(tài)，如果只是想查看特定接口的狀態(tài)，請在該命令后輸入接口類型和接口號，例如：displayinterfacesserial0命令將查看串口0的運行狀態(tài)和相關(guān)信息。[Quidway]displayinterfacesserial0Serial0isdown,lineprotocolisdownphysicallayerissynchronous,baudrateis64000bpsinterfaceisDCE,clockisDCECLK,cabletypeisV35MaximumTransmissionUnitis1500Link-protocolisPPPLCPinitial,IPCPinitial,IPXCPinitial,CCPinitial,BRIDGECPinitial5minutesinputrate0.00bytes/sec,0.00packets/sec5minutesoutputrate0.00bytes/sec,0.00packets/secInputqueue:(size/max/drops)0/75/0FIFOqueueing:FIFOOutputQueue:(size/max/drops)0/75/00packetsinput,0bytes,0nobuffers0packetsoutput,0bytes,0nobuffers0inputerrors,0CRC,0frameerrors0overrunners,0abortedsequences,0inputnobuffersDCD=UPDTR=DOWNDSR=UPRTS=DOWNCTS=UP華為技術(shù)55Displaytech-supportdisplaytech-support命令將顯示系統(tǒng)根本信息，包括版本信息、當前配置信息、接口信息、內(nèi)存信息、接口流量信息等。對于復雜的故障問題，網(wǎng)絡(luò)維護人員可以拷貝該命令的輸出信息發(fā)給華為技術(shù)支持人員使之了解當前路由器的總體情況。華為技術(shù)56Reset命令Reset命令的作用――用于清空當前的統(tǒng)計信息以排除以前積累的數(shù)據(jù)的干擾。Reset命令中最主要的是resetcountersinterface和resetipstatistics命令。對于二層幀收發(fā)的各計數(shù)器的刷新必須使用resetcountersinterface，可通過displayinterfaces命令來觀察；對于三層報文的收發(fā)統(tǒng)計可使用resetipstatistics來刷新，通過displayipinterface命令來觀察。華為技術(shù)57Reset命令Reset命令適用場合如下：許多情況下，我們需要使用帶參數(shù)的ping命令來測試鏈路的通斷，同時在一段時間內(nèi)ping后，通過displayinterfaces或displayipinterface命令來查看端口報文的收發(fā)及CRC校驗等情況的正確與否，從而分析報文的收發(fā)在什么地方出現(xiàn)了問題。但display命令的顯示值是自從路由器運行以來〔或上次reset后〕的所有統(tǒng)計值，這個值是無法分析的。因此，實際我們需要進行的步驟為：首先使用reset命令清空統(tǒng)計值，然后使用一系列ping命令使路由器端口收發(fā)報文，最后使用display命令來查看統(tǒng)計值。華為技術(shù)58debug命令Quidway系列路由器提供大量的debug命令，可以幫助用戶在網(wǎng)絡(luò)發(fā)生故障時獲得路由器中交換的報文和幀的細節(jié)信息，這些信息對網(wǎng)絡(luò)故障的定位是至關(guān)重要的。華為技術(shù)59display命令和debug命令display命令能夠提供某個時間的設(shè)備運行狀況的視圖〔靜態(tài)〕，而debug命令能夠展示一段時間內(nèi)設(shè)備運行的變化情況〔動態(tài)〕。一般說來，display命令不會影響系統(tǒng)的運行性能，而debug命令那么會對系統(tǒng)性能造成影響。因此兩者的使用應(yīng)遵循如下規(guī)那么：首先使用相關(guān)的多個display命令查看設(shè)備當前的運行狀況，分析可能原因，縮減故障到適當范圍，然后翻開某個特定的debug命令觀察變化情況，以定位和排除問題。華為技術(shù)60使用debug命令的注意要點應(yīng)當使用debug命令來查找故障，而不是用來監(jiān)控正常的網(wǎng)絡(luò)運行。盡量在網(wǎng)絡(luò)使用的低峰期或網(wǎng)絡(luò)用戶較少時使用，以降低debug命令對系統(tǒng)的影響性。在沒有完全掌握某debug命令的工作過程以及它所提供的信息前，不要輕易使用該debug命令。由于debug命令在各個輸出方向?qū)ο到y(tǒng)資源的占用情況不同。視網(wǎng)絡(luò)負荷狀況，我們應(yīng)當在使用方便性〔info-centerconsoledebugging命令〕和資源消耗小〔info-centerlogbufferdebugging命令〕間做出權(quán)衡。不要輕易使用類似debugall之類將產(chǎn)生大量輸出的命令。僅當尋找某些類型的流量或故障并且已將故障原因縮小到一個可能的范圍時，才使用某些特定的debug命令。華為技術(shù)61debug命令

案例一

忘記關(guān)閉debug開關(guān)引起的路由器報文轉(zhuǎn)發(fā)速度變慢的故障處理某電信局安裝了Quidway路由器作為接入效勞器的出口網(wǎng)關(guān)，一段時間運轉(zhuǎn)良好。某日用戶反映該設(shè)備明顯速度變慢。執(zhí)行PING操作，PING對端路由器設(shè)備，所用時間為正常的2倍多。華為技術(shù)62debug命令

案例一

忘記關(guān)閉debug開關(guān)引起的路由器報文轉(zhuǎn)發(fā)速度變慢的故障處理相關(guān)信息收集該路由器的日志中記錄了大量的收發(fā)IP報文的信息。原因分析

初步分析可能有以下幾種原因：線路質(zhì)量不好對端設(shè)備問題，導致回應(yīng)較慢自身配置錯誤網(wǎng)絡(luò)繁忙軟硬件故障華為技術(shù)63debug命令

案例一

忘記關(guān)閉debug開關(guān)引起的路由器報文轉(zhuǎn)發(fā)速度變慢的故障處理處理過程檢查線路，沒有發(fā)現(xiàn)問題；PING與之相連的其他路由器設(shè)備，故障依舊，說明對端設(shè)備無問題；對照以前運轉(zhuǎn)良好時備份的current-configuration文件，檢查路由器上的配置，沒有錯誤；當時并非上網(wǎng)頂峰期，且只是變慢，而無丟包，應(yīng)當不是網(wǎng)絡(luò)負荷問題；檢查該路由器的日志信息，發(fā)現(xiàn)其中記錄了大量的收發(fā)IP報文的信息，執(zhí)行命令displaydebugging命令，發(fā)現(xiàn)該路由器的debugippacket處于翻開狀態(tài)。由于設(shè)備需要記錄每一個被轉(zhuǎn)發(fā)的IP報文，大大降低了路由器的處理速度，導致變慢。關(guān)閉該debug開關(guān)后，故障解決。華為技術(shù)64debug命令

案例二通過串口telnet到路由器，在該串口上翻開debug命令產(chǎn)生問題當遠程調(diào)試Quidway路由器時，有時需要通過某個串口telnet上該路由器，如果該串口上的鏈路層協(xié)議封裝的是FR、PPP等，千萬不能翻開該串口相應(yīng)的鏈路層調(diào)試開關(guān)〔可以翻開其他串口的鏈路層調(diào)試開關(guān)〕，否那么由于數(shù)據(jù)流量太大，會使該串口的協(xié)議down掉。如果鏈路層協(xié)議是X.25，那么沒有這個限制。華為技術(shù)65故障處理常用方法分層故障處理法分塊故障處理法分段故障處理法替換法華為技術(shù)66分層故障處理法分層法思想很簡單：所有模型都遵循相同的根本前提－－當模型的所有低層結(jié)構(gòu)工作正常時，它的高層結(jié)構(gòu)才能正常工作。在確信所有低層結(jié)構(gòu)都正常運行之前，解決高層結(jié)構(gòu)問題完全是浪費時間。華為技術(shù)67分層故障處理法—案例分析在一個幀中繼網(wǎng)絡(luò)中，由于物理層的不穩(wěn)定，幀中繼連接總是出現(xiàn)反復失去連接的問題，這個問題的直接表象是到達遠程端點的路由總是出現(xiàn)間歇性中斷。這使得維護工程師第一反響是路由協(xié)議出問題了，然后憑借著這個感覺來對路由協(xié)議進行大量故障診斷和配置，其結(jié)果是可想而知的。如果他能夠從OSI模型的底層逐步向上來探究原因的話，維護工程師將不會做出這個錯誤的假設(shè)，并能夠迅速定位和排除