CSNA网络分析认证专家实战案例1088

第1章某地税网上申报业务系统故障分析报告1.1故障环境1.2故障现象1.3故障分析1.4分析结论及解决方法1.5总结

1.1.1网络拓扑

该故障环境大体的网络拓扑如图1-1所示。1.1故障环境

图1-1说明：

(1)网上申报服务器的地址是，经过网闸后转换为X.X.16.73。

(2)前置机的IP地址为X.X.16.56，征管服务器的IP地址为X.X.16.200。

1.1.2业务访问流程

(1)纳税人通过互联网登录网上申报服务器，提交相关纳税信息。

(2)网上申报服务器将这些纳税信息转发给前置机的同时，将相关信息写入征管服务器数据库。

(3)如果网上申报服务器与前置机的数据交互出现问题，那么网上申报服务器会将征管服务器数据库相关的信息锁死。

(1)网上申报业务系统运行时，每天总有一部分纳税人的申报表单数据无法正常上传，通过征管服务器的业务软件可以看到这些用户的申报数据处于锁死状态。

(2)在没有网闸的情况下，网上申报服务器与前置机直接通信，则故障现象消失，网上纳税系统全部恢复正常。1.2故障现象

1.3.1前期分析

(1)结合故障现象与业务流程，我们可以清晰地发现，问题应该就是出现在网上申报服务器经过网闸的地址转换后与前置机交互的过程中。

(2)当网上申报服务器不通过网闸的地址转换而是直接与前置机交互的时候，业务应用一切正常，那么很可能是网闸在进行地址转换的时候对某些数据报文作了修改，或者是网闸直接丢弃了某些业务报文导致的故障。1.3故障分析(3)网闸是最为可疑的故障关键点，我们决定在网闸前后部署网络分析系统(在此环境下，可直接在申报服务器和前置机上分别安装网络分析系统)，对网上申报业务数据交互过程分别进行抓包，如图1-2所示。

抓取数据报文后，可以为下一步的深入分析或对比分析提供原始数据。

图1-21.3.2数据包分析

(1)我们通过科来网络分析系统捕获前置机交互的数据包，一段时间后，我们在“TCP会话”视图中发现有几个TCP会话持续的时间比一般的TCP会话长很多(这是与正常情况下的业务会话持续时间作对比发现的，属于对比分析法应用方式的一种)，如图1-3所示。

(2)双击其中一个TCP会话，打开详细的数据包视图，以查看其具体交互过程，如图1-4所示。

图1-3

图1-4在图1-4的视图中我们发现，这些TCP会话中存在大量的TCP重置报文，而且第一个发送RESET报文的是网闸的IP地址。

(3)网闸为什么会突然给前置机发送RESET报文呢？我们双击打开这个RESET报文的详细解码视图，如图1-5所示。

图1-5我们发现，这个数据报文的源MAC地址并非网闸的MAC，真实的网闸MAC地址是00:40:63:EF:43:DF，而这个数据报文的源MAC地址却是00:21:5E:82:AF:86，难道是网内存在某些设备针对该业务数据进行会话劫持攻击？

(4)通过进一步的分析发现，在这个RESET报文之前，是前置机发送给网闸地址的确认报文，这个报文封装的目的MAC地址就是00:21:5E:82:AF:86，如图1-6所示。

(5)前置机为什么会在数据交互的过程中突然出现了这种状况呢？一般而言，主机是根据其ARP表项来封装要发送的数据报文的目的MAC地址的，那么，这里前置机发往网闸数据报文的目的MAC地址出现改变是否是因为前置机的ARP表项内容变化了呢？我们在前置机的DOS窗口下，使用“arp

–a”命令查看异常时的ARP表项内容，发现网闸IP对应的MAC地址的确变成了00:21:5E:82:AF:86。

(6)能够导致ARP表项更新的只可能是ARP报文，是前置机收到ARP欺骗报文导致了ARP表项的更新吗？由于前面都是针对TCP层面的数据交互来分析的，看不到ARP报文，因此我们决定在科来网络分析系统的“数据包”视图中查看交互过程的所有数据报文，如图1-7所示。

图1-6

图1-7我们发现，在网闸向前置机发送连接请求之后，前置机立即向网络中发送ARP请求，请求网闸IP对应的MAC；在网闸响应了前置机的ARP请求之后，前置机开始与网闸进行TCP三次握手交互；这时，来自MAC地址为00:21:5E:82:AF:86的ARP响应到达了前置机，前置机更新其ARP表项；在此之后，前置机在收到来自网闸的数据报文时，都会向00:21:5E:82:AF:86地址发送确认报文。

为了便于大家理解，我们将这个交互过程中网闸、前置机以及未知设备的数据交互情况和状态变化作一个图示，如图1-8所示。

图1-8通过上面的图示可以清楚地看到，导致该业务故障的原因是网络内有一台设备使用了和网闸一样的IP地址。

另外，分析前置机的状态可以知道，前置机之所以会在交互的过程中向网络内发送目的IP为网闸的ARP请求报文，是因为前置机ARP表中网闸IP的ARP表项老化了。在前置机ARP表中网闸IP的ARP表项未老化之前，网闸与前置机交互数据是正常的，而网闸与前置机的业务数据交互间隔时间是随机的(这取决于网上纳税用户登录网上申报服务器提交纳税信息的时间)，这就可以解释为什么是部分网上申报业务表单出现异常了。(7)网络内有2台设备使用了同一个IP地址，应该很容易被发现，为什么一直没有被发现呢？其实，这是因为网闸的这个IP只有网上申报业务使用，而那个未知的网络设备设置的这个IP，很可能仅仅是用来管理的，这个设备长期在线，又很少有人管理(至少信息中心的人都不知道该设备的存在)，因此不会主动向网络中发送ARP报文，不会影响到网络内其他主机和应用的正常运行。但是，它会响应其他主机对其IP地址的ARP请求。我们可以通过交换机的MAC地址表找到这个设备所在的位置。

通过上面的综合分析，我们可以得出结论：此次业务故障的原因完全跟网闸无关，是由于内网的一台MAC地址为00:21:5E:82:AF:86的设备和网闸映射的地址冲突导致的。

问题原因定位之后，我们至少可以通过以下三种方式解决该故障：

(1)由于是ARP表更新导致的，我们可以手动绑定网闸的ARP，或者修改注册表，将前置机的ARP表老化时间调大。1.4分析结论及解决方法(2)找出使用了网闸映射IP的设备，修改该设备的IP地址，或修改网上申报服务器通过网闸后映射的IP地址。

(3)还可以让该业务系统在应用层面设置一个检测模块，当发现有表单提交异常时，等待一段时间，重新向前置机提交表单。

在刚接触到这个故障时，我们以为是网闸的原因导致的，但是通过数据包分析后发现是由于网络中IP地址冲突导致的。所以在接触到故障时，不要主观地臆测故障原因，而是要通过分析的手段找到根本的原因，以便提高故障解决的效率。1.5总结第2章某公安系统机房网络丢包分析案例2.1故障描述 2.2故障重现 2.3数据分析 2.4故障结论及解决办法

近日接到某公安机关信息中心电话，反应整个公安系统传输数据丢包。虽然个别机房内网络通信正常，但是办公区域访问服务器都会丢包，导致视频会议传输不正常，严重影响了用户的正常使用。客户希望我们能到现场去分析一下问题的原因，并彻底解决故障。2.1故障描述

