第1章故障排除概述

目录

目 录

第1章 故障排除概述 .................................................................................................................... 1

1.1 网络故障排除综述 .................................................................................................................1

1.1.1 引言 ............................................................................................................................1 1.1.2 网络故障的一般分类 ....................................................................................................2 1.1.3 一般网络故障的解决步骤 ............................................................................................2 1.2 路由器常用诊断工具介绍 ......................................................................................................8

1.2.1 ping命令 ......................................................................................................................9 1.2.2 tracert 命令 ............................................................................................................... 13 1.2.3 display命令 .............................................................................................................. 17 1.2.4 reset命令 ................................................................................................................. 22 1.2.5 debugging命令 ........................................................................................................ 23 1.3 故障排除常用方法 ............................................................................................................... 25

1.3.1 分层故障排除法 ........................................................................................................ 25 1.3.2 分块故障排除法 ........................................................................................................ 26 1.3.3 分段故障排除法 ........................................................................................................ 27 1.3.4 替换法 ....................................................................................................................... 27 1.4 故障排除对网络维护和管理人员的要求............................................................................... 27

1.4.1 对协议要求有精深的理解 .......................................................................................... 27 1.4.2 能够引导客户详细描述出故障现象和相关信息 ......................................................... 28 1.4.3 充分了解自己所管理和维护的网络 ........................................................................... 30 1.4.4 及时进行故障排除的文档记录和经验总结 ................................................................ 31

i

网络故障诊断与排除 第1章 故障排除概述

第1章 故障排除概述

1.1 网络故障排除综述

1.1.1 引言当今的网络互连环境是复杂的，而且其复杂性的日益增长也是可以预见的，主要原因如下：



现代的因特网络要求支持广泛的应用，包括数据、语音、视频及它们的集成传输。



新业务发展使网络带宽的需求不断增长，这就要求新技术的不断出现。例如：十兆以太网向百兆、千兆以太网的演进；MPLS技术的出现；提供QoS能力等。



新技术的应用同时还要兼顾传统的技术。例如，传统的SNA体系结构仍在某些场合使用，DLSw作为通过TCP/IP承载SNA的一种技术而被应用。

因此，现代的因特网络是协议、技术、介质和拓扑的混合体。因特网络环境越复杂，意味着网络的连通性和性能故障发生的可能性越大，而且引发故障的原因也越发难以确定。同时，由于人们越来越多的依赖网络处理日常的工作和事务，一旦网络故障不能及时修复，所造成的损失可能很大甚至是灾难性的。

能够正确地维护网络，并确保出现故障之后能够迅速、准确地定位问题并排除故障，对网络维护人员和网络管理人员来说是个挑战，这不但要求他们对网络协议和技术有着深入的理解，更重要的是要建立一个系统化的故障排除思想并合理应用于实践中，以将一个复杂的问题隔离、分解或缩减排错范围，从而及时修复网络故障。

本书着眼于帮助网络维护人员和管理人员,将他们所掌握的知识有条理的应用于诊断和排除网络故障的过程中；帮助他们针对各种网络环境中的常见故障现象进行定位和解决。

1

网络故障诊断与排除 第1章 故障排除概述

1.1.2 网络故障的一般分类

网络故障一般分为两大类：连通性问题和性能问题。它们各自故障排除的关注点如下： 1. 连通性问题

  

硬件、媒介、电源故障； 配置错误； 设备兼容性问题。

2. 性能问题

    

网络拥塞；

到目的地不是最佳路由； 供电不足； 路由环路； 网络不稳定。

1.1.3 一般网络故障的解决步骤

前面我们基本了解了计算机网络故障的大致种类，那么，如何排除网络故障呢？我们建议采用系统化故障排除思想。故障排除系统化是合理地、一步一步找出故障原因，并解决故障的总体原则。它的基本思想是系统的，将可能的故障原因所构成的一个大集合缩减（或隔离）成几个小的子集，从而使问题的复杂度迅速下降。

故障排除时，有序的思路有助于解决所遇到的任何困难，下图给出了一般网络故障排除流程。

2

网络故障诊断与排除 第1章 故障排除概述

故障现象观察故障相关信息收集循环2经验判断和理论分析各种可能原因列表对每一原因实施排错方案循环1故障排除？YN恢复实施方案前的网络状态故障排除过程文档化 图1-1 网络故障排除基本步骤

 说明：

该流程是网络维护人员所能够采用的排错模型中的一种，如果你根据自己的经验和实践总结了另外的排错模型，并证明它是行之有效的，请继续使用它；网络故障解决的处理流程是可以变化的，但故障排除有序化的思维模式是不可变化的。

下面我们以一个故障排除的实例来学习如何应用这些步骤。 案例： FTP业务传输速度慢

该案例组网如下：某校园网的三个局域网，其中10.11.56.0为一个用户网段，10.11.56.118为一个日志服务器；10.15.0.0是一个集中了很多应用服务器的网段。

3

网络故障诊断与排除 第1章 故障排除概述

图1-2 服务器FTP业务传输速度慢

1. 故障现象描述

要想对网络故障做出准确的分析，首先应该了解故障表现出来的各种现象，然后才能确定可能产生这些现象的故障根源或症结。因此，对网络故障做出完整、清晰的描述是重要的一步。

如上述案例，“日志服务器与10.15.0.0/16网段的备份服务器间备份发生问题”就是一个不完整不清晰的故障现象描述。因为这个描述没有讲述清楚下列问题：

  

这个问题是连续出现，还是间断出现的？

是完全不能备份，还是备份的速度慢（即性能下降）？ 哪个或哪些局域网服务器受到影响，地址是什么？

对实际的的故障现象较好的描述是：

在网络的高峰期，日志服务器10.11.56.118到集中备份服务器10.15.2.153之间进行备份时，FTP传输速度很慢，大约是0.6Mbps。 2. 故障案例相关信息收集

本步骤是搜集有助于查找故障原因的更详细的信息。主要是三种途径：

 

向受影响的用户、网络人员或其他关键人员提出问题；

根据故障描述性质，使用各种工具搜集情况，如网络管理系统、协议分析仪、相关display和debugging命令等；



测试性能与网络基线进行比较。

 说明：

网络基线是指在网络运行正常时，对网络性能进行评估并记录，以作为将来评估网络性能提升或下降的标准。

4

网络故障诊断与排除 第1章 故障排除概述

