1、華為中低端路由器故障處理手冊目 錄PAGE 1PAGE 83目 錄TOC o 1-3第1章故障排除技術概述 PAGEREF _Toc14526998 h 1-11.1網絡故障排除技術概覽 PAGEREF _Toc14526999 h 1-11.1.1在當今日益復雜的網絡中進行故障排除 PAGEREF _Toc14527000 h 1-11.1.2網絡故障的一般分類 PAGEREF _Toc14527001 h 1-21.1.3一般網絡故障的解決步驟 PAGEREF _Toc14527002 h 1-21.2華為中低端路由器產品介紹 PAGEREF _Toc14527003 h 1-61.1.1

2、 Quidway R1600系列低端路由器 PAGEREF _Toc14527004 h 1-61.1.2 Quidway R2500/4000系列低端路由器 PAGEREF _Toc14527005 h 1-61.1.3 Quidway R1700系列低端路由器 PAGEREF _Toc14527006 h 1-61.1.4 Quidway R2600系列和R3600系列中端路由器 PAGEREF _Toc14527007 h 1-61.3路由器常用診斷工具介紹 PAGEREF _Toc14527008 h 1-61.3.1 Ping命令 PAGEREF _Toc14527009 h 1-6

3、1.1.2 Tracert 命令 PAGEREF _Toc14527010 h 1-61.1.3 Show命令 PAGEREF _Toc14527011 h 1-61.1.4 Clear命令 PAGEREF _Toc14527012 h 1-61.1.5 Debug命令 PAGEREF _Toc14527013 h 1-61.4故障排除常用方法 PAGEREF _Toc14527014 h 1-61.4.1分層故障排除法 PAGEREF _Toc14527015 h 1-61.1.2分塊故障排除法 PAGEREF _Toc14527016 h 1-61.1.3分段故障排除法 PAGEREF _

4、Toc14527017 h 1-61.1.4替換法 PAGEREF _Toc14527018 h 1-61.5故障排除對網絡維護和管理人員的要求 PAGEREF _Toc14527019 h 1-61.5.1對協議要求有精深的理解 PAGEREF _Toc14527020 h 1-61.5.2能夠引導客戶詳細描述出故障現象和相關信息 PAGEREF _Toc14527021 h 1-61.5.3充分了解自己所管理和維護的網絡PAGEREF _Toc14527022 h 1-61.5.4及時進行故障排除的文檔記錄和經驗總結 PAGEREF _Toc14527023 h 1-61.6華為數據通信產

5、品故障排除資源 PAGEREF _Toc14527024 h 1-61.1.1 Huawei Datacomm Online PAGEREF _Toc14527025 h 1-61.1.2 Huawei Technical Support PAGEREF _Toc14527026 h 1-6華為中低端路由器故障處理手冊 REF _Ref13538896 r h 第1章 REF _Ref13538900 h 故障排除技術概述故障排除技術概述網絡故障排除技術概覽在當今日益復雜的網絡中進行故障排除當今的網絡互連環境是復雜的，而且其復雜性的日益增長也是可以預見的，主要原因如下：現代的互連網絡要求支持更

6、廣泛的應用，包括數據、語音、視頻及它們的集成傳輸；新業務發展使網絡帶寬的需求不斷增長，這就要求新技術的不斷出現。例如：十兆以太網向百兆、千兆以太網的演進；MPLS技術的出現；提供QoS能力等。新技術的應用同時還要兼顧傳統的技術。例如，傳統的SNA體系結構仍在某些場合使用，DLSw作為通過TCP/IP承載SNA的一種技術而被應用。多樣業務的需求和各種先進技術的引入使網絡日益復雜因此，現代的互連網絡是協議、技術、介質和拓撲的混合體。互連網絡環境越復雜，意味著網絡的連通性和性能故障發生的可能性越大，而且引發故障的原因也越發難以確定。同時，由于人們越來越多的依賴網絡處理日常的工作和事務，一旦網絡故障不

7、能及時修復，其所造成的損失可能很大甚至是災難性的。能夠正確地維護網絡盡量不出現故障，并確保出現故障之后能夠迅速、準確地定位問題并排除故障，對網絡維護人員和網絡管理人員來說是個挑戰，這不但要求他們對網絡協議和技術有著深入的理解，更重要的是要建立一個系統化的故障排除思想并合理應用于實際中，以將一個復雜的問題隔離、分解或縮減排錯范圍，從而及時修復網絡故障。本書著眼于幫助網絡維護人員和管理人員將他們所掌握的知識有條理的應用于診斷和排除網絡故障的過程中；幫助他們針對各種網絡環境中的常見故障現象進行定位和解決。網絡故障的一般分類網絡故障一般分為兩大類：連通性問題和性能問題。它們各自故障排除的關注點如下：連

