您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 管理学资料 > 26--DR020004 NE8040设备故障处理
华为3Com培训中心华为3Com公司版权所有,未经授权不得使用与传播DR020004NE8040设备故障处理2学习完此课程,您将会:掌握一般的故障排除步骤掌握常用的故障排除工具掌握故障处理常用方法了解华为数据通信产品故障处理资源3第一章网络故障处理技术概述第二章故障排除常用工具第三章故障排除常用方法第四章故障处理资源4网络故障处理技术概述当今的网络互连环境是复杂的,而且其复杂性还在日益增长,主要原因如下:现代的因特网络要求支持更广泛的应用,包括数据、语音、视频及它们的集成传输;新业务发展使网络带宽的需求不断增长,这就要求新技术的不断出现。例如:十兆以太网向百兆、千兆以太网的演进;MPLS技术的出现;提供QoS能力等。新技术的应用同时还要兼顾传统的技术。例如,传统的SNA体系结构仍在某些场合使用,DLSw作为通过TCP/IP承载SNA的一种技术而被应用。5网络故障处理技术概述能够正确地维护网络尽量不出现故障,并确保出现故障之后能够迅速、准确地定位问题并排除故障,对网络维护和管理人员来说是个挑战。这不但要求对网络协议和技术有着深入的理解,更重要的是要建立一个系统化的故障处理思想并合理应用于实际中,以将一个复杂的问题隔离、分解或缩减排错范围,从而及时修复网络故障。6网络故障的一般分类连通性问题性能问题硬件、媒介、电源故障配置错误不正确的相互作用网络拥塞到目的地不是最佳路由供电不足路由环路网络错误7一般网络故障的解决步骤故障处理系统化是合理地一步一步找出故障原因并解决的总体原则。它的基本思想是系统地将由故障可能的原因所构成的一个大集合缩减(或隔离)成几个小的子集,从而使问题的复杂度迅速下降。故障现象观察故障相关信息收集经验判断和理论分析各种可能原因列表对每一原因实施排错方案故障排除?恢复实施方案前的网络状态故障排除过程文档化循环1循环2NY8故障处理的实例用户网段广播包过多造成该网段的服务器FTP业务传输速度慢网云A:10.11.56.118/24C:10.11.56.120/24B:10.15.254.253/16D:129.9.35.53/16ETHERNETETHERNETETHERNET该案例组网如上:某校园网的三个局域网,其中10.11.56.0为一个用户网段,10.11.56.118为一个日志服务器;10.15.0.0是一个集中了很多应用服务器的网段91.故障现象描述要想对网络故障做出准确的分析,首先应该了解故障表现出来的各种现象“日志服务器与备份服务器间备份发生问题。”这是一个不完整不清晰的故障现象描述。因为这个描述没有讲述清楚下列问题:这个问题是连续出现,还是间断出现的?是完全不能备份,还是备份的速度慢(即性能下降)?哪个或哪些局域网服务器受到影响,地址是什么?正确的故障现象描述是:在网络的高峰期,日志服务器10.11.56.11到集中备份服务器10.15.254.253之间进行备份时,FTP传输速度很慢,大约是0.6Mbps。102.相关信息收集搜集有助于查找故障原因的详细信息:向受影响的用户、网络人员或其他关键人员提出问题;根据故障描述性质,使用各种工具搜集情况,如网络管理系统、协议分析仪、相关display和debug命令等;测试性能与网络正常情况下的记录进行比较。通过该步骤,我们收集到了下面一些相关信息:最近10.11.56.0网段的客户机不断在增加;129.9.0.0网段的机器与备份服务器间进行FTP传输时速度正常为7Mbps,与日志服务器间进行FTP传输时速度慢,只有0.6Mbps;在非高峰期日志服务器和备份服务器间FTP传输速度正常,大约为6Mbps113.经验判断和理论分析利用前两个步骤收集到的数据,并根据自己以往的故障处理经验和所掌握的的知识,确定一个排错范围。通过范围的划分,就只需注意某一故障或与故障情况相关的那一部分产品、介质和主机。如上述案例,我们现在能够确定是一个网络性能下降问题。那么,是网段10.11.56.0的性能问题?是中间网络的性能问题?还是10.15.0.0网段的性能问题呢?根据129.9.0.0网段的机器与备份服务器间进行FTP传输时速度正常为7Mbps这一事实,我们可以排除掉10.15.0.0网段的性能问题。124.各种可能原因列表该步骤列出根据经验判断和理论分析后总结的各种可能原因如上述案例,可能原因如下:网段10.11.56.0的性能问题,其原因可能为:日志服务器A的性能问题10.11.56.0网络的网关性能问题10.11.56.0网络本身的性能问题中间网络性能问题,主要是到网络10.15.0.0的路由不是最佳路由135.对每一原因实施排错方案根据所列出的可能原因制定故障排查计划,分析最有可能的原因确定一次只对一个变量进行操作,这种方法使你能够重现某一故障的解决办法如果有多个变量同时被改变,而问题得以解决,那么如何判断哪个变量导致了故障发生呢146.观察故障排查结果当我们对某一原因执行了排错方案后,需要对结果进行分析判断问题是否解决,是否引入了新的问题问题解决,那么就可以直接进入文档化过程没有解决问题,那么就需要再次循环进行到故障排查过程157.循环进行故障排查过程在进行下一循环之前必须做的事情就是将网络恢复到实施上一方案前的状态。如果保留上一方案对网络的改动,很可能导致新的问题循环排错可以有两个切入点:当针对某一可能原因的排错方案没有达到预期目的,循环进入下一可能原因制定排错方案并实施;当所有可能原因列表的排错方案均没有达到排错目的,重现进行故障相关信息收集以分析新的可能原因。我们在列出了可能原因列表后,开始制定方案进行故障处理167.循环进行故障排查过程可能原因1:网络10.11.56.0到网络10.15.0.0的路由不是最佳路由。制定的方案:在10.11.56.0网段的网关上使用“tracert10.15.245.253”命令,发现探测报文返回时长仅为10ms,表明该可能原因并不是造成故障的原因。我们进入循环排错过程。177.循环进行故障排查过程可能原因2:日志服务器A的性能问题。制定的方案:测试同一网段的主机C和日志服务器间的FTP传输速度,是6Mbps,正常。可见问题与服务器A无关。187.循环进行故障排查过程可能原因3:10.11.56.0网络的网关性能问题。制定的方案:测试主机C和备份服务器B间FTP传输速度是7Mbps,正常。排除了网关因素,因为B、C在不同网段上而速度正常。197.循环进行故障排查过程可能原因4:10.11.56.0网络本身的性能问题。制定的方案:在网段10.11.56.0的以太网交换机上使用命令“displaymac”,输出如下:PortRcv-UnicastRcv-MulticastRcv-Broadcast----------------------------------------------------------------6/321031781208665PortXmit-UnicastXmit-MulticastXmit-Broadcast----------------------------------------------------------------6/3266679872866522474038(输出的广播:输出的单播比例为1:3,太大了。)PortRcv-OctetXmit-Octet---------------------------------------------------------------6/32140948293581516443041在网段10.15.0.0上的以太网交换机上使用命令“showmac”输出如下:PortRcv-UnicastRcv-MulticastRcv-Broadcast-------------------------------------------------------------6/36557802870285PortXmit-UnicastXmit-MulticastXmit-Broadcast--------------------------------------------------------------6/3627879749190257119430(广播:单播比例=1:270,属于正常。)PortRcv-OctetXmit-Octet---------------------------------------------------------------6/36671725870814998816809207.循环进行故障排查过程由此得知,网段10.11.56.0上广播包和单播包比例为1:3,确实太大了。再次询问用户该网段主要运行的业务是什么,而得出了故障最终原因如下:10.11.56.0是普通用户网段,由于业务原因每个用户需要发送大量广播包和多播包随着近期越来越多的用户接入该网络,在这个网段上的服务器需要花费更多的资源来处理越来越多的广播和多播包,因此其服务的传输速度自然减慢。这是一个网络布局不恰当的问题,需要重新安排服务器的位置,将服务器移动10.15.0.0网段后,故障解决。218.故障处理过程文档化当最终排除了网络故障后,流程的最后一步就是对所做的工作进行文字记录。文档记录主要包括以下几个方面:故障现象描述及收集的相关信息网络拓扑图绘制网络中使用的设备清单和介质清单网络中使用的协议清单和应用清单故障发生的可能原因对每一可能原因制定的方案和实施结果本次排错的心得体会其他:如排错中使用的参考资料列表等22第一章网络故障处理技术概述第二章故障排除常用工具第三章故障排除常用方法第四章故障处理资源23路由器常用诊断工具ping命令tracert命令display命令reset命令debug命令24PING命令命令ping用于检查IP网络连接及主机是否可达。“ping”这个词源于声纳定位操作,指来自声纳设备的脉冲信号。ping命令的思想与发出一个短促的雷达波,通过收集回波来判断目标很相似;即源站点向目的站点发出一个ICMPEchoRequest报文,目的站点收到该报文后回一个ICMPEchoReply报文,这样就验证了两个节点间IP层的可达性--表示了网络层是连通的由于ping和tracert命令不仅是路由器VRP平台的常用网络命令,也是windows平台上常用的网络命令,下面对两种平台下的命令使用均进行介绍25PING命令在NE系列路由器上,ping命令的格式如下:ping[-aX.X.X.X|-ccount|-d|-httl_value|-i{interface-typeinterface-number|interface-name}|ip|-n|-ppattern|-q|-r|-spacketsize|-ttimeout|-v|vpn-instancevpn-instance-name]*host-aping报文中使用的源IP地址-cping报文的个数,缺省值为5-t设置ping报文的超时时间,单位为毫秒,缺省值为2000-s设置ping报文的大小,以字节为单位,缺省值为5626PING命令在PC机上或WindwosNT为平台的服务器上,ping命令的格式如下:ping[-nnumber][-t][-lnumber]ip-address-nping报文的个数,缺省值为5;-t持续地ping直到人为地中断,Ctr+Breack暂时中止ping命令并查看当前的统计结果,而Ctr+C则中断命令的执行。-l设置ping报文所携带的数据部分的字节数,设置范围从0至6550027用ping命令进行故障处理案例一连通性问题还是性能问题工程师小L,在配置完一台路由器之后执行ping命令检测链路是否通畅。发现5个报文都没有ping通,小L断定是连通性问题检查
本文标题:26--DR020004 NE8040设备故障处理
链接地址:https://www.777doc.com/doc-1305236 .html