网络设备故障排除

《网络设备故障排除》由会员分享，可在线阅读，更多相关《网络设备故障排除（77页珍藏版）》请在装配图网上搜索。

1、网络设备故障排除2内容提要p网络故障处理技术概述p一般网络故障的解决步骤pQuidway中低端路由器产品介绍p路由器常用诊断工具介绍p故障处理常用方法p故障处理对网络维护和管理人员的要求3网络故障处理技术概述当今的网络互连环境是复杂的，而且其复杂性的还在日益增长，主要原因如下：p现代的因特网络要求支持更广泛的应用，包括数据、语音、视频及它们的集成传输；p新业务发展使网络带宽的需求不断增长，这就要求新技术的不断出现。例如：十兆以太网向百兆、千兆以太网的演进；MPLS技术的出现；提供QoS能力等。p新技术的应用同时还要兼顾传统的技术。例如，传统的SNA体系结构仍在某些场合使用，DLSw作为通过TC

2、P/IP承载SNA的一种技术而被应用。4网络故障处理技术概述p能够正确地维护网络尽量不出现故障，并确保出现故障之后能够迅速、准确地定位问题并排除故障，对网络维护和管理人员来说是个挑战。p这不但要求对网络协议和技术有着深入的理解，更重要的是要建立一个系统化的故障处理思想并合理应用于实际中，以将一个复杂的问题隔离、分解或缩减排错范围，从而及时修复网络故障。5网络故障的一般分类连通性问题p硬件、媒介、电源故障p配置错误p不正确的相互作用性能问题p网络拥塞p到目的地不是最佳路由p供电不足p路由环路p网络错误6一般网络故障的解决步骤p故障处理系统化是合理地一步一步找出故障原因并解决的总体原则。它的基本思

3、想是系统地将由故障可能的原因所构成的一个大集合缩减（或隔离）成几个小的子集，从而使问题的复杂度迅速下降。7网络故障解决的处理流程 故障现象观察故障相关信息收集经验判断和理论分析各种可能原因列表对每一原因实施排错方案故障排除？恢复实施方案前的网络状态故障排除过程文档化循环1循环2NY8网络故障解决的处理流程p该处理流程是网络维护人员所能够采用的排错模型中的一种，如果你根据自己的经验和实践总结了另外的排错模型并证明是行之有效的，请继续使用它网络故障解决的处理流程是可以变化的，但故障处理有序化的思维模式是不可变化的。p下面我们以一个故障处理的实例来学习如何应用这些步骤。9故障处理的实例 p该案例组网

4、如上：某校园网的三个局域网，其中10.11.56.0为一个用户网段，10.11.56.118为一个日志服务器；10.15.0.0是一个集中了很多应用服务器的网段。用户网段广播包过多造成该网段的服务器FTP业务传输速度慢网云A:10.11.56.118/24C:10.11.56.120/24B:10.15.254.253/16D:129.9.35.53/16ETHERNETETHERNETETHERNET101.故障现象描述p要想对网络故障做出准确的分析，首先应该了解故障表现出来的各种现象 p用户反映“日志服务器与备份服务器间备份发生问题。”这就是一个不完整不清晰的故障现象描述。因为这个描述没有

5、讲述清楚下列问题：n这个问题是连续出现，还是间断出现的？n是完全不能备份，还是备份的速度慢（即性能下降）？n哪个或哪些局域网服务器受到影响，地址是什么？p正确的故障现象描述是：n在网络的高峰期，日志服务器10.11.56.11到集中备份服务器10.15.254.253之间进行备份时，FTP传输速度很慢，大约是0.6Mbps。112.相关信息收集p搜集有助于查找故障原因的详细信息：n向受影响的用户、网络人员或其他关键人员提出问题；n根据故障描述性质，使用各种工具搜集情况，如网络管理系统、协议分析仪、相关display和debug命令等；n测试性能与网络正常情况下的记录进行比较。p如上述案例，可以

6、向用户提问或自行收集下列相关信息：n网络结构或配置是否最近修改过，即问题出现是否与网络变化有关？n是否有用户访问受影响的服务器时没有问题？n在非高峰期日志服务器和备份服务器间FTP传输速度是多少？p通过该步骤，我们收集到了下面一些相关信息：n最近10.11.56.0网段的客户机不断在增加；n129.9.0.0网段的机器与备份服务器间进行FTP传输时速度正常为7Mbps，与日志服务器间进行FTP传输时速度慢，只有0.6Mbps；n在非高峰期日志服务器和备份服务器间FTP传输速度正常，大约为6Mbps；123.经验判断和理论分析p利用前两个步骤收集到的数据，并根据自己以往的故障处理经验和所掌握的的