8、通性問題硬件、媒介、電源故障配置錯誤不正確的相互作用性能問題網絡擁塞到目的地不是最佳路由供電不足路由環路網絡錯誤一般網絡故障的解決步驟故障排除系統化是合理地一步一步找出故障原因并解決的總體原則。它的基本思想是系統地將由故障可能的原因所構成的一個大集合縮減（或隔離）成幾個小的子集，從而使問題的復雜度迅速下降。故障排除時有序的思路有助于解決所遇到的任何困難，下圖給出了一般網絡故障解決的處理流程。說明：該處理流程是網絡維護人員所能夠采用的排錯模型中的一種，如果你根據自己的經驗和實踐總結了另外的排錯模型并證明是行之有效的，請繼續使用它網絡故障解決的處理流程是可以變化的，但故障排除有序化的思維模式是不可

9、變化的。網絡故障排除基本步驟下面我們以一個故障排除的實例來學習如何應用這些步驟。案例：用戶網段廣播包過多造成該網段的服務器FTP業務傳輸速度慢該案例組網圖如下：某校園網的三個局域網，其中為一個用戶網段，18為一個日志服務器；是一個集中了很多應用服務器的網段。用戶網段廣播包過多造成該網段的服務器FTP業務傳輸速度慢故障現象描述要想對網絡故障做出準確的分析，首先應該了解故障表現出來的各種現象，然后才能確定可能產生這些現象的故障根源或癥結。因此，對網絡故障做出完整、清晰的描述是重要的一步。如上述案例，用戶反映：“日志服務器與備份服務器間備份發生問題。”這就是一個不完整不清晰的故障現象描述。因為這個描

10、述沒有講述清楚下列問題：這個問題是連續出現，還是間斷出現的？是完全不能備份，還是備份的速度慢（即性能下降）？哪個或哪些局域網服務器受到影響，地址是什么？正確的故障現象描述是：在網絡的高峰期，日志服務器1到集中備份服務器53之間進行備份時，FTP傳輸速度很慢，大約是0.6Mbps。故障案例相關信息收集本步驟是搜集有助于查找故障原因的更詳細的信息。主要是三種途徑：向受影響的用戶、網絡人員或其他關鍵人員提出問題；根據故障描述性質，使用各種工具搜集情況，如網絡管理系統、協議分析儀、相關show和debug命令等；測試性能與網絡基線進行比較。如上述案例，可以向用戶提問或自行收集下列相關信息：網絡結構或配

11、置是否最近修改過，即問題出現是否與網絡變化有關？是否有用戶訪問受影響的服務器時沒有問題？在非高峰期日志服務器和備份服務器間FTP傳輸速度是多少？通過該步驟，我們收集到了下面一些相關信息：最近網段的客戶機不斷在增加；網段的機器與備份服務器間進行FTP傳輸時速度正常為7Mbps，與日志服務器間進行FTP傳輸時速度慢，只有0.6Mbps；在非高峰期日志服務器和備份服務器間FTP傳輸速度正常，大約為6Mbps；經驗判斷和理論分析利用前兩個步驟收集到的數據，并根據自己以往的故障排除經驗和所掌握的互連網絡設備和協議的知識，來確定一個排錯范圍。通過范圍的劃分，就只需注意某一故障或與故障情況相關的那一部分產品

12、、介質和主機。如上述案例：我們現在能夠確定是一個網絡性能下降問題。那么，是網段的性能問題？是中間網云的性能問題？是網段的性能問題呢？由于網段的機器與備份服務器間進行FTP傳輸時速度正常為7Mbps這一事實，我們可以排除掉網段的性能問題。各種可能原因列表該步驟列出根據經驗判斷和理論分析后總結的各種可能原因。如上述案例，可能原因如下：網段的性能問題，其子原因可能為：日志服務器A的性能問題網絡的網關性能問題網絡本身的性能問題網云性能問題，主要是到網絡的路由不是最佳路由對每一原因實施排錯方案根據所列出的可能原因制定故障排查計劃，分析最有可能的原因，確定一次只對一個變量進行操作，這種方法使你能夠重現某一

13、故障的解決辦法。如果有多個變量同時被改變，而問題得以解決，那么如何判斷哪個變量導致了故障發生呢？說明：我們在對故障處理流程5、6、7步驟介紹完畢后，再繼續進行上述實例案例的排錯步驟介紹。觀察故障排查結果當我們對某一原因執行了排錯方案后，需要對結果進行分析，判斷問題是否解決，是否引入了新的問題。如果問題解決，那么就可以直接進入文檔化過程；如果沒有解決問題，那么就需要再次循環進行到故障排查過程。循環進行故障排查過程當實施了一個方案沒有達到預期的排錯目的時，我們進入到該步驟這是一個努力縮小可能原因的清單過程。在進行下一循環之前必須做的事情就是將網絡恢復到實施上一方案前的狀態。如果保留上一方案對網絡的