网络基线的评估应当是管理员一个周期性的任务。建立基线作用在于当网络性能下降时，它可以为确定故障的严重程度提供参照；如果在网络故障后才试图建立基线，则为时已晚。

制定网络基线有很多方法。可以使用专门的网络管理工具，如华为公司的Quidview产品；也可以使用ping的响应时间和display的显示信息来建立一个提供基本信息的基线。



如上述案例，可以向用户提问或自行收集下列相关信息：

  

网络结构或配置是否最近修改过，即问题出现是否与网络变化有关？ 是否有用户访问受影响的服务器时没有问题？

在非高峰期日志服务器和备份服务器间FTP传输速度是多少？

通过该步骤，我们收集到了下面一些相关信息：

 

最近10.11.56.0网段的客户机不断在增加；

129.9.0.0网段的机器与备份服务器间进行FTP传输时速度正常为7Mbps，与日志服务器间进行FTP传输时速度慢，只有0.6Mbps；



在非高峰期日志服务器和备份服务器间FTP传输速度正常，大约为6Mbps；

3. 经验判断和理论分析

利用前两个步骤收集到的数据，并根据自己以往的故障排除经验和所掌握的因特网络设备和协议的知识，来确定一个排错范围。通过范围的划分，就只需注意某一故障或与故障情况相关的那一部分产品、介质和主机。

如上述案例：我们现在能够确定是一个网络性能下降问题。那么，是网段10.11.56.0的性能问题？是中间网云的性能问题？是10.15.0.0网段的性能问题呢？

由于129.9.0.0网段的机器与备份服务器间进行FTP传输时速度正常为7Mbps这一事实，我们可以排除掉10.15.0.0网段的性能问题。 4. 各种可能原因列表

该步骤列出根据经验判断和理论分析后总结的各种可能原因。 如上述案例，可能原因如下：

网段10.11.56.0的性能问题，其原因可能为：



日志服务器A的性能问题；

5

网络故障诊断与排除 第1章 故障排除概述

  

10.11.56.0网络的网关性能问题； 10.11.56.0网络本身的性能问题。

网云性能问题，主要是到网络10.15.0.0的路由不是最佳路由。

5. 对每一原因实施排错方案

根据所列出的可能原因制定故障排除计划，分析最有可能的原因，确定一次只对一个变量进行操作，这种方法是使你能够重现某一故障的解决办法。如果有多个变量同时被改变，而问题得以解决，那么如何判断哪个变量导致了故障发生呢？  说明：

我们在对故障排除流程5、6、7步骤介绍完毕后，再继续进行上述案例的排错步骤介绍。 6. 观察故障排除结果

当我们对某一原因执行了排错方案后，需要对结果进行分析，判断问题是否解决，是否引入了新的问题。如果问题解决，那么就可以直接进入文档化过程；如果没有解决问题，那么就需要再次循环进行到故障排除过程。 7. 循环进行故障排除过程

当一个方案的实施没有达到预期的排错目的时，我们进入到该步骤――这是一个努力缩小可能原因的清单过程。

在进行下一循环之前必须做的事情就是将网络恢复到实施上一方案前的状态。如果保留上一方案对网络的改动，很可能导致新的问题，例如：假设修改了访问列表但没有产生预期的结果，此时如果不将访问列表恢复到原始状态，就会导致出现不可预期的结果。 循环排错可以有两个切入点：



当针对某一可能原因的排错方案没有达到预期目的，循环进入下一可能原因制定排错方案并实施；



当所有可能原因列表的排错方案均没有达到排错目的，重现进行故障相关信息收集以分析新的可能原因。

如上述案例，我们在列出了可能原因列表后，开始制定方案进行故障排除。 可能原因1：网络10.11.56.0到网络10.15.0.0的路由不是最佳路由。

6

网络故障诊断与排除 第1章 故障排除概述

测试方案：在10.11.56.0网段的网关上使用“tracert 10.15.2.153”命令，发现探测报文返回时长仅为10ms，表明该可能原因并不是造成故障的原因。我们进入循环排错过程。

可能原因2：日志服务器A的性能问题。

测试方案：测试同一网段的主机C(10.11.56.120)和日志服务器(10.11.56.118)间的FTP传输速度是6Mbps(正常)。可见问题与服务器A无关。 可能原因3：10.11.56.0网络的网关性能问题。

测试方案：测试主机C和备份服务器B(10.15.2.153)间FTP传输速度是7Mbps(正常)。排除了网关因素，因为B、C在不同网段上而速度正常。 可能原因4：10.11.56.0网络本身的性能问题。

测试方案：在网段10.11.56.0的以太网交换机上使用命令“display mac-address”，输出如下：

Port Rcv-Unicast Rcv-Multicast Rcv-Broadcast

-------- -------------------- -------------------- ---------------- 6/32 10317812 0 8665

Port Xmit-Unicast Xmit-Multicast Xmit-Broadcast -------- -------------------- -------------------- ---------------- 6/32 6667987 286652 2474038 广播：单播=1：3，比例太大

Port Rcv-Octet Xmit-Octet

-------- -------------------- ------------------------------------- 6/32 14094829358 15143041

在网段10.15.0.0上的以太网交换机上使用命令“display mac-address”输出如下：

Port Rcv-Unicast Rcv-Multicast Rcv-Broadcast -------- -------------------- -------------------- ------------- 6/36 55780287 0 285

Port Xmit-Unicast Xmit-Multicast Xmit-Broadcast -------- -------------------- -------------------- -------------- 6/36 27879749 190257 119430

（广播：单播比例＝1：270，属于正常。）

Port Rcv-Octet Xmit-Octet

-------- -------------------- -----------------------------------

7

网络故障诊断与排除 第1章 故障排除概述

6/36 67172587081 4998816809

由此知道，网段10.11.56.0上广播包和单播包比例为1:3，确实太大了。再次询问用户该网段主要运行的业务是什么，从而得出了故障最终原因如下：10.11.56.0是普通用户网段，由于业务原因每个用户需要发送大量广播包和多播包，随着近期越来越多的用户接入该网络，在这个网段上的服务器需要花费更多的资源来处理越来越多的广播和多播包，因此其服务的传输速度自然减慢。

由于这是一个网络布局不恰当的问题，于是重新安排服务器的位置，将服务器移到10.15.0.0网段后，故障排除。 8. 故障排除过程文档化

当最终排除了网络故障后，那么排除流程的最后一步就是对所做的工作进行文字记录。文档化过程决不是一个可有可无的工作，原因如下：