7、知识，确定一个排错范围。通过范围的划分，就只需注意某一故障或与故障情况相关的那一部分产品、介质和主机。p如上述案例，我们现在能够确定是一个网络性能下降问题。那么，是网段10.11.56.0的性能问题？是中间网络的性能问题？还是10.15.0.0网段的性能问题呢？p根据129.9.0.0网段的机器与备份服务器间进行FTP传输时速度正常为7Mbps这一事实，我们可以排除掉10.15.0.0网段的性能问题。134.各种可能原因列表p该步骤列出根据经验判断和理论分析后总结的各种可能原因。p如上述案例，可能原因如下：n网段10.11.56.0的性能问题，其原因可能为：p日志服务器A的性能问题p10.11

8、.56.0网络的网关性能问题p10.11.56.0网络本身的性能问题n中间网络性能问题，主要是到网络10.15.0.0的路由不是最佳路由145.对每一原因实施排错方案p根据所列出的可能原因制定故障排查计划，分析最有可能的原因，确定一次只对一个变量进行操作，这种方法使你能够重现某一故障的解决办法。如果有多个变量同时被改变，而问题得以解决，那么如何判断哪个变量导致了故障发生呢？156.观察故障排查结果p当我们对某一原因执行了排错方案后，需要对结果进行分析，判断问题是否解决，是否引入了新的问题。如果问题解决，那么就可以直接进入文档化过程；如果没有解决问题，那么就需要再次循环进行到故障排查过程。167

9、.循环进行故障排查过程p在进行下一循环之前必须做的事情就是将网络恢复到实施上一方案前的状态。如果保留上一方案对网络的改动，很可能导致新的问题。p循环排错可以有两个切入点：n当针对某一可能原因的排错方案没有达到预期目的，循环进入下一可能原因制定排错方案并实施；n当所有可能原因列表的排错方案均没有达到排错目的，重现进行故障相关信息收集以分析新的可能原因。p如上述案例，我们在列出了可能原因列表后，开始制定方案进行故障处理：177.循环进行故障排查过程p可能原因1：网络10.11.56.0到网络10.15.0.0的路由不是最佳路由。p制定的方案：在10.11.56.0网段的网关上使用“tracert

10、10.15.245.253”命令，发现探测报文返回时长仅为10ms，表明该可能原因并不是造成故障的原因。我们进入循环排错过程。187.循环进行故障排查过程p可能原因2：日志服务器A的性能问题。p制定的方案：测试同一网段的主机C和日志服务器间的FTP传输速度，是6Mbps，正常。可见问题与服务器A无关。197.循环进行故障排查过程p可能原因3：10.11.56.0网络的网关性能问题。p制定的方案：测试主机C和备份服务器B间FTP传输速度是7Mbps，正常。排除了网关因素，因为B、C在不同网段上而速度正常。207.循环进行故障排查过程p可能原因4：10.11.56.0网络本身的性能问题。p制定的方

11、案：在网段10.11.56.0的以太网交换机上使用命令“show mac”，输出如下：Port 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 1516443041p在网段10.15.0.0上的以太网交换机上使用命令“show mac”输出如下

12、：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 4998816809p由此得知，网段10.11.56.0上广播包和单播包比例为1:3，确实太大了。p再次询问用户该网段主要运行的业务是什么，而得出了故障最终原因如下：10.11.56.0是普通用

13、户网段，由于业务原因每个用户需要发送大量广播包和多播包，随着近期越来越多的用户接入该网络，在这个网段上的服务器需要花费更多的资源来处理越来越多的广播和多播包，因此其服务的传输速度自然减慢。p这是一个网络布局不恰当的问题，需要重新安排服务器的位置，将服务器移动10.15.0.0网段后，故障解决。218.故障处理过程文档化p当最终排除了网络故障后，流程的最后一步就是对所做的工作进行文字记录。p文档化过程决不是一个可有可无的工作，原因如下：n文档是排错宝贵经验的总结，是“经验判断和理论分析”这一过程中最重要的参考资料；n文档记录了这次排错中网络参数所做的修改，这也是下一次网络故障应收集的相关信息。p

