网络故障排除思路.doc

《网络故障排除思路.doc》由会员分享，可在线阅读，更多相关《网络故障排除思路.doc（33页珍藏版）》请在三一文库上搜索。

1、word目 录网络故障排除技术总结11.网络故障排除技术概览1在当今日益复杂的网络中进展故障排除1网络故障的一般分类2一般网络故障的解决步骤22.网络排错常用诊断工具介绍82.1 Ping命令82.2 Traceroute 命令122.3 Show命令172.4 Clear命令212.5 Debug命令233.故障排除常用方法25分层故障排除法25分块故障排除法26分段故障排除法27替换法284. 故障排除对排错技术人员的要求28对协议要求有精深的理解28能够引导客户详细描述出故障现象和相关信息29充分了解自己所管理和维护的网络31与时进展故障排除的文档记录和经验总结3232 / 33网络故障

2、排除技术总结当今的网络互连环境是日趋复杂的，而且随着需求开展的步伐这种复杂性是日益增长的，主要原因如下： 现代的网络要求支持更广泛的应用：包括内容上的数据、语音、视频的应用；接入方式上有线，光纤，无线，多协议转换器，逻辑链路的应用；网络结构上二层，三层，二三层混合，VPN等的应用。 新业务开展使得网络的的需求不断增长，新技术的不断出现。例如：百兆以太网向千兆、万兆以太网的演进；各种防X攻击技术的出现；提供QoS能力；IPV6的支持等。l 新技术的应用同时还要兼顾传统的技术。例如，传统的网络体系结构仍在某些场合使用。各种协议的开展，使得新网络的建设需要兼容原来的根底而进展改造。l图1-1 多样业

3、务的需求和各种先进技术的引入使网络日益复杂因此，现代的互连网络是协议、技术、介质和拓扑的混合体。互连网络环境越复杂，意味着网络的连通性和性能故障发生的可能性越大，而且引发故障的原因也越发难以确定。同时，由于人们越来越多的依赖网络处理日常的工作和事务，一旦网络故障不能与时修复，其所造成的损失可能很大甚至是灾难性的。能够正确地维护网络尽量不出现故障，并确保出现故障之后能够迅速、准确地定位问题并排除故障，对网络维护人员和网络管理人员来说是个挑战，这不但要求我们对网络协议和技术有着深入的理解，更重要的是要建立一个系统化的故障排除思想并合理应用于实际中，以将一个复杂的问题隔离、分解或缩减排错X围，从而与

4、时修复网络故障。网络故障一般分为两大类：连通性问题和性能问题。它们各自故障排除的关注点如下： 连通性问题硬件、系统、电源、媒介故障配置错误不正确的相互作用 性能问题网络拥塞到目的地不是最优路由转发异常路由环路网络错误一般网络故障的解决步骤故障排除系统化是合理地一步一步找出故障原因并解决的总体原如此。它的根本思想是系统地将由故障可能的原因所构成的一个大集合缩减或隔离成几个小的子集，从而使问题的复杂度迅速下降。故障排除时有序的思路有助于解决所遇到的任何困难，如下图给出了一般网络故障解决的处理流程。图1-2 网络故障排除根本步骤我们以一个故障排除的实例来学习如何应用这些步骤。案例：某用户网段广播包过

5、多造成该网段的服务器FTP业务传输速度变慢组网图如下：某校园网的三个局域网，其中为一个用户网段，10.11.56.118为一个日志服务器；10.15.0.0是一个集中了很多应用服务器的网段。图1-3 用户网段广播包过多造成该网段的服务器FTP业务传输速度慢1. 故障现象描述要想对网络故障做出准确的分析，首先应该了解故障表现出来的各种现象，然后才能确定可能产生这些现象的故障根源或症结。因此，对网络故障做出完整、清晰的描述是重要的一步。如上述案例，用户反映：“日志服务器与备份服务器间备份发生问题。这就是一个不完整不清晰的故障现象描述。因为这个描述没有讲述清楚如下问题：l 这个问题是连续出现，还是连

