网络故障诊断.docx
- 文档编号:12185347
- 上传时间:2023-04-17
- 格式:DOCX
- 页数:25
- 大小:124.90KB
网络故障诊断.docx
《网络故障诊断.docx》由会员分享,可在线阅读,更多相关《网络故障诊断.docx(25页珍藏版)》请在冰豆网上搜索。
网络故障诊断
一、网络故障的一般分类
连通性问题:
硬件、媒介、电源故障配置错误不正确的相互作用
性能问题:
网络拥塞到目的地不是最佳路由供电不足路由环路网络错误。
二、网络故障解决的处理流程
1.处理流程是网络维护人员所能够采用的排错模型中的一种,如果你根据自己的经验和实践总结了另外的排错模型并证明是行之有效的,请继续使用它——网络故障解决的处理流程是可以变化的,但故障处理有序化的思维模式是不可变化的。
2.下面我们以一个故障处理的实例来学习如何应用这些步骤。
3.处理流程是网络维护人员所能够采用的排错模型中的一种,如果你根据自己的经验和实践总结了另外的排错模型并证明是行之有效的,请继续使用它——网络故障解决的处理流程是可以变化的,但故障处理有序化的思维模式是不可变化的。
三、下面我们以一个故障处理的实例来学习如何应用这些步骤。
用户网段广播包过多造成该网段的服务器FTP业务传输速度慢
该案例组网如上:
某校园网的三个局域网,其中10.11.56.0为一个用户网段,10.11.56.118为一个日志服务器;10.15.0.0是一个集中了很多应用服务器的网段。
1.故障现象描述
☐要想对网络故障做出准确的分析,首先应该了解故障表现出来的各种现象
☐用户反映“日志服务器与备份服务器间备份发生问题。
”这就是一个不完整不清晰的故障现象描述。
因为这个描述没有讲述清楚下列问题:
⏹这个问题是连续出现,还是间断出现的?
⏹是完全不能备份,还是备份的速度慢(即性能下降)?
⏹哪个或哪些局域网服务器受到影响,地址是什么?
☐正确的故障现象描述是:
⏹在网络的高峰期,日志服务器10.11.56.11到集中备份服务器10.15.254.253之间进行备份时,FTP传输速度很慢,大约是0.6Mbps。
2.相关信息收集
☐搜集有助于查找故障原因的详细信息:
⏹向受影响的用户、网络人员或其他关键人员提出问题;
⏹根据故障描述性质,使用各种工具搜集情况,如网络管理系统、协议分析仪、相关display和debug命令等;
⏹测试性能与网络正常情况下的记录进行比较。
☐如上述案例,可以向用户提问或自行收集下列相关信息:
⏹网络结构或配置是否最近修改过,即问题出现是否与网络变化有关?
⏹是否有用户访问受影响的服务器时没有问题?
⏹在非高峰期日志服务器和备份服务器间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.对每一原因实施排错方案
☐根据所列出的可能原因制定故障排查计划,分析最有可能的原因,确定一次只对一个变量进行操作,这种方法使你能够重现某一故障的解决办法。
如果有多个变量同时被改变,而问题得以解决,那么如何判断哪个变量导致了故障发生呢?
6.观察故障排查结果
☐当我们对某一原因执行了排错方案后,需要对结果进行分析,判断问题是否解决,是否引入了新的问题。
如果问题解决,那么就可以直接进入文档化过程;如果没有解决问题,那么就需要再次循环进行到故障排查过程。
7.循环进行故障排查过程
☐在进行下一循环之前必须做的事情就是将网络恢复到实施上一方案前的状态。
如果保留上一方案对网络的改动,很可能导致新的问题。
☐循环排错可以有两个切入点:
⏹当针对某一可能原因的排错方案没有达到预期目的,循环进入下一可能原因制定排错方案并实施;
⏹当所有可能原因列表的排错方案均没有达到排错目的,重现进行故障相关信息收集以分析新的可能原因。
☐如上述案例,我们在列出了可能原因列表后,开始制定方案进行故障处理:
☐可能原因1:
网络10.11.56.0到网络10.15.0.0的路由不是最佳路由。
☐制定的方案:
在10.11.56.0网段的网关上使用“tracert10.15.245.253”命令,发现探测报文返回时长仅为10ms,表明该可能原因并不是造成故障的原因。
我们进入循环排错过程。
☐可能原因2:
日志服务器A的性能问题。
☐制定的方案:
测试同一网段的主机C和日志服务器间的FTP传输速度,是6Mbps,正常。
可见问题与服务器A无关。
☐可能原因3:
10.11.56.0网络的网关性能问题。
☐制定的方案:
测试主机C和备份服务器B间FTP传输速度是7Mbps,正常。
排除了网关因素,因为B、C在不同网段上而速度正常。
☐可能原因4:
10.11.56.0网络本身的性能问题。
☐制定的方案:
在网段10.11.56.0的以太网交换机上使用命令“showmac”,输出如下:
PortRcv-UnicastRcv-MulticastRcv-Broadcast
----------------------------------------------------------------
6/321031781208665
PortXmit-UnicastXmit-MulticastXmit-Broadcast
----------------------------------------------------------------
6/3266679872866522474038
(输出的广播:
输出的单播比例为1:
3,太大了。
)
PortRcv-OctetXmit-Octet
---------------------------------------------------------------
6/32140948293581516443041
☐在网段10.15.0.0上的以太网交换机上使用命令“showmac”输出如下:
PortRcv-UnicastRcv-MulticastRcv-Broadcast
-------------------------------------------------------------
6/36557802870285
PortXmit-UnicastXmit-MulticastXmit-Broadcast
--------------------------------------------------------------
6/3627879749190257119430
(广播:
单播比例=1:
270,属于正常。
)
PortRcv-OctetXmit-Octet
---------------------------------------------------------------
6/36671725870814998816809
☐由此得知,网段10.11.56.0上广播包和单播包比例为1:
3,确实太大了。
☐再次询问用户该网段主要运行的业务是什么,而得出了故障最终原因如下:
10.11.56.0是普通用户网段,由于业务原因每个用户需要发送大量广播包和多播包,随着近期越来越多的用户接入该网络,在这个网段上的服务器需要花费更多的资源来处理越来越多的广播和多播包,因此其服务的传输速度自然减慢。
☐这是一个网络布局不恰当的问题,需要重新安排服务器的位置,将服务器移动10.15.0.0网段后,故障解决。
8.故障处理过程文档化
☐当最终排除了网络故障后,流程的最后一步就是对所做的工作进行文字记录。
☐文档化过程决不是一个可有可无的工作,原因如下:
⏹文档是排错宝贵经验的总结,是“经验判断和理论分析”这一过程中最重要的参考资料;
⏹文档记录了这次排错中网络参数所做的修改,这也是下一次网络故障应收集的相关信息。
☐文档记录主要包括以下几个方面:
⏹故障现象描述及收集的相关信息
⏹网络拓扑图绘制
⏹网络中使用的设备清单和介质清单
⏹网络中使用的协议清单和应用清单
⏹故障发生的可能原因
⏹对每一可能原因制定的方案和实施结果
⏹本次排错的心得体会
⏹其他:
如排错中使用的参考资料列表等
四、路由器常用诊断工具介绍
PING命令
☐命令ping用于检查IP网络连接及主机是否可达。
☐“ping”这个词源于声纳定位操作,指来自声纳设备的脉冲信号。
ping命令的思想与发出一个短促的雷达波,通过收集回波来判断目标很相似;即源站点向目的站点发出一个ICMPEchoRequest报文,目的站点收到该报文后回一个ICMPEchoReply报文,这样就验证了两个节点间IP层的可达性--表示了网络层是连通的。
☐由于ping和tracert命令不仅是Quidway系列路由器VRP平台的常用网络命令,也是windows平台上常用的网络命令,下面对两种平台下的命令使用均进行介绍。
在Quidway系列路由器上,ping命令的格式如下:
ping[-Rdnqrv][-ccount][-ppattern][-spacketsize][-ttimeout]host
-aping报文中使用的源IP地址
-cping报文的个数,缺省值为5;
-t设置ping报文的超时时间,单位为毫秒,缺省值为2000;
-s设置ping报文的大小,以字节为单位,缺省值为56。
在PC机上或WindwosNT为平台的服务器上,ping命令的格式如下:
ping[-nnumber][-t][-lnumber]ip-address
-nping报文的个数,缺省值为5;
-t持续地ping直到人为地中断,Ctr+Breack暂时中止ping命令并查看当前的统计结果,而Ctr+C则中断命令的执行。
-l设置ping报文所携带的数据部分的字节数,设置范围从0至65500。
用ping命令进行故障处理
案例一连通性问题还是性能问题?
☐程师小L,在配置完一台路由器之后执行ping命令检测链路是否通畅。
发现5个报文都没有ping通,小L断定是连通性问题。
☐检查双方的配置命令并查看路由表,却一直没有找到错误所在。
最后又重复执行了一遍相同的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协议。
数据配置完毕后,一切正常,并在今后相当长的时间内设备运转稳定。
但两个月后,用户反馈网络中断。
相关信息显示:
☐登录到两台路由器上,发现双方连接正常,可以相互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。
故障消除。
☐那么为什么工程初期没有问题呢?
这是因为前期DD报文长度小于1500字节,而后来网络扩容导致路由信息过多使DD报文的长度超过了1500字节。
建议和总结:
☐由于ping缺省报文是56个字节,所以显示的ping通信息只是表示56字节的报文可以通而并不一定表示其他大小的报文仍旧可以通。
所以,应当善于使用ping的其他参数来进行故障处理。
案例三A能ping通B,B就一定能ping通A吗?
☐在RouterA上配置一条指向2.0.0.0/8的静态路由:
[Quidway]iproute-static2.0.0.0255.0.0.01.1.1.1
☐在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报文的源地址填写的是1.1.1.1而不是3.3.3.3,由于两台路由器的s0口处于同一网段,所以响应报文可以顺利到达RouterB。
建议和总结:
☐A能够ping通B则B一定能够ping通A(不考虑防火墙的因素),这句话的对错取决于A和B到底是指主机还是指路由器。
⏹如果是指两台主机,那么这句话就是正确的。
⏹如果是指两台路由器那就是错误的,因为路由器通常会有多个IP地址。
现在就有如下问题:
当从一台路由器上执行ping命令它发出的ICMPEcho报文的源地址究竟选择哪一个呢?
实际情况是路由器选择发出报文的接口的IP地址。
TRACERT命令
☐tracert命令用于测试数据报文从发送主机到目的地所经过的网关,主要用于检查网络连接是否可达,以及分析网络什么地方发生了故障。
☐tracert利用IP报文的TTL域在每经过一个路由器的转发后减一,当TTL=0时则向源节点报告TTL超时这个的特性。
tracert首先发送一个TTL为1的UDP报文,因此第一跳发送回一个ICMP错误消息以指明此数据报不能被发送(因为TTL超时),之后tracert再发送一个TTL为2的报文,同样第二跳返回TTL超时,这个过程不断进行,直到到达目的地,此时由于数据报中使用了无效的端口号(缺省为33434)此时目的主机会返回一个ICMP的目的地不可达消息,表明该tracert操作结束。
tracert记录下每一个ICMPTTL超时消息的源地址,从而提供给用户报文到达目的地所经过的网关IP地址。
在华为Quidway系列路由器上,tracert命令的格式如下:
tracert[-aip-address][-ffirst_TTL][-mmax_TTL][-pport][-qnqueries][-wtimeout]host
-a指定一个发送UDP报文的源地址;
-f指定初始报文的TTL大小,缺省值为1;
-m指定最大TTL大小,缺省值为30;
-p目的主机的端口号,缺省值为33434;
-q每次发送的探测报文的个数,缺省值为3;
-w指明UDP报文的超时时间,单位为毫秒,缺省值为5000。
在PC机上或WindwosNT为平台的服务器上,tracert命令的格式如下:
tracert[-d][-hmaximum_hops][-jhost-list][-wtimeout]host
-d不解析主机名;
-h指定最大TTL大小;
-j设定松散源地址路由列表;
-w用于设置UDP报文的超时时间,单位毫秒;
案例一使用tracert命令定位不当的网络配置点
☐某校园网中,RouterB和RouterC同属于一个运行RIPv2路由协议的网络,主机4.0.0.2访问数据库服务器5.0.0.2,用户抱怨访问性能差。
相关信息显示
☐登录到RouterC,使用带参数的ping远端服务器5.0.0.2,显示如下:
[RouterC]ping-c10-s4000-t60005.0.0.2
PING5.0.0.2:
4000databytes,pressCTRL_Ctobreak
Replyfrom5.0.0.2:
bytes=4000Sequence=0ttl=249time=552ms
Replyfrom5.0.0.2:
bytes=4000Sequence=1ttl=249time=5733ms
Replyfrom5.0.0.2:
bytes=4000Sequence=2ttl=249time=552ms
Replyfrom5.0.0.2:
bytes=4000Sequence=3ttl=249time=5714ms
Replyfrom5.0.0.2:
bytes=4000Sequence=4ttl=249time=552ms
Replyfrom5.0.0.2:
bytes=4000Sequence=5ttl=249time=5711ms
Replyfrom5.0.0.2:
bytes=4000Sequence=6ttl=249time=552ms
Replyfrom5.0.0.2:
bytes=4000Sequence=7ttl=249time=5709ms
Replyfrom5.0.0.2:
bytes=4000Sequence=8ttl=249time=552ms
Replyfrom5.0.0.2:
bytes=4000Sequence=9ttl=249time=5710ms
原因分析
☐上面的ping显示出一个规律:
奇数报文的返回时长短,而偶数报文返回时长很长(是奇数报文的10倍多)。
可以初步判断奇数报文和偶数报文是通过不同的路径传输的。
现在我们需要使用tracert命令来追踪这不同的路径。
在RouterC上,tracert远端RouterA的以太网接口5.0.0.1。
[RouterC]tracert-q85.0.0.1
tracerouteto5.0.0.1(5.0.0.1)30hopsmax,40bytespacket
14.0.0.16ms4ms4ms4ms4ms4ms4ms4ms
……
53.0.0.220ms16ms15ms16ms16ms16ms16ms16ms
65.0.0.130ms278ms25ms279ms25ms278ms25ms277ms
RouterC(config)#
从上面的显示可看到,直至3.0.0.2,UDP探测报文的返回时长都基本一致,而到5.0.0.1时,则发生明显变化,呈现奇数报文时长短,偶数报文时长长的现象。
于是判断,问题发生在RouterB和RouterA之间。
☐通过询问该段网络的管理员,得知这两路由器间有一主一备两串行链路,主链路为2.048Mbps(s0口之间),备份链路为128Kbps(s1口之间)。
网络管理员在此两路由器间配置了静态路由。
RouterB上如下配置:
[RouterB]iproute-static5.0.0.0255.0.0.01.0.0.2
[RouterB]iproute-static5.0.0.0255.0.0.02.0.0.2
RouterA上如下配置:
[RouterA]iproute-static0.0.0.00.0.0.01.0.0.1
[RouterA]iproute-static0.0.0.00.0.0.02.0.0.1
于是问题就清楚了。
例如RouterB,由于管理员配置时没有给出静态路由的优先级,这两条路由项的优先级就同为缺省值60,于是就同时出现在路由表中,实现的是负载分担,而不能达到主备的目的。
处理过程,可以有两种处理方法:
☐继续使用静态路由,进行配置更改
RouterB上进行如下更改:
[RouterB]iproute-static5.0.0.0255.0.0.01.0.0.2(主链路仍使用缺省优先级60)
[RouterB]iproute-static5.0.0.0255.0.0.02.0.0.2100(备份链路的优先级降低至100)
RouterA上进行如下更改:
[RouterA]iproute-static0.0.0.00.0.0.0
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 网络故障 诊断