14、文档记录主要包括以下几个方面：n故障现象描述及收集的相关信息n网络拓扑图绘制n网络中使用的设备清单和介质清单n网络中使用的协议清单和应用清单n故障发生的可能原因n对每一可能原因制定的方案和实施结果n本次排错的心得体会n其他：如排错中使用的参考资料列表等22路由器常用诊断工具介绍pping命令ptracert命令pdisplay命令preset命令pdebug命令23PING命令p命令ping用于检查IP网络连接及主机是否可达。p“ping”这个词源于声纳定位操作，指来自声纳设备的脉冲信号。ping命令的思想与发出一个短促的雷达波，通过收集回波来判断目标很相似；即源站点向目的站点发出一个ICMP

15、 Echo Request报文，目的站点收到该报文后回一个ICMP Echo Reply报文，这样就验证了两个节点间IP层的可达性表示了网络层是连通的。p由于ping和tracert命令不仅是Quidway系列路由器VRP平台的常用网络命令，也是windows平台上常用的网络命令，下面对两种平台下的命令使用均进行介绍。24PING命令在Quidway系列路由器上，ping命令的格式如下：ping-Rdnqrv-c count-p pattern-s packetsize-t ping-Rdnqrv-c count-p pattern-s packetsize-t timeout hosttim

16、eout host-a ping报文中使用的源IP地址-c ping报文的个数，缺省值为5；-t 设置ping报文的超时时间，单位为毫秒，缺省值为2000；-s 设置ping报文的大小，以字节为单位，缺省值为56。25PING命令在PC机上或Windwos NT为平台的服务器上，ping命令的格式如下：ping -n ping -n number number -t -l -t -l numbernumber ip-addressip-address-n ping报文的个数，缺省值为5；-t 持续地ping 直到人为地中断，Ctr+Breack暂时中止ping命令并查看当前的统计结果，而Ctr

17、+C则中断命令的执行。-l 设置ping报文所携带的数据部分的字节数，设置范围从0至65500。26用ping命令进行故障处理案例一 连通性问题还是性能问题？p工程师小L，在配置完一台路由器之后执行ping命令检测链路是否通畅。发现5个报文都没有ping通，小L断定是连通性问题。p检查双方的配置命令并查看路由表，却一直没有找到错误所在。最后又重复执行了一遍相同的ping命令，发现这一次5个报文中有1个ping 通了原来是线路质量不好存在比较严重的丢包现象。27用ping命令进行故障处理案例一 连通性问题还是性能问题？p工程师小L又配置了一台路由器，然后执行ping命令访问Internet上某站

18、点的IP地址，但没有ping通。有了上次的教训小L，再一次ping了20个报文，仍旧没有响应。于是这次小L觉得能够断定是连通性故障。p在费劲周折检查了配置链路之后仍没有发现任何可疑之处，最后小L采取逐段检测的方法对链路中的网关进行逐级测试，发现都可以ping 通，但是响应的时间越来越长，最后一个网关的响应时间在1800ms左右。会不会是由于超时而导致显示为ping 不同呢？受此启发，小L将ping 命令报文的超时时间改为4000ms，这次成功ping通了，显示所有的报文响应时间都在2200ms 左右。28用ping命令进行故障处理案例一 连通性问题还是性能问题？建议和总结：p真的是ping不通

19、吗？这个问题需要定位清楚，因为连通性问题和性能问题排错的关注点是不一样的问题定位错误必然会导致排错过程的周折。p使用一般的ping命令，缺省是发送5个报文的，超时时长是2000ms。如果ping不通情况发生，最好能够再用带参数-c和-t的ping命令再执行一遍，如：ping-c 20-t 4000 ip-address，即连续发送20个报文，每个报文的超时时长为4000ms，这样一般可以判断出到底是连通性问题还是性能问题。29用ping命令进行故障处理案例二 使用大包ping对端进行MTU不一致的故障处理？p某次开局，使用Quidway路由器与其他厂商的某路由器互连，并运行OSPF协议。数据配

20、置完毕后，一切正常，并在今后相当长的时间内设备运转稳定。但两个月后，用户反馈网络中断。30用ping命令进行故障处理案例二 使用大包ping对端进行MTU不一致的故障处理？相关信息显示：p登录到两台路由器上，发现双方连接正常，可以相互ping通对端地址。但OSPF协议中断；p登录Quidway路由器查看邻居状态，发现邻居状态机处于Exstart状态。打开相应的debug开关查看相应的报文信息，发现双方都可以收到Hello报文，但Quidway路由器发送DD报文后，一直没有收到对方回应的DD报文；p登录其他厂商的那台路由器，打开相应的debug开关，发现对方收到Quidway路由器发送的DD报文