6、续出现的？l 是完全不能备份，还是备份的速度慢即性能下降？l 哪个或哪些局域网服务器受到影响，地址是什么？正确的故障现象描述是：在网络的顶峰期，日志服务器到集中备份服务器10.15.254.253之间进展备份时，FTP传输速度很慢，大约只有0.6Mbps。2. 故障案例相关信息收集本步骤是搜集有助于查找故障原因的更详细的信息。主要是三种途径：l 向受影响的用户、网络人员或其他关键人员提出问题；l 根据故障描述性质，使用各种工具搜集情况，如网络管理系统、协议分析仪、相关show命令等；l 测试性能与网络基线进展比拟。如上述案例，可以向用户提问或自行收集如下相关信息：l 网络结构或配置是否最近修改

7、正，即问题出现是否与网络变化有关？l 是否有用户访问受影响的服务器时没有问题？l 在非顶峰期日志服务器和备份服务器间FTP传输速度是多少？通过该步骤，可以收集到了下面一些相关信息：l .0网段的客户机不断在增加；l 网段的机器与备份服务器间进展FTP传输时速度正常为7Mbps，与日志服务器间进展FTP传输时速度慢，只有0.6Mbps；l 在非顶峰期日志服务器和备份服务器间FTP传输速度正常，大约为6Mbps；3. 经验判断和理论分析利用前两个步骤收集到的数据，并根据自己以往的故障排除经验和所掌握的互连网络设备和协议的知识，来确定一个排错X围。通过X围的划分，就只需注意某一故障或与故障情况相关的

8、那一局部产品、介质和主机。如上述案例：我们现在能够确定是一个网络性能下降问题。那么，是网段10.11.56.0的性能问题？是中间网云的性能问题？是10.15.0.0网段的性能问题呢？网段的机器与备份服务器间进展FTP传输时速度正常为7Mbps这一事实，我们可以排除掉10.15.0.0网段的性能问题。4. 各种可能原因列表该步骤列出根据经验判断和理论分析后总结的各种可能原因。如上述案例，可能原因如下：(1) 网段10.11.56.0的性能问题，其子原因可能为：l 日志服务器A的性能问题ll(2) 5. 对每一原因实施排错方案根据所列出的可能原因制定故障排查计划，分析最有可能的原因，确定一次只对一

9、个变量进展操作，这种方法使你能够重现某一故障的解决方法。如果有多个变量同时被改变，而问题得以解决，那么如何判断哪个变量导致了故障发生呢？& 说明：我们在对故障处理流程5、6、7步骤介绍完毕后，再继续进展上述实例案例的排错步骤介绍。6. 观察故障排查结果当我们对某一原因执行了排错方案后，需要对结果进展分析，判断问题是否解决，是否引入了新的问题。如果问题解决，那么就可以直接进入文档化过程；如果没有解决问题，那么就需要再次循环进展到故障排查过程。7. 循环进展故障排查过程当实施了一个方案没有达到预期的排错目的时，我们进入到该步骤这是一个努力缩小可能原因的清单过程。在进展下一循环之前必须做的事情就是将

10、网络恢复到实施上一方案前的状态。如果保存上一方案对网络的改动，很可能导致新的问题，例如：假设修改了访问列表但没有产生预期的结果，此时如果不将访问列表恢复到原始状态，就会导致出现不可预期的结果。循环排错可以有两个切入点：l 当针对某一可能原因的排错方案没有达到预期目的，循环进入下一可能原因制定排错方案并实施；l 当所有可能原因列表的排错方案均没有达到排错目的，重现进展故障相关信息收集以分析新的可能原因。如上述案例，我们在列出了可能原因列表后，开始制定方案进展故障排除。(1) 可能原因1：“命令，发现探测报文返回时长仅为10ms，明确该可能原因并不是造成故障的原因。我们进入循环排错过程。(2) 可