通过与客户沟通，本次网络故障已经持续发生数月，故障原因不明，故障现象为公安系统内部无规律丢包1%～2%，影响网络数据传输。其中，服务器之间Ping的丢包率最多，远端用户Ping服务器丢包较少，部分用户Ping上级机构不丢包。服务器区内的一台管理主机Ping多台不同网段，不同位置的IP有时会同时丢包。该网络的层次结构如图2-1所示。2.2故障重现

图2-1

由于全网都有掉线现象，我们首先抓取的数据包位置为核心交换机，判定是否由于网络阻塞、网络攻击等其他原因造成无规律掉线的情况。如图2-2所示部署网络分析系统。2.3数据分析

图2-2

图2-3由于是双向镜像，我们可以看到数据包转发的情况很正常，但是会有ICMP请求转发出去以后没有收到应答的现象，ICMP返回丢包信息。

为了进一步找到故障原因，并且由于服务器区数据包丢包较多，所以我们将抓包点下移到服务器区的汇聚交换机，其拓扑示意图如图2-4所示。

图2-4

图2-5同样地，我们发现数据包正常被转发，而直连的主机并没有应答。经过多次测试累计发现：

(1)主机144.196发送606个请求数据包，接收到595个回应数据包。

(2)交换机128.39接收598个请求数据包，发送595个回应数据包。

这两组数字证明主机144.196到交换机之间已经存在丢包现象，主机128.39与交换机之间同样存在丢包现象。为进一步确定故障点，我们在服务区内的汇聚交换机直连一台装有科来软件的笔记本，如图2-6所示。

图2-6

图2-7服务器端ICMP显示丢包时，我们停止抓取数据包，发现交换机抓包与直连的主机抓取的数据包的比例为2∶1，即如果服务器共发送101个数据包，则丢失1个数据包，交换机抓到请求包200个(双向抓包)，而新直连的主机抓取100个。说明在这个过程中交换机一直将数据包正确处理并转发，只是在数据包发送的时候，有个数据包没有发送到交换机就已经丢失了。我们进入机房查看网线物理状态，发现部分网线使用的是非屏蔽超五类双绞线，并且强电与网线同走一个线路。同时，当我们在一台服务器同时Ping多网段、多区域的主机时，经常出现同一时间多个Ping包丢失的现象。初步证明是强电传输时对信号造成干扰，最终产生无规律丢包的现象。

丢包是由于服务器区大量使用非屏蔽双绞线，并与强电布线相同导致强电干扰造成的。远端Ping服务器丢包较少是因为远端到核心线路正常，所以丢包较少；服务器Ping服务器丢包多是由于进出交换机的线路都受干扰造成的，所以丢包较多；远端Ping向上级单位不丢包是因为汇聚与核心到上联单位都是通过光纤，并且不通过服务器传送数据；Ping多主机同时丢包，是由于发送请求包时收到电磁干扰信号，交换机无法识别数据包造成丢包现象。2.4故障结论及解决办法最后客户将电缆与数据线缆分开，并采用屏蔽双绞线进行布线，全网丢包现象就没有再出现了。第3章某保险公司VPN异常中断故障分析报告3.1故障描述3.2分析过程3.3结论及建议

3.1.1故障现象

某保险公司北京总公司与各地分公司均通过双线与当地电信和联通两大互联网运营商相连，各地分公司通过IPSecVPN(即指采用IPSec协议来实现远程接入的一种VPN技术，IPSec全称为InternetProtocolSecurity)接入总公司内部网络。3.1故障描述近期由于业务量增加，对广域网的带宽需求加大，用户对总公司的联通接入线路进行了扩容，升级后总公司联通线路的承载能力得到了提高，但各地分公司通过联通网络建立的VPN隧道经常会出现短时间的中断现象。用户怀疑是新升级的联通互联网线路存在问题，或者运营商对其VPN通信进行了限制或干扰，需要通过网络协议分析查找造成中断的具体原因。3.1.2环境描述

本次分析使用科来回溯分析系统1002T，在总公司的VPN服务器(一台Juniper防火墙)外侧部署，7

×

24小时捕获并分析其VPN隧道ESP流量以及ISAKMP(InternetSecurityAssociationandKeyManagementProtocol，Internet安全连接和密钥管理协议)流量，其拓扑示意图如图3-1所示。

图3-1

3.2.1流量趋势分析

用户的技术人员通过VPN两端的防火墙日志查看到福建分公司VPN隧道于11月13日凌晨1时、下午15时和下午18时左右发生过3次短暂中断，本次分析就重点针对这3次中断进行。3.2分析过程首先，通过回溯分析系统的IP流量精细分析功能，查看发生中断的VPN对端IP地址72在11月13日下午14时30分至18时30分的流量趋势，如图3-2所示。

图3-2从4小时窗口(精度:分钟)的趋势图上我们并没有看到明显的长时间流量中断，在发生问题的15时05分和18时05分左右也没有出现流量为0的情况。于是我们进一步使用4分钟窗口(精度:秒)查看15时05分和18时05分左右的流量趋势，如图3-3所示。

图3-3从图3-4能够看出，发生中断时，有2分钟左右的时间，在总公司防火墙前端能够收到福建VPN对端的数据包，但是总公司的防火墙向对端发送的数据包很少。通过与正常时段的流量进行比对分析我们发现，在正常时段VPN两端发送的数据包量基本相当。

图3-4在福建VPN13日凌晨发生中断的时刻，以及用户提供的其他VPN隧道中断的时刻，我们也看到了相同的现象。由此我们基本可以判断：发生中断时，总公司和分公司之间的互联网链路(联通运营商网络)应该没有问题，很可能是由于一段时间内总公司防火墙没有发送数据导致VPN中断。3.2.2数据包解码分析

为了进一步分析造成VPN中断的根源，我们下载了福建VPN72在11月13日下午的全部数据包进行解码分析。

在福建分公司72与总公司1之间通信的数据包中我们看到，在发生中断的15时03分58秒，两端防火墙使用UDP500端口交互了3个报文，在此之后的1分50秒时间只看到72使用新的SPI(安全参数索引)发送ESP数据包，1没有发送任何ESP数据包，如图3-5所示。

图3-5这3个UDP500端口的报文偏移量为3C的字段值(Exchangetype类型字段)均为“0x20”，表示这三个报文是ISAKMP二阶段协商的报文，主要作用是协商新的ESPSA。从这三个报文之后72发送的ESP报文使用了新的SPI可以判断，此次二阶段协商并没有问题，福建分公司的防火墙已经使用了新的ESPSA进行后续数据加密，但总公司的防火墙并没有使用新的SA发送数据，也没有继续使用以前的SA发送数据，很可能是总公司防火墙自身的程序出现问题导致这一现象。从整个下午的数据包来看，在13时04分和14时04分也有过一次二阶段协商，但后续双方都正常使用新的SPI交互数据。由此可以推断：双方的ESPSA生存时间为1小时，双方每过一小时会进行一次二阶段协商更换ESP密钥，不过15时03分的二阶段协商之后出现了意外情况。

在图3-5中的二阶段协商完成1分51秒后，我们看到72向1发送了一个Exchangetype字段为“0x05”(ISAKMPInformation)的通知报文，然后双方又交换了3个二阶段协商报文，如图3-6所示。

图3-6不过在此次协商之后VPN两端都使用了新的SPI进行ESP数据交互，后续通信正常。我们推断很可能是福建分公司的防火墙在15时03分更新ESPSA后一直没有收到总公司的ESP数据，因此在1分50秒后通过ISAKMPinformation消息通知总公司防火墙刷新SA，而这次SA更新后总公司防火墙没有出现异常。