21、后，已发送了相应的DD报文予以回应。31用ping命令进行故障处理案例二 使用大包ping对端进行MTU不一致的故障处理？原因分析：p初步断定，Quidway路由器没有收到DD回应报文，但对方确实发出来了。p既然可以接收到HELLO 报文说明链路是通畅的，而且多播报文的收发也没有问题。那么有可能是对方发送的DD 报文有错误导致Quidway路由器拒收，但查看相应的信息，并没有报告接收到错误的DD 报文。p仔细查看某厂商路由器的调试信息发现这个DD报文很大有2000 多字节。会不会是由于报文太大导致的问题呢？试着ping了一个2000字节的报文，结果不通。那么故障原因很可能是由于双方的MTU不一

22、致导致大包不通。32用ping命令进行故障处理案例二 使用大包ping对端进行MTU不一致的故障处理？处理过程：p检查配置，发现对方路由器的MTU设置为4000多而Quidway路由器的MTU设置为1500，于是修改对端路由器的MTU为1500。故障消除。p那么为什么工程初期没有问题呢？这是因为前期DD报文长度小于1500字节，而后来网络扩容导致路由信息过多使DD 报文的长度超过了1500 字节。33用ping命令进行故障处理案例二 使用大包ping对端进行MTU不一致的故障处理？建议和总结：p由于ping 缺省报文是56 个字节，所以显示的ping 通信息只是表示56字节的报文可以通而并不一

23、定表示其他大小的报文仍旧可以通。所以，应当善于使用ping的其他参数来进行故障处理。34用ping命令进行故障处理案例三 A能ping通B，B就一定能ping通A吗？p在RouterA上配置一条指向2.0.0.0/8的静态路由：Quidway ip route-static 2.0.0.0 255.0.0.0 1.1.1.1p在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/8S

24、0:1.1.1.2/8RouterARouterB35用ping命令进行故障处理案例三 A能ping通B，B就一定能ping通A吗？原因分析：p由于在RouterB上没有相应的配置到3.0.0.0/8 路由，所以在RouterB上ping不通RouterA的以太网口3.3.3.3。p但是为何在A上可以ping 通2.2.2.2 呢？同样是没有回程路由。打开路由器上的IP报文调试开关发现，原来从RouterA上发出的ICMP报文的源地址填写的是1.1.1.1而不是3.3.3.3，由于两台路由器的s0口处于同一网段，所以响应报文可以顺利到达RouterB。36用ping命令进行故障处理案例三 A能

25、ping通B，B就一定能ping通A吗？建议和总结：pA能够ping通B则B一定能够ping通A（不考虑防火墙的因素）,这句话的对错取决于A和B到底是指主机还是指路由器。n如果是指两台主机，那么这句话就是正确的。n如果是指两台路由器那就是错误的，因为路由器通常会有多个IP地址。现在就有如下问题：当从一台路由器上执行ping命令它发出的ICMP Echo报文的源地址究竟选择哪一个呢？实际情况是路由器选择发出报文的接口的IP地址。37TRACERT 命令ptracert 命令用于测试数据报文从发送主机到目的地所经过的网关，主要用于检查网络连接是否可达，以及分析网络什么地方发生了故障。ptracer

26、t利用IP报文的TTL域在每经过一个路由器的转发后减一，当TTL=0时则向源节点报告TTL超时这个的特性。tracert首先发送一个TTL为1的UDP报文，因此第一跳发送回一个ICMP错误消息以指明此数据报不能被发送（因为TTL超时），之后tracert再发送一个TTL为2的报文，同样第二跳返回TTL超时，这个过程不断进行，直到到达目的地，此时由于数据报中使用了无效的端口号（缺省为33434）此时目的主机会返回一个ICMP的目的地不可达消息，表明该tracert操作结束。tracert记录下每一个ICMP TTL超时消息的源地址，从而提供给用户报文到达目的地所经过的网关IP地址。38TRACE