14、改動，很可能導致新的問題，例如：假設修改了訪問列表但沒有產生預期的結果，此時如果不將訪問列表恢復到原始狀態，就會導致出現不可預期的結果。循環排錯可以有兩個切入點：當針對某一可能原因的排錯方案沒有達到預期目的，循環進入下一可能原因制定排錯方案并實施；當所有可能原因列表的排錯方案均沒有達到排錯目的，重現進行故障相關信息收集以分析新的可能原因。如上述案例，我們在列出了可能原因列表后，開始制定方案進行故障排除。可能原因1：“網絡到網絡的路由不是最佳路由”制定的方案：在網段的網關上使用“Tracert 53”命令，發現探測報文返回時長僅為10ms，表明該可能原因并不是造成故障的原因。我們進入循環排錯過程

15、。可能原因2：“日志服務器A的性能問題”制定的方案：測試同一網段的主機C和日志服務器間的FTP傳輸速度，是6Mbps，正常。可見問題與服務器A無關。可能原因3：“網絡的網關性能問題”制定的方案：測試主機C和備份服務器B間FTP傳輸速度是7Mbps，正常。排除了網關因素，因為B、C在不同網段上而速度正常。可能原因3：“網絡本身的性能問題”制定的方案：在網段的以太網交換機上使用命令“Show mac”，輸出如下：Port Rcv-Unicast Rcv-Multicast Rcv-Broadcast 6/32 10317812 0 8665Port Xmit-Unicast Xmit-Multic

16、ast Xmit-Broadcast 6/32 6667987 286652 2474038(輸出的廣播：輸出的單播比例為1：3，太大了。)Port Rcv-Octet Xmit-Octet 6/321516443041在網段上的以太網交換機上使用命令“Show mac”輸出如下：Port Rcv-Unicast Rcv-Multicast Rcv-Broadcast 6/36 55780287 0 285Port Xmit-Unicast Xmit-Multicast Xmit-Broadcast 6/36 27879749 190257 119430（廣播：單播比

17、例1：270，屬于正常。）Port Rcv-Octet Xmit-Octet 6/36 67172587081 4998816809由此知道，網段上廣播包和單播包比例為1:3，確實太大了。再次詢問用戶該網段主要運行的業務是什么，從而得出了故障最終原因如下：是普通用戶網段，由于業務原因每個用戶需要發送大量廣播包和多播包，隨著近期越來越多的用戶接入該網絡，在這個網段上的服務器需要花費更多的資源來處理越來越多的廣播和多播包，因此其服務的傳輸速度自然減慢。由于這是一個網絡布局不恰當的問題，于是重新安排服務器的位置，將服務器移動網段后，故障排除。故障排除過程文檔化當最終排除了網絡故障后，那么排除流程的最

18、后一步就是對所做的工作進行文字記錄。文檔化過程決不是一個可有可無的工作，原因如下：文檔是排錯寶貴經驗的總結，是 “經驗判斷和理論分析”這一過程中最重要的參考資料；文檔記錄了這次排錯中網絡參數所做的修改，這也是下一次網絡故障應收集的相關信息。文檔記錄主要包括以下幾個方面：故障現象描述及收集的相關信息網絡拓撲圖繪制網絡中使用的設備清單和介質清單網絡中使用的協議清單和應用清單故障發生的可能原因對每一可能原因制定的方案和實施結果本次排錯的心得體會其他：如排錯中的使用的參考資料列表等請讀者對照上述案例完成文檔記錄工作。華為中低端路由器產品介紹如圖1-2所示，Quidway系列路由器依托華為公司擁有自主知

19、識產權的VRP（Versatile Routing Platform，通用路由平臺）軟件平臺，使用高性能的處理器、總線技術及快速路由策略，為電信、專網、ISP、金融、稅務、公安、鐵路等行業用戶和大中型企業用戶提供從中低端、高端到核心端的全方位的網絡解決方案。華為IP網絡產品線Quidway NetEngine80是面向電信級運營網絡及骨干核心網絡的GSR路由器，以滿足核心網絡高速轉發數據的需求并實現不同業務的不同級別服務。Quidway NetEngine16/08是面向運營級核心網絡的高端網絡產品，是具有高性能、高可靠性、高可擴展性、多業務的邊緣交換層的高端路由器。本書所舉的故障排除案例分析

20、主要是針對Quidway中低端路由器的系列產品，下面將詳細介紹一下華為中低端路由器系列產品的特性。華為中低端路由器產品主要包括：Quidway 1600系列低端路由器Quidway 2500系列低端路由器Quidway 1700系列低端路由器Quidway 2600系列中端路由器Quidway 3600系列中端路由器Quidway R1600系列低端路由器Quidway R1600系列路由器包括R1602、R1603和R1604三款路由器，是華為公司面向家庭辦公、小型辦公室（SOHO）開發的新一代路由器產品，主要應用于企業上網、家庭辦公、公司遠程機構互連和Internet上網等。Quidway