从上面这些情况来看，15时03分第一次协商之后，福建分公司的防火墙IPSec处理正常，后续发送的ESP数据包序列号连续，可以确定两地之间的互联网链路也没有问题。造成此次中断的直接原因是在15时03分的二阶段协商之后，总公司防火墙处理出现异常，没有正确使用新的ESPSA通信。

在18时05分左右，我们又看到了相同的现象：第一次二阶段协商后总公司防火墙不发送新的ESP数据，1分53秒后进行第二次二阶段协商，只不过第二次二阶段协商后过了48秒总公司防火墙才使用新的SA发送数据，这也正是趋势图上看到有2分40秒单向通信的原因所在，如图3-7所示。通过对比多次不同分公司VPN中断时刻的数据，我们发现每次中断的现象均一致，并且有些正常时段在双方更新SA后，总公司的防火墙也会出现短时间不发送数据的情况。如果这一现象持续时间超过1分50秒，双方就会重新开启二阶段协商，在这段时间内VPN处于中断的状态。

图3-7

3.3.1分析结论

根据上面的分析，我们可以得出以下结论：

(1)监控链路的流量趋势稳定，没有发现明显的持续丢包或链路质量异常的现象，总公司与分公司之间使用联通线路的VPN隧道短时间中断现象与运营商的网络链路无关。

3.3结 论 及 建 议(2)造成异常中断的直接原因是在周期性二阶段协商之后，总公司的防火墙可能存在Bug或异常情况，导致不能使用新的SA进行后续ESP通信。

由于这一现象是在联通线路扩容之后才出现的，我们怀疑是由于扩容后联通线路流量增大，而总公司防火墙上有上百个IPSec隧道，频繁的密钥更新增大了防火墙的负荷，导致其在刷新SA后相关进程出现延时或锁死。3.3.2建议

将捕获数据包与我们分析的结论提交给防火墙厂商，请厂商协助处理。在厂商没有彻底解决相关问题期间，可以通过配置增大各隧道IPSecSA的生存时间，这样可以降低密钥更新的频率，减少对防火墙的压力。第4章某供电局营销应用服务中断问题分析案例4.1故障描述4.2问题分析过程4.3分析结论

4.1.1故障现象

某供电局随着业务的拓展，信息水平不断提升，信息化应用越发突显其关键价值。尽管经过严格测试，各业务用户在上线后还是会遇到许多无法预测的问题。网络带宽、网元健康状况、网络策略、终端性能、用户使用习惯、服务器性能、程序设计等众多相互关联的因素，都会影响到业务的质量，任何一种环境的改变都可能造成业务质量的下降。4.1故障描述某供电局作为供电企业最关键业务应用之一的营销应用出现了多次偶发性死机现象，对该局电网业务造成极大影响。信息部门希望通过这次分析服务，排查故障期间访问过营销系统服务器的主机行为，协助对异常现象进行分析定位，并为网络与应用的运行管理提供优化依据。

下面结合科来网络产品，对该供电局信息部门的网络应用系统的故障问题进行详细分析。4.1.2网络拓扑

用户的网络环境示意图如图4-1所示。

图4-1本案例中部署科来回溯分析系统的目的是对网络进行全面的监控和分析，并不是单纯为了解决营销服务器的问题，因此采用的是核心交换全端口镜像的方式。如果单纯为解决营销服务器的问题，只需要镜像服务器区接口的双向流量就可以实现。

2013年某日下午17时00分左右，营销系统服务器无法访问。通过FTP登录到服务器，发现磁盘空间已经被两个heapdump文件占满。删除heapdump文件，重启营销weblogicserver，服务于17时20分恢复正常。4.2问题分析过程4.2.1服务器流量分析

我们获取营销服务器的访问流量并进行分析(如图4-2所示)，发现从16时48分开始流量持续下降，至17时10分流量达到最低值，接近于0。

图4-2

图4-3这段时间共有251个客户端访问了营销服务器，其中流量最大的是客服中心的两台客户端10.XXX.XXX.165和10.XXX.XXX.157，流量分别达到408.77MB和269.25MB；流量第三的是服务器10.XXX.XXX.121，达到184MB；需要注意的是，流量使用前15名的主机中，多是属于客服中心网段的客户端，大多数流量均超过100MB；大部分访问营销服务器的用户流量不会太高，在8MB左右，如图4-4所示。

图4-44.2.2客户端流量分析

故障发生期间，流量最大的客户端是10.XXX.XXX.165和10.XXX.XXX.157，我们针对其流量作了进一步的分析。

客户端10.XXX.XXX.165使用流量情况如图4-5所示。

图4-5如上图所示，在异常发生期间，客户端10.XXX.XXX.165和营销服务器10.XXX.XXX.11共产生了3591个会话，会话流量从数十KB至数百KB不等，按会话产生的流量进行排序，如图4-6所示。

图4-6流量最大的客户端通过4530端口访问服务器7001端口的会话，共产生了2665个数据报文，流量为2.259MB，对其进行解码时发现了异常情况，如图4-7所示。

图4-7如图4-7所示，该会话过程持续了25秒，会话开始客户端与营销服务器10.XXX.XXX.11建立连接后，客户端在0.017秒后发送了GET请求，请求内容为

GET/j2yd/_assembleLib/systim/fmGrid/lookAndFell/image/btn.jpg

服务器在0.001秒内进行了应答，并开始传输数据，数据内容在0.03秒内传输完毕，客户端又发起了相同的请求，如图4-8所示。

图4-8如图4-8的①处所示，对比上一次的发送时间可知，每隔0.03秒客户端会向服务器发起一个重复的GET请求，请求的对象是“btn.jpg”文件。

我们对相关的会话过程进行了排查整理，发现3591个会话过程中，有3330个会话都一直在请求该文件，剩余261个会话都是故障发生期间客户端发起的TCP连接请求。如此大量的请求数据，客户端是在做什么呢？

“jpg”是以24位颜色存储单个光栅图像的一种图片格式，同时我们发现某些客户端请求相同的文件，却并没有同样的异常行为，见图4-9。

图4-9如图4-9所示，该客户端请求相同的对象，但是仅重复了3次，会话过程没有出现前文所述的异常。

如果不了解应用特征，则很有可能找错方向。供电局负责营销应用的工程师为我们讲述了该文件的作用：从某供电局营销系统应用的角度来看，这些请求的发出，代表的是营销应用客户端模拟点击按钮的操作，我们知道请求了“btn.jpg”文件，要找到其关联的“.do”或者“.js(p)”文件。通过数据解码，如图4-10中②处所示，我们发现该请求是

referer：“1:7001/j2yd/dfScatterRecomShouldAction.do?actionType=GENSHOULD”。也就是说该动作导致了客户端发起“GET…btn.jpg”指令。

图4-10为了得到更直观的指向，我们针对所有会话进行了排查，发现在某些会话过程中(如图4-11所示)，开始期间客户端与服务器的数十次的请求应答，双方行为都较为正常可是到第33次请求的时候，客户端向服务器发送“POSTj2yd/dfScatterRecomShouldAction.do”的请求，收到服务器200OK应答后，就开始了不断地请求btn.jpg文件。

图4-11因此我们认为，这些大量的异常重复的“GET…btn.jpg”的请求，与j2yd/dfScatterRecomShouldAction.do有关。

另外，客户端10.XXX.XXX.157和10.XXX.XXX.149与服务器的会话情况分别如图4-12、图4-13所示。