27、RT 命令在华为Quidway系列路由器上，tracert命令的格式如下：tracert -a ip-address -f first_TTL -m max_TTL -p port -q nqueries -w timeout host-a 指定一个发送UDP报文的源地址；-f 指定初始报文的TTL大小，缺省值为1；-m 指定最大TTL大小，缺省值为30；-p 目的主机的端口号，缺省值为33434；-q 每次发送的探测报文的个数，缺省值为3；-w 指明UDP报文的超时时间，单位为毫秒，缺省值为5000。39TRACERT命令在PC机上或Windwos NT为平台的服务器上，tracert命令的

28、格式如下：tracert -d -h maximum_hops -j host-list -w timeout host-d 不解析主机名；-h 指定最大TTL大小；-j 设定松散源地址路由列表；-w 用于设置UDP报文的超时时间，单位毫秒；40使用tracert命令进行故障处理案例一 使用tracert命令定位不当的网络配置点p某校园网中，RouterB和RouterC同属于一个运行RIPv2路由协议的网络，主机4.0.0.2访问数据库服务器5.0.0.2，用户抱怨访问性能差。网云RIP域E1:4.0.0.1/84.0.0.2/8E0:3.0.0.1/8S0:1.0.0.1/8S1:2.0.

29、0.1/8S0:1.0.0.2/8s1:2.0.0.2/85.0.0.2/8RouterARouterARouterBRouterBRouterCRouterC41使用tracert命令进行故障处理案例一 使用tracert命令定位不当的网络配置点相关信息显示p登录到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=

30、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 Se

31、quence=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 ms42使用tracert命令进行故障处理案例一 使用

32、tracert命令定位不当的网络配置点原因分析p上面的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

33、 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之间。43使用tracert命令进行故障处理案例一 使用tracert命令定位不当的网络配置点原因分析p通过询问该段

34、网络的管理员，得知这两路由器间有一主一备两串行链路，主链路为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.

35、0.0.1 于是问题就清楚了。例如RouterB，由于管理员配置时没有给出静态路由的优先级，这两条路由项的优先级就同为缺省值60，于是就同时出现在路由表中，实现的是负载分担，而不能达到主备的目的。44使用tracert命令进行故障处理案例一 使用tracert命令定位不当的网络配置点处理过程，可以有两种处理方法：p继续使用静态路由，进行配置更改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

36、 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这样，只有当主链路发生故障，备份链路的路由项才会出线在路由表中，从而接替主链路完成报文转发，实现主备目的。p在两路由器上运行动态路由协议，如OSPF等，但不要运行RIP协议（因为RIP协议仅以hop作为Metric的）45使用tracert命令进行故障处理案例一 使用tracert命令定位不当的网络配置点建议和总结p本案例的目的不是

37、为了解释网络配置问题，而是用来展示ping命令和tracert命令的相互配合来找到网络问题的发生点。尤其在一个大的组网环境中，维护人员可能无法沿着路径逐机排查，此时，能够迅速定位出发生问题的线路或路由器就非常重要了。46使用tracert命令进行故障处理案例二 使用tracert命令发现路由环路p三台路由器均配置静态路由，完成后，登录到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/8S0:1.0.0.2/8E0:3.0.0.2/8RouterARouterBRouterC47

38、使用tracert命令进行故障处理案例二 使用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

39、 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）48使用tracert命令进行故障处理案例二 使用tracert命令发现路由环路原因分析p从上面的tracert命令的显示可以立即发现，在RouterA和RouterB间产生了路由环路。由于是配置的是静态路由，基本可以断定是RouterA或RouterB的静态路由配置错误。p检查RouterA的路由表，

40、配置的是缺省静态路由：ip route-static 0.0.0.0 0.0.0.0 1.0.0.1，没有问题。p检查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。这正是错误所在。49使用tracert命令进行故障处理案例二 使用tracert命令发现路由环路处理过程修改RouterB的配置如下：RouterB no ip route-static 4.0.0.0 255.0.0.0 1.0.0.2RouterB ip route-static

41、4.0.0.0 255.0.0.0 3.0.0.1故障处理完成。50使用tracert命令进行故障处理案例二 使用tracert命令发现路由环路建议和总结ptracert命令能够很容易发现路由环路等潜在问题。当路由器A认为路由器B知道到达目的地的路径，而路由器B也认为路由器A知道目的地时，就是路由环路发生了。使用ping命令只能知道接收端出现超时错误，而tracert能够立即发现环路所在如果tracert命令两次或者多次显示同样的接口。p当通过tracert发现路由环路后，如果配置为：n静态路由：几乎可以肯定是手工配置有问题。n单动态路由协议：可能是地址聚合产生的问题。n多动态路由协议：可能是

