数据产品故障处理基础

liuwx91

数据产品故障处理基础

1 故障处理目的和注意事项

网络故障处理以网络原理、网络配置和网络运行的知识为基础，从故障现象出发，以网络诊断工具为手段获取诊断信息，确定网络故障点，查找问题的根源，排除故障，恢复网络正常运行的一项活动。本章介绍了故障处理活动达到的目的以及该活动过程当中应该注意的一些事项。

1.1 故障处理目的

网络故障处理应该实现如下几个方面的目的：

[size=10.5000pt]l 确定网络的故障点，恢复网络的正常运行

这是网络故障处理的基本目的，网络故障处理的一切活动都必须紧紧围绕这一点。

[size=10.5000pt]l 发现网络规划和配置中欠佳之处，改善和优化网络的性能

网络维护人员有时候会发现，有些故障是由于网络没有很好的规划所导致的，一些网络规划考虑不周的网络虽然也能正常运行，但是在发生故障时候往往会造成比预想的要严重的多的后果（例如：将两个上联端口规划到一块单板上，由于单板故障导致两个上联都中断，业务全阻，这对于运营商来说是不能接受的），因此在故障处理完成后提出适当的网络优化建议也应该是故障处理人员的必要工作。

[size=10.5000pt]l 观察网络的运行状况，及时预测网络通信的质量

针对目前网络的运行情况和业务发展情况，故障处理人员应能够及时的向运营商提供网络在未来一段时间内可能出现的运行状况信息，并给出必要的网络扩容和改造建议。

[size=10.5000pt]l 及时总结故障处理经验，避免类似问题再次发生

故障处理人员在完成故障处理后，应必要的总结故障维护经验，为后期的网络维护人员提供参考文档，必要时应提供针对具体网络的紧急故障处理指导以提升后期网络故障处理的效率。

1.2 故障处理注意事项

在故障处理过程当中，在应达到故障目的的同时也应该注意如下一些事项，以保证故障处理的目的能够顺利达成：

[size=10.5000pt]l 优先恢复业务，其次才是查找故障原因

随着all ip时代的来临，越来越多重要的业务承载在数通网络之上，对于运营商来说，网络的中断时间越长就意味着损失的营收越多，有些时候甚至还会导致用户的索赔。所以一旦发生故障，第一任务就是迅速恢复业务，而不是查找故障原因，有些时候，甚至明知采取相应操作后就肯定不能定位故障原因，但为了能在第一时间抢通业务，也不允许有第二种选择。当然，在有限恢复业务的前提之下，采集越多的故障信息就越有利于后期的故障原因定位。

[size=10.5000pt]l 创建网络基线并定期更新维护之

所谓网络基线，指的是网络在故障发生之前正常运行时候的基本信息和运行性能。网络维护人员应该定期的采集和更新网络基线以保证故障处理人员能在第一时间掌握准确的网络信息，从而为迅速定位故障提供必要的输入信息。

[size=10.5000pt]l 故障发生后应详细记录故障信息

通过4W（Who，What，Where，When）法则，准确了解故障的详细情况，这是开始处理故障前的基本工作。

  注意:

有关于4W法则，将在“3.1 故障处理技能培养”介绍。

[size=10.5000pt]l 保持一颗怀疑的心

对于现场局方人员所反馈的故障信息不能够完全相信，最好能将所反馈的信息一一加以测试验证，以确保对于故障的判断和排查没有受到错误信息的干扰。

[size=10.5000pt]l 处理故障时应该保持冷静的头脑

惊慌失措是网络故障处理中的大忌，手忙脚乱，头脑发热会导致不经过周密的计划和思考就做出反映，有时候这样做会造成严重的后果，因此情况越是紧急，越是要注意冷静。另外，如果在局方面前表现的惊慌失措会导致局方的不信任，从而影响故障处理工作的正常进行。当然，镇定的表现是要有深厚的网络维护经验作为保证的。

[size=10.5000pt]l 远程处理故障时候要谨慎操作

当设备出现故障，业务中断时，如果可以远程登录处理则一定要谨慎操作，尤其是在局方维护人员不在现场的时候，防止由于错误的操作导致设备脱网且无人能在现场处理。另外，远程的所有操作都应该跟局方提前说明，以免引起不必要的麻烦。

[size=10.5000pt]l 要善用自己的经验，而不可滥用