图4-12

图4-13我们发现，只要“GET…btn.jpg”是referer：“http://10.XXX.XXX.11:7001/j2yd/dfScatterRecomShouldAction.do”的操作，均会出现前文所述的不断密集重复请求的异常。

大量的异常请求，很有可能导致应用系统的异常，建议管理员对该操作进行排查。

(从英文字符的意思来看，df表示电费，Scatter表示分散，Recom含义不详)4.2.3营销应用其他服务器的排查

相同的异常在营销应用的其他服务器上也有体现。如图4-14所示，某些客户端流量远高于与这台服务器相连接的两台数据库服务器10.XXX.XXX.14和10.XXX.XXX.16的流量。

图4-14这些客户端也是在向服务器大量重复请求“btn.jpg”文件，见图4-15。

图4-15

4.3.1故障说明

经过排查，定位出错的程序为“电费管理系统”的“分散复核明细查询”功能模块。4.3分析结论4.3.2优化后监测

我们在监测后期看到各客户端访问营销服务器的流量持续下降，异常流量的减少，很有可能与故障发生后系统管理员对营销应用进行了一系列的优化调整有关，如图4-16所示。

图4-16发生故障时，异常客户端的流量高于服务器10.XXX.XXX.121以及数据库服务器10.XXX.XXX.14和10.XXX.XXX.16的流量。在对后期的监测数据(3月13日)进行分析的时候，我们发现客户端的流量有了明显的减少，均低于这3台服务器的流量。前文所述的异常客户端的流量也都恢复到比较低的水平，没有再出现过这样的故障。第5章某移动公司BOSS系统故障分析5.1故障描述5.2分析过程5.3结论及建议

5.1.1故障现象

(1)

BOSS系统向服务器提交订单，每天会有600个左右不成功的订单，不成功的订单需手工录入，极大地影响工作效率，情况已持续2、3个月。

(2)持续Ping服务器和BOSS，未出现任何丢包现象。

(3)应用部门和应用厂商检查应用程序和规则后表示一切正常。5.1故障描述(4)网管人员检查网络设备的性能，设置(MTU、MSS等)一切正常。

(5)管理人员反映在BOSS系统上抓取的同步数据包大于在PIX之前抓取的数据包，怀疑有丢包，但其他应用和Ping都正常，网络丢包没有说服力。5.1.2网络拓扑

本案例中BOSS系统的网络拓扑结构如图5-1所示。

图5-1说明：

(1)

BOSS系统访问6的80端口。

(2)

BOSS系统收集营业厅的数据传给Server，BOSS既是客户端又是服务器。

(3)

6将80端口映射到97。

(4)将97负载均衡到5和6。

5.2.1捕获数据包

订单提交不成功有两种情况，一种是服务端未收到BOSS的请求，另一种则是服务端收到请求后未响应。由于客户反映在BOSS和PIX上抓包不一致，故先从这里着手，选择抓包位置，如图5-2所示。5.2分析过程

图5-25.2.2分析数据包

提取回溯系统和便携式上的数据包，进行对比分析。首先来看在6503上抓取的数据，如图5-3所示。

图5-3在6503上捕获到0和6的会话中，存在多个SYN包无响应的会话，从而证明确实存在订单提交不成功的问题，而在PIX的入口并没有捕获到该会话，也就是说服务端并未收到BOSS的应用请求，所以该现象与服务器端无关。

再来看在PIX前抓取的数据，如图5-4所示。

图5-4服务端没有收到BOSS系统的请求包，是不是因为包被丢弃了？从拓扑上看，数据经过的都是路由、交换设备，该数据包并未到达防火墙，且该链路上的其他应用一切正常。如前所说，网络丢包没有说服力，继续看数据包，看能不能找到其他线索。

查看“概要”视图，发现网络中存在大量的FIN数据包，4452个数据包就有2498个包带FIN标记，见图5-5。

图5-5过滤FIN数据包，发现绝大部分FIN数据包都是由BOSS服务器发出来的，见图5-6。

图5-6再定位到TCP会话，通过“时序图”查看会话中FIN包的情况，如图5-7所示。

图5-7通过“时序图”可以看到，在一个会话中存在多个FIN位置为1的数据包，而且未收到对端的确认，这表示该会话没有正常关闭。

网络中存在许多在一个会话中发送大量FIN+ACK置1且窗口为0的数据包的情况(我们知道，在数据传输过程中，窗口为0表示不能接受任何数据，至于关闭连接的窗口为0是否表示不能接收任何数据包还有待验证，但可以肯定这是不正常的)，且这些会话都与0有关，这就表示在0上有很多未关闭的TCP会话，这也是不正常的，需要进一步分析原因。这里先插入一些TCP连接建立和关闭的介绍，简单地说，在通信过程中，客户端和服务端的TCP状态迁移如下：

(1)客户端TCP状态迁移：

CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED

(2)服务器TCP状态迁移：

CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED

登录0后台，通过netstat查看主机的会话状态。0上存在近5000个状态为COLSE_WAIT的连接，会话处于COLSE_WAIT表示该连接还没有发FIN+ACK数据包，如图5-9所示。通常情况下，一个COLSE_WAIT会维持至少2个小时的时间，这样，随着时间的增加就会导致不能释放的会话越来越多，直到系统没有资源处理新的连接请求。

图5-8

图5-9

5.3.1分析结论

0上存在大量未释放的TCP连接，我们都知道，TCP是有队列限制的，当队列已满时，TCP将不会处理传入的SYN，也不会发RST应答，因为通常队列已满是由应用程序和操作系统繁忙造成的。这也能够解释为什么服务器端没有收到BOSS的SYN包了，实际上这些数据包是BOSS系统收到的营业厅的SYN包，但由于BOSS系统队列已满或繁忙，故对其不作处理。5.3结 论 及 建 议0在与Server关闭连接的过程中，窗口为0，可能是系统忙于处理COLSE_WAIT会话所致，从而导致BOSS与Server的通信异常。订单提交不成功的原因是BOSS系统队列已满或繁忙，没有资源对连接请求进行处理，问题出在BOSS系统。5.3.2建议

检查0与27和0的应用通信和应用程序(因为COLSE_WAIT的会话大多数与这两个IP有关，而0与Server的连接状态是正常的)，建议修改TCP_KEEPALIVE_*的相关参数。第6章某航空公司客服系统故障排查6.1故障描述6.2故障排查过程6.3解决问题建议

某航空公司华南客服中心人员用客服系统接电话时经常出现接听失败的现象，由于客服服务器位于北京数据中心，中间涉及的网络设备较多，一直未能找到故障原因。6.1故障描述6.1.1故障现象

网络拓扑结构如图6-1所示，每个客服人员桌面都会有一台电脑和电话机，一天中会出现几次偶发故障。故障发生时，用电脑上的客服软件接听用户电话失败，如果及时改用座机接听则可以成功接听。我们用科来网络回溯分析系统在华南客服中心广域网出口抓包并进行分析。

图6-16.1.2故障规律摸索

(1)客服人员可以用电脑和座机接听电话，电脑接听电话失败时，改用座机可以成功接听。

规律分析：电脑与座机是连接在同一个Hub(集线器)上，座机可以成功接听电话说明网络连接正常，需要从电脑客服软件的角度分析问题。

(2)故障发生时间段主要集中在中午午休后及凌晨时段，重置电脑的客服软件后也能恢复正常。

规律分析：这两个时间段的特点就是接听的电话数量比较少，很可能是空闲时间太长，电脑客服软件某些连接被中断了。