42、路由引入产生的问题。51DISPLAY命令pdisplay命令是用于了解路由器的当前状况、检测相邻路由器、从总体上监控网络、隔离因特网络中故障的最重要的工具之一。几乎在任何故障处理和监控场合，display命令都是必不可少的。p这里仅介绍部分最常用的、全局性的display命令，而与各协议相关的display命令，将在后面章节相应的协议故障处理中详细介绍。52Display Versionp该命令将帮助用户收集下列信息：nVRP软件版本n是哪一系列的路由器n设备运行时间n处理器的信息nRAM的容量n配置寄存器的设置n固件的版本n引导程序的版本p不同型号的设备显示的内容可能会略有差别Quidwa

43、ydisplay version Huawei Versatile Routing Platform Software VRP(tm)software,Version 1.44 Release 0006 Copyright(c)1997-2002 HUAWEI TECH CO.,LTD.Compiled 20:42:52,Jun 12 2003,Quidway R2511 uptime is 0 days 7 hours 40 minutes 13 seconds,System returned to ROM by power-on.Quidway R2511 with 1 68360 Pro

44、cessor Router serial number is 00E0FC05D5C76A40 16 Mbytes DRAM 4608 Kbytes Flash Memory hardware version is 1.053display current-configuration 与display saved-configurationpDisplay current-configuration用于查看当前的配置信息。Display saved-configuration用于显示NVRAM或Flash中的路由器配置文件，即路由器下次上电启动时所用的配置文件。pCurrent-configu

45、ration是路由器目前正在运行的配置文件，当更改某一配置时，current-configuration会立即改变；如果不使用save命令将改变保存到启动配置文件saved-configuration中，路由器重启时该改动将丢失。因此请注意到修改运行配置并验证正确后，应当将之保存到启动配置文件中。54display current-configuration 与display saved-configurationp强烈建议网络维护或管理人员保存一份启动配置文件的拷贝存放到路由器以外的其他设备上。这有几点好处：n这将使维护人员能够迅速配置一个替代的路由器；n这个保存在外部的文本文件也可以按上述

46、规定的格式脱机编辑然后使用Download config命令加载到路由器上；n可以将该配置文件通过E-mail形式发给华为技术支持人员以帮助定位配置问题。55Display interfaces pdisplay interfaces命令可以显示所有接口的当前状态，如果只是想查看特定接口的状态，请在该命令后输入接口类型和接口号，例如：display interfaces serial 0命令将查看串口0的运行状态和相关信息。Quidwaydisplay interfaces serial 0Serial0 is down,line protocol is down physical layer

47、 is synchronous,baudrate is 64000 bps interface is DCE,clock is DCECLK,cable type is V35 Maximum Transmission Unit is 1500 Link-protocol is PPP LCP initial,IPCP initial,IPXCP initial,CCP initial,BRIDGECP initial 5 minutes input rate 0.00 bytes/sec,0.00 packets/sec 5 minutes output rate 0.00 bytes/se

48、c,0.00 packets/sec Input queue:(size/max/drops)0/75/0 FIFO queueing:FIFO Output Queue:(size/max/drops)0/75/0 0 packets input,0 bytes,0 no buffers 0 packets output,0 bytes,0 no buffers 0 input errors,0 CRC,0 frame errors 0 overrunners,0 aborted sequences,0 input no buffers DCD=UP DTR=DOWN DSR=UP RTS=

49、DOWN CTS=UP56Display tech-support pdisplay tech-support命令将显示系统基本信息，包括版本信息、当前配置信息、接口信息、内存信息、接口流量信息等。对于复杂的故障问题，网络维护人员可以拷贝该命令的输出信息发给华为技术支持人员使之了解当前路由器的总体情况。57Reset命令 pReset 命令的作用用于清空当前的统计信息以排除以前积累的数据的干扰。pReset命令中最主要的是reset counters interface和reset ip statistics命令。n对于二层帧收发的各计数器的刷新必须使用reset counters inter

50、face，可通过display interfaces命令来观察；n对于三层报文的收发统计可使用reset ip statistics来刷新，通过display ip interface命令来观察。58Reset命令pReset命令适用场合如下：许多情况下，我们需要使用带参数的ping命令来测试链路的通断，同时在一段时间内ping后，通过display interfaces或display ip interface命令来查看端口报文的收发及CRC校验等情况的正确与否，从而分析报文的收发在什么地方出现了问题。但display命令的显示值是自从路由器运行以来（或上次reset后）的所有统计值，这个值

