网络故障排查的思路和方法

╰+哭是因爲堅強的太久メ 2022-09-09 04:50 317阅读 0赞

## **0 网络故障处理原则** ##

介绍网络处理思路和方法前，先说明网络故障处理原则：

恢复业务为首要目的。  
    避免处理过程中产生更大故障。

## 1 网络故障排错思路 ##

网络故障发生时， 可以按照收集信息、分析现象，提出假设，验证假设，分析根因、制定解决方案，并执行验证。

###    1.1 收集信息 ###

收集信息包括以下信息：

故障现象。故障是什么现象，是完全中断时断时续，还是还是丢包，抖动；  
    故障发生时间。故障是什么时候发生的，是一直存在还是刚刚发生，故障发生前是否由变更，变更是否可能导致故障；  
    故障范围；故障产生的范围，是所有人所有业务都受到影响，还是局部影响，故障范围是否由共性，例如都经过一个路由器，一条链路，一个接口；

### 1.2 分析现象，提出假设 ###

收集到信息后，需要将故障现象转化成网络专业中的现象，进行分析，并得提出假设。例如基站掉站转化成基站网管平面到基站控制器管理面之间不通，可能是因为路由丢失；某基站下无法发送短信转换成该基站下无法发送大包数据，可能是因为端到端MTU不满足业务需求。  
如果故障和业务紧密相关，且网络连通性没有问题，此时就需要对业务由深刻理解和积累，才能得出合理，专业的假设。一些业务故障发生后，如果在业务层面排查没有没有问题，网络工程师可以今早参与到其中，一方面是为了尽快确保网络没有故障，另一方面是避免到最后发现是网络问题导致被动。

###    1.3 验证假设，分析根因 ###

提出假设后，开始对假设对假设进行验证，如果假设得到证实，则需要分析故障出现的根本原因，并提出解决方案，如果假设不成立，则需要针对收集的信息对进一步分析，提出假设。

继续以基站断站为例，第二步分析后提出的假设是路由丢失导致基站断站，开始对基站控制器管理面到基站的沿途的路由进行检查，确保每一跳都由去程和回城路由，如果发现某一跳路由缺少，需要进一步分析根本原因。

如果检查过后，发现假设不成立，则需要回到第2步，甚至第1步，重新进行采集和收集。

###    1.4 制定解决方案，并执行验证 ###

得出根本原因后，开始制定解决方案，在制定和执行解决方案时，必须遵循以下原则：

确保执行方案不会造成更大故障；  
    执行方案可回退；  
    执行解决方案前，需要保存当前业务，网络状态，以便执行后进行对比；  
    每次只执行一个操作，并观察业务；  
    如果解决方案部署后仍无法解决，考虑是否需要回退；

如果无法解决方案执行后，仍然无法解决，需要从新进行分析和假设。

###    1.5 故障总结 ###

故障解决后，需要对故障进行总结，总结内容包括：

故障产生的原因。故障是人为导致故障还是非人为导致。如果是人为故障，是否因为变更导致的故障故障，如果是，需要检查遵循了变更流程，如果遵循了变更流程，则需要了解变更方案是否经过审核，测试，是否遵循变更步骤等。如果是非人为原因，则考虑分析现有网络，设备，线路是否有足够能力在一定程度上保证网络可靠性。  
    故障是否及时发现。现有监控工具是否能够及时发现故障，现有流程是否能使得故障及时有人处理，及时上报,升级；  
    改进措施。如果是人为导致故障，则考虑如何从权限，流程，测试，自动化上避免故障再次发生，如果是非人非考虑如何从网络弹性设计，网络自愈方面考虑避免故障发生。

## 2 故障排除方法和工具 ##

故障处理时，可以使用的工具包括：syslog,监控系统，wireshark,设备自带命令等；  
故障处理的方法包括：自顶向下，自底向上，从网络层开始，分段法，替换法，比较法等。

###    2.1 故障处理工具 ###