6.2.1排查思路

重现故障，在科来网络回溯分析系统将客服电脑与北京服务器之间的通信流量进行回溯分析，寻找故障原因。6.2故障排查过程6.2.2故障重现

在深圳客服中心寻找一台客服电脑，首先验证该客服电脑、座机都能正常接听电话，然后从16时12分开始将该客服电脑闲置；超过半个小时后，于16时48分再拨打该客户座机，接听失败，故障成功重现。6.2.3IP会话分析

客服电脑的IP为1，与北京的两台服务器有通信流量，如图6-2所示。这两台服务器的IP分别是1(经确认为客服软件界面的服务器)和55(经确认是客服软件控制插件的服务器)。

图6-26.2.4软件界面连接分析

从客服电脑1与服务器1通信的TCP时序图可以看到，两者采用了长连接的机制，在空闲的时间段，客户端每隔几秒钟就会发送一个GET的请求以与服务器保持连接，如图6-3所示。

图6-3从16时12分至16时48分，每隔6分钟客户端与服务器就更新一次TCP连接，未曾中断过，因此软件界面一直能够正常显示，见图6-4。

图6-46.2.5控制插件连接分析

客服电脑1与服务器55在16时12分至16时48分这段时间只有3对TCP连接一直保持，如图6-5所示。如果这3对TCP连接没有采用长连接的传输机制，很可能会因为空闲太长时间而被网络中的防火墙等设备中断连接。

图6-5果然，客户端在空闲2090秒(34分钟)的时间内没有发送任何保持连接的数据包，等到客服电脑重新发起接听电话请求的时候，客户端的请求已经无法到达服务器端，一直在发起重传的请求，最后客服人员看到请求超时的告警提示，如图6-6所示。

图6-66.2.6故障原因分析

大部分防火墙都会将空闲时间超过30分钟的TCP连接断开，而控制进程在空闲的34分钟内没有采用长连接机制保持连接，所以被防火墙中断了，再有电话接入的时候便会出现接听失败的现象。

(1)修改防火墙的策略：增长访问北京55的TCP连接的空闲时间。该策略实施后，偶发故障出现的次数明显下降。

(2)优化客服控制插件程序设置，从根本上解决问题。6.3解决问题建议第7章同一网段部分电脑无法Ping通网关故障分析7.1故障描述7.2分析方案设计7.3分析情况7.4分析结论

7.1.1故障现象

某供电局一个下属的客服中心有几十台电脑，在每天上班期间出现部分电脑一直无法Ping通网关的问题，致使客服中心人员无法正常收费及办公。7.1故障描述在故障发生时，故障电脑ARP表中网关MAC地址显示为全0的无效地址，管理员通过ARP防火墙、安全设备分析等排除了ARP欺骗病毒及链路故障等问题，经过近三四天的查找一直找不到故障原因。7.1.2基本环境

用户基本网络拓扑如图7-1所示，客服中心有两个VLAN都接到HP5308交换机上，HP5308只做二层数据转发，网关在分局办公楼的交换机上，中间通过光端机将双绞线转换为光纤进行连接。

图7-1管理员自己采取了以下方式尝试解决问题，但都没有效果：

(1)通过对广播包的检查发现部分电脑ARP包数量较多，尝试断开发包较多的主机。

(2)检查无法Ping通网关主机的防毒软件信息，病毒码正常，病毒日志中未发现异常。

(3)在无法Ping通网关的主机上安装ARP防火墙，未发现有ARP欺骗。

(4)管理员发现，在无法Ping通网关时，主机与局域网内的其他电脑可以Ping通。

7.2.1分析目标

借助网络协议分析工具，跟踪数据包走向，明确一个目标：对比正常电脑与异常电脑通信数据包并找出异同。

7.2.2分析设备部署

在分局办公楼及客服中心交换机上进行抓包，查看数据包走向，如图7-2所示。7.2分析方案设计

图7-2

(1)故障电脑可以Ping通局域网电脑，说明故障机本身协议及物理连接正常。

(2)故障主机无规律性，可以排除安全设备策略方面的原因。

(3)在主机上绑定网关MAC地址仍无法通信，可以确定网络中无ARP欺骗病毒，问题应该出在接入交换机到网关之间。7.3分析情况7.3.1客服中心抓包情况

在客服中心，IP为2(MAC:00:16:35:A3:32:8B)的电脑可以正常通信，IP为(MAC:00:16:35:A3:32:11)的电脑无法正常通信。对以上电脑通信进行分析。

从图7-3可以看到，能正常通信的主机(MAC:00:16:35:A3:32:8B)有ARP请求数据包到达客服中心汇聚交换机，并且也收到网关的回应数据包。

图7-3无法正常通信的主机(MAC:

00:16:35:A3:32:11)同样也有ARP请求数据包到达客服中心汇聚交换机，但无任何回应数据包，如图7-4所示。

图7-47.3.2分局办公楼抓包情况

IP为4(MAC:78:AC:C0:BB:6C:67)的电脑可正常通信，而IP为(00:16:35:A3:32:11)和11(MAC：78:AC:C0:B1:BD:A9)的电脑无法正常通信，对以上电脑通信进行分析。

如图7-5所示，可正常通信的电脑(MAC:78:AC:C0:BB:6C:67)有ARP请求包到达分局办公楼交换机，且有网关回应。

图7-5IP为(MAC：00:16:35:A3:32:11)和11(MAC：78:AC:C0:B1:BD:A9)的电脑通信，在分局办公楼的交换机数据包中查找均无法发现它们，见图7-6和7-7。

图7-6

图7-7客服中心交换机转发了相应的数据包，而网关并未收到该数据包，因此故障点定位在两台光端机上，如图7-8所示。

图7-8

将分析报告提交给光端机厂商，厂商派工程师到现场检查，发现是由于客服中心MAC地址数量超过了光端机默认允许通过的最大值，修改两台光端机相关设定后问题得以解决。7.4分析结论第8章网络环路分析8.1故障描述 8.2分析过程8.3分析结果8.4紧急处理办法及优化建议

某公司网络全部为内部网络，不与Internet连接，出口防火墙上联集团内网，下联核心交换机，核心交换机下联下属单位防火墙，如图8-1所示。8.1故障描述

图8-1前一段时间每天上午8～10时左右，网络及应用不定时访问缓慢，内网用户PingDMZ区(中文称隔离区)服务器时会产生大量丢包现象，甚至无法正常提供服务，严重地影响了正常的工作。经过一段时间的排查，并没有发现网络及应用产生故障的原因。

通过在网络中部署科来网络回溯分析系统，对之前发生的问题进行长时间的回溯分析，定位到故障发生的时段，来重现故障当时的情景，以便帮助我们找到产生问题的根本原因，进而解决问题。图8-2和图8-3为发生异常的3小时内流量趋势与概要视图，对网络总流量及进出流量作出统计，峰值达到了682.35Mbps，带宽利用率达到70%左右，瞬时的利用率甚至更高。当前测试网络已经达到非常高的网络利用率，这就可能会造成大量的数据包丢失。

图8-2

图8-3

8.2.1详细分析

针对网络应用进行分析，发现这3小时的数据中未知的UDP应用流量占用了总流量的99%以上，如图8-4所示。8.2分析过程

图8-4通过对未知UDP应用的深入挖掘分析，可以发现大量UDP2425端口的单方向通信，参见图8-5。