11、能原因2：“日志服务器A的性能问题制定的方案：测试同一网段的主机C和日志服务器间的FTP传输速度，是6Mbps，正常。可见问题与服务器A无关。(3) 可能原因3：“制定的方案：测试主机C和备份服务器B间FTP传输速度是7Mbps，正常。排除了网关因素，因为B、C在不同网段上而速度正常。(4) 可能原因3：“show interfaces fastEthernet 0/X counters，输出如下：Interface : Fa0/x5 minute input rate : 4800 bits/sec, 4 packets/sec5 minute output rate : 55936 bit

12、s/sec, 5 packets/secInOctets : 32533624InUcastPkts : 390531InMulticastPkts : 39InBroadcastPkts : 13164OutOctets : 32126341OutUcastPkts : 33133OutMulticastPkts : 1840OutBroadcastPkts : 12611广播与单播的比例在1：3，显然太大了。“show interfaces fastEthernet 0/x counters输出如下：Interface : Fa0/135 minute input rate : 4800

13、bits/sec, 4 packets/sec5 minute output rate : 55936 bits/sec, 5 packets/secInOctets : 4253824InUcastPkts : 29432175InMulticastPkts : 39InBroadcastPkts : 11061OutOctets : 21127345OutUcastPkts : 39432172OutMulticastPkts : 1840OutBroadcastPkts : 12611广播与单播的比例在1：280，是正常的。由此知道，网段10.11.56.0上广播包和单播包比例为1:3，

14、确实太大了。再次询问用户该网段主要运行的业务是什么，从而得出了故障最终原因如下：10.11.56.0是普通用户网段，由于业务原因每个用户需要发送大量广播包和多播包，随着近期越来越多的用户接入该网络，在这个网段上的服务器需要花费更多的资源来处理越来越多的广播和多播包，因此其服务的传输速度自然减慢。网段后，故障排除。8. 故障排除过程文档化当最终排除了网络故障后，那么排除流程的最后一步就是对所做的工作进展文字记录。文档化过程决不是一个可有可无的工作，原因如下：l 文档是排错宝贵经验的总结，是 “经验判断和理论分析这一过程中最重要的参考资料；l 文档记录了这次排错中网络参数所做的修改，这也是下一次网

15、络故障应收集的相关信息。文档记录主要包括以下几个方面：l 故障现象描述与收集的相关信息l 网络拓扑图绘制l 网络中使用的设备清单和介质清单l 网络中使用的协议清单和应用清单l 故障发生的可能原因l 对每一可能原因制定的方案和实施结果l 本次排错的心得体会l 其他：如排错中的使用的参考资料列表等请读者对照上述案例完成文档记录工作。锐捷的产品提供了一套完整的命令集，可以用于监控网络互联环境的工作状况和解决根本的网络故障。主要包括以下命令： Ping命令 Traceroute命令l Show命令l Clear命令l Debug命令2.1 Ping命令1.原理：“ping这个词源于声纳定位操作，指来自

16、声纳设备的脉冲信号。Ping命令的思想与发出一个短促的雷达波，通过收集回波来判断目标很相似；即源站点向目的站点发出一个ICMP Echo Request报文，目的站点收到该报文后回一个ICMP Echo Reply报文，这样就验证了两个节点间IP层的可达性表示了网络层是连通的。Ping命令用于检查IP网络连接与主机是否可达。平台的ping命令在RG系列设备上，Ping命令的格式如下：Ping ip-address例如，向主机10.15.50.1 Ping报文RG# /ping通SwitchPINGTarget IP address or host: Repeat count 5: 2Datag

17、ram size 100: 8100Timeout in milliseconds 2000: 5000Extended mands n:Sending 2, 8100-byte ICMP Echos to ,timeout is 5000 milliseconds.!Success rate is 100 percent (2/2)Minimum = 21ms Maximum = 22ms, Average = 21msRG# /不通Sending 5, 100-byte ICMP Echos to 10.15.50.1,timeout is 2000 milliseconds.Succes

