1 引言
　　作为网络工程师，在网络环境出现故障时，及时定位故障并解决故障是十分重要的。本文以CISCO路由式网络为基础，介绍使用诊断工具对Cisco路由器进行故障诊断的方法。限于篇幅，我们所介绍的内容和示例主要是基于IP报文的，基于IPX和Appletalk等协议的诊断技术与此类似。
　　2 路由器的功能特性和体系结构
　　在学习Cisco路由器上可使用的各种故障排除和诊断工具之前，了解路由器的基本体系结构是十分重要的。网络工程师应该理解诊断命令执行时所起的作用以及对于路由器性能所产生的影响。
　　交换与路由是我们在网络互联中经常碰到的术语。此处所说的交换与局域网中的帧级交换是完全不同的概念。交换过程是指路由器如何在两个不同的接口间传送报文。
　　比如，路由器在以太网接口0接收到一个报文。路由器首先从报文中获取MAC头信息，然后检查网络层报文头。路由器检查路由表是否有与报文的目的地址匹配的表项。假设路由表中包含匹配的项，并且下一跳地址是另外一个路由器，该路由器可以通过以太网接口1到达。然后路由器需要检查下一跳的第二层地址。假如它没有该地址，则需要在以太网接口1发送ARP广播报文。假如没有接收到ARP响应，路由器则将该报文丢弃。假如有响应信息，路由器则建立到下一跳路由器的以太网帧。在这个例子中，路由器从接收到以太网帧到建立并发送以太网帧的整个过程称为交换过程。需要注重的是，ARP解析过程通常不认为是交换过程的一部分。上面的过程中，执行路由表查询以寻找下一跳的地址表明采用了交换过程。这是一种最简单的报文交换方法，因而其开销和延迟都比较大。所有的路由协议最终都依靠于路由表的建立，路由器通过接收运行相同协议的相邻路由器发送的路由更新报文来更新相应的路由表，我们称之为路由过程（routing process），它主要由路由处理器完成。
　　目前在国内应用比较广泛的Cisco路由器包括2500系列、4000系列、7000系列和7500系列，这些路由器进行路由的过程基本上是相似的，但是交换的过程却根据其系统结构的不同而不同。
　　7000系列支持过程交换、快速交换、自治交换和硅交换。Cisco 7500系列路由器比7000系列在体系结构方面有很多改进。路由处理器和交换处理器的功能被集成到路由器交换处理器（RSP）中。这一新的体系结构减少了快速交换时系统总线的负载。集成后的功能对路由处理器和交换处理器都作了性能、稳定性、可扩充性和安全等方面的优化。7500系列路由器既不支持自治交换也支持硅交换，它支持更加灵活的优化交换。
　　Cisco 4000/2500系列路由器的硬件结构比7000/7500系列路由器的硬件结构简单。这些设备只在交换过程中才共享存储器。所有的报文缓存和Cache都位于共享存储器中，因此只支持快速交换或过程交换。
　　需要知道过程交换需要通过查询路由表来做出路由选择，而且其他交换技术都是通过缓存来提高交换速度的，因为其缓存的位置不同而分别称为不同的技术。
　　3 故障诊断与排除命令
　　Cisco ISO操作系统软件提供了一组功能丰富的命令，可以用来进行故障查找与排除、问题诊断以及性能检测。命令大致可以分为两类：show命令和debug命令。同时，还包含一组用于连接这两类命令的clear命令。下面我们分别讲解各命令
　　3.1 show命令
　　在这一节中，我们将讲述最常用的show命令，阐述这些命令的输出以及这些命令适用于解决的故障类型。为了叙述清楚，这些命令被分为全局系统命令、与接口相关的命令和与协议相关的命令。我们仅讨论最常使用的命令。
　　全局系统命令
　　本节将列出与路由器软件和硬件相关的输出命令，其中包括存储区和电源。show version命令是最基本的命令之一，它显示路由器本身以及其所使用的软、硬件的基本信息。show hardware命令的功能与show version命令类似。
　　命令的输出信息包括：IOS的版本、路由器持续运行的时间约23周、最近一次重启动的原因、路由器主存的大小、共享存储器的大小、闪存的大小、IOS映像的文件名，以及路由器从何处启动等信息。show version命令显示了路由器的许多非常有用的信息。在解决问题时，通常应该从这个命令开始收集数据。
　　假如路由器的多个接口同时丢失报文，则可能由于路由器内存不足或者CPU过载。用户可以使用show memory命令检查内存利用率（如下所示）。CPU利用率可以使用show process命令检查。
　　YH-Router#show memory
　　Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)
　　Processor 60DB19C0 19195456 6162924 13032532 11615164 11250780
　　Fast 60DB19C0 131072 128344 2728 2728 2684
　　show memory的前两行显示了存储器的一般信息，它表明系统有足够可用的内存。同时它还显示内存中没有碎片，因为在13.03兆字节可用内存中最大的可用块接近11.25兆字节。内存碎片表明内存被划分为了许多不连续的块。它将导致内存的利用率降低，严重时可能产生内存错误从而也严重影响路由器的性能。
　　现在看一看路由器中有许多内存碎片的情形（如下所示）。此时我们有足够多的可用内存（8.4兆字节），但是其中最大的块仅为0.5兆字节。连续内存中没有足够大的可用块，这有可能导致严重的内存分配问题。这些问题有时表现为一个或多个接口间歇性的丢失报文。此时路由器产生内存碎片错误消息。
　　HX-Router#sh mem
　　Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)
　　Processor 60DB19C0 19195456 10713712 8481744 192680 586748
　　Fast 60DB19C0 131072 90936 40136 40136 40092
　　使用命令show memory free，用户可以看到可用内存被划分为许多很小的碎片。需要注重的是，路由器中存在一定数量的内存碎片是正常的。虽然并没有一个很严格的界限来划分内存碎片的可接受程度，但是可用块的大小至少应该不小于可用内存的一半。用户可以通过重新启动路由器来解决这个问题。在重新启动时，系统重新分配内存和缓存空间。此时，用户应该监视内存分配的过程。假如再次发生类似的情况，则应该咨询Cisco TAC。
　　用户可以使用show process cpu命令检查路由器的CPU是否过载。该命令将给出路由器CPU的利用率，同时显示路由器中不同进程的CPU占用率。在下述示例中，路由器的CPU工作正常。在通常情况下，在5分钟内CPU的平均利用率小于60%是可以接受的。假如怀疑CPU利用率出现了问题，则需要不断地监视这一参数，因为它可能在短时间内发生变化。最好每10秒钟使用一次该命令。通过这种方法，可以清楚地了解CPU利用率的波动情况。
　　YH-Router#sh process cpu
　　CPU utilization for five seconds:15%/4%;one minute:175;five minutes:19%
　　PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
　　1 460184 5380085 85 0.00% 0.00% 0.00% 0 NTP
　　2 252749536 2384205 106010 0.00% 2.35% 2.65% 0 Check Heaps
　　......
　　13 26155236 9135958 2862 0.32% 0.25% 0.22% 0 IP Background
　　14 317720 150150 2116 0.00% 0.00% 0.00% 0 IP Cache ager
　　......
　　23 51598380 135094851 381 0.32% 0.24% 0.28% 0 IPX Input
　　24 86792124 23662071 3667 0.98% 0.87% 0.89% 0 IPX RIP
　　25 438480948 123384161 3553 7.94% 3.31% 3.91% 0 IPX SAP
　　......
　　假如CPU的平均利用率超过了80%，则表明路由器过载。下一步需要检测那一些进程导致了CPU利用率过高。在上面的显示中，我们可以看到进程IPX SAP占用了绝大部分的CPU处理能力，但是它还在可以接受的范围之内。有时候，假如SRB background参数持续过高，则表明发生了路由网桥风暴。
　　show process memory命令可以用来给出路由器可用内存的一般信息，然后显示每一个进程所占用的内存空间的具体信息。
　　假如路由器由于临时重启动而完全崩溃，则相应的错误消息将包含在show version命令的输出中。show stack命令用于跟踪路由器的堆栈，提供路由器临时重新启动的原因。假如由于错误而导致重新启动，堆栈记录将在输出的末尾显示。为了抽取与故障相关的信息，堆栈记录需要解码。这一工作通常由Cisco TAC工程师完成。此外，拥有相应CCO登录ID的用户可以通过将show stack命令的输出发送到CCO而获得解码信息。堆栈记录解码的结果有时与Cisco路由器的bug有关。
　　当用户向Cisco TAC报告故障时，支持技术人员通常要求用户发送show tech_support命令的输出结果。这个命令将导致下述命令的按序执行：Show version、Show controllers、Show buffers、Show interface、Show stack、Show process cpu、Show process memory和Show running-config。这些命令的组合将给出路由器配置以及大多数要害性能参数的具体信息。show tech_support命令的输出对于Cisco TAC技术人员解决复杂网络问题是十分有用。
　　与接口相关的命令
　　下面我们将阐述一些直接与路由器活跃接口相关的命令。show ip interface brief将显示每一个路由器接口的IP地址信息以及第二层的状态信息（如下所示）。其他与IP对应的协议的相关性信息可以通过相应命令属性获得，比如show ipx interface brief。
　　YH-Router#sh ip in brief
　　Interface IP-Address OK? Method Status Protocol
　　TokenRing0/0 172.26.12.3 YES NVRAM up up
　　TokenRing0/1 172.27.12.3 YES NVRAM up up
　　TokenRing0/2 172.28.12.3 YES NVRAM up up
　　TokenRing0/3 unassigned YES NVRAM administratively down down
　　Ethernet1/0 172.30.12.3 YES NVRAM up up
　　Ethernet1/0 172.31.12.3 YES NVRAM up up
　　Ethernet1/0 172.32.12.3 YES NVRAM up up
　　Ethernet1/0 172.33.12.3 YES NVRAM up up
　　show interface命令可以获得更多的信息。我们以以太网为例来讨论这些通用接口参数。
　　YH-Router#sh int e1/0
　　Ethernet1/0 is up,line protcol is up
　　Hardware is cxBus Ethernet,address is 00e0.f78a.6d40(bia 00e0.f78a.6d40)
　　Description:seg=E2 LAB SRV1
　　Internet address is 172.30.12.3/16
　　MTU 1500bytes,BW 10000Kbit,DLY 1000usec,rely 255/255,load 1/255
　　Encapsulation ARPA, loopback not set, keepalive set(10sec)
　　ARP type:ARPA,ARP Timeout 04:00:00
　　Last input 00:00:00,output 00:00:00,output hang never
　　Queueing strategy:fifo
　　Output queue 0/40,44 drops;input queue 0/75,66114 drops
　　5 minute input rate 181000 bits/sec,23 packets/sec
　　5 minute output rate 43000 bits/sec,26 packets/sec
　　525599659 packets input,2042735431 bytes, 0 no buffer
　　Received 4004547 broadcasts,10 runts,0 giants
　　139 input errors, 0 CRC, 129 frame, 0 overrun, 0 ignored, 0 abort
　　0 input packets with dribble condition detected
　　481020335 packets output, 1069273018 bytes, 47 underruns
　　20 output errors, 95880485 collisions, 0 interface resets
　　0 babbles, 0 late collision, 0 deferred
　　0 lost carrier, 0 no carrier
　　0 output buffer failures, 0 output buffers swapped out
　　其中：
　　Ethernet 1/0 is up 表明OSI模型的第一层成功启动。
　　Line protocol up 表明第二层成功启动 。
　　Description 用户自定义的描述。使用这一功能给出接口准确的描述是十分重要的。在一个大型组织中，一个局部网络的工程师很难定位发生故障的路由器。
　　MTU 指定最大传输单元，用户可以配置。
　　BW、Dly、rely、load（带宽、延迟、可靠性和负载）：这些参数与IGRP/EIGRP标准有关。带宽和延迟的配置可以影响到路由选择。在工作正常的接口中，可靠性的值为255。除非在十分繁忙的条件下，否则负载通常不应超过150/255。
　　Encapsulation 它指在接口的第二层封装。在以太网中，对于IP，Cisco的缺省设置为ARPA，而IPX的缺省设置为Novell-Ether。
　　从输出中还能获取哪些其他的信息呢？读者可以看到，ARP cache timeout的值为4小时（该值为缺省设置）。从路由器接口输入到输出的时间不到1秒钟。输出从未被挂起。接口计数器最后一次被清0是在5个星期以前。在评估接口的统计信息时，这些数据是十分有用的。在通常情况下，可以将计数器清０以便作进一步的监视。
　　接口所采用的是FIFO排队规则。输出队列和输入队列的缺省长度分别为40和75。队列中都不包含报文。在计数器最后一次被清0后，输入队列丢失了许多报文。但是，正如我们前面所说的，计数器5个星期未被清0；因此，该值不能说明一定发生了网络故障。在这种情况下，应该首先将计数器清０，然后再监视输出队列的丢失报文数。
　　同时，命令的输出中还显示每1秒钟通过路由器接口的平均信息量（以字节为单位）以及报文数。这些参数的总量信息、路由器接口观测到的所有广播报文的数量也在命令的输出中显示。假如广播报文的数量增长非常迅速，尤其是假如相对于输入报文的数量非常高，则表明在局域网段中有广播风暴。由于某些特定的应用程序需要频繁使用广播报文，因此确定广播报文的数量阀值是很困难的。但是，假如广播报文的数量超过了整个输入报文的30%，则需要使用局域网协议分析仪进一步检测网络。
　　我们还可以获取接口的下列错误检测信息：
　　Runts 是指大小小于最小值的报文。在示例的以太网中，该值为64。以太网中指定最小报文大小大小是由于在这种传输模式下的工作站需要检测碰撞。假如以太网段中包含以太网中继器并且其距离符合规定的标准，最小报文大小大小可以使处在这种传输模式下的工作站检测线路中的任何碰撞。
　　Giants 指大小超过线路可以承受的最大报文大小的报文。以太网的MTU通常为1500字节，或者最大的封装数据为1500字节。
　　Input errors 指到达报文中检测到的错误，也可能表明网段本身发生了错误。
　　Output errors 指输出报文中的错误，它可能表明路由器接口本身发生了故障。
　　CRCs 由于报文不正确的以太网校验和而检测到的循环冗余校验错。它可能由于网段的噪声引起，或者由于网卡故障、报文冲突引发。CRC的频率应是每100000个输入报文中发生一次。
　　Frame errors 指接收到的帧的类型与路由器以太网帧类型（IP协议帧类型为ARPA）不匹配。
　　Aborts 在碰撞检测中过度的重传而导致的问题。在以太网中，重传的最大次数不超过15次。
　　Dribble condition 指接收到的帧比MTU大，但不属于Giants。
　　Babble 是指持续接收到可疑的帧。
　　Deferred 假如线路繁忙，报文在传输时将被延缓发送。
　　Interface resets 在检测到过多的错误时，路由器将重置接口。这些错误可能存在于局域网段中，也可能是接口本身的错误。在此不能够判定具体是那儿发生故障，但是，假如伴随着大量的输出错误，则表明路由器接口本身发生故障。
　　Collisions 在以太网中，冲突被分为两大类：early和late。early collision 由发送方在帧的前64个字节进入线路之前检测到的冲突。early collision是以太网CSMA/CD访问方法中的组成部分。early collision通常导致小的被中断的帧或称为runt。Late collision发生在帧的多个字节（大于64）被发送到线路中时产生的冲突。在理论上，以太网不会产生此类冲突。产生late collision的原因包括：
　　电缆违反了距离规则。
　　发生故障的NIC卡不正确地监听线路。
　　Lost carrier 表明在计数器最后一次清0后，载波和线路协议发生的故障。此类故障通常与路由器无关。例如，载波丢失可能是因为路由器与集线器之间的电缆连接中断。
　　Buffer parameters show interface命令还提供与缓冲区分配有关的故障信息，它包括no buffer、overruns、ignored、underruns、buffer failures和swapped out buffers等。
　　
　　上面，我们具体讨论了show interface命令的用法。这些命令的输出提供了与路由器接口相关以及与传输介质相关的参数等有价值的信息。
　　show controller命令提供连接到路由器接口物理线路以及传输介质的具体信息。并且提供状态的历史信息。其中一些具体信息很少被使用，它们一般仅被TAC技术人员用于解决十分复杂的问题。
　　与协议相关的命令
　　本节将讨论如何使用与不同协议相关的显示命令。
　　show protocol命令给出了路由器运行的协议信息以及路由这些协议的每一个接口的地址信息（如下所示）。
　　YH-Router#sh protocol
　　Global values:
　　Internet Protocol routing is enabled
　　Novell routing is enabled
　　Serial0 is up, line protocol is up
　　Internet address is 171.137.8.130/25
　　Novell address is AB890880.0000.30e8.b7c8
　　Serial1 is administratively down, line protocol is down
　　TokenRing0 is up, line protocol is up
　　Internet address is 171.137.6.1/25
　　Novell address is AB890600.0000.30e8.b7c8
　　......
　　3.2 Debug命令
　　Cisco IOS 软件中包含大量的调试命令。这些命令可以在路由器正常工作或者发生网络故障时获得在路由器中交换的报文和帧的细节信息。调试命令在排除网络故障时的非凡功能，可以减少用户对协议分析仪的需求。在使用调试命令时，需要注重以下几点：
　　在没有完全把握调试命令的工作过程以及它所提供的信息时，不要使用调试命令。
　　调试命令仅能捕捉通过过程交换的报文。调试命令会明显增加处理器的负载。某一些命令的负载很小，但是另一些处理器敏感的命令会极大地增加处理器的负担。建议读者在使用调试命令之前，使用命令show process cpu检查CPU的负载。即使CPU的负载很小，在使用处理器敏感的命令时仍需要十分慎重。在不能确定的情况下，可以查询Cisco调试命令参考手册。对CPU十分敏感的命令将会产生警告信息。通常情况下，调试命令的大量输出将会增加处理器的负担。
　　调试命令针对故障排除，监视时最好不要使用这些命令。在获得了足够的信息后，应马上中止调试命令的执行。
　　下面我们将阐述在Cisco IOS中可以使用的各种调试命令。为了叙述清楚，我们将所有的调试命令分为三类：全局（系统）调试命令、接口调试命令以及协议调试命令。与show命令类似，这些命令之间并没有严格的界限。
　　首先，需要了解的是有哪些调试命令可以使用。使用与调试相关的帮助，输入“debug ?”，我们将获得了一个命令的列表，其中每一个命令都包含若干的属性，它们在排除故障时提供各种不同的作用。
　　全局调试
　　在配置Cisco路由器时，全局和接口命令的界限是十分明显的。在这种情况下，我们使用“全局”来标识那些不能用于接口调试或者特定的传输介质类型和协议调试的命令。例如，在2500系列路由器中，就可以使用调试命令分析Cisco发现协议（Cisco Discovery Protocol，CDP）。我们通过telnet远程登录到路由器。在缺省方式下，调试命令的输出被发送到控制台，假如处于telnet会话中，我们可以使用terminal monitor命令查看输出。
　　接口调试
　　debug serial interface命令是直接与路由器接口和传输介质类型相关的调试命令。在下面的示例中，串行接口采用HDLC封装。端到端的HDLC保持活跃的报文每10秒钟交换一次。这表明链路操作正常并且第二层工作正常。show interface serial0命令表明线路协议正常启动。使用undebug all命令关闭所有的调试。
　　YH-Router#debug serial interface
　　Serial network interface debugging is on
　　YH-Router#
　　Jun 1 21:54:55 PDT:Serial0: HDLC myseq 171093, mineseen 171093*, yourseen 1256540,line up
　　Jun 1 21:55:05 PDT:Serial0: HDLC myseq 171094, mineseen 171094*, yourseen 1256541,line up
　　Jun 1 21:54:15 PDT:Serial0: HDLC myseq 171095, mineseen 171095*, yourseen 1256542,line up
　　YH-Router#undebug all
　　All possible debugging has been turned off
　　协议调试
　　下面我们举协议调试的两个示例。两个示例都与IP协议有关。当然，调试命令适用于所有的其他协议。
　　第一个示例（如下所示）显示ARP调试。ARP调试启动，然后清除ARP缓存，同时产生了ARP请求和响应。首先，我们使用命令清除了路由器上所有的ARP缓存，因此路由器连接的每一个局域网段都将产生ARP报文。因为我们不需要产生过多的ARP报文，所以所选择的路由器仅与一个以太网段相连。
　　YH-Router#debug arp
　　ARP packet debugging is on
　　YH-Router#clear arp
　　YH-Router#
　　*Jun 1 21:57:36 PDT: IP ARP: sent req src 171.136.10.1 00e0.1eb9.bbcd
　　dst 171.136.10.34 00a0.24d1.5823 Ethernet0
　　*Jun 1 21:57:36 PDT: IP ARP: sent req src 171.136.10.1 00e0.1eb9.bbcd
　　dst 171.136.10.10 0080.5f06.ca3d Ethernet0
　　......
　　*Jun 1 21:57:36 PDT: IP ARP: rcvd req src 171.136.10.10 0080.5f06.ca3d, dst 171.136.10.1 Ethernet0
　　*Jun 1 21:57:36 PDT: IP ARP: creating entry for IP address:171.136.10.10,hw: 0080.5f06.ca3d
　　......
　　第二个示例（如下所示）显示IP RIP调试。在调试开始时，并没有清空路由器表，因为路由器每隔30秒自动进行一次RIP更新，因此不需要强制更新。与第一个示例中类似，在获得了足够的信息后应该关闭所有的调试。
　　YH-Router#debug ip rip events
　　RIP event debugging is on
　　YH-Router#
　　NOV 27 13:55:45 PST: RIP: sending v1 update to 255.255.255.255 via TokenRing1/0 (165.48.65.136)
　　NOV 27 13:55:45 PST: RIP: Update contains 25 routes
　　NOV 27 13:55:45 PST: RIP: Update queued
　　NOV 27 13:55:45 PST: RIP: Update contains 6 routes
　　NOV 27 13:55:45 PST: RIP: Update queued
　　NOV 27 13:55:45 PST: RIP: Update sent via TokenRing1/0
　　......
　　YH-Router#undeb all
　　All possible debugging has been turned off
　　3.3 Ping命令
　　Ping是最常使用的故障诊断与排除命令。它由一组ICMP回应请求报文组成，假如网络正常运行将返回一组回应应答报文。ICMP消息以IP数据包传输，因此接收到ICMP回应应答消息能够表明第三层以下的连接都工作正常。
　　Cisco的ping命令不但支持IP协议，而且支持大多数其他的桌面协议，如IPX和AppleTalk协议的ping命令。我们首先看一下支持IP协议的ping命令以用户EXEC方式执行的情况，然后再讨论在特权模式下，扩展的ping命令包含的许多强大功能。
　　用户执行模式
　　IP PING 简单的IP ping既可以在用户模式下执行，也可以在特权模式下执行。正常情况下，命令会发送回5个回应请求，5个赞叹号表明所有的请求都成功地接收到了响应。输出中还包括最大、最小和平均往返时间等信息。
　　每一个“！”表明一个echo响应被成功的接受，假如不是“！”号，则表明echo响应未被接收到的原因：
　　！ 响应成功接收
　　· 请求超时
　　U 目的不可达
　　P 协议不可达
　　N 网络不可达
　　Q 源抑制
　　M 不能分段
　　？ 不可知报文类型
　　IPX PING IPX ping命令只能在运行IOS v 8.2及其以上版本的路由器上执行。用户模式下的IPX ping通常仅用于测试Cisco路由器接口。在特权模式下，用户可以ping特定的NOVELL工作站，命令的格式为“ping ipx IPX地址”。
　　APPLETALE PING 该命令使用Apple Echo Protocol（AEP）以确认AppleTalk节点之间的连通性。需要注重的是，目前的Cisco路由器仅对以太网接口支持Apple Echo Protocol。命令的格式为“ping apple Appletalk地址”。
　　特权执行模式
　　在特权执行模式下，扩展的ping命令适用于任何一种桌面协议。它包含更多的功能属性，因此可以获得更为具体的信息。通过这些信息我们可以分析网络性能下降的原因而不单单是服务丢失的原因。扩展的ping命令的执行方式也是敲入ping。然后路由器提示各种不同的属性。
　　EXTENDED IP PING 其使用方法如下所示：
　　YH-Router#ping
　　Protocol [ip]:
　　Target IP address: 165.48.183.12
　　Repeat count [5]: 10
　　Datagram size [100]: 1600
　　Timeout in seconds [2]:
　　Extended commands [n]: y
　　Source address or interface: 165.48.48.3
　　Type of service [0]:
　　Set DF bit in IP header? [no]:
　　Data pattern [0xABCD]:
　　Loose, Srict, Record, Timestamp, Verbose[none]:
　　Sweep range of sizes [n]:
　　Type escape sequence to abort.
　　Sending 10, 1600-byte ICMP Echoes to 165.58.183.12, timeout is 2 seconds:
　　!!!!!!!!!!
　　SUCcess rate is 100 percent (10/10), round-trip min/avg/max = 36/39/48 ms
　　首先我们讨论特权模式下的ping的各种可用属性。每种属性的缺省值在括号中显示。
　　Protocol 需要测试的协议。
　　Target address 测试的目标地址。
　　Repeat count 假如出现间歇性的失败或者响应时间过慢，ping重复的次数。
　　Datagram size 假如怀疑报文由于延迟过长或者分段失败而丢失，则可以提高报文的大小。例如，我们可以使用1600字节的报文来强制分段。
　　Timeout 假如怀疑超时是由于响应过慢而不是报文丢失，则可以提高该值。
　　Extended commands 回答确定以获得扩展属性。
　　Source address 必须是路由器接口的地址。
　　Type of service 根据RFC 791 TOS规定的属性，通常缺省值为0。
　　Set DF bit in IP header？ 通过设置DF位禁止分段，即使是报文超过了路由器定义的MTU也禁止分段。
　　Data pattern [0xABCD] 通过改变数据模式可以测试线路的噪声。
　　Loose，Strict，Record，Timestamp，Verbose[none] 这些都是IP报文头的属性。一般只使用Record属性和Verbose，其他属性很少被使用。Record可以用来记录报文每一跳的地址，Verbose属性给出每一个回应应答的响应时间。。
　　Sweep range of sizes [n] 该属性主要用于测试大报文被丢失、处理速度过慢或者分段失败等故障。
　　
　　EXTEND IPX PING 扩展的IPX ping也答应用户修改参数，比如报文大小和重复次数。对用户模式下ping的另一个增强属性是使用了Novell Standard echo属性。使用这一属性，用户可以ping装载IPX的工作站。假如禁用该属性，Novell IPX设备将不响应ping，因为它们不支持Cisco proprietary IPX ping协议。用户可以修改设备的属性使它们支持这一特性
　　EXTENDED APPLETALK PING 扩展的AppleTalk ping命令是对用户模式下ping的增强，这一点与扩展的IPX ping类似。与IP和IPX扩展ping一样，用户也可以选择Verbose等属性。
　　3.4 trace命令
　　trace命令提供路由器到目的地址的每一跳的信息。它通过控制IP报文的生存期（TTL）字段来实现。TTL等于1的ICMP回应请求报文将被首先发送。路径上的第一个路由器将会丢弃该报文并且发送回标识错误消息的报文。错误消息通常是ICMP超时消息，表明报文顺利到达路径的下一跳，或者端口不可达消息，表明报文已经被目的地址接收但是不能向上传送到IP协议栈。
　　为了获得往返延迟时间的信息，trace发送三个报文并显示平均延迟时间。然后将报文的TTL字段加1并发送3个报文。这些报文将到达路径的第二个路由器上，并返回超时错误或者端口不可达消息。反复使用这一方法，不断增加报文的TTL字段的值，直到接收到目的地址的响应消息。
　　在有些情况下，使用trace命令可能会导致故障。因为IOS中存在与trace命令相关的bug。这些bug的相关信息可以从CCO得到。另外一个问题是，某些目标站点不响应ICMP端口不可达消息。当命令的输出显示一系列星号（*）时，就可能碰到了此类站点。用户可以使用Ctrl-Shift-6中断命令的执行。
　　用户执行模式 下面展示了一个简单的在用户执行模式下执行的trace命令的输出。到达目的地的距离是3跳。TTL值为1的3个报文的响应消息是ICMP超时错误，并且返回报文的IP地址有两个。因为路由器1和路由器2在同一个网段中，并且它们到路由器3的距离都是一跳，因此这些路由器都响应该报文。
　　Router3#trace 171.144.1.39
　　Type escape sequence to abort.
　　Tracing the route to Router9 (171.144.1.39)
　　1 Router2 (165.48.48.2) 0 msec
　　Router2 (165.48.48.2) 0 msec
　　Router1 (165.48.48.1) 0 msec
　　2 165.48.48.129 12 msec
　　Router6 (165.48.49.129) 12 msec 12 msec
　　3 Router4 (171.133.1.2) 12 msec 12 msec
　　Router9 (171.144.1.39) 12 msec 12 msec
　　Router3
　　下面列出了IP trace命令的输出中出现的不同字符及其含义：
　　XY msec 在接收到响应消息之前的往返延迟（以毫秒为单位）
　　* 报文超时
　　？ 报文类型不能识别
　　U 端口不可达
　　P 协议不可达
　　N 网络不可达
　　H 主机不可达
　　Q ICMP 源抑制
　　特权模式扩展Trace 用于扩展ping命令的许多属性都可以用来扩展trace命令的功能。扩展trace命令的非凡属性有：
　　Numeric display 在缺省情况下，trace命令的输出中既包括IP地址也包括其对应的DNS域名。假如用户不需要显示DNS域名，则可以使用该属性。
　　Probe count 其缺省值为3，用户可以根据需要进行调整。
　　TTL 该值可以在最大和最小TTL值之间变化。
　　Port number 这是一个非常有用的属性，它可以使工程技术人员跟踪特定的传输层端口。因此，不但可以确认源端与目的端之间的IP连通性，而且可以确认高层服务是否可被访问。
　　
　　与trace命令相关的另外一个问题是，假如存在到达目的地的多条路径，返回报文的源地址可能不相同。在这种情况下，用户需要仔细比较不同返回报文的延迟时间。假如仍不能得到明确的结果，可以远程访问路径上的一个或多个路由器，使用trace命令访问源地址和目的地址。
　　4 理解Cisco错误消息
　　4.1 错误消息格式
　　系统错误消息格式如下：
　　%Facility - subfacility - Severity - Mnemonic ： Message Text
　　Facility 它指出错误消息涉及的设备名。该值可以是协议、硬件设备或者系统软件模块。
　　Subfacility 它仅与通道接口处理器（CIP）卡有关。具体的信息可以参见Cisco文档的相关章节。
　　Severity 它是一个范围在0到7之间的数字。数字的值越小，严重程度越高。
　　Mnemonic 唯一标识错误消息的单值代码。该代码通常可以暗示错误的类型。
　　Message Text 它是错误消息的简短描述，其中包括涉及的路由器硬件和软件信息。
　　下面是一些错误消息的示例。用户可以查阅CCO ISO文档的系统错误消息一节，以查找这些错误消息的说明。
　　%DUAL-3-SIA：Route 171.155.148.192/26 stuck-in-active state in IP-EIGP 211. Cleaning up
　　%LANCE-3-OWNERR: Unit 0, buffer ownership error
　　需要注重的是，并不是所有的消息都涉及到故障或者问题的状况。某些消息显示的是状态方面的信息。例如，以下消息仅表明ISDN BRI 0接口与特定的远端数据连接。
　　%ISDN-6-CONNECT: Interface BRI0 is now connected to 95551212
　　4.2 Traceback Report
　　某些与路由器内部错误相关的错误消息包含了traceback信息。在向Cisco TAC报告错误时，应在错误描述中加入这些信息。
　　5 错误消息和事件信息的日志
　　根据错误消息的重要性和有效性，Cisco错误消息可以被记录到以下位置：
　　控制台
　　虚拟终端
　　Syslog服务器
　　内部缓冲区
　　logging on命令使日志消息的输出到上述位置。对于Syslog服务器，必须使用下述全局配置命令指明服务器的IP地址：
　　logging ip-address
　　通过反复使用这一命令，可以建立一个服务器的列表。在治理大型网络时，通常需要设置冗余服务器。
　　logging buffered命令用于将日志信息发送到内部缓冲区。缓冲区的大小必须在4096字节以上。缺省值根据系统平台的不同而不同。用户需要选择适合环境的缓冲区大小。假如缓冲区太小，新的消息将会覆盖旧的消息。这有可能会导致问题。但是，假如缓冲区大小过大将会浪费系统缓存。no logging buffered命令将禁止消息被写入内部缓存。
　　用户可以使用show logging命令显示内部缓冲区的内容。假如用户需要某一时间段的信息，首先使用NTP或者手工设置时钟，具体操作为：
　　YH-Router#clock set 11:37:00 December 2000
　　YH-Router#sh clock
　　11:37:03.596 PST Fri Dec 11 2000
　　日志消息的时间戳和调试信息可以使用以下全局配置命令：
　　YH-Router (config)#service timestamps log datetime
　　YH-Router (config)#service timestamps debug datetime
　　terminal monitor命令将在当前终端上显示调试时的日志信息。该命令不是一个配置命令。相反，它可以通过telnet到路由器时在命令行方式下使用。
　　在大多数情况下，用户可能需要显示某一级别的日志信息。因此，日志信息被分为八个不同的级别，按照重要程度由高到低排列如下：
　　Emergencies
　　Alerts
　　Critical
　　Errors
　　Warnings
　　Notifications
　　Informational
　　Debugging
　　例如，需要在控制台上显示严重程度等于或者大于警告（Warning）的所有日志信息，可以使用下述全局配置命令：
　　logging console warning
　　类似的，将某种类型的日志信息发送到当前的终端时，使用
　　logging monitor level
　　或者将信息发送到Syslog服务器时使用
　　logging trap level
　　与terminal monitor命令不同，logging monitor命令是路由器配置的一部分。前一种命令不答应在不同的安全级别下执行。
　　需要注重的是，将日志记录到不同的位置时，系统开销变化很大。将日志记录到控制台的开销比较大，然而将日志记录到虚拟终端时开销较小。使用Syslog服务器时开销更小。系统开销最小的日志写入方式是写入内部缓冲区。
　　6 核心转储（Core Dump）
　　为了查找路由器崩溃的原因，我们可以使用许多命令来获取有效的信息。其中我们已经讲解了show stacks命令的用法。核心转储是系统内存映象的拷贝，它可以被写入到TFTP服务器中。从这个二进制文件中，我们可以获得与路由器崩溃或者严重误操作相关的信息，通过这些信息可以排除可能的故障。
　　下面的配置命令将核心转储写入到命令中IP地址对应的TFTP服务器上：
　　exception dump ip-address
　　write core命令通常用于路由器发生严重的误操作但是没有完全崩溃时，保存核心映像。
　　只有运行IOS v 9.0或更高版本的服务器才可以使用核心转储。但是，需要注重的是，在使用核心转储时，最好获取有经验的工程师或者Cisco TAC的支持。
　　7 结束语
　　要顺利地诊断并排除网络故障，网络工程技术人员必须把握两种基本的技能。首先是对网络技术和协议要有清楚的理解，它是诊断与排除网络故障的基础。没有适当的知识和经验，故障诊断与排除工具比如路由器诊断命令和网络分析仪都不能发挥其作用。
　　网络工程技术人员必须把握的第二种技能是将所把握的知识以有条理的方式应用于诊断和排除网络故障的过程中。本文虽然只阐述了一些诊断的命令，但需要强调的是：故障诊断与排除是一种结构化的方法。许多工程技术人员认为故障诊断与排除计划不如研究和应用技术本身重要。事实上，正确的计划在故障诊断与排除过程中往往起决定性的作用。在故障排除过程中，一个偶然的行为可能使故障得以顺利解决，但是它不能替代结构化的故障诊断与排除方法。
　　网络故障的排除是一项系统工程，应该经过定义问题、搜集事实、基于事实考虑可能性、建立行动计划、实施计划、观察结果和循环过程等步骤，这一过程就如同软件开发过程的瀑布模型，其重要性是不言而喻的。限于篇幅，本文对这些知识不再赘述