图8-5所以，基本上我们可以确定，网络中产生大数据量传输导致网络访问速度慢的原因就是内网中这些使用UDP2425端口进行通信的数据占用了网络的大量带宽，造成网络中产生很多丢包现象。

查阅资料和UDP会话分析发现，飞秋软件使用的正是UDP2425端口。飞秋(FeiQ)是一款局域网聊天传送文件的绿色软件，它参考了飞鸽传书(IPMSG)和QQ，完全兼容飞鸽传书(IPMSG)协议。再查找占用带宽较大的IP，基本上所有大流量传输的IP地址均为该公司下属单位网段的IP地址。8.2.2网络环路分析

我们下载其中两台主机传输的数据包并进行精细的解码分析，发现数据中存在大量IP端口相同并且具有相同的IP标识位的数据包，这就证明了这两台主机之间传输的数据包为同一个数据包，如图8-6所示。

图8-6再来定位到数据包中的TTL字段，发现该字段数值呈现逐步递减的趋势，每个数据包TTL值减2，如图8-7所示。这就说明了这个数据包在传输的过程中经过了2个三层设备的处理后又回到了核心交换机与防火墙上联的接口，被再次捕获。

图8-7经过确认，在防火墙上发现一条为/16指向核心交换机的路由，这就造成下属公司网段中发往/16网段的数据包，由于在核心交换机没有精确匹配的路由，所以通过核心交换机的默认路由指向防火墙，而经过防火墙后被防火墙的/16路由指回核心交换机，形成了路由环路。

通过对内网的整体流量分析，发现大量未知UDP2425流量，占用总带宽的99%，导致其他网络访问缓慢。经过下载分析发现是由于路由环路导致，具体是下属公司的网段到总部的一些网段之间路由配置存在问题，产生路由环路，造成了核心交换机和防火墙之间传输大量数据，阻塞链路带宽，造成网络传输效率降低，产生网络问题。8.3分析结果

通过联系下属公司网络管理员，禁止了下属公司的防火墙到核心交换机的UDP2425的流量，之后网络流量恢复正常，故障现象基本消失，网络恢复正常。8.4紧急处理办法及优化建议针对本次流量异常情况，我们建议修改防火墙上的路由配置，精细路由条目，进行整理规划，或禁止UDP2425的流量。类似的路由环路可以通过“黑洞路由”的方式避免，在上级路由器使用汇总路由，而下级路由器配置缺省路由。同时，在汇总的网段中有部分子网未使用的情况下，最好在下级设备中额外配置一条静态路由，将汇总的大网段指向空接口。例如，上级设备(防火墙)配置/16指向下级核心交换机，下级核心交换机则配置/16指向“null0”接口(针对Cisco路由器)。由于路由转发遵循精确匹配原则，这样配置不会影响下级路由器已配置的子网访问，只是将目标地址为未配置的子网主机的数据包丢弃，避免环路发生。第9章某运营商客户系统访问故障分析9.1故障描述9.2故障分析9.3分析结论与建议

9.1.1故障环境

如图9-1所示，客户端通过IP71访问客服Web，F5-1的IP为69，F5-2的IP为70，F5-1和F5-2通过自身的IP与客服Web(IP：10.191.121.X)通信，F5转发客户端的请求，然后再将响应转发给客户端。9.1故障描述

图9-19.1.2故障现象

(1)客户端通过71访问Web服务器，会出现“Error404--NotFound”提示，如图9-2所示。

(2)客户端直接访问客服Web的IP则不会出现问题，怀疑F5转发存在问题，需要找到数据进行验证。

图9-2

9.2.1分析思路

本故障中出现“404--NotFound”错误的原因有两个：

(1)客户发起的请求不存在。

(2)

F5转发客户端的请求存在问题。

原因一的分析确认方法：提取“404--NotFound”会话中的客户端请求，直接访问可以确定客户的请求是否有效。经验证，出现“404--NotFound”提示的请求直接可以访问，从而排除了第一个原因。9.2故障分析原因二的分析确认方法：将客户端的请求与F5转发的请求进行对比分析，确定F5的转发是否存在问题。这也是这次分析的重点。9.2.2前期分析准备

(1)通过客户反馈，找出错误提示的会话，提取关键字。

(2)经过与用户确认，每个出错页面的CONTENT为“WebLogicServer”，如图9-3所示。

(3)数据流信息包括客户端IP、SessionID等关键字。

(4)提取正常访问数据，为对比分析作准备。

客户端与F5正常的通信数据如图9-4所示。图9-3

图9-4客户端的请求里包括详细的GET请求、客户端IP、sna_cookie和login_cookie等信息。

F5与服务器的正常通信数据如图9-5所示。

图9-5F5(IP:0)发起请求，包含的信息与客户端发出的请求信息一致。9.2.3分析过程

由于需要完整抓取客户端到F5和F5到客服Web的所有数据，而且该现象不定期出现，所以镜像F5端口，并部署科来网络回溯分析系统进行数据采集(如图9-6所示)，等问题重现后提取数据包分析。

图9-61．客户端与F5的通信数据分析

客户端(IP：10)发起GET请求，请求数据大小为1.601KB，内容包括客户端IP、sna_cookie和login_cookie等信息，

服务器71响应

“Error404--NotFound”，客户端的端口为1359，见图9-7。

图9-7

再看客户端与F5的数据流信息验证，如图9-8所示。

图9-8

客户端的请求里包括详细的GET请求、客户端IP、sna_cookie和login_cookie等信息，且服务器的错误响应包含CONTENT=“WebLogicServer”。

图9-92．F5与服务器的通信分析

提取F5与服务器的通信，设置高级过滤器(请求里的cookie有客户端的IP信息，数据流包括WebLogicServer，还可以通过SessionID等)，如图9-9和图9-10所示。

F5(IP：0)发起请求，请求数据大小为826B，小于客户端的请求数据(未见GET请求)，服务器2响应“Error--404NotFound”，F5的端口为1359，与客户端的端口一样。与客户端的请求综合对比分析可知，F5与服务器端通信的请求不完整，未见sna_cookie信息，但通过login_cookie、客户端IP、SessionID等信息可以确定这是与客户端请求F5的同一会话，且服务器的错误响应包含CONTENT=“WebLogicServer”，见图9-11。

图9-10

图9-11

F5转发的请求与客户端的发出的请求不一致，导致客户端访问客服Web出现“Error404--NotFound”提示，该问题与客户端和服务器无关，应该是F5的转发存在Bug。9.3分析结论与建议第10章某应用间歇性无法访问故障分析10.1故障描述10.2分析内容10.3分析总结

10.1.1故障现象及环境

用户内部新上线一台应用服务器，上线后出现访问缓慢，有时可以登录，有时无法登录的情况。产品为B/S架构，二层结构，不涉及中间件。根据网络拓扑得知，客户端访问服务器要经过防火墙，网关设在防火墙上，防火墙连接交换机有Trunk，详情见拓扑图10-1。10.1故障描述

图10-1故障原因预测：

(1)首先怀疑是应用系统本身的问题，因为同样的部署，其他系统没有类似问题。涉及应用交互分析。

(2)还有可能是链路丢包，客户端访问服务器经过的链路涉及交换机和防火墙。可能涉及多点抓包。

因此，客户需要借助科来网络回溯分析系统进行分析。10.1.2检测描述

监测系统：科来网络回溯分析系统3.1。

样本文件：Colasoft.pkt。

采样时间：2012年12月29日。

采样时长：7

×

24小时。

样本说明：防火墙前Trunk链路抓包。