51、是无法分析的。因此，实际我们需要进行的步骤为：首先使用reset命令清空统计值，然后使用一系列ping命令使路由器端口收发报文，最后使用display命令来查看统计值。59debug命令 pQuidway系列路由器提供大量的debug命令，可以帮助用户在网络发生故障时获得路由器中交换的报文和帧的细节信息，这些信息对网络故障的定位是至关重要的。60display命令和debug命令 pdisplay命令能够提供某个时间的设备运行状况的视图（静态），而debug命令能够展示一段时间内设备运行的变化情况（动态）。p一般说来，display命令不会影响系统的运行性能，而debug命令则会对系统性能造成

52、影响。因此两者的使用应遵循如下规则：首先使用相关的多个display命令查看设备当前的运行状况，分析可能原因，缩减故障到适当范围，然后打开某个特定的debug命令观察变化情况，以定位和排除问题。61使用debug命令的注意要点 p应当使用debug命令来查找故障，而不是用来监控正常的网络运行。p尽量在网络使用的低峰期或网络用户较少时使用，以降低debug命令对系统的影响性。p在没有完全掌握某debug命令的工作过程以及它所提供的信息前，不要轻易使用该debug命令。p由于debug命令在各个输出方向对系统资源的占用情况不同。视网络负荷状况，我们应当在使用方便性（info-center cons

53、ole debugging命令）和资源耗费小（info-center logbuffer debugging命令）间做出权衡。p不要轻易使用类似debug all之类将产生大量输出的命令。仅当寻找某些类型的流量或故障并且已将故障原因缩小到一个可能的范围时，才使用某些特定的debug命令。62debug命令 案例一 忘记关闭debug开关引起的路由器报文转发速度变慢的故障处理p某电信局安装了Quidway路由器作为接入服务器的出口网关，一段时间运转良好。某日用户反映该设备明显速度变慢。执行PING操作，PING对端路由器设备，所用时间为正常的2倍多。63debug命令 案例一 忘记关闭debug

54、开关引起的路由器报文转发速度变慢的故障处理相关信息收集 p该路由器的日志中记录了大量的收发IP报文的信息。原因分析 p初步分析可能有以下几种原因：n线路质量不好n对端设备问题，导致回应较慢n自身配置错误n网络繁忙n软硬件故障 64debug命令 案例一 忘记关闭debug开关引起的路由器报文转发速度变慢的故障处理处理过程 p检查线路，没有发现问题；pPING与之相连的其他路由器设备，故障依旧，说明对端设备无问题；p对照以前运转良好时备份的current-configuration文件，检查路由器上的配置，没有错误；p当时并非上网高峰期，且只是变慢，而无丢包，应当不是网络负荷问题；p检查该路由器

55、的日志信息，发现其中记录了大量的收发IP报文的信息，执行命令display debugging命令，发现该路由器的debug ip packet处于打开状态。由于设备需要记录每一个被转发的IP报文，大大降低了路由器的处理速度，导致变慢。p关闭该debug开关后，故障解决。65debug命令 案例二 通过串口telnet到路由器，在该串口上打开debug命令产生问题p当远程调试Quidway路由器时，有时需要通过某个串口telnet上该路由器，如果该串口上的链路层协议封装的是FR、PPP等，千万不能打开该串口相应的链路层调试开关（可以打开其他串口的链路层调试开关），否则由于数据流量太大，会使该串

56、口的协议down掉。如果链路层协议是X.25，则没有这个限制。66故障处理常用方法p分层故障处理法 p分块故障处理法 p分段故障处理法 p替换法 67分层故障处理法p分层法思想很简单：所有模型都遵循相同的基本前提当模型的所有低层结构工作正常时，它的高层结构才能正常工作。在确信所有低层结构都正常运行之前，解决高层结构问题完全是浪费时间。68分层故障处理法案例分析p在一个帧中继网络中，由于物理层的不稳定，帧中继连接总是出现反复失去连接的问题，这个问题的直接表象是到达远程端点的路由总是出现间歇性中断。这使得维护工程师第一反应是路由协议出问题了，然后凭借着这个感觉来对路由协议进行大量故障诊断和配置，其