18、s rate is 0 percent (0/5)4.Windows平台的Ping命令在PC机上或Windwos NT为平台的服务器上，Ping命令的格式如下：Ping -n number -t -l number ip-address-n Ping报文的个数，缺省值为5；-t 持续地ping 直到人为地中断，Ctr+Breack暂时中止ping命令并查看当前的统计结果，而Ctr+C如此中断命令的执行。-l 设置Ping报文所携带的数据局部的字节数，设置X围从0至65500。例：向主机10.15.50.1 发出2个数据局部大小为 3000 Bytes的ping报文C:Pinging 10.15

19、50.1 with 3000 bytes of dataReply from 10.15.50.1: bytes=3000 time=321ms TTL=123Reply from 10.15.50.1: bytes=3000 time=297ms TTL=123Ping statistics for 10.15.50.1: Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),Approximate round trip times in milli-seconds: Minimum = 297ms, Maximum = 321ms, Av

20、erage = 309ms& 说明：实际上Windows平台的Ping命令的参数非常多，这里只介绍其中最重要的三个参数。其他参数介绍请参考Windows在线帮助。Ping命令进展故障排除案例一：连通性问题还是性能问题？(1) 案例描述 工程师小C，在配置完一台路由器之后执行Ping命令检测链路是否通畅。发现5个报文都没有Ping通，于是检查双方的配置命令并查看路由表，却一直没有找到错误所在。最后又重复执行了一遍一样的Ping命令，发现这一次5个报文中有1个Ping 通了原来是线路质量不好存在比拟严重的丢包现象。 工程师小C又配置了一台路由器，然后执行Ping命令访问Internet上某站点的I

21、P地址，但没有Ping通。有了上次的教训小L，再一次Ping了20个报文，仍旧没有响应。于是小L断定是网络故障。但是在费劲周折检查了配置链路之后仍没有发现任何可疑之处，最后小L采取逐段检测的方法对链路中的网关进展逐级测试，发现都可以Ping 通，但是响应的时间越来越长，最后一个网关的响应时间在1800ms左右。会不会是由于超时而导致显示为Ping 不同呢？受此启发，小L将Ping 命令报文的超时时间改为4000ms，这次成功Ping通了，显示所有的报文响应时间都在2200ms 左右。(2) 建议和总结：真的是Ping不通吗？这个问题需要定位清楚，因为连通性问题和性能问题排错的关注点是不一样的问

22、题定位错误必然会导致排错过程的周折。使用一般的Ping命令，缺省是发送5个报文的，超时时长是2000ms。如果Ping不通情况发生，最好能够再用带参数-c和-t的Ping命令再执行一遍，如：Ping -c 20 -t 4000 ip-address，即连续发送20个报文，每个报文的超时时长为4000ms，这样一般可以判断出到底是连通性问题还是性能问题。案例二：使用大包ping对端进展MTU不一致的故障排除(1) 现象描述：某次开局，使用RG路由器与其他厂商的某路由器互连，并运行OSPF协议。数据配置完毕后，一切正常，并在今后相当长的时间内设备运转稳定。但两个月后，用户反响网络中断。(2) 相关

23、信息显示： 登录到两台路由器上，发现双方连接正常，可以相互Ping通对端地址。但OSPF协议中断； 登录RG路由器查看邻居状态，发现邻居状态机处于Exstart状态。打开相应的debug开关查看相应的报文信息，发现双方都可以收到Hello报文，但RG路由器发送DD报文后，一直没有收到对方回应的DD报文； 登录其他厂商的那台路由器，打开相应的debug开关，发现对方收到RG路由器发送的DD报文后，一发送了相应的DD报文予以回应。(3) 原因分析：初步断定，RG路由器没有收到DD回应报文，但对方确实发出来了。既然可以接收到HELLO 报文说明链路是通畅的，而且多播报文的收发也没有问题。那么有可能是