10.2.1分析过程

(1)首先，使用链路测试法分析。在一个客户端Ping服务器，结果显示正常，但是Telnet服务器的应用端口异常，有时无法建立连接。由链路测试法分析可知，客户端Ping服务器没有问题，但Telnet有问题。说明问题是发生在网络层之上，属于策略性问题。因为三层以下设备出问题，一般都是没有策略性的，丢包都是随机的，无法选择上层应用，具体表现为Ping的时候会出现丢包。10.2分析内容(2)客户端和服务器连接同一交换机，访问正常，说明单纯的应用层面是没有问题的。

(3)数据包分析。由于环境比较简单，而且很有可能是由于链路异常造成的访问异常。整个访问过程经历了3个设备：接入交换机、核心交换机和防火墙。首先选择抓包位置，判断是否需要多点抓包。按常理来说，应该是多点抓包分析判定故障点。但是通过观察发现，由于防火墙和核心交换机之间有Trunk协议，且位于中间位置，只要在防火墙和核心交换机之间抓包，一个TCP连接只要抓到2次相同数据，就说明链路没有问题；如果一个TCP连接我们只能抓到一次数据，那就说明是防火墙的问题。通过客户端4做测试，访问服务器1，下面是具体数据分析过程。如图10-2所示，正常登录时整个TCP三次握手每一步都有重传，为了证明是被重复抓到，而不是TCP重传，只要看数据包的Identification即可。因为如果是TCP重传的话，IP标识是会变的。

图10-2从图10-3可以发现，每一次交互的身份标识是不变的，说明访问数据被重复抓到了2次，这个时候链路是没有问题的。

不正常登录时，我们只抓到了TCP的3个SYN包，如图10-4所示。

这是典型的TCP三次握手阶段的重传，间隔3秒和6秒重传两次SYN包。为了再次确认，可以看一下身份标识，见图10-5。

图10-3

图10-4

图10-5我们可以发现，序列号相同的数据包，IP标识Idetifacation字段是变化的，说明是TCP重传；访问数据只被抓到一次，访问数据过了防火墙就被丢弃，否则即便是TCP重传也应该是被抓到2次。10.2.2分析结果

通过以上的分析步骤，我们可以得出结论：数据在经过防火墙时，发生了丢失的现象有可能是防火墙策略的问题造成的。10.2.3处理方法

根据以上分析结果，我们只要找到防火墙是否有相关的策略限制，修改相应的策略即可排除故障。可以采取以下两个措施解决问题：

(1)仔细查看防火墙的策略，是否有针对服务器IP或端口的限制。

(2)如果防火墙策略没有发现问题，可以考虑让访问路径绕过防火墙。

通过本次故障分析我们发现，抓包的位置选择至关重要，选择好的抓包点可以避免多点抓包的苦恼，节省时间。同时，通过科来网络回溯分析系统可以快速定位、分析、解决网络故障，大大提高工作效率。10.3分析总结第11章防火墙策略导致服务器访问异常分析11.1故障描述11.2故障分析11.3测试总结

11.1.1测试描述

测试软件：科来网络分析系统2010。

测试部署：该公司核心交换机的服务器端口。11.1故障描述11.1.2故障现象

1.外网用户不能访问业务服务器

该单位网络是双链路出口，在边界防火墙上有两条链路，一条是网通，一条是电信。正常情况下，电信和网通的用户从外部访问内网服务器时都是通过电信链路，但是数据回去时在防火墙上有策略，电信的选择电信的出口回去，网通的选择网通的出口回去。但是三天前突然出现了异常情况，电信的外网用户部分能成功地访问，但是网通的外网用户都访问不了。网管人员初步判断是路由策略的问题，但这只是凭着日常的经验判断的。因为单位网络数据的高度敏感性和必要的稳定性，不能仅凭借经验就妄动现有的网络配置，所以我们用科来软件来具体地分析。2.网络拓扑环境描述

管理员一直尝试通过Ping和Tracert(跟踪路由)命令来观察网络中的一些故障点，这种传统的判断方法在处理日常的问题时的确很有效，但是它只能大概判断问题可能出在哪里，当故障比较隐蔽、层次比较深时它们就无能为力了。图11-1所示为该公司网络拓扑结构和部署的科来分析点。

图11-1

借助科来网络分析软件，我们在图11-1所示的两个位置同时抓包，让一个外网的网通用户访问内网的服务器，在分析点1我们看到如图11-2所示结果。11.2故障分析

图11-238是访问内网服务器的客户端IP，在分析点1我们发现只有请求的数据，没有返回的数据。查看TCP连接的时序图，如图11-3所示。

图11-3通过时序图我们看到，网络中只有SYN请求包，没有服务器给客户端的回应包，连接没有建立起来。因为是在两个点同时抓的包，在分析点2会话的时序图如图11-4所示。

图11-4因为经过防火墙会有一些地址转换，所以看到的是1和5的交互，5是服务器的内网地址。点开一个会话可看到两者之间建立了正常的连接，说明在防火墙到服务器的这一段是正常的，可排除是服务器的故障。

如图11-5所示，黑色的箭头线表示成功地建立了连接，白色的箭头线表示在这一段没能建立起连接。

图11-5再结合我们测试客户端发来的Tracert的截图(如图11-6所示)，能够确定故障点就在防火墙上。

图11-6

(1)如果通过常规的方法判断，我们只能估计哪个点出现故障的概率比较大，然后着重检查这些点。现在通过科来软件，我们轻而易举地就能判断出问题是出现在防火墙上，而且我们并不是通过经验判断问题，而是通过网络中实际传输的数据包的数据来定位问题。步骤很简单，精准度却很高。11.3测试总结(2)管理员请来防火墙厂家的技术人员，双方确定了故障点之后，着重查看了防火墙的配置情况，结果发现就是防火墙的一些策略出了问题。通过修改策略，问题很快得以解决，网络恢复正常。第12章某单位部分用户Web无法正常访问故障分析12.1故障描述12.2分析过程12.3总结

12.1.1网络环境

该单位网络结构如图12-1所示。12.1故障描述

图12-1从结构图上可以看出，用户在进行互联网Web访问时，除经过接入层交换机和核心交换机外，中间还经过了一个流控设备和一个防火墙。12.1.2故障现象

部分用户在进行互联网访问时，可以正常打开2、3个页面，之后再也无法正常打开其他Web页面，而这些用户在访问单位内部网页时，速度却很快，访问也都很正常。

12.2.1故障点分析

用户在访问互联网Web页面时，数据包只经过了交换机、流控和防火墙。由于用户在访问单位内部网页时都很正常，并且交换机并未对这些用户进行策略上的限制，只是进行单纯的数据转发。因此，我们定位出以下几个可疑故障点，见图12-2。12.2分析过程

图12-212.2.2分析设备部署

根据故障现象，我们定位了流控设备和防火墙这两个可疑故障点。首先跳过流控设备，使核心交换机和防火墙直接相连。此时，我们让那些故障用户进行互联网Web页面的访问，发现问题依旧存在。那么我们得出结论：故障问题与流控设备无关。由于防火墙工作在路由模式下，我们无法将其透明过去，只能通过抓取数据包的方式来确定故障产生的原因。所以，开启防火墙的抓包功能，并在防火墙后端利用科来网络分析系统抓取通信的数据包，如图12-3所示。

图12-312.2.3数据包分析

故障用户访问互联网时，我们进行数据包的抓取，图12-4所示是在防火墙后端抓取的数据包。

