DIY编程器网

 找回密码
 注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 1123|回复: 0
打印 上一主题 下一主题

[待整理] 利用科来网络回溯分析技术诊断网络设备异常丢包故障

[复制链接]
跳转到指定楼层
楼主
发表于 2014-10-13 10:01:55 | 只看该作者 |只看大图 回帖奖励 |倒序浏览 |阅读模式
案例背景
       
        某大型集团公司县公司信息内网PC在访问省公司业务和市公司业务时间歇性出现访问连接非常慢的情况,以及使用内网PC对省公司DNS服务器和市公司官网IP持续ping操作时出现不定时丢包现象,但县公司访问其内部服务器并无故障现象。访问连接慢严重影响信息内网的正常业务交互,尤其是营销部门对省公司收费系统服务器的请求访问。
       
        网络拓扑图,如图1:
       
       
        图1某大型企业网络拓扑图
       
        将科来网络回溯分析系统旁路接入到县公司信息内网的核心交换机上,由于故障发生的间歇性需要对县公司到市公司的主干出口流量做长时间捕获。并利用科来网络分析系统不间断的捕获市公司核心交换机与C路由器的下行接口流量。利用对比分析法,在故障发生时段,分别对两处捕获到的流量做精确分析。
       
        案例分析
       
        一、出口流量分析
       
        通过科来网络回溯分析系统对通讯流量的长时间存储,我们对故障时段的通讯流量进行故障重现。我们在县公司捕获点,对故障时段数据进行回溯。选择4分钟分析窗口(流量统计精度为1秒),未见突发流量和通讯流量为0的情况。广播与组播流量正常,TCP SYN比值属于正常范围。
       
        对该时段的网络应用进行分析,流量占用最大网络应用为:HTTP、未知TCP、HTTP Proxy,属正常业务行为。网络应用中存在CIFS扫描,但该应用的通讯数据包少,对主干链路的传输影响不大,网络安全事件不是造成丢包的原因。
       
        对县公司访问关键业务标准应用监控梳理,网络链路传输质量良好,排除链路拥塞造成丢包现象。但客户端访问10.176.X.X服务器的TCP会话中存在98次TCP重传,上行重传次数为97次。大量的TCP重传造成会话延迟确认,严重影响会话质量。TCP重传大部分发生在上行,说明丢包位置在县公司到省公司之间。
       
        二、TCP会话解码
       
        对应用请求的TCP会话进行解码以确定访问延迟的具体原因。选取故障时段,县公司信息内网PC主机10.178.x.x访问10.176.X.X的应用通讯流量,客户端10.178.x.x使用2487端口访问10.176.x.x的TCP 80端口,网络链路传输质量良好,无链路拥塞。
       
        持续向下分析,我们发现县公司捕获点TCP会话的77号数据包在271ms后对73号数据包Seq4245726722进行了重传,73号数据包已达到县公司信息内网办公核心交换机出口。而同一会话在市公司捕获点客户端10.178.x.x发送的数据包中Seq4245726722的数据包只捕获了一次,该包并未出现在Seq4245725830与Seq4245728182之间,而是间隔200多毫秒后才出现了一次,说明在市公司只捕获到了重传的数据包,客户端10.178.x.x第一次发送的Seq4245726722数据包在县公司到市公司之间被丢弃。
       
        我们对两次捕获TCP会话进行对比分析,如图2:
       
        图2捕获的两次TCP会话
       
        该TCP会话中存在大量的TCP重传,通过对两处捕包点的TCP会话对比分析,确定造成丢包位置在县公司与市公司之间某一中间件网络设备。整个TCP会话过程中客户端和服务器响应时间未见异常,结合前面对网络链路传输质量的分析,确定县公司对省市公司的业务访问出现间歇性延迟的原因是由于中间件网络设备对数据包的丢弃造成。
       
        三、故障定位
       
        根据拓扑图,县公司路由到市公司核心交换机之间需要经过3台路由器进行转发。我们对故障发生时段接入B路由器的其他区县信息内网PC访问省市公司业务系统的TCP会话进行解码分析。三次握手时间7.9ms,网络传输质量良好,未见链路拥塞。TCP会话中未见丢包重传,客户端和服务器响应正常。说明故障时段,只有该县公司信息内网出现访问丢包现象。因此,故障范围缩小为县公司→A路由器→B路由器之间。
       
        我们对县公司到B路由的各个路由接口进行逐一检查,发现A路由器与县公司连接的下行接口光模块在Input方向有大量CRC校验码错误日志。
       
        CRC循环冗余校验码错误有三种可能:
       
        1、双方网卡工作模式不同;
       
        2、链路通道信号衰减严重;
       
        3、网卡故障。
       
        我们又对县公司至A路由上行接口进行检查,光模块工作模式与对端A路由器相同,排除第一种可能。对县公司与A路由器之间的光纤通道进行衰减测试,通道正常。排除第二种可能。
       
        CRC校验码错误日志是在A路由器与县公司的下行接口的Input方向上检查到,说明县公司的路由器的上行接口在对数据包进行CRC循环冗余校验码封装时出现间歇性故障,导致A路由器下行接口在对数据包进行CRC校验码解码时发现错误。对错误CRC校验码数据包丢弃。
       
        四、故障处理
       
        将县公司到A路由器的光模块进行更换,恢复通讯一段时间后,对A路由器下行接口进行检查,CRC循环冗余校验码数值不再增加。对县公司访问省市公司业务系统的TCP会话进行解码,双方通讯交互正常。TCP会话统计信息中无重传和丢包。县公司与省市公司之间的通讯恢复正常。
       
        案例结论
       
        1、县公司到市公司之间的链路流量值不大,流量趋势不稳定,对县公司至市公司之间的业务交互的TCP会话分析后,客户端RTT值正常,服务器RTT值正常,未见链路拥塞情况;
       
        2、通过在县公司和市公司的对比抓包分析,发现业务交互的TCP会话存在严重丢包现象,经过定位分析,发现县公司边界路由器出口光模块存在CRC校验和错误;
       
        3、将县公司边界路由器出口光模块更换以后,CRC校验和错误提示不再增加,对业务交互流量分析,未见丢包现象,业务通讯恢复正常。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友 微信微信
收藏收藏 分享分享 支持支持 反对反对
您需要登录后才可以回帖 登录 | 注册

本版积分规则

小黑屋|文字版|手机版|DIY编程器网 ( 桂ICP备14005565号-1 )

GMT+8, 2025-6-29 05:52 , 耗时 0.091715 秒, 22 个查询请求 , Gzip 开启.

各位嘉宾言论仅代表个人观点,非属DIY编程器网立场。

桂公网安备 45031202000115号

DIY编程器群(超员):41210778 DIY编程器

DIY编程器群1(满员):3044634 DIY编程器1

diy编程器群2:551025008 diy编程器群2

QQ:28000622;Email:libyoufer@sina.com

本站由桂林市临桂区技兴电子商务经营部独家赞助。旨在技术交流,请自觉遵守国家法律法规,一旦发现将做封号删号处理。

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