24、对方发送的DD 报文有错误导致RG路由器拒收，但查看相应的信息，并没有报告接收到错误的DD 报文。仔细查看某厂商路由器的调试信息发现这个DD报文很大有2000 多字节。会不会是由于报文太大导致的问题呢？试着Ping了一个2000字节的报文，结果不通。那么故障原因很可能是由于双方的MTU不一致导致大包不通。(4) 处理过程：检查配置，发现对方路由器的MTU设置为4000多而RG路由器的MTU设置为1500，于是修改对端路由器的MTU为1500。故障排除。那么为什么工程初期没有问题呢？这是因为前期DD报文长度小于1500字节，而后来网络扩容导致路由信息过多使DD 报文的长度超过了1500 字节。(

25、5) 建议和总结：由于Ping 缺省报文是56 个字节，所以显示的Ping 通信息只是表示56字节的报文可以通而并不一定表示其他大小的报文仍旧可以通。所以，应当善于使用Ping的其他参数来进展故障排除。案例三：A能Ping通B，B就一定能Ping通A吗？(1) 现象描述组网图如下：图1-4 案例：A能Ping通B，B就一定能Ping通A吗？在RouterA上配置一条指向的静态路由：RouterAconfig# 在RouterA 上Ping RouterB 的以太网地址，显示可以正常Ping通；但是在RouterB上Ping RouterA的以太网地址，却无法Ping通。(2) 原因分析：由于在

26、RouterB 上却没有相应的配置到路由，所以从RouterB 上Ping不通RouterA的以太网口3.3.3.3 。但是为何在A上可以Ping 通2.2.2.2 呢？同样是没有回程路由呀？打开路由器上的IP报文调试开关发现，原来从RouterA上发出的ICMP报文的源地址填写的是而不是，由于两台路由器的s0口处于同一网段，所以响应报文可以顺利到达RouterB。(3) 建议和总结：A能够Ping通B如此B一定能够Ping通A不考虑防火墙的因素,这句话的对错取决于A和B到底是指主机还是指路由器。 如果是指两台主机，那么这句话就是正确的。 如果是指两台路由器那就是错误的，因为路由器通常会有多个

27、IP地址。现在就有如下问题：当从一台路由器上执行Ping命令它发出的ICMP Echo报文的源地址终究选择哪一个呢？实际情况是路由器选择发出报文的接口的IP地址。2.2 Traceroute 命令Traceroute是为了探测源节点到目的节点之间数据报文所经过的路径。利用IP报文的TTL域在每经过一个路由器的转发后减一，当TTL=0时如此向源节点报告TTL超时这个的特性。Traceroute首先发送一个TTL为1的UDP报文，因此第一跳发送回一个ICMP错误消息以指明此数据报不能被发送因为TTL超时，之后Traceroute再发送一个TTL为2的报文，同样第二跳返回TTL超时，这个过程不断进展

28、直到到达目的地，此时由于数据报中使用了无效的端口号缺省为33434此时目的主机会返回一个ICMP的目的地不可达消息，明确该Traceroute操作完毕。Traceroute记录下每一个ICMP TTL超时消息的源地址，从而提供应用户报文到达目的地所经过的网关IP地址。Traceroute 命令用于测试数据报文从发送主机到目的地所经过的网关，主要用于检查网络连接是否可达，以与分析网络什么地方发生了故障。3.RGNOS平台的Traceroute命令在锐捷RG系列路由器上，Traceroute命令的格式如下：Traceroute host destination例如：查看到目的主机10.15.50

29、1 中间所经过的网关。RG# Type esc/CTRLc/CTRLz/q to abort.traceroute 192.168.0.1 . 1 10.110.40.1 1 4 ms 5 ms 5 ms 2 10.110.0.64 10 ms 5 ms 5 ms 3 10.110.7.254 10 ms 5 ms 5 ms 4 10.3.0.177 175 ms 160 ms 145 ms 5 129.9.181.254 185 ms 210 ms 260 ms 6 10.15.50.1 230 ms 185 ms 220 msTrace plete successfully.4.Wind