21、 R1602路由器定位為桌面級遠程分支路由器。采用M68360 33M RISC CPU；提供1個10Base-T、2個同/異步串口（可達2Mbps）、1個AUX口。Quidway R1603/1604路由器定位為桌面級分支ISDN接入路由器。采用M68360 33M RISC CPU；提供1個10Base-T、1個ISDN BRI接口（R1603提供BRI S/T接口，R1604提供BRI U接口）、1個同/異步串口（可達2Mbps）、1個AUX口和2個模擬電話接口。Quidway R2500系列低端路由器Quidway R2500系列路由器包括R2501/2501E、R2509/2509E

22、、 R2511/2511E、 R4001/4001E八款路由器。是華為公司面向中、小型辦公室開發的新一代路由器產品，主要應用于電信記費、電信網管、機構互連、Internet訪問、電信設備配套IP接入網關等。Quidway R2501路由器定位為網絡遠程分支路由器。采用M68360 25M RISC CPU；提供1個10Base-T、1個以太網口、2個高速同/異步串口、1個AUX口。Quidway R2509/R2511路由器定位為網絡遠程分支接入路由器。采用M68360 33M RISC CPU；提供1個10Base-T、1個以太網口、2個高速同/異步串口、1個AUX口、1/2個8異步串行口；

23、可作為小企業PSTN接入服務器。Quidway R4001路由器定位為企業級分支路由器。采用M68360 33M RISC CPU；提供1個10Base-T；1個AUI口；1個高速同/異步串口、1個AUX口、1個E1/CE1/PRI接口。可作為企業ISDN接入服務器使用；它是以低端產品價格提供E1接口的路由器，具有超高性價比。Quidway R2500E系列路由器（R2501E、R2509E、R2511E、R4001E）內置一個接口插槽，可以插入128位以上硬件序列碼加密的加密板，升級為一臺高性能邊緣加密路由器。應用于需要數據保密領域，如：安全辦公、機要部門等特殊應用；去掉加密卡就是普通路由器

24、。Quidway R1700系列低端路由器QuidwayR1700系列路由器目前有R1760一款，是華為公司最新開發的邊緣接入路由器。它采用模塊化結構，在提供了集成的快速以太網接口、AUX口和同/異步串口的同時，又提供了豐富的可選配的智能接口卡SIC（Smart Interface Card，智能接口卡）及多功能接口模塊MIM（Multifunctional Interface Module，多功能接口模塊）。與同類產品相比，R1760模塊化路由器具有更高的性能價格比和可擴展能力，既適合于在一些大的分支機構擔當接入路由器，也可以在中小型企業網中擔當核心路由器。R1760路由器采用MPC8241

25、 200MHz高速CPU，提供的網絡接口和插槽數量如下：三個固定的網絡接口，包括1個10/100M以太網口、一個AUX口和1個同/異步串口；三個插槽，包括1個MIM插槽和2個SIC插槽。R1760路由器支持多種SIC和MIM，其中SIC是R1760路由器特有的智能接口卡，MIM是R1760/2600/3600路由器共用的多功能接口模塊，用戶可以通過更換或擴展接口卡及接口模塊的方法滿足未來變化的需求。SIC的種類如下：1端口10/100M以太網接口卡（SIC-1FEA）1端口多協議同/異步串口接口卡（SIC-1SA）3端口異步串口接口卡（SIC-3AS）1端口ISDN BRI S/T接口卡（SI

26、C-1BS）2端口ISDN BRI S/T接口卡（SIC-2BS）1端口ISDN BRI U接口卡（SIC-1BU）2端口ISDN BRI U接口卡（SIC-2BU）1端口E1/CE1/ PRI兼容接口卡（SIC-EPRI）1端口T1/CT1/ PRI兼容接口卡（SIC-TPRI）1端口模擬調制解調器接口卡（SIC-1AM）2端口模擬調制解調器接口卡（SIC-2AM）1端口語音用戶電路接口卡（SIC-1FXS）2端口語音用戶電路接口卡（SIC-2FXS）1端口語音AT0模擬中繼接口卡（SIC-1FXO）2端口語音AT0模擬中繼接口卡（SIC-2FXO）MIM的種類請參閱下文Quidway R2

27、600/R3600中端路由器的相關介紹。Quidway R2600系列和R3600系列中端路由器Quidway R2600系列和Quidway R3600系列路由器是華為公司面向企業級的網絡產品。其中，Quidway R2600系列路由器部分采用模塊化結構，在提供集成的高速以太網接口和同步串口同時，還具有豐富的可選配模塊。Quidway R3600系列路由器則完全采用模塊化結構。Quidway R2620系列Quidway R2620系列路由器包含兩款：R2620和R2621。 R2620系列路由器既可在中小型企業網中擔當核心路由器，也可在一些大的分支機構擔當接入路由器。R2620系列路由器提

28、供的網絡接口和模塊插槽數量如下：R2620提供1個固定的10/100M以太網口、2個固定的同步串口和2個標準的MIM模塊插槽。R2621提供2個固定的10/100M以太網口、2個固定的同步串口和2個標準的MIM模塊插槽。Quidway R2630系列Quidway R2630系列路由器包含四款：R2630、R2631、R2630E、R2631E。與R2620系列相比，R2630系列路由器具有更靈活的配置方式和更高的處理能力。既適合于在中小型企業網中擔當核心路由器，也可在一些大的分支機構擔當接入路由器。R2630系列路由器提供的固定網絡接口與模塊插槽數量如下：R2630、R2630E：1個固定的