文档是排错宝贵经验的总结，是 “经验判断和理论分析”这一过程中最重要的参考资料；



文档记录了这次排错中网络参数所做的修改，这也是下一次网络故障应收集的相关信息。

文档记录主要包括以下几个方面：

       

故障现象描述及收集的相关信息； 网络拓扑图绘制；

网络中使用的设备清单和介质清单； 网络中使用的协议清单和应用清单； 故障发生的可能原因；

对每一可能原因制定的方案和实施结果； 本次排错的心得体会；

其他：如排错中使用的参考资料列表等。

请读者对照上述案例完成文档记录工作。

1.2 路由器常用诊断工具介绍

华为Quidway 系列路由器提供了一套完整的命令集，可以用于监控网络互联环境的工作状况和解决基本的网络故障。主要包括以下命令：

 

ping命令； tracert命令；

8

网络故障诊断与排除 第1章 故障排除概述

  

display命令； reset 命令； debugging命令。

1.2.1 ping命令

1. 原理

“ping”这个词源于声纳定位操作，指来自声纳设备的脉冲信号。ping命令的思想与发出一个短促的雷达波，通过收集回波来判断目标很相似；即源站点向目的站点发出一个ICMP Echo Request报文，目的站点收到该报文后回一个ICMP Echo Reply报文，这样就验证了两个节点间IP层的可达性－－表示了网络层是连通的。 2. 功能

命令ping用于检查IP网络连接及主机是否可达。 3. VRP平台的ping命令

在Quidway系列路由器上， ping命令的格式如下：

ping [ ip ] [ -c count] [ -t timeout] [ -s packetsize] ip-address -c ping报文的个数，缺省值为5；

-t 设置ping报文的超时时间，单位为毫秒，缺省值为2000； -s 设置ping报文的大小，以字节为单位，缺省值为56。  说明：

实际上Quidway系列路由器ping命令的参数非常多，这里只介绍其中最重要的三个参数。其他参数介绍请参考《VRP用户手册－命令参考》‘系统管理’部分内容。

例如，向主机10.15.50.1发出2个8100字节的ping报文

Quidway# ping -c 2 -s 8100 10.15.50.1

PING 10.15.50.1: 8100 data bytes, press CTRL_C to break

Reply from 10.15.50.1: bytes=8100 Sequence=0 ttl=123 time = 538 ms Reply from 10.15.50.1: bytes=8100 Sequence=1 ttl=123 time = 730 ms

--- 10.15.50.1 ping statistics --- 2 packets transmitted

9

网络故障诊断与排除 第1章 故障排除概述

2 packets received 0.00% packet loss

round-trip min/avg/max = 538/634/730 ms

4. Windows平台的ping命令

在PC机上或Windwos NT为平台的服务器上，ping命令的格式如下： ping [ -n count ] [ -t ] [ -l size ] ip-address -n ping报文的个数；

-t 持续地ping 直到人为地中断，Ctr+Breack暂时中止ping命令并查看当前的统计结果，而Ctr+C则中断命令的执行。

-l 设置ping报文所携带的数据部分的字节数，设置范围从0至65500。 例：向主机10.15.50.1 发出2个数据部分大小为 3000 Bytes的ping报文

C:\\> ping -l 3000 -n 2 10.15.50.1

Pinging 10.15.50.1 with 3000 bytes of data

Reply from 10.15.50.1: bytes=3000 time=321ms TTL=123 Reply from 10.15.50.1: bytes=3000 time=297ms TTL=123 Ping 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, Average = 309ms

 说明：

实际上Windows平台的ping命令的参数非常多，这里只介绍其中最重要的三个参数。其他参数介绍请参考Windows在线帮助。 5. 巧用ping命令进行故障排除 案例一：连通性问题还是性能问题？

工程师小L，在配置完一台路由器之后执行ping命令检测链路是否通畅。发现5个报文都没有ping通，于是检查双方的配置命令并查看路由表，却一直没有找到错误所在。最后又重复执行了一遍相同的ping命令，发现这一次5个报文中有1个ping 通了－－原来是线路质量不好存在比较严重的丢包现象。

工程师小L又配置了一台路由器，然后执行ping命令访问Internet上某站点的IP地址，但没有ping通。有了上次的教训小L，再一次ping了20个报文，仍旧没有响应。于是小L断定是网络故障。但是在费尽周折检查了配置链路之后仍没有发现任何可疑之处，最后小L采取逐段检测的方法对链路中的网

10

网络故障诊断与排除 第1章 故障排除概述

关进行逐级测试，发现都可以ping 通，但是响应的时间越来越长，最后一个网关的响应时间在1800ms左右。会不会是由于超时而导致显示为ping 不通呢？受此启发，小L将ping 命令报文的超时时间改为4000ms，这次成功ping通了，显示所有的报文响应时间都在2200ms 左右。

真的是ping不通吗？这个问题需要定位清楚，因为连通性问题和性能问题排错的关注点是不一样的――问题定位错误必然会导致排错过程的周折。使用一般的ping命令，缺省是发送5个报文的，超时时长是2000ms。如果ping不通情况发生，最好能够再用带参数-c和-t的ping命令再执行一遍，如： ping -c 20 -t 4000 ip-address，即连续发送20个报文，每个报文的超时时长为4000ms，这样一般可以判断出到底是连通性问题还是性能问题。 案例二：使用大包ping对端进行MTU不一致的故障排除

某次开局，使用Quidway路由器与其他厂商的某路由器互连，并运行OSPF协议。数据配置完毕后，一切正常，并在今后相当长的时间内设备运转稳定。但两个月后，用户反馈网络中断。 相关信息显示：



登录到两台路由器上，发现双方连接正常，可以相互ping通对端地址。但OSPF协议中断；



登录Quidway路由器查看邻居状态，发现邻居状态机处于Exstart状态。打开相应的debug开关查看相应的报文信息，发现双方都可以收到Hello报文，但Quidway路由器发送DD报文后，一直没有收到对方回应的DD报文；



登录其他厂商的那台路由器，打开相应的debug开关，发现对方收到Quidway路由器发送的DD报文后，发送了相应的DD报文予以回应。

初步断定，Quidway路由器没有收到DD回应报文，但对方确实发出来了。 既然可以接收到HELLO 报文说明链路是通畅的，而且多播报文的收发也没有问题。那么有可能是对方发送的DD 报文有错误导致Quidway路由器拒收，但查看相应的信息，并没有报告接收到错误的DD 报文。