30、ows平台的Tracert 命令在PC机上或Windwos NT为平台的服务器上，Tracert命令的格式如下：tracert -d -h maximum_hops -j host-list -w timeout host-d 不解析主机名；-h 指定最大TTL大小；-j 设定松散源地址路由列表；-w 用于设置UDP报文的超时时间，单位毫秒；例如： 查看到目的主机10.15.50.1 中间所经过的前两个网关。 C:Tracing route to 10.15.50.1 over a maximum of 2 hops:Trace plete.5.使用Traceroute命令进展故障排除案例一：

31、使用Traceroute命令定位不当的网络配置点(1) 现象描述组网情况如如下图所示：图1-5 案例：使用Traceroute命令定位不当的网络配置点某校园网中，RouterB和RouterC同属于一个运行RIPv2路由协议的网络，主机4.0.0.2访问数据库服务器5.0.0.2，用户抱怨访问性能差。(2) 相关信息显示在主机上ping 5.0.0.2显示如下：C:Documents and Settingscping -n 10 -l 1000 5.0.0.2Pinging 5.0.0.2 with 1000 bytes of data:Reply from 5.0.0.2: bytes=1

32、000 time=552ms TTL=250Reply from 5.0.0.2: bytes=1000 time=5735ms TTL=250Reply from 5.0.0.2: bytes=1000 time=551ms TTL=250Reply from 5.0.0.2: bytes=1000 time=5734ms TTL=250Reply from 5.0.0.2: bytes=1000 time=549ms TTL=250Reply from 5.0.0.2: bytes=1000 time=5634ms TTL=250Reply from 5.0.0.2: bytes=1000

33、 time=555ms TTL=250Reply from 5.0.0.2: bytes=1000 time=5738ms TTL=250Reply from 5.0.0.2: bytes=1000 time=455ms TTL=250Reply from 5.0.0.2: bytes=1000 time=5811ms TTL=250原因分析上面的Ping显示出一个规律：奇数报文的返回时长短，而偶数报文返回时长很长是奇数报文的10倍多。可以初步判断奇数报文和偶数报文是通过不同的路径传输的。现在我们需要使用Traceroute命令来追踪这不同的路径。在RouterC上，Traceroute远端R

34、outerA的以太网接口5.0.0.1。RouterC(config)#traceroute Target IP address or host: Maximum number of hops to search for target 30:10Repeat count for each echo3:8Wait timeout milliseconds for each reply 2000:Type esc/CTRLc/CTRLz/q to abort.traceroute .1 6 ms 4 ms 4 ms 4 ms 4 ms 4 ms 4 ms 4 ms 。中间省略5 20 ms 16

35、ms 15 ms 16 ms 16 ms 16 ms 16 ms 16 ms 6 30 ms 278 ms 25 ms 279 ms 25 ms 278 ms 25 ms 277 ms RouterC(config)#从上面的显示可看到，直至3.0.0.2，UDP探测报文的返回时长都根本一致，而到5.0.0.1时，如此发生明显变化，呈现奇数报文时长短，偶数报文时长长的现象。于是判断，问题发生在RouterB和RouterA之间。通过询问该段网络的管理员，得知这两路由器间有一主一备两串行链路，主链路为2.048Mbpss0口之间，备份链路为128Kbpss1口之间。网络管理员在此两路由器间配置了

36、静态路由。RouterB上如下配置：RouterBconfig#RouterBconfig# RouterA上如下配置：RouterAconfig# RouterAconfig# 于是问题就清楚了。例如RouterB，由于管理员配置时没有给出静态路由的优先级，这两条路由项的管理距离就同为缺省值1，于是就同时出现在路由表中，实现的是负载分担，而不能达到主备的目的。(3) 处理过程可以有两种处理方法：l 继续使用静态路由，进展配置更改RouterB上进展如下更改：RouterBconfig# 主链路仍使用缺省RouterBconfig# 100备份链路的降低至100RouterA上进展如下更改：R