29、10/100M以太網口和3個標準的MIM模塊插槽。R2631、R2631E：2個固定的10/100M以太網口和3個標準的MIM模塊插槽。Quidway R3600系列Quidway R3600系列路由器包含四款： R3640、 R3680、 R3640E、 R3680E。面向企業級網絡的產品，和R2620、R2630系列相比， R3600系列路由器具有更高的處理能力和更大的接入密度。 R3600系列路由器既適合于在中小型企業網中擔當核心路由器，也可以在大型網絡中擔當匯聚層路由器。R3600系列路由器提供的模塊插槽數量如下：R3640、R3640E提供4個標準的MIM模塊插槽。R3680、R36

30、80E提供8個標準的MIM模塊插槽。Quidway R1760/R260/R3600系列路由器支持的模塊種類1端口10Base-T/100Base-TX快速以太網接口模塊（1FE）2端口10Base-T/100Base-TX快速以太網接口模塊（2FE）2端口高速同/異步串口模塊（2SA）4端口高速同/異步串口模塊（4SA）8端口低速同/異步串口模塊（8LSA）2端口同/異步串口 + 1端口ISDN BRI S/T接口模塊（2S1B）1端口可拆分通道化cE1/PRI模塊（1E1）2端口可拆分通道化cE1/PRI模塊（2E1）4端口可拆分通道化cE1/PRI模塊（4E1）4端口ISDN BRI S

31、/T接口模塊（4BS）8端口異步串口模塊（8AS）16端口異步串口模塊（16AS）2端口語音模塊（FXS接口）（2FXS）2端口語音模塊（FXO接口）（2FXO）2端口語音模塊（E&M接口）（2E&M）4端口語音模塊（FXS接口）（4FXS）4端口語音模塊（FXO接口）（4FXO）4端口語音模塊（E&M接口）（4E&M）1端口E1語音模塊（E1VI）路由器常用診斷工具介紹華為Quidway 系列路由器提供了一套完整的命令集，可以用于監控網絡互聯環境的工作狀況和解決基本的網絡故障。主要包括以下命令：Ping命令Tracert命令說明：由于上面命令不僅是Quidway系列路由器VRP平臺的常用網絡

32、命令，也是windows平臺上常用的網絡命令，所以本手冊對兩種平臺下的命令使用均進行介紹。Show命令Clear命令Debug命令Ping命令原理：“ping”這個詞源于聲納定位操作，指來自聲納設備的脈沖信號。Ping命令的思想與發出一個短促的雷達波，通過收集回波來判斷目標很相似；即源站點向目的站點發出一個ICMP Echo Request報文，目的站點收到該報文后回一個ICMP Echo Reply報文，這樣就驗證了兩個節點間IP層的可達性表示了網絡層是連通的。功能Ping命令用于檢查IP網絡連接及主機是否可達。VRP平臺的ping命令在Quidway系列路由器上，Ping命令的格式如下：P

33、ing -c number -tnumber -s number ip-address-c Ping報文的個數，缺省值為5；-t 設置Ping報文的超時時間，單位為毫秒，缺省值為2000；-s 設置Ping報文的大小，以字節為單位，缺省值為56。說明：實際上Quidway系列路由器Ping命令的參數非常多，這里只介紹其中最重要的三個參數。其他參數介紹請參考VRP用戶手冊命令參考。例如，向主機發出2個8100字節的Ping報文Quidway# ping -c 2 -s 8100 PING: 8100 data bytes, press CTRL_C to break Reply from : b

34、ytes=8100 Sequence=0 ttl=123 time = 538 ms Reply from : bytes=8100 Sequence=1 ttl=123 time = 730 ms ping statistics 2 packets transmitted 2 packets received 0.00% packet loss round-trip min/avg/max = 538/634/730 ms Windows平臺的Ping命令在PC機上或Windwos NT為平臺的服務器上，Ping命令的格式如下：Ping -n number -t -l number ip-a

35、ddress-n Ping報文的個數，缺省值為5；-t 持續地ping 直到人為地中斷，Ctr+Breack暫時中止ping命令并查看當前的統計結果，而Ctr+C則中斷命令的執行。-l 設置Ping報文所攜帶的數據部分的字節數，設置范圍從0至65500。例：向主機 發出2個數據部分大小為 3000 Bytes的ping報文C:ping -l 3000 -n 2 Pinging with 3000 bytes of dataReply from : bytes=3000 time=321ms TTL=123Reply from : bytes=3000 time=297ms TTL=123Pin

