本帖最后由 孤独的意尹者 于 2012-5-4 19:28 编辑
+++++++++++++++++++++++++++++++++++++++++++++++++
本文转自于我的个人博客：www.vants.org，该文链接为：http://www.vants.org/?post=27，后续我的大部分文章将首先发布在我的个人博客，欢迎大家关注。
+++++++++++++++++++++++++++++++++++++++++++++++++
当我们在工作中遇到疑难杂症时，我们需要有一个明确的分析流程和清晰的分析思路，不能东一枪西一炮，上来就抓包。明确的流程和思路可以让我们少走弯路，节省我们宝贵的时间，大大提高我们分析定位故障的效率。
我们在这里主要针对疑难杂症分析定位的常规流程和思路进行讲解。下图为疑难故障分析时的流程图：
1
故障信息的收集
[url=]一般情况下，我们需要收集的故障信息主要包含故障相关的拓扑结构，路由设置，相关设备的地址信息等。[/url]
网络拓扑
故障发生的网络拓扑结构是我们首先需要搞清楚的信息。拓扑结构为我们提供了故障环境下，从客户端到服务器端大致的网络连接情况，包含经过的各种网络设备、网络链路等。下图为一个网络拓扑图的例子：
拓扑图的例子 [url=]
路由情况[/url]
路由情况主要指故障环境下，各个网络层转发设备处的路由设置情况，包括客户端和服务器端网络环境中的三层交换机、路由器、防火墙等路由表信息。
我们可以通过路由信息和拓扑结构，分析出数据包交互的来回路径。
相关设备的地址信息
相关设备的地址信息主要指故障客户端、服务器的IP地址、默认网关、路由设置等信息
。
[url=]2
[/url]验证故障现象
我们需要在故障现场，通过与用户的充分沟通和我们自己的亲身体验，确认具体的故障现象。
[url=]3
[/url]常规测试和分析
常规测试主要指利用ping、tracert、telnet、nslookup等常用工具，对故障进行常规性的测试，从而判断包括网络层的延时丢包情况、经过的路径、服务开启情况、DNS解析的情况等信息。我们在这些常规测试的基础上，结合检查相关设备的ARP表、路由表、访问控制列表等配置信息，大致分析判断出故障是否需要通过分析数据报文交互的方式来定位。
另一方面，在条件许可的情况下，常规测试还包含通过多次改变环境、置换相关关键设备观察故障现象的有无来分析判断故障产生的大致位置，排除跟故障无关的设备和环境，是为后续的数据包分析提供思路依据，提高故障分析定位效率。
4
确认故障范围
确认故障范围主要是确认故障是属于全局故障还是局部故障。
全局故障
全局故障主要指整个网络都出现故障现象，如全网中断、全网缓慢等。
全局故障一般多为核心设备处理性能不足或核心链路利用率过高导致，较为常见的原因遭受了来自内部病毒或外部的恶意攻击，一般具有较为明显的流量异常情况，我们需要在核心交换机处部署网络分析工具，捕获核心交换机或者核心链路上的数据报文，查看是否存在流量过大（BT下载、DOS攻击）、TCP会话、UDP会话数过高等异常的主机、是否存在各种攻击（ARP、蠕虫、DOS、扫描等）数据包，这些具有明显异于正常水平的流量参数可以帮助我们快速定位异常的原因类型和源头。
具体参数请大家参考《流量分析相关参数说明》一文，常见流量异常情况的分析定位请大家参考《常见流量异常分析》一文。
局部故障
局部故障主要指部分网段、部分主机、部分应用等出现故障，这些问题往往是个体现象，如VLAN2丢包严重、FTP服务登陆不上、部分地方VPN隧道建立异常等。
局部故障一般都具有一定的分析难度，我们一般需要通过数据交互的过程和数据报文的封装来判断定位。
[url=]5
[/url]确定数据报文交互路径
有一些故障，特别是业务应用的故障，客户端与服务器端在进行业务数据流交互时，中间会经过各种链路和中间设备。当客户端反馈业务应用存在故障，我们仅仅在某一个点（客户端、服务器端或者其他中间链路处）进行抓包，是无法真正反映故障真实面貌的，我们需要多点同步抓包，这样才能完整的反馈业务数据流在网络中交互的全部过程。在这个完整交互的过程中，我们通过对比分析，可以发现故障发生的位置和原因。
结合故障环境和路由情况，确认出现故障的业务系统的访问路径，需要重点了解清楚这个路径中所要经过的网关型设备，同时需要了解清楚业务访问数据流的来回路径是否一至。
[url=]6
[/url]确认故障关键点
网络数据报文在交互的过程中，其经过了客户端、客户内网、客户内网网关、外网、服务器端网关、服务器内网、服务器的各种处理，这些点都会针对交互数据报文的相关情况进行相应的处理，包括请求、检测、修改、转发、丢弃、响应等。网络数据报文交互的过程既然有这么多的点参与处理，那么当一个网络数据报文交互出现故障时，任何一个点都有可能是导致故障的原因，为了提高我们分析定位的效率，我们首先需要找出最有可能影响数据交互的关键点。
在了解清楚数据报文交互路径的情况之下，我们就可以确认可能的故障关键点了。这里面需要特别注意的是：关键点的选择，一定要跟具体的数据报文交互路径结合起来。
我们为了简化结构、突出重点，提高分析的效率，我们一般会将实际网络环境进行抽象，将其划分为由端系统和中间系统组成的网络，如下图所示：
 端系统、中间系统图示