仔细查看某厂商路由器的调试信息发现这个DD报文很大有2000 多字节。会不会是由于报文太大导致的问题呢？试着ping了一个2000字节的报文，结果不通。那么故障原因很可能是－－由于双方的MTU不一致导致大包不通。 检查配置，发现对方路由器的MTU设置为4000多而Quidway路由器的MTU设置为1500，于是修改对端路由器的MTU为1500。故障排除。

11

网络故障诊断与排除 第1章 故障排除概述

那么为什么工程初期没有问题呢？这是因为前期DD报文长度小于1500字节，而后来网络扩容导致路由信息过多使DD 报文的长度超过了1500 字节。 由于ping 缺省报文是56 个字节，所以显示的ping 通信息只是表示56字节的报文可以通而并不一定表示其他大小的报文仍旧可以通。所以，应当善于使用ping的其他参数来进行故障排除。

案例三：A能ping通B，B就一定能ping通A吗？ 组网图如下：

e0:3.3.3.3/8s0:1.1.1.1/8s0:1.1.1.2/8e0:2.2.2.2/8RouterARouterB

图1-3 案例：A能ping通B，B就一定能ping通A吗？

在RouterA上配置一条指向2.0.0.0/8的静态路由：

[RouterA]ip route-static 2.0.0.0 255.0.0.0 1.1.1.2

在RouterA 上ping路由器RouterB 的以太网地址2.2.2.2，显示可以正常ping通；但是在RouterB上ping路由器RouterA的以太网地址3.3.3.3，却无法ping通。 原因分析：

由于在RouterB 上却没有相应的配置到3.0.0.0/8 路由，所以从RouterB 上ping不通RouterA的以太网口3.3.3.3 。

但是为何在A上可以ping 通2.2.2.2 呢？同样是没有回程路由呀？打开路由器上的IP报文调试开关发现，原来从RouterA上发出的ICMP Request报文的源地址填写的是1.1.1.1而不是3.3.3.3，由于两台路由器的s0口处于同一网段，所以Request报文可以顺利到达RouterB，而RouterB同样可以发现到1.1.1.1的直连路由，这样RouterB发出的Echo Reply报文就可以顺利到达RouterA。

A能够ping通B则B一定能够ping通A（不考虑防火墙的因素）,这句话的对错取决于A和B到底是指主机还是指路由器。

 

如果是指两台主机，那么这句话就是正确的。

如果是指两台路由器那就是错误的，因为路由器通常会有多个IP地址。现在就有如下问题：当从一台路由器上执行ping命令它发出的ICMP Echo报文的源地址究竟选择哪一个呢？实际情况是路由器选择发出报文的接口的IP地址。

12

网络故障诊断与排除 第1章 故障排除概述

1.2.2 tracert 命令

1. 原理

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

tracert 命令用于测试数据报文从发送主机到目的地所经过的网关，主要用于检查网络连接是否可达，以及分析网络什么地方发生了故障。 3. VRP平台的tracert命令

在华为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。 例如：查看到目的主机10.15.50.1 中间所经过的网关。

[Quidway] tracert 10.15.50.1

traceroute to 10.15.50.1(10.15.50.1) 30 hops max,40 bytes packet 1 10.110.40.1 1 4 ms 5 ms 5 ms 2 10.110.0. 10 ms 5 ms 5 ms 3 10.110.7.2 10 ms 5 ms 5 ms 4 10.3.0.177 175 ms 160 ms 145 ms 5 129.9.181.2 185 ms 210 ms 260 ms 6 10.15.50.1 230 ms 185 ms 220 ms

13

网络故障诊断与排除 第1章 故障排除概述

4. Windows平台的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:\\>tracert -h 2 10.15.50.1

Tracing route to 10.15.50.1 over a maximum of 2 hops: 1 3 ms 2 ms 2 ms 10.110.40.1 2 5 ms 3 ms 2 ms 10.110.0. Trace complete.

5. 使用tracert命令进行故障排除

案例一：使用tracert命令定位不当的网络配置点 组网情况如下图所示：

图1-4 使用tracert命令定位不当的网络配置点

某校园网中，RouterB和RouterC同属于一个运行RIPv2路由协议的网络，主机4.0.0.2访问数据库服务器5.0.0.2，用户抱怨访问性能差。

登录到RouterC，使用带参数的ping命令，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

14

网络故障诊断与排除 第1章 故障排除概述

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

原因分析：

上面的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 ms

从上面的显示可看到，直至3.0.0.2，UDP探测报文的返回时长都基本一致，而到5.0.0.1时，则发生明显变化，呈现奇数报文时长短，偶数报文时长长的现象。于是判断，问题发生在RouterB和RouterA之间。

通过询问该段网络的管理员，得知这两路由器间有一主一备两串行链路，主链路为2.048Mbps（s0口之间），备份链路为128Kbps（s1口之间）。网络管理员在此两路由器间配置了静态路由。 RouterB上如下配置：

[RouterB]ip route-static 5.0.0.0 255.0.0.0 1.0.0.2 [RouterB]ip route-static 5.0.0.0 255.0.0.0 2.0.0.2

RouterA上如下配置：

[RouterA]ip route-static 0.0.0.0 0.0.0.0 1.0.0.1 [RouterA]ip route-static 0.0.0.0 0.0.0.0 2.0.0.1

于是问题就清楚了。例如RouterB，由于管理员配置时没有给出静态路由的优先级，这两条路由项的优先级就同为缺省值60，于是就同时出现在路由表中，实现的是负载分担，而不能达到主备的目的。 可以有两种处理方法：



继续使用静态路由，进行配置更改

RouterB上进行如下更改：

[RouterB]ip route 5.0.0.0 255.0.0.0 1.0.0.2 （主链路仍使用缺省优先级60）

15

网络故障诊断与排除 第1章 故障排除概述

[RouterB]ip route 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.1 [RouterA]ip route-static 0.0.0.0 0.0.0.0 2.0.0.1 100

这样，只有当主链路发生故障，备份链路的路由项才会出线在路由表中，从而接替主链路完成报文转发，实现主备目的。



在两路由器上运行动态路由协议，如OSPF等，但不要运行RIP协议（因为RIP协议仅以hop作为Metric的）