36、g statistics for : Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),Approximate round trip times in milli-seconds: Minimum = 297ms, Maximum = 321ms, Average = 309ms說明：實際上Windows平臺的Ping命令的參數非常多，這里只介紹其中最重要的三個參數。其他參數介紹請參考Windows在線幫助。巧用Ping命令進行故障排除案例一：連通性問題還是性能問題？案例描述工程師小L，在配置完一臺路由器之后執行Ping命令檢測鏈路是否通暢

37、。發現5個報文都沒有Ping通，于是檢查雙方的配置命令并查看路由表，卻一直沒有找到錯誤所在。最后又重復執行了一遍相同的Ping命令，發現這一次5個報文中有1個Ping 通了原來是線路質量不好存在比較嚴重的丟包現象。工程師小L又配置了一臺路由器，然后執行Ping命令訪問Internet上某站點的IP地址，但沒有Ping通。有了上次的教訓小L，再一次Ping了20個報文，仍舊沒有響應。于是小L斷定是網絡故障。但是在費勁周折檢查了配置鏈路之后仍沒有發現任何可疑之處，最后小L采取逐段檢測的方法對鏈路中的網關進行逐級測試，發現都可以Ping 通，但是響應的時間越來越長，最后一個網關的響應時間在1800m

38、s左右。會不會是由于超時而導致顯示為Ping 不同呢？受此啟發，小L將Ping 命令報文的超時時間改為4000ms，這次成功Ping通了，顯示所有的報文響應時間都在2200ms 左右。建議和總結：真的是Ping不通嗎？這個問題需要定位清楚，因為連通性問題和性能問題排錯的關注點是不一樣的問題定位錯誤必然會導致排錯過程的周折。使用一般的Ping命令，缺省是發送5個報文的，超時時長是2000ms。如果Ping不通情況發生，最好能夠再用帶參數-c和-t的Ping命令再執行一遍，如：Ping -c 20 -t 4000 ip-address，即連續發送20個報文，每個報文的超時時長為4000ms，這樣一

39、般可以判斷出到底是連通性問題還是性能問題。案例二：使用大包ping對端進行MTU不一致的故障排除現象描述：某次開局，使用Quidway路由器與其他廠商的某路由器互連，并運行OSPF協議。數據配置完畢后，一切正常，并在今后相當長的時間內設備運轉穩定。但兩個月后，用戶反饋網絡中斷。相關信息顯示：登錄到兩臺路由器上，發現雙方連接正常，可以相互Ping通對端地址。但OSPF協議中斷；登錄Quidway路由器查看鄰居狀態，發現鄰居狀態機處于Exstart狀態。打開相應的debug開關查看相應的報文信息，發現雙方都可以收到Hello報文，但Quidway路由器發送DD報文后，一直沒有收到對方回應的DD報文

40、；登錄其他廠商的那臺路由器，打開相應的debug開關，發現對方收到Quidway路由器發送的DD報文后，一發送了相應的DD報文予以回應。原因分析：初步斷定，Quidway路由器沒有收到DD回應報文，但對方確實發出來了。既然可以接收到HELLO 報文說明鏈路是通暢的，而且多播報文的收發也沒有問題。那么有可能是對方發送的DD 報文有錯誤導致Quidway路由器拒收，但查看相應的信息，并沒有報告接收到錯誤的DD 報文。仔細查看某廠商路由器的調試信息發現這個DD報文很大有2000 多字節。會不會是由于報文太大導致的問題呢？試著Ping了一個2000字節的報文，結果不通。那么故障原因很可能是由于雙方的M

41、TU不一致導致大包不通。處理過程：檢查配置，發現對方路由器的MTU設置為4000多而Quidway路由器的MTU設置為1500，于是修改對端路由器的MTU為1500。故障排除。那么為什么工程初期沒有問題呢？這是因為前期DD報文長度小于1500字節，而后來網絡擴容導致路由信息過多使DD 報文的長度超過了1500 字節。建議和總結：由于Ping 缺省報文是56 個字節，所以顯示的Ping 通信息只是表示56字節的報文可以通而并不一定表示其他大小的報文仍舊可以通。所以，應當善于使用Ping的其他參數來進行故障排除。案例三：A能Ping通B，B就一定能Ping通A嗎？現象描述組網圖如下：案例：A能Pi

42、ng通B，B就一定能Ping通A嗎？在RouterA上配置一條指向/8的靜態路由：RouterA（config）# ip route 在RouterA 上Ping RouterB 的以太網地址，顯示可以正常Ping通；但是在RouterB上Ping RouterA的以太網地址，卻無法Ping通。原因分析：由于在RouterB 上卻沒有相應的配置到/8 路由，所以從RouterB 上Ping不通RouterA的以太網口 。但是為何在A上可以Ping 通 呢？同樣是沒有回程路由呀？打開路由器上的IP報文調試開關發現，原來從RouterA上發出的ICMP報文的源地址填寫的是而不是，由于兩臺路由器的s