57、结果是可想而知的。如果他能够从OSI模型的底层逐步向上来探究原因的话，维护工程师将不会做出这个错误的假设，并能够迅速定位和排除问题。69分层故障处理法各层次的关注点 p物理层：电缆、连接头、信号电平、编码、时钟和组帧，这些都是导致端口处于down状态的因素。p数据链路层：数据链路层负责在网络层与物理层之间进行信息传输；规定了介质如何接入和共享；站点如何进行标识；如何根据物理层接收的二进制数据建立帧。封装的不一致是导致数据链路层故障的最常见原因。可以使用display interfaces命令初步判断数据链路层是否存在故障。p网络层：地址错误和子网掩码错误是引起网络层故障最常见的原因；网络中的地

58、址重复是网络故障的另一个可能原因；另外，路由协议是网络层的一部分，在较复杂的网络中是排错重点关注的内容。70分块故障处理法pQuidway系列路由器current-configuration文件的组织结构，是以全局配置、物理接口配置、逻辑接口配置、路由配置等方式编排的。p我们可以以此作为故障定位提供了一个原始框架，当出现一个故障案例现象时，我们可以把它归入上述某一类或某几类中，从而有助于缩减故障定位范围。：n 管理部分（路由器名称、口令、服务、日志等）n 端口部分（地址、封装、cost、认证等）n 路由协议部分（静态路由、RIP、OSPF、BGP、路由引入等）n 策略部分（路由策略、策略路由、

59、安全配置等）n 接入部分（主控制台、Telnet登录或哑终端、拨号等）n 其他应用部分（语言配置、VPN配置、Qos配置等）71分块故障处理法举例p当使用display ip routing-table命令，结果只显示出了直连路由，那么问题可能发生在哪里呢？p根据上述的分块，我们发现有三部分可能引起该故障：路由协议、策略、端口。如果没有配置路由协议或配置不当，路由表就可能为空；如果访问列表配置错误，就可能妨碍路由的更新；如果端口的地址、掩码或认证配置错误，也可能导致路由表错误。72分段故障处理法 p如果两个路由器跨越电信部门提供的线路而不能相互通信时，分段故障处理法是有效的：n主机到路由器LA

60、N接口的这一段n路由器到CSU/DSU接口的这一段nCSU/DSU到电信部门接口的这一段nWAN电路nCSU/DSU本身问题n路由器本身问题73分段故障处理法案例案例：路由器通过DDN专线连接时的调试方法 p目前路由器在网上较多的一种应用是通过DDN专线连接，这种应用对路由器来说配置并不太复杂，而问题多容易出在线路和Modem方面。以下是对这种组网实际调试中的一些经验。中继线路MODEMMODEMMODEMMODEMDDN节点机DDN节点机ABCDEFRouterARouterB74分段故障处理法案例案例：路由器通过DDN专线连接时的调试方法p正常情况下，Modem上指示灯状态为：PWR（电源

61、指示灯）、RTS、DCD三个灯常亮，TD、RD在有数据收发时闪烁。两侧路由器连上并完成配置后，S口应激活，线路协议应激活，双方可以相互ping通。p当出现问题时，可按照以下步骤进行测试：75分段故障处理法案例案例：路由器通过DDN专线连接时的调试方法1.在Router1上打开调试开关。以封装PPP为例，在全局模式下输入debug ppp packet命令。2.将Modem A上的ANA键按下。此时Modem的RTS、DCD、TEST常亮，在Router1上能看到大量经过环回的LCP层收发消息包。此时表示Modem A和Router1之间连接正常。3.将Modem A的REM键按下。此时若灯状态

62、同上，路由器上看到的debug消息也同上，则表示从Router1到Modem B之间连接正常。4.请本地数据局在节点机C上进行环回，观察是否有环回的数据包。5.请对端数据局在节点机D上向本端进行环回，观察是否有环回的数据包。6.对端将Modem F的DIG键按下，若能看到环回的数据包，则表示从Router1一直到Modem F都正常。若不通，可以在Router2上重复以上操作步骤，直至找出有问题的一段。76替换法p这是我们在检查硬件是否存在问题时最常用的方法。当怀疑是网线问题时，更换一根确定是好的网线试一试；当怀疑是接口模块有问题时，更换一个其他接口模块试一试。77故障处理对网络维护和管理人员的要求p对协议要求有精深的理解p能够引导客户详细描述出故障现象和相关信息p充分了解自己所管理和维护的网络p及时进行故障处理的文档记录和经验总结