通信常见网络故障处理.ppt

常见网络故障处理 网络监控维护中心2015年1月 产品系统工程师 数据网技能培训 初阶 之二 本课程解决的根本问题是故障处理的基本步骤及常用诊断工具 以上模块都遵循课程设计的基本法则 循序渐进 由浅入深 课程总体思路图 2 关键问题 课程模块 关键方法 内容介绍 第一章故障处理技术概述第二章故障处理步骤第三章常用诊断工具介绍 第一章故障处理技术概述 第1节导言第2节故障分类 导言 能够正确地维护网络尽量不出现故障 并确保出现故障之后能够迅速 准确地定位问题并排除故障 对网络维护和管理人员来说是个挑战 这不但要求对网络协议和技术有着深入的理解 更重要的是要建立一个系统化的故障处理思想 并合理应用于实际中 以将一个复杂的问题隔离 分解或缩减排错范围 从而及时修复网络故障 连通性问题硬件 媒介 电源故障配置错误不正确的相互作用 性能问题网络拥塞到目的地不是最佳路由路由环路网络错误 故障分类 第二章故障处理步骤 第1节导言第2节故障处理思路第3节故障处理实例 8 故障处理系统化是合理地一步一步找出故障原因并解决的总体原则 它的基本思想是系统地将由故障可能的原因所构成的一个大集合缩减 或隔离 成几个小的子集 从而使问题的复杂度迅速下降 导言 故障处理步骤 该处理流程是网络维护人员所能够采用的排错模型中的一种网络故障解决的处理流程是可以变化的 但故障处理有序化的思维模式是不可变化的下面我们以一个故障处理的实例来学习如何应用这些步骤 该案例组网如上 某校园网的三个局域网 其中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 故障处理实例 要想对网络故障做出准确的分析 首先应该了解故障表现出来的各种现象用户反映 日志服务器与备份服务器间备份发生问题 这就是一个不完整不清晰的故障现象描述 因为这个描述没有讲述清楚下列问题 这个问题是连续出现 还是间断出现的 是完全不能备份 还是备份的速度慢 即性能下降 哪个或哪些局域网服务器受到影响 地址是什么 正确的故障现象描述是 在网络的高峰期 日志服务器10 11 56 11到集中备份服务器10 15 254 253之间进行备份时 FTP传输速度很慢 大约是0 6Mbps 故障处理实例 故障现象描述 搜集有助于查找故障原因的详细信息 向受影响的用户 网络人员或其他关键人员提出问题 根据故障描述性质 使用各种工具搜集情况 如网络管理系统 协议分析仪 相关display和debug命令等 测试性能与网络正常情况下的记录进行比较 如上述案例 可以向用户提问或自行收集下列相关信息 网络结构或配置是否最近修改过 即问题出现是否与网络变化有关 是否有用户访问受影响的服务器时没有问题 在非高峰期日志服务器和备份服务器间FTP传输速度是多少 通过该步骤 我们收集到了下面一些相关信息 最近10 11 56 0网段的客户机不断在增加 129 9 0 0网段的机器与备份服务器间进行FTP传输时速度正常为7Mbps 与日志服务器间进行FTP传输时速度慢 只有0 6Mbps 在非高峰期日志服务器和备份服务器间FTP传输速度正常 大约为6Mbps 故障处理实例 搜集相关信息 利用前两个步骤收集到的数据 并根据自己以往的故障处理经验和所掌握的的知识 确定一个排错范围 通过范围的划分 就只需注意某一故障或与故障情况相关的那一部分产品 介质和主机 如上述案例 我们现在能够确定是一个网络性能下降问题 那么 是网段10 11 56 0的性能问题 是中间网络的性能问题 还是10 15 0 0网段的性能问题呢 根据129 9 0 0网段的机器与备份服务器间进行FTP传输时速度正常为7Mbps这一事实 我们可以排除掉10 15 0 0网段的性能问题 故障处理实例 经验判断和理论分析 该步骤列出根据经验判断和理论分析后总结的各种可能原因 如上述案例 可能原因如下 网段10 11 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网段的网关上使用 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 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 36671725870814998816809 由此得知 网段10 11 56 0上广播包和单播包比例为1 3 确实太大了 再次询问用户该网段主要运行的业务是什么 而得出了故障最终原因如下 10 11 56 0是普通用户网段 由于业务原因每个用户需要发送大量广播包和多播包 随着近期越来越多的用户接入该网络 在这个网段上的服务器需要花费更多的资源来处理越来越多的广播和多播包 因此其服务的传输速度自然减慢 这是一个网络布局不恰当的问题 需要重新安排服务器的位置 将服务器移动10 15 0 0网段后 故障解决 第三章常用诊断工具介绍 第1节导言第2节命令介绍第3节案例分析 ping命令tracert命令display命令debug命令抓包软件sniffer ethereal 几个常用诊断工具 命令ping用于检查IP网络连接及主机是否可达 ping 这个词源于声纳定位操作 指来自声纳设备的脉冲信号 ping命令的思想与发出一个短促的雷达波 通过收集回波来判断目标很相似 即源站点向目的站点发出一个ICMPEchoRequest报文 目的站点收到该报文后回一个ICMPEchoReply报文 这样就验证了两个节点间IP层的可达性 表示了网络层是连通的 ping和tracert命令不仅是路由器平台的常用网络命令 也是windows平台上常用的网络命令 PING命令 在Quidway系列路由器上 ping命令的格式如下 ping Rdnqrv ccount ppattern spacketsize ttimeout host aping报文中使用的源IP地址 cping报文的个数 缺省值为5 t设置ping报文的超时时间 单位为毫秒 缺省值为2000 s设置ping报文的大小 以字节为单位 缺省值为56 在PC机上或WindowsNT为平台的服务器上 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不通吗 这个问题需要定位清楚 因为连通性问题和性能问题排错的关注点是不一样的 问题定位错误必然会导致排错过程的周折 使用一般的ping命令 缺省是发送5个报文的 超时时长是2000ms 如果ping不通情况发生 最好能够再用带参数 c和 t的ping命令再执行一遍 如 ping c20 t4000ip address 即连续发送20个报文 每个报文的超时时长为4000ms 这样一般可以判断出到底是连通性问题还是性能问题 用ping命令进行故障处理 案例一连通性问题还是性能问题 在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 RouterA的以太网地址3 3 3 3 却无法ping通 用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命令进行故障处理 案例二A能ping通B B就一定能ping通A吗 建议和总结 A能够ping通B则B一定能够ping通A 不考虑防火墙的因素 这句话的对错取决于A和B到底是指主机还是指路由器 如果是指两台主机 那么这句话就是正确的 如果是指两台路由器那就是错误的 因为路由器通常会有多个IP地址 现在就有如下问题 当从一台路由器上执行ping命令它发出的ICMPEcho报文的源地址究竟选择哪一个呢 实际情况是路由器选择发出报文的接口的IP地址 用ping命令进行故障处理 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 用户抱怨访问性能差 网云 RIP域 E1 4 0 0 1 8 4 0 0 2 8 E0 3 0 0 1 8 S0 1 0 0 1 8 S1 2 0 0 1 8 S0 1 0 0 2 8 s1 2 0 0 2 8 5 0 0 2 8 RouterA RouterB RouterC tracert命令进行故障处理 相关信息显示登录到RouterC 使用带参数的ping远端服务器5 0 0 2 显示如下 RouterC ping c10 s4000 t60005 0 0 2PING5 0 0 2 4000databytes pressCTRL CtobreakReplyfrom5 0 0 2 bytes 4000Sequence 0ttl 249time 552msReplyfrom5 0 0 2 bytes 4000Sequence 1ttl 249time 5733msReplyfrom5 0 0 2 bytes 4000Sequence 2ttl 249time 552msReplyfrom5 0 0 2 bytes 4000Sequence 3ttl 249time 5714msReplyfrom5 0 0 2 bytes 4000Sequence 4ttl 249time 552msReplyfrom5 0 0 2 bytes 4000Sequence 5ttl 249time 5711msReplyfrom5 0 0 2 bytes 4000Sequence 6ttl 249time 552msReplyfrom5 0 0 2 bytes 4000Sequence 7ttl 249time 5709msReplyfrom5 0 0 2 bytes 4000Sequence 8ttl 249time 552msReplyfrom5 0 0 2 bytes 4000Sequence 9ttl 249time 5710ms 案例一使用tracert命令定位不当的网络配置点 tracert命令进行故障处理 原因分析上面的ping显示出一个规律 奇数报文的返回时长短 而偶数报文返回时长很长 是奇数报文的10倍多 可以初步判断奇数报文和偶数报文是通过不同的路径传输的 现在我们需要使用tracert命令来追踪这不同的路径 在RouterC上 tracert远端RouterA的以太网接口5 0 0 1 RouterC tracert q85 0 0 1tracerouteto5 0 0 1 5 0 0 1 30hopsmax 40bytespacket14 0 0 16ms4ms4ms4ms4ms4ms4ms4ms 53 0 0 220ms16ms15ms16ms16ms16ms16ms16ms65 0 0 130ms278ms25ms279ms25ms278ms25ms277msRouterC config 从上面的显示可看到 直至3 0 0 2 UDP探测报文的返回时长都基本一致 而到5 0 0 1时 则发生明显变化 呈现奇数报文时长短 偶数报文时长长的现象 于是判断 问题发生在RouterB和RouterA之间 案例一使用tracert命令定位不当的网络配置点 tracert命令进行故障处理 原因分析通过询问该段网络的管理员 得知这两路由器间有一主一备两串行链路 主链路为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 2RouterA上如下配置 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 于是就同时出现在路由表中 实现的是负载分担 而不能达到主备的目的 案例一使用tracert命令定位不当的网络配置点 tracert命令进行故障处理 处理过程 可以有两种处理方法 继续使用静态路由 进行配置更改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 01 0 0 1 RouterA iproute static0 0 0 00 0 0 02 0 0 1100这样 只有当主链路发生故障 备份链路的路由项才会出线在路由表中 从而接替主链路完成报文转发 实现主备目的 在两路由器上运行动态路由协议 如OSPF等 但不要运行RIP协议 因为RIP协议仅以hop作为Metric的 案例一使用tracert命令定位不当的网络配置点 tracert命令进行故障处理 建议和总结本案例的目的不是为了解释网络配置问题 而是用来展示ping命令和tracert命令的相互配合来找到网络问题的发生点 尤其在一个大的组网环境中 维护人员可能无法沿着路径逐机排查 此时 能够迅速定位出发生问题的线路或路由器就非常重要了 案例一使用tracert命令定位不当的网络配置点 tracert命令进行故障处理 DISPLAY命令 display命令是用于了解路由器的当前状况 检测相邻路由器 从总体上监控网络 隔离因特网络中故障的最重要的工具之一 几乎在任何故障处理和监控场合 display命令都是必不可少的 这里仅介绍部分最常用的 全局性的display命令 而与各协议相关的display命令 将在后面章节相应的协议故障处理中详细介绍 DisplayVersion 该命令将帮助用户收集下列信息 VRP软件版本是哪一系列的路由器设备运行时间处理器的信息RAM的容量配置寄存器的设置固件的版本引导程序的版本不同型号的设备显示的内容可能会略有差别 Quidway displayversionHuaweiVersatileRoutingPlatformSoftwareVRP tm software Version1 44Release0006Copyright c 1997 2002HUAWEITECHCO LTD Compiled20 42 52 Jun122003 QuidwayR2511uptimeis0days7hours40minutes13seconds SystemreturnedtoROMbypower on QuidwayR2511with168360ProcessorRouterserialnumberis00E0FC05D5C76A4016MbytesDRAM4608KbytesFlashMemoryhardwareversionis1 0 displaycurrent configuration与displaysaved configuration Displaycurrent configuration用于查看当前的配置信息 Displaysaved configuration用于显示NVRAM或Flash中的路由器配置文件 即路由器下次上电启动时所用的配置文件 Current configuration是路由器目前正在运行的配置文件 当更改某一配置时 current configuration会立即改变 如果不使用save命令将改变保存到启动配置文件saved configuration中 路由器重启时该改动将丢失 因此请注意到修改运行配置并验证正确后 应当将之保存到启动配置文件中 Displayinterfaces displayinterfaces命令可以显示所有接口的当前状态 如果只是想查看特定接口的状态 请在该命令后输入接口类型和接口号 例如 displayinterfacesserial0命令将查看串口0的运行状态和相关信息 Quidway displayinterfacesserial0Serial0isdown lineprotocolisdownphysicallayerissynchronous baudrateis64000bpsinterfaceisDCE clockisDCECLK cabletypeisV35MaximumTransmissionUnitis1500Link protocolisPPPLCPinitial IPCPinitial IPXCPinitial CCPinitial BRIDGECPinitial5minutesinputrate0 00bytes sec 0 00packets sec5minutesoutputrate0 00bytes sec 0 00packets secInputqueue size max drops 0 75 0FIFOq