某用户网络问题分析报告.docx

某用户网络问题分析报告.docx

ID:61514824

大小:529.66 KB

页数:8页

时间:2021-02-09

某用户网络问题分析报告.docx_第1页
某用户网络问题分析报告.docx_第2页
某用户网络问题分析报告.docx_第3页
某用户网络问题分析报告.docx_第4页
某用户网络问题分析报告.docx_第5页
资源描述:

《某用户网络问题分析报告.docx》由会员上传分享,免费在线阅读,更多相关内容在应用文档-天天文库

1、某用户网络问题分析报告故障现象描述1.故障现象描述某公司总部业务内网IP电话系统中,一台位于办公区的IP电话管理系统主机(vSphere虚拟机)10.10.15.191需要定期与位于核心区的一台服务器(也是vSphere虚拟机)10.10.36.50通信,传递IP电话状态信息。10.10.36.50是一台WebSphere应用服务器,在应用服务器的日志中不定期会出现10.10.15.191客户端无响应导致会话超时的错误警报。2.环境描述发生问题的两台主机之间的网络逻辑结构示意图如下:发生问题的客户机与服务器的通信需要经过两道防火墙以及多台网络设备,两台防火墙均未配置内网间NAT地址翻

2、译。1.2.分析方案设计1.分析目标鉴于发生问题的两台主机间网络设备较多,初步怀疑是防火墙故障阻断了两台主机间的数据传输导致会话超时。需要通过数据包解码分析验证是否中间设备故障导致,找出问题的根源。2.分析方法3.将科来回溯分析服务器部署在核心区,同时连接服务器接入交换机与办公网汇聚交换机,将服务器接入端口与办公网上行端口的流量镜像到分析服务器。利用科来回溯分析系统7*24小时不间断捕获防火墙两端的流量,根据服务器日志产生故障警报的时间回溯当时两台主机间的通信数据包。通过两端流量分析对比,判断防火墙以及中间网络设备是否对两台主机的通信造成影响;如果中间设备没有对会话造成影响,则进一步

3、分析定位造成故障的直接原因。1.1.分析情况1.正常会话行为分析首先需要对未发生问题时段的正常会话进行解码分析,以建立两台主机间通信的行为模型。下载正常时段10.10.15.191与10.10.36.50之间IP会话的数据包,在科来网络分析模块的TCP视图中可以看到两台主机间的会话使用10.10.36.50的TCP9080服务端口,会话持续时间、通信数据包数量都不固定,如下图。从其中一个会话的交易时序图中,可以看到在正常情况下TCP三次握手之后,客户端(10.10.15.191)会首先向服务器端(10.10.36.50)POST数据,如下图。从图中还可以看出,位于防火墙两端的监控链路

4、先后都捕获到了会话双方向完全相同的数据包,说明至少在正常时段防火墙并未阻断两台主机的通信。在会话结束阶段,都是由服务器发送第一个FIN报文,客户机应答后向服务器发送FIN报文关闭会话,是标准的TCP四次握手关闭会话的过程,如下图。整个会话关闭过程时间非常短,客户机在收到服务器的FIN报文后立刻就发送了应答和FIN报文。结束阶段的报文我们也是捕获了两次,说明中间设备也未对会话关闭造成影响。不过在正常时段,我们也发现有个别会话在传输一些数据后,客户端会停止发送数据,服务端在等待30s后关闭会话的情况;而这种情况下,客户机在接收的FIN报文并作出ACK应答后会等待一段时间再发送FIN报文关

5、闭会话。服务器发送FIN报文并接收到客户机的ACK之后,如果没有立刻接收到客户端发送的FIN报文,则服务器的会话会处在半关闭状态(FIN-WAIT2状态),如果半关闭状态时间过长超过了服务器的tcp-fin-timeout,服务器就会强行终止会话并在日志中记录会话超时(tcp-fin-timeout因操作系统而异,一般不超过180秒)。在上图的会话中客户端2秒之后发送的FIN报文,因此会话正常关闭,服务器没有会话超时记录。在上述停顿的时间内,两条监控链路都没有捕获客户端的数据,说明确实是客户端没有发送数据,并非中间设备阻断了客户端数据传输。通常情况客户机如果还有数据需要发送才会暂缓发

6、送FIN报文,但从上面的情况看客户机并未再发送任何应用数据,因此怀疑停顿是由客户端应用系统问题导致的。1.异常时段会话行为分析通过服务日志记录我们调取12月27日凌晨3点左右发送问题时段的数据包,从中发现了明显有问题的会话,如下图。在三次握手建立TCP连接之后,客户机没有发送任何数据,服务器在等待124秒之后向客户机发送“RequestTimeout”,并立即发送FIN报文请求关闭会话,这正是服务器日志记录会话超时的时间。从这个会话中还能够看出客户机在接收到服务器的FIN报文后,立刻回应了ACK确认,而且两条监控链路都捕获了相关报文,说明在此时刻中间网络通路没有问题并且客户机操作系统

7、的TCP协议进程也没有问题;但是客户机回应服务器的FIN报文后并没有立即发送FIN报文关闭会话,而是在176秒后才发送RST报文终止会话,在此期间客户机也没有再使用这个会话发送任何数据(如下图),因此可以判断客户机的应用程序对这个会话的处理出现了问题。除了这个客户机完全没有发送应用数据的会话外,27日凌晨3点左右还有一些会话出现了客户机发送了一些数据后不再继续POST数据,导致服务器在30秒后发送FIN报文关闭会话,而客户机很长时间后才向服务器发送FIN报

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。