43、0口處于同一網段，所以響應報文可以順利到達RouterB。建議和總結：A能夠Ping通B則B一定能夠Ping通A（不考慮防火墻的因素）,這句話的對錯取決于A和B到底是指主機還是指路由器。如果是指兩臺主機，那么這句話就是正確的。如果是指兩臺路由器那就是錯誤的，因為路由器通常會有多個IP地址。現在就有如下問題：當從一臺路由器上執行Ping命令它發出的ICMP Echo報文的源地址究竟選擇哪一個呢？實際情況是路由器選擇發出報文的接口的IP地址。Tracert 命令原理Tracert是為了探測源節點到目的節點之間數據報文所經過的路徑。利用IP報文的TTL域在每經過一個路由器的轉發后減一，當TTL=0時

44、則向源節點報告TTL超時這個的特性。Tracert首先發送一個TTL為1的UDP報文，因此第一跳發送回一個ICMP錯誤消息以指明此數據報不能被發送（因為TTL超時），之后Tracert再發送一個TTL為2的報文，同樣第二跳返回TTL超時，這個過程不斷進行，直到到達目的地，此時由于數據報中使用了無效的端口號（缺省為33434）此時目的主機會返回一個ICMP的目的地不可達消息，表明該Tracert操作結束。Tracert記錄下每一個ICMP TTL超時消息的源地址，從而提供給用戶報文到達目的地所經過的網關IP地址。功能Tracert 命令用于測試數據報文從發送主機到目的地所經過的網關，主要用于檢查

45、網絡連接是否可達，以及分析網絡什么地方發生了故障。VRP平臺的Tracert命令在華為Quidway系列路由器上，Tracert命令的格式如下：Tracert -a ip-address -ffirst_TTL -m max_TTL -p port -q nqueries -wtimeout host-a 指定一個發送UDP報文的源地址；-f 指定初始報文的TTL大小，缺省值為1；-m 指定最大TTL大小，缺省值為30；-p 目的主機的端口號，缺省值為33434；-q 每次發送的探測報文的個數，缺省值為3；-w 指明UDP報文的超時時間，單位為毫秒，缺省值為5000。例如：查看到目的主機 中間

46、所經過的網關。Quidway# tracert traceroute to () 30 hops max,40 bytes packet 1 1 4 ms 5 ms 5 ms 2 4 10 ms 5 ms 5 ms 3 54 10 ms 5 ms 5 ms 4 77 175 ms 160 ms 145 ms 5 54 185 ms 210 ms 260 ms 6 230 ms 185 ms 220 ms Windows平臺的Tracert 命令在PC機上或Windwos NT為平臺的服務器上，Tracert命令的格式如下：tracert -d -hmaximum_hops -jhost-lis

47、t -wtimeout host-d 不解析主機名；-h 指定最大TTL大小；-j 設定松散源地址路由列表；-w 用于設置UDP報文的超時時間，單位毫秒；例如：查看到目的主機 中間所經過的前兩個網關。C:tracert -h 2 Tracing route to over a maximum of 2 hops: 1 3 ms 2 ms 2 ms 2 5 ms 3 ms 2 ms 4Trace complete.使用Tracert命令進行故障排除案例一：使用Tracert命令定位不當的網絡配置點現象描述組網情況如下圖所示：案例：使用Tracert命令定位不當的網絡配置點某校園網中，Router

48、B和RouterC同屬于一個運行RIPv2路由協議的網絡，主機訪問數據庫服務器，用戶抱怨訪問性能差。相關信息顯示登錄到RouterC，使用帶參數的Ping遠端服務器，顯示如下：RouterC#ping -c 10 -s 4000 -t 6000PING: 4000 data bytes, press CTRL_C to break Reply from : bytes=4000 Sequence=0 ttl=249 time = 552 ms Reply from : bytes=4000 Sequence=1 ttl=249 time = 5733 ms Reply from : bytes

49、=4000 Sequence=2 ttl=249 time = 552 ms Reply from : bytes=4000 Sequence=3 ttl=249 time = 5714 ms Reply from : bytes=4000 Sequence=4 ttl=249 time = 552 ms Reply from : bytes=4000 Sequence=5 ttl=249 time = 5711 ms Reply from : bytes=4000 Sequence=6 ttl=249 time = 552 ms Reply from : bytes=4000 Sequenc

50、e=7 ttl=249 time = 5709 ms Reply from : bytes=4000 Sequence=8 ttl=249 time = 552 ms Reply from : bytes=4000 Sequence=9 ttl=249 time = 5710 ms原因分析上面的Ping顯示出一個規律：奇數報文的返回時長短，而偶數報文返回時長很長（是奇數報文的10倍多）。可以初步判斷奇數報文和偶數報文是通過不同的路徑傳輸的。現在我們需要使用Tracert命令來追蹤這不同的路徑。在RouterC上，Tracert遠端RouterA的以太網接口。RouterC(config)#tr