图12-4从图12-4可以看出，用户在访问Web页面时，主机向外网地址发送了TCP的SYN同步请求，但是没有收到外网地址对主机的SYN/ACK回应数据包，TCP会话的三次握手都没有建立成功，这导致了页面无法打开的故障现象。

图12-5是防火墙本身抓取的数据包。

图12-5通过防火墙本身抓取的数据包我们同样可以看出，防火墙能收到内网主机访问外网的TCPSYN同步请求数据包(图中S代表SYN数据包)，但同样没有收到SYN/ACK的回应数据包，TCP三次握手没有建立成功。12.2.4分析结论

通过上面的分析，我们可以得出：故障是由防火墙引起的，它丢掉了所有外网地址对内网主机的回应数据包。这一现象可能是防火墙的性能或者配置不当引起的。

通过数据包的分析，发现故障问题的产生是由防火墙引起的。通过与防火墙厂商配合，最终解决了这一问题，图12-6所示是问题解决后在防火墙上抓取的数据包。12.3总结

图12-6第13章内外网核心对接故障分析报告13.1故障描述13.2分析方案设计13.3分析情况13.4分析结论

13.1.1故障现象

内、外网核心交换机设备对接时启用Trunk(802.1q)链路，VLAN1为网络管理，VLAN2和VLAN3为正常业务。内、外网核心交换机通过配置后，检查Trunk链路协商，工作正常(见图13-1)，但VLAN1管理通信异常，其他VLAN正常(见图13-2)。此故障严重影响内、外网正常的网络运行维护工作。13.1故障描述

图13-1

图13-213.1.2基本环境

该单位计算机网络由内网系统、外网系统两部分组成，内网只负责原内部审计系统的资质审批、上报、核准等重要业务。随着此业务不断发展壮大，现有的内网系统已不能适应新的业务模式，于是将此审计系统全部迁移到新建机房系统，原内网系统将用于普通办公使用。为了节省资金，内网系统访问互联网借用外网系统的互联网链路。

设计拓扑结构见图13-3。

图13-3

13.2.1分析目标

确定内、外网VLAN1通信异常的根本原因，并对其调整使通信恢复正常。13.2分析方案设计13.2.2分析设备部署

为了能及时、准确地分析定位故障原因，现将科来分析系统部署到Trunk链路中，对流经的数据包进行详细分析，如图13-4所示。

图13-4

13.3.1内网核心

在内网核心交换机(CiscoIOS)设备测试到外网核心交换机地址的抓包结果如图13-5所示。13.3分析情况

图13-513.3.2外网核心

在外网核心交换机(CiscoCatOS)测试Ping内网地址，抓包结果如图13-6所示。

图13-6此处的VLANID：256实际上就是VLAN1，发现CatOS设备在对NativeVLAN穿越Trunk链路时是打了标记的。

通过对内、外网核心交换机针对NativeVLAN不同处理结果的分析，发现导致此次故障的根本原因为CiscoIOS和CatOS不同处理机制。经过查找相关技术文档资料，将CiscoIOS也调整为NativeVLAN打标后该故障顺利解决。13.4分析结论第14章某集团LIMS服务器访问ERP系统故障分析14.1故障描述14.2具体分析14.3推荐解决方法

14.1.1故障现象

某集团LIMS(LaboratoryInformationManagementSystem，实验室信息管理系统)从2008年11月1日正式接入网络，开始对ERP(EnterpriseResourcePlanning，企业资源计划)系统进行访问。同时，集团内部还有很多用户对ERP系统进行访问。14.1故障描述从2009年1年5日开始，ERP系统时常出现访问速度慢、业务瘫痪甚至ERP系统死机的情况。集团网络管理人员分析后发现，当LIMS系统断开与ERP系统的链路时，ERP系统一切正常。

继续分析后发现，在LIMS系统与ERP链路相连的时候，如果LIMS系统使用手动模式，ERP工作正常，但使用自动模式(每5分钟一次查询)，即会出现故障，导致ERP系统不能正常工作。LIMS系统开发商表示，自动和手动工作模式，在工作时没有任何区别。

对LIMS系统进行了彻底的安全检查、病毒木马查杀，均未发现任何异常。对ERP系统进行了彻底的检查，也一切正常。14.1.2网络拓扑

LIMS访问ERP系统的拓扑如图14-1所示。从图中可知，LIMS访问ERP的链路非常简单，具体是LIMS服务器→接入交换机→核心C6509E→数据中心C6509E→ERP系统。

图14-1

14.2.1捕获数据包

通过上述分析，明确了该故障属于应用故障，而不是网络故障。由于已对该应用的两端(LIMS和ERP)进行过彻底检查，故在此情况下，我们捕获并分析了该应用的原始数据包。捕获数据包的位置是在LIMS服务器和接入交换机之间串接一个HUB，然后将捕获数据包的笔记本接入到HUB上，如图14-2所示。14.2具体分析

图14-2从捕获的数据包可知，不管是手动模式还是自动模式，LIMS对ERP每进行1次访问，均会创建3个连接，其中前2个是LIMS从ERP下载数据，第3个是LIMS上传数据到ERP，第3个与第2个连接之间相隔约105秒(此时间应该是LIMS检查本地是否存在更新)。

自动模式下首先进行的是LIMS从ERP下载数据，然后是LIMS上传数据到ERP。手动模式下可自由选择顺序(测试时两种顺序都进行了测试，下面的分析选择和自动模式一样的顺序，即先从ERP下载，再上传到ERP)。14.2.2LIMS访问ERP的RFC函数及模块

通过科来的TCP数据流重组可以知道，自动和手动两种模式下，LIMS调用SAP的RFC函数只有极少数存在差异，具体如下：

1．自动模式

LIMS从ERP下载数据，此过程包括2个连接。

(1)第1个连接调用SAP函数及模块的顺序如下：

RFCPING

RFC_SYSTEM_INFORFC_SYSTEM_INFO

RFC_GET_FUNCTION_INTERFACE

RFC_GET_UNICODE_STRUCTURE

RFC_SYSTEM_INFO

RFC_GET_UNICODE_STRUCTURE

RFC_SYSTEM_INFO

RFC_GET_FUNCTION_INTERFACE

RFC_GET_UNICODE_STRUCTURE

RFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTURE

IRF_SEND_INSP_REQUIRMENTS

(注：连续调用此函数若干次)

(2)第2个连接调用SAP函数及模块的顺序如下：

RFCPING

RFC_SYSTEM_INFO

RFC_SYSTEM_INFORFC_GET_FUNCTION_INTERFACE

RFC_GET_UNICODE_STRUCTURE

RFC_SYSTEM_INFO

RFC_GET_UNICODE_STRUCTURE

RFC_SYSTEM_INFO

RFC_GET_FUNCTION_INTERFACE

RFC_GET_UNICODE_STRUCTURE

RFC_SYSTEM_INFORFC_GET_UNICODE_STRUCTURE

RFC_SYSTEM_INFO

RFC_GET_UNICODE_STRUCTURE

RFC_SYSTEM_INFO

RFC_GET_UNICODE_STRUCTURE

RFC_SYSTEM_INFO

RFC_GET_UNICODE_STRUCTURE

QIRF_SEND_REQUIRMENTS_GET_DATA

(3)

LIMS上传数据到ERP，调用SAP函数及模块的顺序如下：RFCPING

RFC_SYSTEM_INFO

RFC_SYSTEM_INFO

RFC_GET_FUNCTION_INTERFACE

RFC_GET_UNICODE_STRUCTU