对于富有经验的网络维护人员，在处理故障时，利用已有的经验往往能够事半功倍，但有时候过于依赖经验来处理故障，反而容易出现问题。因此建议在处理复杂故障或者经验不足时，还是采用系统的排障步骤来做（对于系统的排障步骤将在下一章节具体介绍），必将可靠。

[size=10.5000pt]l 故障处理完成后一定要及时总结并广播经验

排查完故障之后要及时总结经验教训，并推广给自己所在部门的同事，以便今后遇到类似故障时候可以提升处理效率，一些时候还可以防止类似的故障在其他网络当中的再次发生。

2.4 故障处理常用命令和工具

本章介绍处理故障时候常用的命令行以及工具。

2.4.1 处理常用命令

本节介绍网络故障处理过程中常用的命令及使用的注意事项。

2.4.1.1 Ping命令

Ping命令是用于检查IP网络连接及主机是否可达。其工作原理是：

源站点向目的站点发送ICMP Echo Request报文，目的站点收到后回送ICMP Echo Reply报文，以此检测两个节点间在IP层的可达性，检测网络层是否连通。

关于ZXR10数据设备以及各种平台的主机上ping命令的使用方法以及使用ping命令来排查故障的具体案例请参考文档：“RTUB_103_C1 网络故障诊断常用工具详解”。

注意：相对于其他厂家的ping命令，ZXR10数据设备在ping命令中提供了一个limit参数用来控制每秒发出的ping包的数量：

ZXR10#ping x.x.x.x limit  ?

  0        Absolute mode

  <1-100>  Number of packet

ZXR10#ping x.x.x.x limit  0   //表示全速，尽全力的ping

2.4.1.2 Trace命令

Trace命令是用于测试报文从发送到目的地所经过的网关，主要用于检查网络连接是否可达，以及初步确定网络发生故障的位置。其工作原理是：

利用报文IP头部的TTL域每经过一台路由器转发后减一，当TTL=0时向源节点报告TTL超时的特殊icmp报文来实现的。

网络维护人员经常会结合使用ping命令和trace命令来排查网络故障。

关于ZXR10数据设备以及各种平台的主机上trace命令的使用方法以及一些使用trace命令来排查故障的具体案例请参考文档：“RTUB_103_C1 网络故障诊断常用工具详解”。（一些厂家和平台的命令是tracert，而非trace）

  注意:

ZXR10设备从4603的平台之后可以支持vrf下的trace，以便在bgp mpls/vpn环境下来排查故障。

2.4.1.3 Show命令

Show命令对于日常维护和故障处理都是非常重要的命令。熟练的掌握各种show命令，并了解显示信息的含义，是网络维护人员所必须具备的技能之一。

ZXR10设备的show命令可以在各种命令模式下执行，并且部分show命令支持正则表达式，以方便更换的查找到所需要的信息。如表 2-1所示列出了ZXR10平台中常用的show命令及在show命令中可以获取到的信息：

表 2-1  常用show命令的含义和获取的信息

命令	含义和获取信息
[size=9.0000pt]Show version	显示设备版本号，平台版本号，设备运行时间，单板运行时间，配置单板的数量和类型，单板上的一些硬件信息。
[size=9.0000pt]Show run	设备目前正在运行的配置信息。
[size=9.0000pt]Show process	设备各版本的cpu利用率和内存利用率。
[size=9.0000pt]Show logging alarm	设备历史告警信息。
[size=9.0000pt]Show logfile	及其登录设备的用户对于设备所做过的操作记录。
[size=9.0000pt]Show interface	端口工作状态，描述，ip地址，流量统计，mut值等等。
[size=9.0000pt]Show ip interface brief	所有端口的三种状态：物理，协议，管理状态列表。
[size=9.0000pt]Show ip route	显示路由表情况
[size=9.0000pt]Show arp	显示ARP表情况
[size=9.0000pt]Show mac	显示MAC表情况
[size=9.0000pt]Show vlan	显示VLAN和端口对应关系
[size=9.0000pt]Show ip ospf nei	查看OSPF邻居状态

注：低端交换机的命令有所不同；另外，不同类型设备同样的show命令显示内容也会有所差异。

关于show命令的具体说明可以参考文档：“RTUB_203_C1 ZXR10 数据查看、诊断命令介绍”。

&  提示:

在需要获取多个show命令结果的时候，在高端路由器上有一个terminal length 0命令，输入该命令后，可以一次粘贴多条命令执行，从而加快信息搜集的速度。

2.4.1.4 Debug命令

