Cisco 路由器故障诊断技术 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

 

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 个星期以前。在评估接口的统计信息时，这些数据是十分有用的。在通常情况下，可以将计数器清 0 以便作进一步的监视。

　　接口所采用的是 FIFO 排队规则。输出队列和输入队列的缺省长度分别为 40 和 75 。队列中都不包含报文。在计数器最后一次被清 0 后，输入队列丢失了许多报文。但是，正如我们前面所说的，计数器 5 个星期未被清 0 ；因此，该值不能说明一定发生了网络故障。在这种情况下，应该首先将计数器清 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 的原因包括：
　　 &#61550;  ;; 电缆违反了距离规则。
　　 &#61550;  ;; 发生故障的 NIC 卡不正确地监听线路。
　　 Lost carrier 表明在计数器最后一次清 0 后，载波和线路协议发生的故障。此类故障通常与路由器无关。例如，载波丢失可能是因为路由器与集线器之间的电缆连接中断。
　　 Buffer parameters show interface 命令还提供与缓冲区分配有关的故障信息，它包括 no buffer 、 overruns 、 ignored 、 underruns 、 buffer failures 和 swapped out buffers 等。  

　　上面，我们详细讨论了 show interface 命令的用法。这些命令的输出提供了与路由器接口相关以及与传输介质相关的参数等有价值的信息。

　　 show controller 命令提供连接到路由器接口物理线路以及传输介质的详细信息。并且提供状态的历史信息。其中一些详细信息很少被使用，它们一般仅被 TAC 技术人员用于解决十分复杂的问题。

 

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 错误消息可以被记录到以下位置：

　　 &#61550;  ;; 控制台
　　 &#61550;;; 虚拟终端
　　 &#61550;;; Syslog 服务器
　　 &#61550;;; 内部缓冲区
　　 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 到路由器时在命令行方式下使用。

　　在大多数情况下，用户可能需要显示某一级别的日志信息。因此，日志信息被分为八个不同的级别，按照重要程度由高到低排列如下：

　　 &#61550;  ;; Emergencies
　　 &#61550;;; Alerts
　　 &#61550;;; Critical
　　 &#61550;;; Errors
　　 &#61550;;; Warnings
　　 &#61550;;; Notifications
　　 &#61550;;; Informational
　　 &#61550;;; 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 结束语

　　要顺利地诊断并排除网络故障，网络工程技术人员必须掌握两种基本的技能。首先是对网络技术和协议要有清楚的理解，它是诊断与排除网络故障的基础。没有适当的知识和经验，故障诊断与排除工具比如路由器诊断命令和网络分析仪都不能发挥其作用。

　　网络工程技术人员必须掌握的第二种技能是将所掌握的知识以有条理的方式应用于诊断和排除网络故障的过程中。本文虽然只阐述了一些诊断的命令，但需要强调的是：故障诊断与排除是一种结构化的方法。许多工程技术人员认为故障诊断与排除计划不如研究和应用技术本身重要。事实上，正确的计划在故障诊断与排除过程中往往起决定性的作用。在故障排除过程中，一个偶然的行为可能使故障得以顺利解决，但是它不能替代结构化的故障诊断与排除方法。

　　网络故障的排除是一项系统工程，应该经过定义问题、搜集事实、基于事实考虑可能性、建立行动计划、实施计划、观察结果和循环过程等步骤，这一过程就如同软件开发过程的瀑布模型，其重要性是不言而喻的。