在这个结构中，我们需要分析的关键点只有两个，那就是端系统和中间系统。
端系统关键点
客户端
首先，客户端是网络交互数据的发起者，是整个数据交互过程的起点，也是数据交互过程中的，客户端网络行为的基准点；另外，客户端也可能需要对服务器的响应数据进行相应处理并作出回应，在这些过程中，有可能存在客户端本身处理的问题导致整个数据交互过程出现问题，因此，客户端是一个非常重要的关键点。
服务器端
服务器端是服务器所有网络行为的基准点；同时，服务器端需要对客户端的请求做出相应的处理和响应，这些处理过程本身可能导致网络数据交互的故障，因此，服务器端跟客户端一样，是一个非常重要的关键点。
中间系统关键点
中间系统为各种对网络交互数据报文进行不同处理的设备，我们在做分析的时候，主要针对可能会对交互的数据进行检测、修改、丢弃等处理的网关设备，包括路由器、防火墙、流量控制设备以及各种应用层检测防护设备等。
由于这些设备的工作原理和特性以及可能存在的策略失误、性能不足等原因，其在处理交互数据包的过程中，可能存在修改、丢弃数据的行为，从而导致网络交互故障的产生，因此，中间设备也是我们分析过程中的一个关键点。
7
确定故障类型
在离故障点最近的位置抓取故障时的数据交互报文，在此主要指故障客户端主机报文和故障服务器端报文。
一般情况下，我们可以按照如下步骤确认故障的类型：
1，在故障客户端机器上，部署网络分析工具，开启抓包；
2，在故障客户端机器上，还原故障现象，也就是通过操作，让故障现象发生，然后捕获到这个故障现场的交互报文；
3，捕获到故障现场的数据报文后，停止抓包；
4，通过网络分析工具分析具体故障交互时的数据包；
5，通过分析，定位导致故障的类型。
故障类型主要分为两类，一类为端系统问题导致的故障，如服务器端处理延时、业务系统本身BUG等，此类故障主要为端系统本身问题；另一类为中间系统原因导致的故障，如中间系统较大的转发延时、中间系统策略误报过滤等导致的丢包等。如果是中间系统导致的，那么则需要结合故障环境和报文交互路径设计需要捕包的具体位置。
[url=]8
[/url]架设捕包环境
在需要做数据包捕获的位置，主要为各个故障关键点前后，主要通过交换机的端口镜像功能以及链路串接TAP等方式实现。
这些捕包环境全部部署完成后，就可以进行下一步的工作了。
[url=]9
[/url]全面测试，做数据包的捕获
1，在各个重点位置，利用网络分析工具进行同步捕包；
2，在故障客户端主机上，进行相应操作，还原故障现象；
3，故障出现后，故障客户端主机停止相应的操作，同时，停止运行各个捕包位置的网络分析工具；
4，使用简单明了的名字，保存各个捕包位置处捕获到的数据包文件。
[url=]10
[/url]深入分析，定位故障
捕获到全面的数据包之后，就可以利用关联分析法、对比分析法，确认故障发生的真正原因和位置了，关于对比分析法和关联分析法的详细说明请参考《疑难网络故障的分析方法和原理》。
[url=]11
[/url]故障解决
故障原因和位置确认了，那么解决故障就是一件很简单的事情了。如果故障原因涉及到第三方厂商的产品，则及时联系相应厂商配合解决即可。
|
发表于 2012-5-4 19:25:53
发表于 2012-5-5 00:47:23