通信常见网络故障处理课件.ppt
《通信常见网络故障处理课件.ppt》由会员分享,可在线阅读,更多相关《通信常见网络故障处理课件.ppt(51页珍藏版)》请在三一办公上搜索。
1、常见网络故障处理,网络监控维护中心2015年1月,【产品系统工程师】数据网技能培训(初阶)之二,本课程解决的根本问题是故障处理的基本步骤及常用诊断工具?,以上模块都遵循课程设计的基本法则:循序渐进、由浅入深,课程总体思路图,2,关键问题,课程模块,关键方法,内容介绍,第一章 故障处理技术概述 第二章 故障处理步骤 第三章 常用诊断工具介绍,第一章 故障处理技术概述,第1节 导言 第2节 故障分类,导言,能够正确地维护网络尽量不出现故障,并确保出现故障之后能够迅速、准确地定位问题并排除故障,对网络维护和管理人员来说是个挑战。这不但要求对网络协议和技术有着深入的理解,更重要的是要建立一个系统化的故
2、障处理思想,并合理应用于实际中,以将一个复杂的问题隔离、分解或缩减排错范围,从而及时修复网络故障。,连通性问题硬件、媒介、电源故障配置错误不正确的相互作用,性能问题网络拥塞到目的地不是最佳路由路由环路网络错误,故障分类,第二章 故障处理步骤,第1节 导言 第2节 故障处理思路 第3节 故障处理实例,8,故障处理系统化是合理地一步一步找出故障原因并解决的总体原则。它的基本思想是系统地将由故障可能的原因所构成的一个大集合缩减(或隔离)成几个小的子集,从而使问题的复杂度迅速下降。,导言,故障处理步骤,该处理流程是网络维护人员所能够采用的排错模型中的一种网络故障解决的处理流程是可以变化的,但故障处理有
3、序化的思维模式是不可变化的下面我们以一个故障处理的实例来学习如何应用这些步骤。,该案例组网如上:某校园网的三个局域网,其中10.11.56.0为一个用户网段,10.11.56.118为一个日志服务器;10.15.0.0是一个集中了很多应用服务器的网段。,用户网段广播包过多造成该网段的服务器FTP业务传输速度慢,网云,A:10.11.56.118/24,C:10.11.56.120/24,B:10.15.254.253/16,D:129.9.35.53/16,ETHERNET,ETHERNET,ETHERNET,故障处理实例,要想对网络故障做出准确的分析,首先应该了解故障表现出来的各种现象 用户
4、反映“日志服务器与备份服务器间备份发生问题。”这就是一个不完整不清晰的故障现象描述。因为这个描述没有讲述清楚下列问题:这个问题是连续出现,还是间断出现的?是完全不能备份,还是备份的速度慢(即性能下降)?哪个或哪些局域网服务器受到影响,地址是什么?正确的故障现象描述是:在网络的高峰期,日志服务器10.11.56.11到集中备份服务器10.15.254.253之间进行备份时,FTP传输速度很慢,大约是0.6Mbps。,故障处理实例故障现象描述,搜集有助于查找故障原因的详细信息:向受影响的用户、网络人员或其他关键人员提出问题;根据故障描述性质,使用各种工具搜集情况,如网络管理系统、协议分析仪、相关d
5、isplay和debug命令等;测试性能与网络正常情况下的记录进行比较。如上述案例,可以向用户提问或自行收集下列相关信息:网络结构或配置是否最近修改过,即问题出现是否与网络变化有关?是否有用户访问受影响的服务器时没有问题?在非高峰期日志服务器和备份服务器间FTP传输速度是多少?通过该步骤,我们收集到了下面一些相关信息:最近10.11.56.0网段的客户机不断在增加;129.9.0.0网段的机器与备份服务器间进行FTP传输时速度正常为7Mbps,与日志服务器间进行FTP传输时速度慢,只有0.6Mbps;在非高峰期日志服务器和备份服务器间FTP传输速度正常,大约为6Mbps;,故障处理实例搜集相关
6、信息,利用前两个步骤收集到的数据,并根据自己以往的故障处理经验和所掌握的的知识,确定一个排错范围。通过范围的划分,就只需注意某一故障或与故障情况相关的那一部分产品、介质和主机。如上述案例,我们现在能够确定是一个网络性能下降问题。那么,是网段10.11.56.0的性能问题?是中间网络的性能问题?还是10.15.0.0网段的性能问题呢?根据129.9.0.0网段的机器与备份服务器间进行FTP传输时速度正常为7Mbps这一事实,我们可以排除掉10.15.0.0网段的性能问题。,故障处理实例经验判断和理论分析,该步骤列出根据经验判断和理论分析后总结的各种可能原因。如上述案例,可能原因如下:网段10.1
7、1.56.0的性能问题,其原因可能为 :日志服务器A的性能问题10.11.56.0网络的网关性能问题10.11.56.0网络本身的性能问题中间网络性能问题,主要是到网络10.15.0.0的路由不是最佳路由,故障处理实例各种可能原因列表,根据所列出的可能原因制定故障排查计划,分析最有可能的原因,确定一次只对一个变量进行操作,这种方法使你能够重现某一故障的解决办法。如果有多个变量同时被改变,而问题得以解决,那么如何判断哪个变量导致了故障发生呢?,故障处理实例对每种原因逐个实施排错方案,可能原因1:网络10.11.56.0到网络10.15.0.0的路由不是最佳路由。制定的方案:在10.11.56.0
8、网段的网关上使用“tracert 10.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
9、的以太网交换机上使用命令“show mac”,输出如下:Port Rcv-Unicast Rcv-Multicast Rcv-Broadcast- - - -6/32 10317812 0 8665Port Xmit-Unicast Xmit-Multicast Xmit-Broadcast- - - -6/32 6667987 286652 2474038(输出的广播:输出的单播比例为1:3,太大了。)Port Rcv-Octet Xmit-Octet- - - 6/32 14094829358 1516443041在网段10.15.0.0上的以太网交换机上使用命令“show mac”输出如
10、下:Port Rcv-Unicast Rcv-Multicast Rcv-Broadcast- - - -6/36 55780287 0 285Port Xmit-Unicast Xmit-Multicast Xmit-Broadcast- - - -6/36 27879749 190257 119430(广播:单播比例1:270,属于正常。)Port Rcv-Octet Xmit-Octet- - -6/36 67172587081 4998816809,由此得知,网段10.11.56.0上广播包和单播包比例为1:3,确实太大了。再次询问用户该网段主要运行的业务是什么,而得出了故障最终原因如
11、下:10.11.56.0是普通用户网段,由于业务原因每个用户需要发送大量广播包和多播包,随着近期越来越多的用户接入该网络,在这个网段上的服务器需要花费更多的资源来处理越来越多的广播和多播包,因此其服务的传输速度自然减慢。这是一个网络布局不恰当的问题,需要重新安排服务器的位置,将服务器移动10.15.0.0网段后,故障解决。,第三章 常用诊断工具介绍,第1节 导言 第2节 命令介绍 第3节 案例分析,ing命令tracert命令display命令debug命令抓包软件sniffer/ethereal,几个常用诊断工具,命令ping用于检查IP网络连接及主机是否可达。“ping”这个词源于声纳定位
12、操作,指来自声纳设备的脉冲信号。ping命令的思想与发出一个短促的雷达波,通过收集回波来判断目标很相似;即源站点向目的站点发出一个ICMP Echo Request报文,目的站点收到该报文后回一个ICMP Echo Reply报文,这样就验证了两个节点间IP层的可达性表示了网络层是连通的。ping和tracert命令不仅是路由器平台的常用网络命令,也是windows平台上常用的网络命令,PING命令,在Quidway系列路由器上, ping命令的格式如下:ping -Rdnqrv -c count -p pattern -s packetsize -t timeout host-a ping报
13、文中使用的源IP地址-c ping报文的个数,缺省值为5;-t 设置ping报文的超时时间,单位为毫秒,缺省值为2000;-s 设置ping报文的大小,以字节为单位,缺省值为56。,在PC机上或Windows NT为平台的服务器上,ping命令的格式如下:ping -n number -t -l number ip-address-n ping报文的个数,缺省值为5;-t 持续地ping 直到人为地中断,Ctr+Breack暂时中止ping命令并查看当前的统计结果,而Ctr+C则中断命令的执行。-l 设置ping报文所携带的数据部分的字节数,设置范围从0至65500。,用ping命令进行故障处
14、理,工程师小L,在配置完一台路由器之后执行ping命令检测链路是否通畅。发现5个报文都没有ping通,小L断定是连通性问题。检查双方的配置命令并查看路由表,却一直没有找到错误所在。最后又重复执行了一遍相同的ping命令,发现这一次5个报文中有1个ping 通了原来是线路质量不好存在比较严重的丢包现象。,案例一 连通性问题还是性能问题?,工程师小L又配置了一台路由器,然后执行ping命令访问Internet上某站点的IP地址,但没有ping通。有了上次的教训小L,再一次ping了20个报文,仍旧没有响应。于是这次小L觉得能够断定是连通性故障。在费劲周折检查了配置链路之后仍没有发现任何可疑之处,最
15、后小L采取逐段检测的方法对链路中的网关进行逐级测试,发现都可以ping 通,但是响应的时间越来越长,最后一个网关的响应时间在1800ms左右。会不会是由于超时而导致显示为ping 不同呢?受此启发,小L将ping 命令报文的超时时间改为4000ms,这次成功ping通了,显示所有的报文响应时间都在2200ms 左右。,用ping命令进行故障处理,案例一 连通性问题还是性能问题?,建议和总结:真的是ping不通吗?这个问题需要定位清楚,因为连通性问题和性能问题排错的关注点是不一样的问题定位错误必然会导致排错过程的周折。使用一般的ping命令,缺省是发送5个报文的,超时时长是2000ms。如果pi
16、ng不通情况发生,最好能够再用带参数-c和-t的ping命令再执行一遍,如: ping -c 20 -t 4000 ip-address,即连续发送20个报文,每个报文的超时时长为4000ms,这样一般可以判断出到底是连通性问题还是性能问题。,用ping命令进行故障处理,案例一 连通性问题还是性能问题?,在RouterA上配置一条指向2.0.0.0/8的静态路由:Quidway ip route-static 2.0.0.0 255.0.0.0 1.1.1.1在RouterA 上ping路由器RouterB 的以太网地址2.2.2.2,RouterA的以太网地址3.3.3.3,却无法ping通
17、。,用ping命令进行故障处理,案例二 显示可以正常ping通;但是在RouterB上ping路由器,案例二 A能ping通B,B就一定能ping通A吗?,原因分析:由于在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。,用ping命令进行
18、故障处理,案例二 A能ping通B,B就一定能ping通A吗?,建议和总结:A能够ping通B则B一定能够ping通A(不考虑防火墙的因素),这句话的对错取决于A和B到底是指主机还是指路由器。如果是指两台主机,那么这句话就是正确的。如果是指两台路由器那就是错误的,因为路由器通常会有多个IP地址。现在就有如下问题:当从一台路由器上执行ping命令它发出的ICMP Echo报文的源地址究竟选择哪一个呢?实际情况是路由器选择发出报文的接口的IP地址。,用ping命令进行故障处理,TRACERT 命令,tracert 命令用于测试数据报文从发送主机到目的地所经过的网关,主要用于检查网络连接是否可达,以
19、及分析网络什么地方发生了故障。tracert利用IP报文的TTL域在每经过一个路由器的转发后减一,当TTL=0时则向源节点报告TTL超时这个特性。 tracert首先发送一个TTL为1的UDP报文,因此第一跳发送回一个ICMP错误消息以指明此数据报不能被发送(因为TTL超时),之后tracert再发送一个TTL为2的报文,同样第二跳返回TTL超时,这个过程不断进行,直到到达目的地,此时由于数据报中使用了无效的端口号(缺省为33434)此时目的主机会返回一个ICMP的目的地不可达消息,表明该tracert操作结束。tracert记录下每一个ICMP TTL超时消息的源地址,从而提供给用户报文到达
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 通信 常见 网络故障 处理 课件
链接地址:https://www.31ppt.com/p-1490734.html