本案例的目的不是为了解释网络配置问题，而是用来展示ping命令和tracert命令的相互配合来找到网络问题的发生点。尤其在一个大的组网环境中，维护人员可能无法沿着路径逐机排除，此时，能够迅速定位出发生问题的线路或路由器就非常重要了。

案例二：使用tracert命令发现路由环路 组网情况如下图所示：

e1：4.0.0.1/8e0：3.0.0.2/8e0：3.0.0.1/8RTBs0：1.0.0.1/8s0：1.0.0.2/8RTAe0：5.0.0.1/8RTC4.0.0.2/8

三台路由器均配置静态路由，完成后，登录到RTA上ping主机4.0.0.2，发现不通。 相关信息如下：

[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 out [RouterA]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）

16

网络故障诊断与排除 第1章 故障排除概述

。。。。。。

从上面的tracert命令的显示可以立即发现，在RouterA和RouterB间产生了路由环路。由于配置的是静态路由，基本可以断定是RouterA或RouterB的静态路由配置错误。

检查RouterA的路由表，配置的是缺省静态路由：ip route 0.0.0.0 0.0.0.0 1.0.0.1，没有问题。

检查RouterB的路由表，配置到4.0.0.0网络的静态路由为：ip route 4.0.0.0 255.0.0.0 1.0.0.2――下一跳配置的是1.0.0.2，而不是3.0.0.1。这正是错误所在。 处理方法：

修改RouterB的配置如下：

[RouterB] undo ip route-static 4.0.0.0 255.0.0.0 1.0.0.2 [RouterB] ip route-static 4.0.0.0 255.0.0.0 3.0.0.1

故障排除。

tracert命令能够很容易发现路由环路等潜在问题。当路由器A认为路由器B知道到达目的地的路径，而路由器B也认为路由器A知道目的地时，就是路由环路发生了。使用ping命令只能知道接收端出现超时错误，而tracert能够立即发现环路所在――如果tracert命令两次或者多次显示同样的接口。 当通过tracert发现路由环路后，如果配置为：

  

静态路由：几乎可以肯定是手工配置有问题，如本案例所示。 OSPF协议：可能是地址聚合产生的问题。 多路由协议：可能是路由引入产生的问题。

1.2.3 display命令

display命令是用于了解路由器的当前状况、检测相邻路由器、从总体上监控网络、隔离因特网络中故障的最重要的工具之一。几乎在任何故障排除和监控场合，display命令都是必不可少的。

例如：基于VRP1.74路由平台的display命令选项如下所示：

[Quidway]display ?

aaa AAA information

acl Display access-list information arp ARP table

base-information Some basal system information bgp BGP protocol information

17

网络故障诊断与排除 第1章 故障排除概述

bridge Remote bridge information client Current client information clock System clock information

configfile Memory information in which config.ini is stored controller An E1/T1/E3/T3 entry information

current-configuration Operating current configuration information debugging Debugging state information

dhcp Display DHCP server database items dialer Display dialer parameters and statistics dlsw Information about DLSW(Data Link Switch) duration Running time information fcm Fcm counter information

fe1 Display E1-F congiguration information firewall Display Firewall status information fr Display frame relay information

ft1 Display T1-F congiguration information ftp-server Ftp server information history-command History command information igmp IGMP information

ike Display IKE specific information

info-center interfaces ip IP information

iphc IPHC compression information ipsec IPSec information ipx Novell IPX information isdn ISDN information

isintr Whether current time is in the time range l2tp L2TP information level User level information

local-user Display login or logout users information MFR Display Multilink Frame Relay information multicast Multicast information nat NAT status

ospf OSPF protocol Information pim PIM information pos-app POSAPP information pos-interface POSINT information ppp PPP informattion

pppoe-client printer LPD printer information

processes Current Process statistics information

Display info-center configuration information Interface status and configuration information PPP over Ethernet(client) status and configuration 18

网络故障诊断与排除 第1章 故障排除概述

qos Display QOS information reboot Reboot information rip RIP on/off state rmon Rmon information

route-policy Configured route-policy information saved-configuration Contents of saved configuration information sysname system name information

tcp TCP connections status information timerange Display time range status information tty Current tty information

tty-app Current Terminal Access application information ttymanage Current Terminal Access manange channel information version System hardware and software status information vlan VLAN ID in use, interface and subinterface number voice Display voice information vrrp Current vrrp information

x25 Display the information concerning X.25

 说明：

上述清单列出了display命令可以使用的全部一级关键字，其中大部分关键字后还可以跟更多的关键字，以使用户能够清晰的了解到特定的信息。 在故障排除中最有用的是那些用粗体字显示的关键字，用户应该记住它们并熟悉它们的输出信息。

这里介绍最常用的、全局性的display命令，与各协议相关的display命令，在后面章节相应的协议故障排除中有详细介绍。 1. display version 命令

display version 命令是最基本的命令之一，它用于显示路由器硬件和软件的基本信息。因为不同的版本有不同的特征，实现的功能也不完全相同，所以，查看硬件和软件的信息是解决问题的重要一步。在进行故障排除时，我们通常从这个命令开始收集数据。该命令将帮助用户收集下列信息：

     

VRP软件版本 是哪一系列的路由器 处理器的信息 RAM的容量 配置寄存器的设置 硬件的版本

19

网络故障诊断与排除 第1章 故障排除概述



引导程序的版本

输出示例如下，请找到上述提及的相应项。

[Router1760]display version Copyright Notice:

All rights reserved (Apr 15 2003).

Without the owner's prior written consent, no decompiling or reverse-engineering shall be allowed. Huawei Versatile Routing Platform Software VRP (R) software, Version 1.74 Release 0007 Copyright (c) 1997-2003 HUAWEI TECH CO., LTD.

Quidway R1760 uptime is 0 days 5 hours 10 minutes 35 seconds System returned to ROM by power-on.

Quidway R1760 with 1 MPC 8241 Processor Router serial number is 00E0FC0F278552A8 M bytes SDRAM

8192K bytes Flash Memory 0K bytes NVRAM

Config Register points to FLASH

Hardware Version is MTR 1.0 CPLD Version is CPLD 1.0 Bootrom Version is 4.69

[LAN ] 1FE Hardware Version is 2.0, Driver Version is 2.0 [AUX ] AUX Hardware Version is 1.0, Driver Version is 1.0, Cpld Version is 1.0

[WAN ] WAN Hardware Version is 1.0, Driver Version is 1.0, Cpld Version is 1.0

2. display current-configuration和display saved-configuration命令 display current-configuration用于查看当前的配置信息。

display saved-configuration用于显示NVRAM或Flash中的路由器配置文件，即路由器下次上电启动时所用的配置文件。

注意：

Current-configuration是路由器目前正在运行的配置文件，当更改某一配置时，current-configuration会立即改变；如果不使用save命令将改变后的配置信息保存到启动配置文件saved-configuration中，路由器重启时该改动将

20

网络故障诊断与排除 第1章 故障排除概述

丢失。因此请注意，修改运行配置并验证正确后，应当保存到启动配置文件中。

配置文件为一文本文件，其格式如下：

 

以命令格式保存；

为节约空间，只保存非缺省的常数命令；组织以命令模式为基本框架，同一命令模式的命令组织在一起，形式一节，节与节间以注释行隔开（以“！”开始的语句为注释行）；

 

节的顺序安排：系统视图、接口视图、协议视图等； 以return 为结束。

示例如下：

[Router1760]display current-configuration Now create configuration... Current configuration !

version 1.74

info-center console firewall enable sysname Router1760 encrypt-card fast-switch !

interface Aux0 async mode flow link-protocol ppp !

interface Ethernet0

ip address 10.110.32.222 255.255.248.0 !

interface Serial0 link-protocol ppp

ip address 1.1.1.1 255.0.0.0 ! quit

ip route-static 2.0.0.0 255.0.0.0 1.1.1.2 preference 60 ! return

强烈建议网络维护或管理人员保存一份启动配置文件的拷贝存放到路由器以外的其他设备上。这有几点好处：

21

网络故障诊断与排除 第1章 故障排除概述

 

这将使维护人员能够迅速配置一个替代的路由器；

这个保存在外部的文本文件，也可以按上述规定的格式脱机编辑，然后使用命令加载到路由器上；



可以将配置文件发给其他技术支持人员以帮助定位配置问题。

3. Display interface命令

Display interface命令可以显示所有接口的当前状态，如果只是想查看特定接口的状态，请在该命令后输入接口类型和接口号，例如：display interface serial 0命令将查看串口0的运行状态和相关信息。  说明：

关于各接口的display interface命令的详细解释请见第二章《物理层及以太网故障排除》的内容。

另外，VRP1.7等版本还有一条命令display interface brief，它是display interfaces命令的简化，显示所有接口物理状态和协议状态的简单信息。 示例如下：

[Quidway]display interfaces brief

Ethernet0 is down, line protocol is down

Internet address is 1.1.1.1 255.255.255.0 1.1.1.255 Ethernet1 is down, line protocol is down Hardware address is 00-e0-fc-00-01-03

Auto-Negotiation is enabled, Duplex AUTO, Speed AUTO Serial0 is down, line protocol is down Internet address is 2.1.1.1 255.255.255.0 Encapsulation X.25

Serial1 is down, line protocol is down Encapsulation PPP

1.2.4 reset命令

在介绍完毕display命令的基本使用后，必须提及一下reset命令的作用――用于清空当前的统计信息以排除以前积累的数据的干扰。

reset命令中最主要的是reset counters interface 和 reset ip counters命令。对于二层帧收发的各计数器的刷新必须使用reset counters interface，可通过display interface命令来观察；对于三层报文的收发统计可使用reset ip counters来刷新，通过display ip interface命令来观察。

22

网络故障诊断与排除 第1章 故障排除概述

reset命令适用场合如下：许多情况下，我们需要使用带参数的ping命令来测试链路的通断，同时在一段时间内ping后，通过display interface或display ip interface命令来查看端口报文的收发及CRC校验等情况的正确与否，从而分析报文的收发在什么地方出现了问题。但display命令的显示值是自从路由器运行以来（或上次reset后）的所有统计值，这个值是无法分析的。因此，实际我们需要进行的步骤为：首先使用reset命令清空统计值，然后使用一系列ping命令使路由器端口收发报文，最后使用display命令来查看统计值。 例如：通过display interface e0 观察到端口e0有如下统计数据：

10 input errors,5 CRC,1 frame errors

0 overrunners,0 aborted sequences, 0 input no buffers

我们发现端口收发有了错误，但这些错误是否是最近产生的呢？可用reset counters interface e0来进行刷新，再通过ping一组报文测试路由器端口的收发，最后再使用display interface e0看结果统计。如果仍然显示发生错误，那么我们就需要分析原因进行故障排除了。

1.2.5 debugging命令

1. debugging命令概述

Quidway系列路由器提供大量的debugging命令，可以帮助用户在网络发生故障时获得路由器中交换的报文和帧的细节信息，这些信息对网络故障的定位是至关重要的。

在VRP中，debugging信息及其他提示信息的输出是由信息中心（info-center）来统一管理的。因此，用户要查看调试信息，需要进行如下三步骤：



开启info-center功能： 设定调试信息的输出方向

[Quidway]info-center enable



调试信息有四个输出方向：控制台（Console）、Telnet终端或哑终端（Monitor）、内部缓冲区（Buffered）、主机（Loghost） 例如：将调试信息输出到控制台，命令为：

[Quidway] info-center console debugging

其他三个方向的输出分别为：

[Quidway] info-center monitor debugging [Quidway] info-center logbuffer debugging [Quidway] info-center loghost 0 10.110.200.200

23

网络故障诊断与排除 第1章 故障排除概述

 说明：

info-center 各个输出方向对系统资源的占用从大到小依次为： Console>monitor> Loghost > Buffer



打开相应的调试开关

例如：打开IP packet调试开关，命令为：

[Quidway] debugging ip packet

2. debugging命令使用注意事项

由于调试信息的输出在CPU处理中赋予了很高的优先级，许多形式的debugging命令会占用大量的CPU运行时间，在负荷高的路由器上运行debug命令可能引起严重的网络故障（如网络性能迅速下降）。但debugging命令的输出信息对于定位网络故障又是如此的重要，是维护人员必须使用的工具。因此，我们总结了一些使用debugging命令的注意要点，如下： A. 应当使用debugging命令来查找故障，而不是用来监控正常的网络运行。 B. 尽量在网络使用的低峰期或网络用户较少时使用，以降低debugging命

令对系统的影响性。

C. 在没有完全掌握某debugging命令的工作过程以及它所提供的信息前，

不要轻易使用该debugging命令。

D. 由于debugging命令在各个输出方向对系统资源的占用情况不同。视网

络负荷状况，我们应当在使用方便性（info-center console debugging命令）和资源耗费小（info-center logbuffer debugging命令）间做出权衡。 E. 仅当寻找某些类型的流量或故障并且已将故障原因缩小到一个可能的范

围时，才使用某些特定的debugging命令。

例如：我们要查看帧中继报文的调试信息时，最好使用带接口参数的debug命令“debugging fr packet interface s0”（这将打开串口0的帧中继报文调试开关），而不使用“debugging fr packet”（这将打开所有串口的帧中继报文调试开关）。这样一方面可以减少debugging 命令对路由器性能的影响，另一方面减少了许多无用信息的输出，有利于更加迅速定位故障。

在使用debugging命令获得足够多的信息后，应立即以“undo debugging xx”命令终止debugging命令的执行。

可以使用display debugging命令查看当前已打开哪些调试开关，使用相应命令关闭；使用undo debug all命令关闭可以所有调试开关。

24

网络故障诊断与排除 第1章 故障排除概述

3. display命令和debugging命令的配合使用

display命令能够提供某个时间的设备运行状况的视图（静态），而debugging命令能够展示一段时间内设备运行的变化情况（动态）。因此，要在故障排除时了解系统运行的总体情况，必须同时使用这两个命令。例如：当进行OSPF协议的故障排除时，需要使用display ip routing-table命令来了解路由器当前已经知道了哪些路由表项，需要使用debugging ospf event命令来了解路由表是如何更新的。如果不知道路由表的当前内容，路由更新的信息对故障排除是不够的。 debugging 命令并不能直接告诉你设备已知道的信息，而display命令则不能告诉路由表的变化情况，两者的配合使用，才能全面了解正在发生的事情。

一般说来，display命令不会影响系统的运行性能，而debugging 命令则会对系统性能造成影响。因此两者的使用应遵循如下规则：首先使用相关的多个display命令查看设备当前的运行状况，分析可能原因，缩减故障到适当范围，然后打开某个特定的debugging命令观察变化情况，以定位和排除问题。

1.3 故障排除常用方法

1.3.1 分层故障排除法

1. 层次化的故障排除思想

过去的十几年，因特网络领域的变化是惊人的，但有一件事情没有变化：论述因特网络技术的方法都与OSI模型有关，即使新的技术与OSI模型不一定精确对应，但所有的技术都仍然是分层的。因此，我们重要的是要培养一种层次化的网络故障分析方法。

分层法思想很简单：所有模型都遵循相同的基本前提－－当模型的所有低层结构工作正常时，它的高层结构才能正常工作。在确信所有低层结构都正常运行之前，解决高层结构问题完全是浪费时间。

例如：在一个帧中继网络中，由于物理层的不稳定，帧中继连接总是出现反复失去连接的问题，这个问题的直接表象是到达远程端点的路由总是出现间歇性中断。这使得维护工程师第一反应是路由协议出问题了，然后凭借着这个感觉来对路由协议进行大量故障诊断和配置，其结果是可想而知的。如果他能够从OSI模型的底层逐步向上来探究原因的话，维护工程师将不会做出这个错误的假设，并能够迅速定位和排除问题。

25

网络故障诊断与排除 第1章 故障排除概述

2. 各层次的关注点

物理层负责通过某种介质提供到另一设备的物理连接，包括端点间的二进制流的发送与接收，完成与数据链路层的交互操作等功能。

物理层需要关注的是：电缆、连接头、信号电平、编码、时钟和组帧，这些都是导致端口处于down状态的因素。

数据链路层负责在网络层与物理层之间进行信息传输；规定了介质如何接入和共享；站点如何进行标识；如何根据物理层接收的二进制数据建立帧。 封装的不一致是导致数据链路层故障的最常见原因。当使用display interface命令显示端口和协议均为up时，我们基本可以认为数据链路层工作正常；而如果端口up而协议为down，那么数据链路层存在故障。

链路的利用率也和数据链路层有关，端口和协议是好的，但链路带宽有可能被过度使用，从而引起间歇性的连接失败或网络性能下降。

网络层负责实现数据的分段打包与重组以及差错报告，更重要的是它负责信息通过网络的最佳路径的选择。

地址错误和子网掩码错误是引起网络层故障最常见的原因；因特网络中的地址重复是网络故障的另一个可能原因；另外，路由协议是网络层的一部分，也是排错重点关注的内容。

排除网络层故障的基本方法是：沿着从源到目的地的路径查看路由器上的路由表，同时检查那些路由器接口的IP地址。通常，如果路由没有在路由表中出现，就应该通过检查来弄清是否已经输入了适当的静态、默认或动态路由，然后，手工配置丢失的路由或排除动态路由协议选择过程的故障以使路由表更新。

1.3.2 分块故障排除法

display current-configuration命令的介绍中提及了Quidway系列路由器和交换机等网络设备的配置文件的组织结构，它是以系统视图、接口视图、协议视图、路由策略视图等方式编排的。其实我们还能够以另一种角度看待这个配置文件，该配置分为以下几块：

    

管理部分（路由器名称、口令、服务、日志等） 端口部分（地址、封装、cost、认证等）

路由协议部分（静态路由、RIP、OSPF、BGP、路由引入等） 策略部分（路由策略、策略路由、安全配置等） 接入部分（主控制台、Telnet登录或哑终端、拨号等）

26

网络故障诊断与排除 第1章 故障排除概述



其他应用部分（语言配置、VPN配置、Qos配置等）

上述分类给故障定位提供了一个原始框架，当出现一个故障案例现象时，我们可以把它归入上述某一类或某几类中，从而有助于缩减故障定位范围。 例如：当使用“display ip routing-table ”命令，结果只显示出了直连路由，那么问题可能发生在哪里呢？看上述的分块，我们发现有三部分可能引起该故障：路由协议、策略、端口。如果没有配置路由协议或配置不当，路由表就可能为空；如果访问列表配置错误，就可能妨碍路由的更新；如果端口的地址、掩码或认证配置错误，也可能导致路由表错误。

1.3.3 分段故障排除法

如果两个路由器跨越电信部门提供的线路而不能相互通信时，分段故障排除法是有效的。如：

     

主机到路由器LAN接口的这一段 路由器到CSU/DSU接口的这一段 CSU/DSU到电信部门接口的这一段 WAN电路

CSU/DSU本身问题 路由器本身问题

1.3.4 替换法

这是我们检查硬件是否存在问题最常用的方法。例如，当怀疑是网线问题时，更换一根确定是好的网线试一试；当怀疑是接口模块有问题时，更换一个其他接口模块试一试。

1.4 故障排除对网络维护和管理人员的要求

1.4.1 对协议要求有精深的理解

案例：RIPv1和OSPF相互路由引入的问题

在一个地址空间为10.0.0.0 的网络中配置了OSPF域，其中该网络的某些子网的掩码是24位，另一些是26位；同时在该网络中还配置了一个24位子网掩码的RIP域，并在OSPF域和RIP域间相互进行路由引入。结果发现，RIP域中的路由器不能ping通OSPF域中的某些接口。

27

网络故障诊断与排除 第1章 故障排除概述

为什么会出现这样的结果？我们知道，RIP1不支持VLSM，因此RIP域中的子网必须使用相同长度的子网掩码且它们必须是相邻的；OSPF支持可变长度子网掩码并且不要求子网相邻。因此，在相互进行路由引入时，OSPF能够识别所有RIP路由，而RIP不能够识别所有OSPF路由，这样就出现了上述的故障现象。

了解了RIP和OSPF协议的原理和特性后，也就找到了两种解决办法：在OSPF域内进行路由汇总或RIP域中采用RIP2协议。

设想一下，如果网络维护和管理人员对OSPF和RIP协议不是非常了解，不知道RIP和OSPF所适用的子网化规则和相互路由再引入的规则，遇到上面的故障现象就只会一片茫然了，就更不用提找到切实可行的解决方案了。

1.4.2 能够引导客户详细描述出故障现象和相关信息

在多数情况下，网络维护和管理人员会听到客户的求助，他说出了一个常见问题，但又没有该问题产生原因的任何信息。例如，客户说：“我的机器不能够访问FTP服务器了”。此时，网络维护和管理人员就必须以系统的、渐近的、有序的一系列问题引导客户，以得到所有的相关信息。

网络维护和管理人员定位网络问题的过程，实质上是一个不断提出问题的过程（问客户或问自己），提问通常应当以这样一个顺序进行：谁出了问题？是什么问题？何时产生的？何处出现的？并且这些问题是可以循环提出的，当你提出一个问题的时候，必须能够根据用户对该问题的回答继续提问，直到对整个问题有了一个准确的了解并满意为止。 1. 谁出了问题？

是单个用户、一组存在共性的用户还是网络中的所有用户？ 对于单个用户的问题，你将来的提问可能应关注下列方面：

    

物理层问题，包括连接该用户的网络电缆问题； 该特定主机上的硬件问题；

该特定主机的软件问题，尤其是网络协议方面的问题； 该特定主机的IP地址或子网掩码问题； 默认网关问题。

对于一组用户问题或所有用户问题，你将来的提问可能应关注下列方面：

  

网络设备问题，比如Hub或交换机； 路由器接口问题； 服务器问题；

28

网络故障诊断与排除 第1章 故障排除概述

 

访问列表设置问题； VLAN配置问题；

2. 是什么问题

是连通性问题，还是性能差的问题？如果是连通性问题，是完全连通性问题，还是部分连通性问题？

对于完全连通性问题，你将来的提问可能应关注以下方面：

  

硬件故障 远程通信服务故障 路由协议故障

对于部分连通性问题，你将来的提问可能应关注以下方面：

  

访问列表问题 子网掩码问题 路由协议不兼容问题

对于性能问题，你将来的提问可能应关注下列方面：

   

网络拥塞 路由环路 供电不足 非最佳路由

3. 问题何时发生的？

是间歇性问题，还是经常发生的问题，或者是刚刚发生的问题？ 对于间歇性问题，你将来的提问可能应关注下列方面：

   

网络拥塞或广播风暴 路由环路 远程通信服务故障 网络介质质量差

对于刚刚才发生的问题，你将来的提问可能应关注下列方面：

   

新的硬件故障或介质故障 新增设备或拓扑改变 访问列表重新配置 路由协议发生变化

29

网络故障诊断与排除 第1章 故障排除概述

4. 何处发生的故障？

故障发生在核心区域、边缘区域还是接入区域？ 对于核心区域的故障，你的提问可能应关注下列方面：

 

路由协议变更 重新进行路由引入

对于边缘区域的故障，通常是与访问列表有关。对于接入区域的问题，那么就可能和上述所有问题都有关系了。

1.4.3 充分了解自己所管理和维护的网络

复杂问题的排错不仅在于技术人员的专业技能（如各种协议知识的精通、各种配置命令和诊断工具的熟悉等），更重要的在于他对所要排错网络的熟悉程度――只有充分了解自己的网络，才能够迅速、有效地与网络管理所涉及的关键人员以及受故障影响的人员进行沟通；只有充分了解自己的网络，才能够对网络的变动做出明智的决策，才能够尽快、尽可能简单地排除故障。 为确定是否已充分了解了自己的网络，请尝试回答下列问题：



你是否清楚所管理和维护的网络物理布局，即网络设备的位置与它们之间的连接关系；



你是否清楚网络各段二层使用了哪些技术，以太网、专线、帧中继、X.25、ISDN还是其它；对于每一技术，是否清楚它们的相关配置；



你是否清楚网络所运行的全部网络协议清单，TCP/IP、IPX或是其他；对于每一协议，是否清楚相关的网络地址、子网地址、区域以及其他信息；



你是否清楚网络中运行了哪些路由协议？对于每一路由协议，是否记录了路由器的配置信息？



你是否清楚网络上层主要跑的是什么业务；是否清楚网络中是否运用了访问列表、防火墙、IPSec、Qos等机制；



你是否清楚网络与外部网络（如Internet）的所有连接点，每一连接点使用的路由协议是什么？



你是否清楚最近十天对网络做了哪些变动，如，增加了哪些新设备或软件、重新进行了哪些配置？



你有没有定期制定自己网络的基线？

30

网络故障诊断与排除 第1章 故障排除概述

如果对上述问题做出了肯定的回答，那么你就能够更快、更容易的进行故障排除了。如果不能做出肯定的回答，那么请你赶紧行动，将上述所有的信息查询清楚并详细记录。

1.4.4 及时进行故障排除的文档记录和经验总结

网络管理和维护人员必须养成及时进行故障排除的文档记录和经验总结的习惯。在发现异常情况时，应有序的记录VRP软件版本、模块化插卡的版本、display current-configuration显示等信息，一方面是网络维护工作的基本要求，一方面也是提高自身排错技能的需要。

31