处理故障过程中，要善于利用现有的工具和系统，例如监控系统,常见的开源监控系统包括zabbix, cacti,open-falcon, 普罗米修斯等。cacti功能简单，可以用于网络建设初期快速部署的场景，随着网络规模和需求的增加，cacti在多厂商设备支持和监控项支持上就显得不足，此时zabbix是一个很好的选择，可以自定义监控模板，监控项，并且提供API接口;open-falcon和普罗米修斯是新出现的开源项目，可以进一步支持自定义功能。

syslog目前没有发现很好用的开源系统，大家可以推荐。

除了syslog和监控日志，其他常见的工具包括filezilla,用于测试FTP上传下载，使用过程中需要注意将多线程上传打开；wireshark用于抓包分析报文;cli中的ping ,traceroute, debug,也可以再特定情况下使用。

##    2.2 故障处理方法 ##

###    2.2.1 自顶向下 ###

顾名思义，自顶向下是指从TCP/IP协议栈顶部向下排查，通常是定位了故障点后对单个节点进行排查。自顶向下方法适用于应用层或传输层出现故障的场景，例如网络可达但应用不可用，例如无法连接FTP服务器，无法连接数据库等。如果应用层无相应，则可以向下检查传输层，TCP三次握手流程等。  
常用的工具包括使用wireshark抓包，检查数据包交互流程。

###    2.2.1 自底向上 ###

从TCP/IP协议栈底部向上排查。从物理层开始，向上排查。物理层通常检查是否有CRC,error包，光功率，双工速率是否匹配等。如果物理层无问题，再检查数据链路层，通常检查MAC地址是否正确学习，VLAN是否允许，是否STP震荡等内容。

###    2.2.2 从网络层开始 ###

顾名思义，就是从网络层开始排查问题，网络层主要关注是否有路由，路由下一跳是否正确，路由是否稳定，是否有地址冲突等问题，排查网络层后，可根据情况，向上或向下检查TCP/IP其他协议栈问题。根据个人的实际经验，从网络层开始排查常用，也最高效。

###    2.2.3分段法 ###

分段法最常用于性能问题的排查，将流量经过的路径进行分段排查。例如，A-B-C-D的网络连接，下载速率无法满足要求，可以采取的排查办法是，先测试从A-B，是否满足要求，如果满足再测试A-C,如果无法满足，问题大概率出现在B-C段，再对B-C段进行排查。

使用分段法排查性能问题可能会出现一种情况，就是A-B-C测试不满足要求，但是A-B,B-C都满足要求，这中情况下，就要分析分段测试的设备是否正确，是否遗漏了设备，或分段结合部是否有问题。

###    2.2.4 替换法 ###

替换法是指将怀疑有问题的部件替换，检查故障是否消除，如果消除，很可能是原有部件有问题。通过某块办卡接入网络的服务器连接失败率很高，可以考虑将该办卡下的服务器迁移到另一台机器或办卡，观察连接失败率是否有变化。

###    2.2.5 对比分析法 ###

对比分析法是指对比有故障设备和无故障设备的相同点和不同点，得出初步判断，并采取措施；例如50%的基站无法正常提供4G服务器，另外50%基站4G业务正常，可以对比两部分基站有什么不一样的地方，通过对比发现了故障的50%的基站都最终都汇聚到了一台网关，正常的基站汇聚到另一台网段，根据整个现象，再对比两台网关配置，状态差异，就可以很快地位出故障。

##    3 小结和思考 ##

网络故障排除不仅靠处理故障时的思路和方法，更多的是靠的时日常积累。从个人角度看，工程需要日常熟悉各业务流程，才能迅速将用户上报的故障转换成网络问题，开始进行排查；同时需要熟练掌握网络中应用的各种技术，才能提供合理假设，对故障节点进行分析，得出结论。个人的经验是，像数据包一样，走一遍设备对数据包的处理流程。

从组织角度看，网络建设和运维过程中，如果建立了完备的工具，系统和基线，同样有利于快速定位和解决故障。

与业务故障不同，网络故障通常是通过告警，日志，或用户保障发现，如何像业务一样建立各种指标，指标异常时及时同时告警，是另一个值得深入研究和探讨的方向。当前实践虽然已经有了流量，CPU,内存等指标，但仍远远不足。