51、acert -q 8 traceroute to () 30 hops max,40 bytes packet 1 6 ms 4 ms 4 ms 4 ms 4 ms 4 ms 4 ms 4 ms 。（中間省略） 20 ms 16 ms 15ms 16 ms 16 ms 16 ms 16 ms 16 ms 30 ms 278 ms 25 ms 279 ms 25 ms 278 ms 25 ms 277 msRouterC(config)#從上面的顯示可看到，直至，UDP探測報文的返回時長都基本一致，而到時，則發生明顯變化，呈現奇數報文時長短，偶數報文時長長的現象。于是判斷，問題發生在Router

52、B和RouterA之間。通過詢問該段網絡的管理員，得知這兩路由器間有一主一備兩串行鏈路，主鏈路為2.048Mbps（s0口之間），備份鏈路為128Kbps（s1口之間）。網絡管理員在此兩路由器間配置了靜態路由。RouterB上如下配置：RouterB（config）# ip route RouterB（config）# ip route RouterA上如下配置：RouterA（config）# ip route RouterA（config）# ip route 于是問題就清楚了。例如RouterB，由于管理員配置時沒有給出靜態路由的優先級，這兩條路由項的優先級就同為缺省值60，于是就同時出

53、現在路由表中，實現的是負載分擔，而不能達到主備的目的。處理過程可以有兩種處理方法：繼續使用靜態路由，進行配置更改RouterB上進行如下更改：RouterB（config）# ip route （主鏈路仍使用缺省優先級60）RouterB（config）# ip route 100（備份鏈路的優先級降低至100）RouterA上進行如下更改：RouterA（config）# ip route RouterA（config）# ip route 100這樣，只有當主鏈路發生故障，備份鏈路的路由項才會出線在路由表中，從而接替主鏈路完成報文轉發，實現主備目的。在兩路由器上運行動態路由協議，如IGRP

54、、EIGRP、OSPF等，但不要運行RIP協議（因為RIP協議僅以hop作為Metric的）建議和總結本案例的目的不是為了解釋網絡配置問題，而是用來展示Ping命令和Tracert命令的相互配合來找到網絡問題的發生點。尤其在一個大的組網環境中，維護人員可能無法沿著路徑逐機排查，此時，能夠迅速定位出發生問題的線路或路由器就非常重要了。案例二：使用Tracert命令發現路由環路現象描述組網情況如下圖所示：三臺路由器均配置靜態路由，完成后，登錄到RouterA上Ping主機，發現不通。相關信息顯示RouterA#ping -c 6 -t 5000 PING: 56 data bytes, press

55、 CTRL_C to break Request time out Request time out Request time out Request time out Request time out Request time outRouterA# tracert traceroute to () 30 hops max,40 bytes packet 1 6 ms 4 ms 4 ms（RouterB） 2 8 ms 8 ms 8 ms（RouterA） 12 ms 12 ms 12 ms（RouterB） 16 ms 16 ms 16 ms（RouterA）。原因分析從上面的Tracer

56、t命令的顯示可以立即發現，在RouterA和RouterB間產生了路由環路。由于是配置的是靜態路由，基本可以斷定是RouterA或RouterB的靜態路由配置錯誤。檢查RouterA的路由表，配置的是缺省靜態路由：ip route ，沒有問題。檢查RouterB的路由表，配置到網絡的靜態路由為：ip route 下一跳配置的是，而不是。這正是錯誤所在。處理過程修改RouterB的配置如下：RouterB（config）# no ip route RouterB（config）# ip route 故障排除。建議和總結Tracert命令能夠很容易發現路由環路等潛在問題。當路由器A認為路由器B知道

57、到達目的地的路徑，而路由器B也認為路由器A知道目的地時，就是路由環路發生了。使用Ping命令只能知道接收端出現超時錯誤，而Tracert能夠立即發現環路所在如果Tracert命令兩次或者多次顯示同樣的接口。當通過Tracert發現路由環路后，如果配置為：靜態路由：幾乎可以肯定是手工配置有問題，如本案例所示。OSPF協議：可能是地址聚合產生的問題。請參閱相關章節內容。多路由協議：可能是路由引入產生的問題。請參閱相關章節內容。Show命令Show命令是用于了解路由器的當前狀況、檢測相鄰路由器、從總體上監控網絡、隔離互連網絡中故障的最重要的工具之一。幾乎在任何故障排除和監控場合，Show命令都是必不

58、可少的。例如：基于VRP1.6路由平臺的Show命令選項如下所示：Quidway#show ? aaa Display AAA information access-list Display access-list structurearp ARP table call-history Display voice port call history client Display current client information clock Display the system clock configfile Show the memory in which config.ini is s

59、tored controller Display an E1/T1 entry crypto Show information about IPSec and crypto map debugging State of each debugging option dialer Dialer parameters and statistics dlsw Data Link Switch Information encrypt-card Show information about encrypt-card firewall Display firewall status frame-relay

60、Frame Relay information ftp-server Ftp server information gateway Display status of gateway gw-h323 Show voice store information history Display the session command history host Display hosts name and IP Address hostname Display hostname interfaces Interface status and configuration ip IP informatio