Debug命令是网络维护人员所必须掌握的一条故障处理命令。一般建议使用debug命令配合show命令来定位骨折那个原因，在配合使用时，应遵循如下的规则：

[size=10.5000pt]l 首先使用show命令查看当前运行状态，分析可能的故障原因，缩小故障检查的范围。

[size=10.5000pt]l 打开某个特定的debug命令，观察调试信息变化情况，定位和排除故障。

由于debug命令会消耗大量的系统资源，因此在使用debug命令应该注意：

[size=10.5000pt]l 只能使用debug命令定位故障，而不是监控网络运行状态，因此不能长期打开debug命令。

[size=10.5000pt]l 需要选择在业务量不大的时候使用debug命令。

[size=10.5000pt]l 永远都不用使用debug all命令，对于不熟悉具体含义的debug命令也不要使用。

[size=10.5000pt]l 不要使用串口来输出debug信息，否则会导致debug信息丢失。

[size=10.5000pt]l 使用完debug命令之后，应该及时的使用no debug all命令关闭debug。

  注意:

注意事项1：telnet使用debug命令时最好打开两个telnet窗口，一个用于抓取debug信息，一个用于随时敲no debug all来终止debug命令的执行。

注意事项2：telnet使用debug命令时需要使用terminal monitor命令将debug的输出信息打印出来。

2.4.1.5 Clear命令

ZXROS平台提供了两大类的clear命令：一类是用来复位一些路由协议的邻接关系；一类是用来清除统计计数。处理故障时，我们经常会使用后一类的clear命令，现将经常使用的一些clear命令在表 22加以介绍。

表 2-2  常用clear命令的作用

命令	含义和获取信息
[size=9.0000pt]Clear counter	清除端口上的计数统计，可以针对某个具体的端口来执行。
[size=9.0000pt]Clear logging alarm	清除所有告警日志。
[size=9.0000pt]Clear ip traffic	清除上送cpu的数据报文的统计值。
clear ip nat statistics	清除用户nat转换的技术统计值。
[size=9.0000pt]Clear arp	清楚arp表

注： clear命令只能在特权模式下执行。

  注意:

在执行clear命令的时候，请做好操作日志的记录工作，将执行clear命令前后的统计值都记录下来，以便后续分析问题时参考。

2.4.2 故障处理常用工具

本节简要介绍网络故障处理过程中常用的一些工具。

2.4.2.1 网管服务器和日志记录服务器

设备上的内存资源和flash空间都是有限的，当储存空间满了之后，设备将会把生成时间较早的日志和告警进行删除。为了防止重要的告警信息和日志丢失，一般建议给重要的网络配置网管服务器上传告警信息，同时在网管服务器上开启Syslog服务器，记录设备上的各种日志信息，以便在故障发生后（尤其是设备重启：重启后设备上的告警和日志都会清空）获取故障线索。

2.4.2.2 光功率测量仪&网线测量仪&万用表

当怀疑故障是由于物理层的原因导致故障时，比如光功率不足，网线质量差或者设备供电不足时，可以使用一些仪器来进行精准的测量，从而快速定位问题。

2.4.2.3 抓包工具

在处理IP网络的故障时，经常使用以太网抓包工具来查看和抓取IP网络上某些端口或某些网段的数据包，并对这些数据包进行分析，定位问题；必要时，还会使用发包工具发送一些定制的报文来复现故障。

常用的抓包工具有：ethreal和sniffer，其中sniffer还可以支持造包和发包。关于常用的抓包工具的使用介绍请参考文档：“RTUB_105_C1 以太网常用抓包工具介绍”。

  注意:

不论是发包工具还是抓包工具，都会一定程度的影响网络运行性能，因此在操作时一定要注意如下一些事项：

注意事项1：不要将流量很大的端口直接镜像到抓包端口，以防影响设备转发性能，并且PC也无法抓取太大的流量，此时应该采用流镜像的方式来抓包

注意事项2：使用发包工具时一定要谨慎，防止发送的报文流量过大导致网络出现拥塞，影响正常业务等情况的发生。

2.4.2.4 网络性能测试仪

随着all ip时代的来临，越来越多重要的业务承载在ip网络上。这些业务对于网络的时延，抖动和丢包率都有严格的要求。一些故障往往需要使用精密的网络测量仪器来确定网络故障点，常见的网络测量仪如：samrtbits。和使用发包工具相同，使用网络测量仪器需谨慎发送测试流量。