37、outerAconfig# RouterAconfig# 100这样，只有当主链路发生故障，备份链路的路由项才会出线在路由表中，从而接替主链路完成报文转发，实现主备目的。l 在两路由器上运行动态路由协议，如IGRP、EIGRP、OSPF等，但不要运行RIP协议因为RIP协议仅以hop作为Metric的(4) 建议和总结本案例的目的不是为了解释网络配置问题，而是用来展示Ping命令和Traceroute命令的相互配合来找到网络问题的发生点。尤其在一个大的组网环境中，维护人员可能无法沿着路径逐机排查，此时，能够迅速定位出发生问题的线路或路由器就非常重要了。案例二：使用Traceroute命令发现路

38、由环路(1) 现象描述组网情况如如下图所示：三台路由器均配置静态路由，完成后，登录到RouterA上Ping主机4.0.0.2，发现不通。(2) 相关信息显示RouterA# ping 4.0.0.2Sending 5, 100-byte ICMP Echos to 4.0.0.2,timeout is 2000 milliseconds.Success rate is 0 percent (0/5)RouterA# Type esc/CTRLc/CTRLz/q to abort.traceroute .1 6 ms 4 ms 4 msRouterB 2 8 ms 8 ms 8 ms Rout

39、erA 3 12 ms 12 ms 12 msRouterB 4 16 ms 16 ms 16 ms RouterA 。(3) 原因分析从上面的Traceroute命令的显示可以立即发现，在RouterA和RouterB间产生了路由环路。由于是配置的是静态路由，根本可以断定是RouterA或RouterB的静态路由配置错误。检查RouterA的路由表，配置的是缺省静态路由：ip route 0.0.0.0 0.0.0.0 1.0.0.1，没有问题。下一跳配置的是1.0.0.2，而不是3.0.0.1。这正是错误所在。(4) 处理过程修改RouterB的配置如下：RouterBconfig#Rou

40、terBconfig# ip 故障排除。(5) 建议和总结Traceroute命令能够很容易发现路由环路等潜在问题。当路由器A认为路由器B知道到达目的地的路径，而路由器B也认为路由器A知道目的地时，就是路由环路发生了。使用Ping命令只能知道接收端出现超时错误，而Traceroute能够立即发现环路所在如果Traceroute命令两次或者屡次显示同样的接口。当通过Traceroute发现路由环路后，如果配置为：l 静态路由：几乎可以肯定是手工配置有问题，如本案例所示。l OSPF协议：可能是地址聚合产生的问题。l 多路由协议：可能是路由引入产生的问题。2.3 Show命令Show命令是用于了解

41、路由器的当前状况、检测相邻路由器、从总体上监控网络、隔离互连网络中故障的最重要的工具之一。几乎在任何故障排除和监控场合，Show命令都是必不可少的。例如：基于RGNOS路由平台的Show命令选项如下所示：RG#show ? access-group MAC access-group access-lists List access lists accounting Accounting configurations parameters address-bind address binding table arp ARP table class-map Show QoS Class Map c

42、lock Display the system clock cluster Cluster information configure Contents of Non-Volatile memory cpu CPU statistics debugging State of each debugging option detect detect user ip dot1x IEEE 802.1X information file Show filesystem information gvrp GVRP configure mand host IP dns host table interfa

43、ces Interface status and configuration ip IP information ip-auth-mode Show IP authentication mode key Key information line TTY line information lldp LLDP information logging Show the contents of logging buffers mac MAC information mac-address-table MAC forwarding table member Show members information memory Memory statistics mls Show MultiLayer Switching information monitor Show a SPAN session policy-map Show QoS Policy Map port-security Show secure port information privilege Show current privilege level radius-server