第1章故障排除概述Word文档下载推荐.docx

资源描述

第1章故障排除概述Word文档下载推荐.docx

《第1章故障排除概述Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《第1章故障排除概述Word文档下载推荐.docx（30页珍藏版）》请在冰豆网上搜索。

第1章故障排除概述Word文档下载推荐.docx

MPLS技术的出现；

提供QoS能力等。

●新技术的应用同时还要兼顾传统的技术。

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

因此，现代的因特网络是协议、技术、介质和拓扑的混合体。

因特网络环境越复杂，意味着网络的连通性和性能故障发生的可能性越大，而且引发故障的原因也越发难以确定。

同时，由于人们越来越多的依赖网络处理日常的工作和事务，一旦网络故障不能及时修复，所造成的损失可能很大甚至是灾难性的。

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

本书着眼于帮助网络维护人员和管理人员,将他们所掌握的知识有条理的应用于诊断和排除网络故障的过程中；

帮助他们针对各种网络环境中的常见故障现象进行定位和解决。

1.1.2网络故障的一般分类

网络故障一般分为两大类：

连通性问题和性能问题。

它们各自故障排除的关注点如下：

1.连通性问题

●硬件、媒介、电源故障；

●配置错误；

●设备兼容性问题。

2.性能问题

●网络拥塞；

●到目的地不是最佳路由；

●供电不足；

●路由环路；

●网络不稳定。

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

前面我们基本了解了计算机网络故障的大致种类，那么，如何排除网络故障呢？

我们建议采用系统化故障排除思想。

故障排除系统化是合理地、一步一步找出故障原因，并解决故障的总体原则。

它的基本思想是系统的，将可能的故障原因所构成的一个大集合缩减（或隔离）成几个小的子集，从而使问题的复杂度迅速下降。

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

图1-1网络故障排除基本步骤

说明：

该流程是网络维护人员所能够采用的排错模型中的一种，如果你根据自己的经验和实践总结了另外的排错模型，并证明它是行之有效的，请继续使用它；

网络故障解决的处理流程是可以变化的，但故障排除有序化的思维模式是不可变化的。

下面我们以一个故障排除的实例来学习如何应用这些步骤。

案例：

FTP业务传输速度慢

该案例组网如下：

某校园网的三个局域网，其中10.11.56.0为一个用户网段，10.11.56.118为一个日志服务器；

10.15.0.0是一个集中了很多应用服务器的网段。

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

1.故障现象描述

要想对网络故障做出准确的分析，首先应该了解故障表现出来的各种现象，然后才能确定可能产生这些现象的故障根源或症结。

因此，对网络故障做出完整、清晰的描述是重要的一步。

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

因为这个描述没有讲述清楚下列问题：

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

●是完全不能备份，还是备份的速度慢（即性能下降）？

●哪个或哪些局域网服务器受到影响，地址是什么？

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

在网络的高峰期，日志服务器10.11.56.118到集中备份服务器10.15.254.153之间进行备份时，FTP传输速度很慢，大约是0.6Mbps。

2.故障案例相关信息收集

本步骤是搜集有助于查找故障原因的更详细的信息。

主要是三种途径：

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

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

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

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

网络基线的评估应当是管理员一个周期性的任务。

建立基线作用在于当网络性能下降时，它可以为确定故障的严重程度提供参照；

如果在网络故障后才试图建立基线，则为时已晚。

制定网络基线有很多方法。

可以使用专门的网络管理工具，如华为公司的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的性能问题；

●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的路由不是最佳路由。

测试方案：

在10.11.56.0网段的网关上使用“tracert10.15.254.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.254.153）间FTP传输速度是7Mbps（正常）。

排除了网关因素，因为B、C在不同网段上而速度正常。

可能原因4：

10.11.56.0网络本身的性能问题。

在网段10.11.56.0的以太网交换机上使用命令“displaymac-address”，输出如下：

PortRcv-UnicastRcv-MulticastRcv-Broadcast

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

6/321031781208665

PortXmit-UnicastXmit-MulticastXmit-Broadcast

6/3266679872866522474038

广播：

单播=1：

3，比例太大

PortRcv-OctetXmit-Octet

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

6/32140948293581516443041

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

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

6/36557802870285

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

6/3627879749190257119430

（广播：

单播比例＝1：

270，属于正常。

）

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

6/36671725870814998816809

由此知道，网段10.11.56.0上广播包和单播包比例为1:

3，确实太大了。

再次询问用户该网段主要运行的业务是什么，从而得出了故障最终原因如下：

10.11.56.0是普通用户网段，由于业务原因每个用户需要发送大量广播包和多播包，随着近期越来越多的用户接入该网络，在这个网段上的服务器需要花费更多的资源来处理越来越多的广播和多播包，因此其服务的传输速度自然减慢。

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

8.故障排除过程文档化

当最终排除了网络故障后，那么排除流程的最后一步就是对所做的工作进行文字记录。

文档化过程决不是一个可有可无的工作，原因如下：

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

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

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

●故障现象描述及收集的相关信息；

●网络拓扑图绘制；

●网络中使用的设备清单和介质清单；

●网络中使用的协议清单和应用清单；

●故障发生的可能原因；

●对每一可能原因制定的方案和实施结果；

●本次排错的心得体会；

●其他：

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

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

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

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

主要包括以下命令：

●ping命令；

●tracert命令；

●display命令；

●reset命令；

●debugging命令。

1.2.1ping命令

1.原理

“ping”这个词源于声纳定位操作，指来自声纳设备的脉冲信号。

ping命令的思想与发出一个短促的雷达波，通过收集回波来判断目标很相似；

即源站点向目的站点发出一个ICMPEchoRequest报文，目的站点收到该报文后回一个ICMPEchoReply报文，这样就验证了两个节点间IP层的可达性－－表示了网络层是连通的。

2.功能

命令ping用于检查IP网络连接及主机是否可达。

3.VRP平台的ping命令

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

ping[ip][-ccount][-ttimeout][-spacketsize]ip-address

-cping报文的个数，缺省值为5；

-t设置ping报文的超时时间，单位为毫秒，缺省值为2000；

-s设置ping报文的大小，以字节为单位，缺省值为56。

实际上Quidway系列路由器ping命令的参数非常多，这里只介绍其中最重要的三个参数。

其他参数介绍请参考《VRP用户手册－命令参考》‘系统管理’部分内容。

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

Quidway#ping-c2-s810010.15.50.1

PING10.15.50.1:

8100databytes,pressCTRL_Ctobreak

Replyfrom10.15.50.1:

bytes=8100Sequence=0ttl=123time=538ms

bytes=8100Sequence=1ttl=123time=730ms

---10.15.50.1pingstatistics---

2packetstransmitted

2packetsreceived

0.00%packetloss

round-tripmin/avg/max=538/634/730ms

4.Windows平台的ping命令

在PC机上或WindwosNT为平台的服务器上，ping命令的格式如下：

ping[-ncount][-t][-lsize]ip-address

-nping报文的个数；

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

-l设置ping报文所携带的数据部分的字节数，设置范围从0至65500。

例：

向主机10.15.50.1发出2个数据部分大小为3000Bytes的ping报文

ping-l3000-n210.15.50.1

Pinging10.15.50.1with3000bytesofdata

Replyfrom10.15.50.1:

bytes=3000time=321msTTL=123

bytes=3000time=297msTTL=123

Pingstatisticsfor10.15.50.1:

Packets:

Sent=2,Received=2,Lost=0（0%loss）,

Approximateroundtriptimesinmilli-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采取逐段检测的方法对链路中的网关进行逐级测试，发现都可以ping通，但是响应的时间越来越长，最后一个网关的响应时间在1800ms左右。

会不会是由于超时而导致显示为ping不通呢？

受此启发，小L将ping命令报文的超时时间改为4000ms，这次成功ping通了，显示所有的报文响应时间都在2200ms左右。

真的是ping不通吗？

这个问题需要定位清楚，因为连通性问题和性能问题排错的关注点是不一样的――问题定位错误必然会导致排错过程的周折。

使用一般的ping命令，缺省是发送5个报文的，超时时长是2000ms。

如果ping不通情况发生，最好能够再用带参数-c和-t的ping命令再执行一遍，如：

ping-c20-t4000ip-address，即连续发送20个报文，每个报文的超时时长为4000ms，这样一般可以判断出到底是连通性问题还是性能问题。

案例二：

使用大包ping对端进行MTU不一致的故障排除

某次开局，使用Quidway路由器与其他厂商的某路由器互连，并运行OSPF协议。

数据配置完毕后，一切正常，并在今后相当长的时间内设备运转稳定。

但两个月后，用户反馈网络中断。