故障排除概述1.ppt

网络监测与故障恢复 All rights reserved故障排除概述ISSUE1.0网络监测与故障恢复All rights reserved本课介绍了网络故障处理技术的一些常用知识。学完本课程您能掌握一般网络故障的解决步骤和路由器常用诊断工具的使用方法。Page 网络监测与故障恢复All rights reserved学习完此课程，您将会：l了解网络故障处理技术l掌握一般网络故障的解决步骤l掌握路由器常用诊断工具介绍l掌握故障处理常用方法l了解故障处理对网络维护和管理人员的要求Page 网络监测与故障恢复All rights reserved第第第第1 1章章章章 故障处理技术概述故障处理技术概述故障处理技术概述故障处理技术概述第第2章章 一般网络故障的解决步骤一般网络故障的解决步骤第第3章章 路由器常用诊断工具介绍路由器常用诊断工具介绍第第4章章 故障处理的常用方法故障处理的常用方法Page 网络监测与故障恢复All rights reserved网络故障处理技术概述l当今的网络互连环境是复杂的，而且其复杂性的还在日益增长，主要原因如下：l现代的因特网络要求支持更广泛的应用，包括数据、语音、视频及它们的集成传输；l新业务发展使网络带宽的需求不断增长，这就要求新技术的不断出现。例如：十兆以太网向百兆、千兆以太网的演进；MPLS技术的出现；提供QoS能力等。l新技术的应用同时还要兼顾传统的技术。例如，传统的SNA体系结构仍在某些场合使用，DLSw作为通过TCP/IP承载SNA的一种技术而被应用。Page 网络监测与故障恢复All rights reserved网络故障处理技术概述l能够正确地维护网络尽量不出现故障，并确保出现故障之后能够迅速、准确地定位问题并排除故障，对网络维护和管理人员来说是个挑战。l这不但要求对网络协议和技术有着深入的理解，更重要的是要建立一个系统化的故障处理思想并合理应用于实际中，以将一个复杂的问题隔离、分解或缩减排错范围，从而及时修复网络故障。Page 网络监测与故障恢复All rights reserved网络故障的一般分类l连通性问题硬件、媒介、电源故障配置错误不正确的相互作用l性能问题网络拥塞到目的地不是最佳路由供电不足路由环路网络错误Page 网络监测与故障恢复All rights reserved第第1章章 故障处理技术概述故障处理技术概述第第第第2 2章章章章 一般网络故障的解决步骤一般网络故障的解决步骤一般网络故障的解决步骤一般网络故障的解决步骤第第3章章 路由器常用诊断工具介绍路由器常用诊断工具介绍第第4章章 故障处理的常用方法故障处理的常用方法Page 网络监测与故障恢复All rights reserved一般网络故障的解决步骤l故障处理系统化是合理地一步一步找出故障原因并解决的总体原则。它的基本思想是系统地将由故障可能的原因所构成的一个大集合缩减（或隔离）成几个小的子集，从而使问题的复杂度迅速下降。Page 网络监测与故障恢复All rights reserved网络故障解决的处理流程 Page 网络监测与故障恢复All rights reserved网络故障解决的处理流程l该处理流程是网络维护人员所能够采用的排错模型中的一种，如果你根据自己的经验和实践总结了另外的排错模型并证明是行之有效的，请继续使用它网络故障解决的处理流程是可以变化的，但故障处理有序化的思维模式是不可变化的。l下面我们以一个故障处理的实例来学习如何应用这些步骤。Page 网络监测与故障恢复All rights reserved故障处理的实例 l用户网段广播包过多造成该网段的服务器FTP业务传输速度慢l该案例组网如上：某校园网的三个局域网，其中10.11.56.0为一个用户网段，10.11.56.118为一个日志服务器；10.15.0.0是一个集中了很多应用服务器的网段。网云A:10.11.56.118/24C:10.11.56.120/24B:10.15.254.253/16ETHERNETETHERNETETHERNETPage 网络监测与故障恢复All rights reserved1.故障现象描述l要想对网络故障做出准确的分析，首先应该了解故障表现出来的各种现象 l用户反映“日志服务器与备份服务器间备份发生问题。”这就是一个不完整不清晰的故障现象描述。因为这个描述没有讲述清楚下列问题：这个问题是连续出现，还是间断出现的？是完全不能备份，还是备份的速度慢（即性能下降）？哪个或哪些局域网服务器受到影响，地址是什么？l正确的故障现象描述是：在网络的高峰期，日志服务器10.11.56.11到集中备份服务器10.15.254.253之间进行备份时，FTP传输速度很慢，大约是0.6Mbps。Page 网络监测与故障恢复All rights reserved2.相关信息收集l搜集有助于查找故障原因的详细信息：向受影响的用户、网络人员或其他关键人员提出问题；根据故障描述性质，使用各种工具搜集情况，如网络管理系统、协议分析仪、相关display和debug命令等；测试性能与网络正常情况下的记录进行比较。l如上述案例，可以向用户提问或自行收集下列相关信息：网络结构或配置是否最近修改过，即问题出现是否与网络变化有关？是否有用户访问受影响的服务器时没有问题？在非高峰期日志服务器和备份服务器间FTP传输速度是多少？l通过该步骤，我们收集到了下面一些相关信息：最近10.11.56.0网段的客户机不断在增加；129.9.0.0网段的机器与备份服务器间进行FTP传输时速度正常为7Mbps，与日志服务器间进行FTP传输时速度慢，只有0.6Mbps；在非高峰期日志服务器和备份服务器间FTP传输速度正常，大约为6Mbps；Page 网络监测与故障恢复All rights reserved3.经验判断和理论分析l利用前两个步骤收集到的数据，并根据自己以往的故障处理经验和所掌握的的知识，确定一个排错范围。通过范围的划分，就只需注意某一故障或与故障情况相关的那一部分产品、介质和主机。l如上述案例，我们现在能够确定是一个网络性能下降问题。那么，是网段10.11.56.0的性能问题？是中间网络的性能问题？还是10.15.0.0网段的性能问题呢？l根据129.9.0.0网段的机器与备份服务器间进行FTP传输时速度正常为7Mbps这一事实，我们可以排除掉10.15.0.0网段的性能问题。Page 网络监测与故障恢复All rights reserved4.各种可能原因列表l该步骤列出根据经验判断和理论分析后总结的各种可能原因。l如上述案例，可能原因如下：网段10.11.56.0的性能问题，其原因可能为：日志服务器A的性能问题10.11.56.0网络的网关性能问题10.11.56.0网络本身的性能问题中间网络性能问题，主要是到网络10.15.0.0的路由不是最佳路由Page 网络监测与故障恢复All rights reserved5.对每一原因实施排错方案l根据所列出的可能原因制定故障排查计划，分析最有可能的原因，确定一次只对一个变量进行操作，这种方法使你能够重现某一故障的解决办法。如果有多个变量同时被改变，而问题得以解决，那么如何判断哪个变量导致了故障发生呢？Page 网络监测与故障恢复All rights reserved6.观察故障排查结果l当我们对某一原因执行了排错方案后，需要对结果进行分析，判断问题是否解决，是否引入了新的问题。如果问题解决，那么就可以直接进入文档化过程；如果没有解决问题，那么就需要再次循环进行到故障排查过程。Page 网络监测与故障恢复All rights reserved7.循环进行故障排查过程l在进行下一循环之前必须做的事情就是将网络恢复到实施上一方案前的状态。如果保留上一方案对网络的改动，很可能导致新的问题。l循环排错可以有两个切入点：当针对某一可能原因的排错方案没有达到预期目的，循环进入下一可能原因制定排错方案并实施；当所有可能原因列表的排错方案均没有达到排错目的，重现进行故障相关信息收集以分析新的可能原因。l如上述案例，我们在列出了可能原因列表后，开始制定方案进行故障处理：Page 网络监测与故障恢复All rights reserved7.循环进行故障排查过程l可能原因1：网络10.11.56.0到网络10.15.0.0的路由不是最佳路由。l制定的方案：在10.11.56.0网段的网关上使用“tracert 10.15.245.253”命令，发现探测报文返回时长仅为10ms，表明该可能原因并不是造成故障的原因。我们进入循环排错过程。Page 网络监测与故障恢复All rights reserved7.循环进行故障排查过程l可能原因2：日志服务器A的性能问题。l制定的方案：测试同一网段的主机C和日志服务器间的FTP传输速度，是6Mbps，正常。可见问题与服务器A无关。Page 网络监测与故障恢复All rights reserved7.循环进行故障排查过程l可能原因3：10.11.56.0网络的网关性能问题。l制定的方案：测试主机C和备份服务器B间FTP传输速度是7Mbps，正常。排除了网关因素，因为B、C在不同网段上而速度正常。Page 网络监测与故障恢复All rights reserved7.循环进行故障排查过程l可能原因4：10.11.56.0网络本身的性能问题。l制定的方案：在网段10.11.56.0的以太网交换机上使用命令“show mac”，输出如下：APort Rcv-Unicast Rcv-Multicast Rcv-Broadcast-6/32 10317812 0 8665Port Xmit-Unicast Xmit-Multicast Xmit-Broadcast-6/32 6667987 286652 2474038(输出的广播：输出的单播比例为1：3，太大了。)Port Rcv-Octet Xmit-Octet-6/32 14094829358 1516443041l在网段10.15.0.0上的以太网交换机上使用命令“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（广播：单播比例1：270，属于正常。）Port Rcv-Octet Xmit-Octet-6/36 67172587081 4998816809l由此得知，网段10.11.56.0上广播包和单播包比例为1:3，确实太大了。l再次询问用户该网段主要运行的业务是什么，而得出了故障最终原因如下：10.11.56.0是普通用户网段，由于业务原因每个用户需要发送大量广播包和多播包，随着近期越来越多的用户接入该网络，在这个网段上的服务器需要花费更多的资源来处理越来越多的广播和多播包，因此其服务的传输速度自然减慢。l这是一个网络布局不恰当的问题，需要重新安排服务器的位置，将服务器移动10.15.0.0网段后，故障解决。Page 网络监测与故障恢复All rights reserved8.故障处理过程文档化l当最终排除了网络故障后，流程的最后一步就是对所做的工作进行文字记录。l文档化过程决不是一个可有可无的工作，原因如下：文档是排错宝贵经验的总结，是“经验判断和理论分析”这一过程中最重要的参考资料；文档记录了这次排错中网络参数所做的修改，这也是下一次网络故障应收集的相关信息。l文档记录主要包括以下几个方面：故障现象描述及收集的相关信息网络拓扑图绘制网络中使用的设备清单和介质清单网络中使用的协议清单和应用清单故障发生的可能原因对每一可能原因制定的方案和实施结果本次排错的心得体会其他：如排错中使用的参考资料列表等Page 网络监测与故障恢复All rights reserved第第1章章 故障处理技术概述故障处理技术概述第第2章章 一般网络故障的解决步骤一般网络故障的解决步骤第第第第3 3章章章章 路由器常用诊断工具介绍路由器常用诊断工具介绍路由器常用诊断工具介绍路由器常用诊断工具介绍第第4章章 故障处理的常用方法故障处理的常用方法Page 网络监测与故障恢复All rights reserved路由器常用诊断工具介绍lping命令ltracert命令ldisplay命令lreset命令ldebug命令Page 网络监测与故障恢复All rights reservedPING命令l命令ping用于检查IP网络连接及主机是否可达。l“ping”这个词源于声纳定位操作，指来自声纳设备的脉冲信号。ping命令的思想与发出一个短促的雷达波，通过收集回波来判断目标很相似；即源站点向目的站点发出一个ICMP Echo Request报文，目的站点收到该报文后回一个ICMP Echo Reply报文，这样就验证了两个节点间IP层的可达性表示了网络层是连通的。l由于ping和tracert命令不仅是Quidway系列路由器VRP平台的常用网络命令，也是windows平台上常用的网络命令，下面对两种平台下的命令使用均进行介绍。Page 网络监测与故障恢复All rights reservedPING命令l在Quidway系列路由器上，ping命令的格式如下：lping-Rdnqrv-c count-p pattern-s packetsize-t timeout hostl-a ping报文中使用的源IP地址l-c ping报文的个数，缺省值为5；l-t 设置ping报文的超时时间，单位为毫秒，缺省值为2000；l-s 设置ping报文的大小，以字节为单位，缺省值为56。Page 网络监测与故障恢复All rights reservedPING命令l在PC机上或Windwos NT为平台的服务器上，ping命令的格式如下：lping -n number -t -l number ip-addressl-n ping报文的个数，缺省值为5；l-t 持续地ping 直到人为地中断，Ctr+Breack暂时中止ping命令并查看当前的统计结果，而Ctr+C则中断命令的执行。l-l 设置ping报文所携带的数据部分的字节数，设置范围从0至65500。Page 网络监测与故障恢复All rights reserved用ping命令进行故障处理l工程师小L，在配置完一台路由器之后执行ping命令检测链路是否通畅。发现5个报文都没有ping通，小L断定是连通性问题。l检查双方的配置命令并查看路由表，却一直没有找到错误所在。最后又重复执行了一遍相同的ping命令，发现这一次5个报文中有1个ping 通了原来是线路质量不好存在比较严重的丢包现象。案例一 连通性问题还是性能问题？Page 网络监测与故障恢复All rights reserved用ping命令进行故障处理l工程师小L又配置了一台路由器，然后执行ping命令访问Internet上某站点的IP地址，但没有ping通。有了上次的教训小L，再一次ping了20个报文，仍旧没有响应。于是这次小L觉得能够断定是连通性故障。l在费劲周折检查了配置链路之后仍没有发现任何可疑之处，最后小L采取逐段检测的方法对链路中的网关进行逐级测试，发现都可以ping 通，但是响应的时间越来越长，最后一个网关的响应时间在1800ms左右。会不会是由于超时而导致显示为ping 不同呢？受此启发，小L将ping 命令报文的超时时间改为4000ms，这次成功ping通了，显示所有的报文响应时间都在2200ms 左右。案例一 连通性问题还是性能问题？Page 网络监测与故障恢复All rights reserved用ping命令进行故障处理建议和总结：建议和总结：l真的是ping不通吗？这个问题需要定位清楚，因为连通性问题和性能问题排错的关注点是不一样的问题定位错误必然会导致排错过程的周折。l使用一般的ping命令，缺省是发送5个报文的，超时时长是2000ms。如果ping不通情况发生，最好能够再用带参数-c和-t的ping命令再执行一遍，如：ping-c 20-t 4000 ip-address，即连续发送20个报文，每个报文的超时时长为4000ms，这样一般可以判断出到底是连通性问题还是性能问题。案例一 连通性问题还是性能问题？Page 网络监测与故障恢复All rights reserved用ping命令进行故障处理l某次开局，使用Quidway路由器与其他厂商的某路由器互连，并运行OSPF协议。数据配置完毕后，一切正常，并在今后相当长的时间内设备运转稳定。但两个月后，用户反馈网络中断。案例二 使用大包ping对端进行MTU不一致的故障处理？Page 网络监测与故障恢复All rights reserved用ping命令进行故障处理相关信息显示：相关信息显示：l登录到两台路由器上，发现双方连接正常，可以相互ping通对端地址。但OSPF协议中断；l登录Quidway路由器查看邻居状态，发现邻居状态机处于Exstart状态。打开相应的debug开关查看相应的报文信息，发现双方都可以收到Hello报文，但Quidway路由器发送DD报文后，一直没有收到对方回应的DD报文；l登录其他厂商的那台路由器，打开相应的debug开关，发现对方收到Quidway路由器发送的DD报文后，已发送了相应的DD报文予以回应。案例二 使用大包ping对端进行MTU不一致的故障处理？Page 网络监测与故障恢复All rights reserved用ping命令进行故障处理原因分析：原因分析：l初步断定，Quidway路由器没有收到DD回应报文，但对方确实发出来了。l既然可以接收到HELLO 报文说明链路是通畅的，而且多播报文的收发也没有问题。那么有可能是对方发送的DD 报文有错误导致Quidway路由器拒收，但查看相应的信息，并没有报告接收到错误的DD 报文。l仔细查看某厂商路由器的调试信息发现这个DD报文很大有2000 多字节。会不会是由于报文太大导致的问题呢？试着ping了一个2000字节的报文，结果不通。那么故障原因很可能是由于双方的MTU不一致导致大包不通。案例二 使用大包ping对端进行MTU不一致的故障处理？Page 网络监测与故障恢复All rights reserved用ping命令进行故障处理处理过程：处理过程：l检查配置，发现对方路由器的MTU设置为4000多而Quidway路由器的MTU设置为1500，于是修改对端路由器的MTU为1500。故障消除。l那么为什么工程初期没有问题呢？这是因为前期DD报文长度小于1500字节，而后来网络扩容导致路由信息过多使DD 报文的长度超过了1500 字节。案例二 使用大包ping对端进行MTU不一致的故障处理？Page 网络监测与故障恢复All rights reserved用ping命令进行故障处理建议和总结：建议和总结：l由于ping 缺省报文是56 个字节，所以显示的ping 通信息只是表示56字节的报文可以通而并不一定表示其他大小的报文仍旧可以通。所以，应当善于使用ping的其他参数来进行故障处理。案例二 使用大包ping对端进行MTU不一致的故障处理？Page 网络监测与故障恢复All rights reserved用ping命令进行故障处理l在RouterA上配置一条指向2.0.0.0/8的静态路由：Quidway ip route-static 2.0.0.0 255.0.0.0 1.1.1.1l在RouterA 上ping路由器RouterB 的以太网地址2.2.2.2，显示可以正常ping通；但是在RouterB上ping路由器RouterA的以太网地址3.3.3.3，却无法ping通。E0:3.3.3.3/8E0:2.2.2.2/8S0:1.1.1.1/8S0:1.1.1.2/8RouterARouterB案例三 A能ping通B，B就一定能ping通A吗？Page 网络监测与故障恢复All rights reserved用ping命令进行故障处理原因分析：原因分析：l由于在RouterB上没有相应的配置到3.0.0.0/8 路由，所以在RouterB上ping不通RouterA的以太网口3.3.3.3。l但是为何在A上可以ping 通2.2.2.2 呢？同样是没有回程路由。打开路由器上的IP报文调试开关发现，原来从RouterA上发出的ICMP报文的源地址填写的是1.1.1.1而不是3.3.3.3，由于两台路由器的s0口处于同一网段，所以响应报文可以顺利到达RouterB。案例三 A能ping通B，B就一定能ping通A吗？Page 网络监测与故障恢复All rights reserved用ping命令进行故障处理建议和总结：建议和总结：lA能够ping通B则B一定能够ping通A（不考虑防火墙的因素）,这句话的对错取决于A和B到底是指主机还是指路由器。如果是指两台主机，那么这句话就是正确的。如果是指两台路由器那就是错误的，因为路由器通常会有多个IP地址。现在就有如下问题：当从一台路由器上执行ping命令它发出的ICMP Echo报文的源地址究竟选择哪一个呢？实际情况是路由器选择发出报文的接口的IP地址。案例三 A能ping通B，B就一定能ping通A吗？Page 网络监测与故障恢复All rights reservedTRACERT 命令ltracert 命令用于测试数据报文从发送主机到目的地所经过的网关，主要用于检查网络连接是否可达，以及分析网络什么地方发生了故障。ltracert利用IP报文的TTL域在每经过一个路由器的转发后减一，当TTL=0时则向源节点报告TTL超时这个的特性。tracert首先发送一个TTL为1的UDP报文，因此第一跳发送回一个ICMP错误消息以指明此数据报不能被发送（因为TTL超时），之后tracert再发送一个TTL为2的报文，同样第二跳返回TTL超时，这个过程不断进行，直到到达目的地，此时由于数据报中使用了无效的端口号（缺省为33434）此时目的主机会返回一个ICMP的目的地不可达消息，表明该tracert操作结束。tracert记录下每一个ICMP TTL超时消息的源地址，从而提供给用户报文到达目的地所经过的网关IP地址。Page 网络监测与故障恢复All rights reservedTRACERT 命令l在华为Quidway系列路由器上，tracert命令的格式如下：ltracert -a ip-address -f first_TTL -m max_TTL -p port -q nqueries -w timeout hostl-a 指定一个发送UDP报文的源地址；l-f 指定初始报文的TTL大小，缺省值为1；l-m 指定最大TTL大小，缺省值为30；l-p 目的主机的端口号，缺省值为33434；l-q 每次发送的探测报文的个数，缺省值为3；l-w 指明UDP报文的超时时间，单位为毫秒，缺省值为5000。Page 网络监测与故障恢复All rights reservedTRACERT命令l在PC机上或Windwos NT为平台的服务器上，tracert命令的格式如下：ltracert -d -h maximum_hops -j host-list -w timeout hostl-d 不解析主机名；l-h 指定最大TTL大小；l-j 设定松散源地址路由列表；l-w 用于设置UDP报文的超时时间，单位毫秒；Page 网络监测与故障恢复All rights reserved使用tracert命令进行故障处理l某校园网中，RouterB和RouterC同属于一个运行RIPv2路由协议的网络，主机4.0.0.2访问数据库服务器5.0.0.2，用户抱怨访问性能差。5.0.0.2/8网云RIP域4.0.0.2/8E0:3.0.0.1/8S0:1.0.0.1/8S1:2.0.0.1/8S0:1.0.0.2/8s1:2.0.0.2/8RouterARouterARouterBRouterBRouterCRouterC案例一 使用tracert命令定位不当的网络配置点Page 网络监测与故障恢复All rights reserved使用tracert命令进行故障处理相关信息显示相关信息显示l登录到RouterC，使用带参数的ping远端服务器5.0.0.2，显示如下：RouterC ping-c 10-s 4000-t 6000 5.0.0.2 PING 5.0.0.2:4000 data bytes,press CTRL_C to break Reply from 5.0.0.2:bytes=4000 Sequence=0 ttl=249 time=552 ms Reply from 5.0.0.2:bytes=4000 Sequence=1 ttl=249 time=5733 ms Reply from 5.0.0.2:bytes=4000 Sequence=2 ttl=249 time=552 ms Reply from 5.0.0.2:bytes=4000 Sequence=3 ttl=249 time=5714 ms Reply from 5.0.0.2:bytes=4000 Sequence=4 ttl=249 time=552 ms Reply from 5.0.0.2:bytes=4000 Sequence=5 ttl=249 time=5711 ms Reply from 5.0.0.2:bytes=4000 Sequence=6 ttl=249 time=552 ms Reply from 5.0.0.2:bytes=4000 Sequence=7 ttl=249 time=5709 ms Reply from 5.0.0.2:bytes=4000 Sequence=8 ttl=249 time=552 ms Reply from 5.0.0.2:bytes=4000 Sequence=9 ttl=249 time=5710 ms案例一 使用tracert命令定位不当的网络配置点Page 网络监测与故障恢复All rights reserved使用tracert命令进行故障处理原因分析原因分析l上面的ping显示出一个规律：奇数报文的返回时长短，而偶数报文返回时长很长（是奇数报文的10倍多）。可以初步判断奇数报文和偶数报文是通过不同的路径传输的。现在我们需要使用tracert命令来追踪这不同的路径。在RouterC上，tracert远端RouterA的以太网接口5.0.0.1。RouterC tracert-q 8 5.0.0.1 traceroute to 5.0.0.1(5.0.0.1)30 hops max,40 bytes packet 1 4.0.0.1 6 ms 4 ms 4 ms 4 ms 4 ms 4 ms 4 ms 4 ms 5 3.0.0.2 20 ms 16 ms 15 ms 16 ms 16 ms 16 ms 16 ms 16 ms 6 5.0.0.1 30 ms 278 ms 25 ms 279 ms 25 ms 278 ms 25 ms 277 msRouterC(config)#从上面的显示可看到，直至3.0.0.2，UDP探测报文的返回时长都基本一致，而到5.0.0.1时，则发生明显变化，呈现奇数报文时长短，偶数报文时长长的现象。于是判断，问题发生在RouterB和RouterA之间。案例一 使用tracert命令定位不当的网络配置点Page 网络监测与故障恢复All rights reserved使用tracert命令进行故障处理原因分析原因分析l通过询问该段网络的管理员，得知这两路由器间有一主一备两串行链路，主链路为2.048Mbps（s0口之间），备份链路为128Kbps（s1口之间）。网络管理员在此两路由器间配置了静态路由。RouterB上如下配置：RouterB ip route-static 5.0.0.0 255.0.0.0 1.0.0.2RouterB ip route-static 5.0.0.0 255.0.0.0 2.0.0.2RouterA上如下配置：RouterA ip route-static 0.0.0.0 0.0.0.0 1.0.0.1RouterA ip route-static 0.0.0.0 0.0.0.0 2.0.0.1 于是问题就清楚了。例如RouterB，由于管理员配置时没有给出静态路由的优先级，这两条路由项的优先级就同为缺省值60，于是就同时出现在路由表中，实现的是负载分担，而不能达到主备的目的。案例一 使用tracert命令定位不当的网络配置点Page 网络监测与故障恢复All rights reserved使用tracert命令进行故障处理处理过程，可以有两种处理方法：处理过程，可以有两种处理方法：l继续使用静态路由，进行配置更改RouterB上进行如下更改：RouterB ip route-static 5.0.0.0 255.0.0.0 1.0.0.2（主链路仍使用缺省优先级60）RouterBip route-static 5.0.0.0 255.0.0.0 2.0.0.2 100（备份链路的优先级降低至100）RouterA上进行如下更改：RouterA ip route-static 0.0.0.0 0.0.0.0 1.0.0.1RouterA ip route-static 0.0.0.0 0.0.0.0 2.0.0.1 100这样，只有当主链路发生故障，备份链路的路由项才会出线在路由表中，从而接替主链路完成报文转发，实现主备目的。l在两路由器上运行动态路由协议，如OSPF等，但不要运行RIP协议（因为RIP协议仅以hop作为Metric的）案例一 使用tracert命令定位不当的网络配置点Page 网络监测与故障恢复All rights reserved使用tracert命令进行故障处理建议和总结建议和总结l本案例的目的不是为了解释网络配置问题，而是用来展示ping命令和tracert命令的相互配合来找到网络问题的发生点。尤其在一个大的组网环境中，维护人员可能无法沿着路径逐机排查，此时，能够迅速定位出发生问题的线路或路由器就非常重要了。案例一 使用tracert命令定位不当的网络配置点Page 网络监测与故障恢复All rights reserved使用tracert命令进行故障处理l三台路由器均配置静态路由，完成后，登录到RouterA上ping主机4.0.0.2，发现不通。E1:4.0.0.1/84.0.0.2/8E0:3.0.0.1/8E0:3.0.0.2/8S0:1.0.0.2/8RouterARouterBRouterC案例二 使用tracert命令发现路由环路Page 网络监测与故障恢复All rights reserved使用tracert命令进行故障处理相关信息显示相关信息显示RouterA ping-c 6-t 5000 4.0.0.2 PING 4.0.0.1:56 data bytes,press CTRL_C to break Request time out Request time out Request time out Request time out Request time out Request time outRouterA tracert 4.0.0.2 traceroute to 4.0.0.2(4.0.0.2)30 hops max,40 bytes packet 1 1.0.0.1 6 ms 4 ms 4 ms （RouterB）2 1.0.0.2 8 ms 8 ms 8 ms （RouterA）3 1.0.0.1 12 ms 12 ms 12 ms（RouterB）4 1.0.0.2 16 ms 16 ms 16 ms（RouterA）案例二 使用tracert命令发现路由环路Page 网络监测与故障恢复All rights reserved使用tracert命令进行故障处理原因分析原因分析l从上面的tracert命令的显示可以立即发现，在RouterA和RouterB间产生了路由环路。由于是配置的是静态路由，基本可以断定是RouterA或RouterB的静态路由配置错误。l检查RouterA的路由表，配置的是缺省静态路由：ip route-static 0.0.0.0 0.0.0.0 1.0.0.1，没有问题。l检查RouterB的路由表，配置到4.0.0.0网络的静态路由为：ip route-static 4.0.0.0 255.0.0.0 1.0.0.2下一跳配置的是1.0.0.2，而不是3.0.0.1。这正是错误所在。案例二 使用tracert命令发现路由环路Page 网络监测与故障恢复All rights reserved使用tracert命令进行故障处理处理过程处理过程修改RouterB的配置如下：RouterB no ip route-static 4.0.0.0 255.0.0.0 1.0.0.2RouterB ip route-static 4.0.0.0 255.0.0.0 3.0.0.1故障处理完成。案例二 使用tracert命令发现路由环路Page 网络监测与故障恢复All rights reserved使用tracert命令进行故障处理建议和总结建议和总结ltracert命令能够很容易发现路由环路等潜在问题。当路由器A认为路由器B知道到达目的地的路径，而路由器B也认为路由器A知道目的地时，就是路由环路发生了。使用ping命令只能知道接收端出现超时错误，而tracert能够立即发现环路所在如果tracert命令两次或者多次显示同样的接口。l当通过tracert发现路由环路后，如果配置为：静态路由：几乎可以肯定是手工配置有问题。单动态路由协议：可能是地址聚合产生的问题。多动态路由协议：可能是路由引入产生的问题。案例二 使用tracert命令发现路由环路Page 网络监测与故障恢复All rights reservedDISPLAY命令ldisplay命令是用于了解路由器的当前状况、检测相邻路由器、从总体上监控网络、隔离因特网络中故障的最重要的工具之一。几乎在任何故障处理和监控场合，display命令都是必不可少的。l这里仅介绍部分最常用的、全局性的display命令，而与各协议相关的display命令，将在后面章节相应的协议故障处理中详细介绍。Page 网络监测与故障恢复All rights reservedDisplay Versionl该命令将帮助用户收集下列信息：VRP软件版本是哪一系列的路由器设备运行时间处理器的信息RAM的容量配置寄存器的设置固件的版本引导程序的版本l不同型号的设备显示的内容可能会略有差别lQuidwaydisplay versionl Huawei Versatile Routing Platform Softwarel VRP(tm)software,Version 1.44 Release 0006l Copyright(c)1997-2002 HUAWEI TECH CO.,LTD.l Compiled 20:42:52,Jun 12 2003,l Quidway R2511 uptime is 0 days 7 hours 40 minutes 13 seconds,l System returned to ROM by power-on.l Quidway R2511 with 1 68360 Processorl Router serial number is 00E0FC05D5C76A40l