查看: 10419|回复: 0

【案例】利用科来网络分析系统分析某学院部分内部网段访问缓慢的故障

[复制链接]
发表于 2015-8-31 14:51:55 | 显示全部楼层 |阅读模式
一、问题描述

1.用户基本网络环境描述
  某学院的网络主要分为办公网和家用网两大块,基本网络拓扑如下:

图 1

  如上图所示,整个网络环境主要是通过核心交换机连一个流控设备,然后流控设备再连到防火墙,通过防火墙上网。
  招待所的网络通过连接一台Tplink路由器做了地址转换,将所有招待所出去的主机地址都映射为一个地址:192.168.30.253。


2.故障现象描述
  招待所内的主机打开网页的速度非常慢,特别是图片多的网站,甚至访问本学院对外的web服务器也很慢,我们通过Ping测试发现Ping网站的延时只有几十毫秒,也没有严重的丢包现象。
  但是,把招待所网络全部断掉,用一台机器直接接在招待所路由上访问,打开速度正常。且此故障出现在招待所网络,办公运行正常。

二、分析方案设计
1.分析目标
  确认Internet访问慢是由于网络原因引起的还是其他原因引起的。
2.分析设备部署
  我们在招待所交换机上、学院核心交换机上部署分析设备,镜像网络流量,对访问互联网的流量进行捕获并分析。如下图:


图 2


三、分析过程

1.在招待所捕获的对外访问的数据分析
首先,我们在招待所捕获一个对学院对外web服务器访问的数据流,然后对该数据流进行详细解码分析。如下图:


图 3

TCP会话分析中,我们得到该数据流的如下信息:
a.数据流持续时间:1分17秒(即此次访问的持续时间)。
b.总字节数:57 Kbytes
从上面的数据上我们可以看到,整个的访问总字节数只有57KB,但整个时间用了1分多钟,确实是非常慢。
然后,解码分析详细的会话过程:
 1)三次握手时间
   我们发现这个数据流的三次握手时间很短,只有不到1毫秒,说明网络的时延很短。
 2)服务器响应
   通过分析服务器响应的数据包,服务器对get请求的响应为145毫秒,响应速度正常。
 3)数据传输时间
   数据传输的时间为1分17秒,传输的时间过长。
  从上面的分析我们可以发现,整个会话的时间过长全部由数据传输造成
  通过对传输过程数据包的进一步分析,我们发现在传输过程中没有出现重传、丢包的现象,但是发现服务器发送数据时有停顿现象,在整个过程中出现了9次停顿,每次停顿的时间从4秒——10秒不等,整个停顿的时间非常长,导致了传输的过程很长。

如下图所示,传输过程中还出现重复的确认和乱序的现象,说明在网络中传输出现异常。

图 4


2.在服务器端进行流量分析
  为确认服务器发送数据的停顿是服务器造成的还是网络传输造成的,我们在服务器端和核心交换机上同时捕获流量进行比对分析,来确认造成数据传输停顿的原因。

图 5

  在Server端和客户端的数据分析结果有明显的不同,客户端分析中并没有发现数据没有确认的现象,只有服务器停顿的现象,而在服务器端分析却是发出了数据包没有得到确认,所以停顿后重传,这说明网络中可能存在丢包,导致数据传输出现问题


3.查找丢包的点
  利用分析设备分段捕获,来查找造成网络丢包的点,从而定位问题点。
  我们对流量控制设备前和流量控制设备后的访问数据进行对比分析,发现互联网服务端发送的数据包在经过流控设备时有丢包现象,发生丢包后服务器会重传没有应答的数据包,然而在丢包发生时刻流控设备之后有较长一段时间没有捕获任何服务器数据包,所以我们可以判断数据包丢失是发生在流控设备上。

四、分析结论
  流控设备的丢包造成招待所对Internet访问缓慢,当招待所上网主机少时,流控设备没有丢包,访问正常,但当上网主机多时,流控设备丢包明显,导致访问极其缓慢。然而同样经过流控设备的办公网络没有这种现象。
  推断是由于招待所采用了一台路由设备进行NAT,对流控设备来讲是一个IP的访问,且流控设备的控制策略设定控制单个IP的访问流量或会话,导致招待所访问出现异常。
  我们的技术人员将招待所的NAT设置去除后,发现访问网页速度明显变快,从而排除了故障恢复正常使用。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | CSNA会员注册

本版积分规则

快速回复 返回顶部 返回列表