某银行自助业务不能登录的故障解决分析案例-csna网络分析专家案例

某银行自助业务不能登录的故障解决分析案例CSNA网络分析专家案例分析报告

© 2001-2014科来版权所有

http://www.77cn.com.cn

目 录

1．故障描述 ............................................................................................................................................................ 2

1.1 某分行自助业务不能登录故障 ............................................................................................................. 2

1.1.1故障描述 ........................................................................................................................................ 2 1.1.2故障区域网络拓扑 ....................................................................................................................... 2 1.2 某分行ATM取款机交易失败故障 ...................................................................................................... 2

1.2.1故障描述 ........................................................................................................................................ 2 1.2.2 故障区域网络拓扑 ...................................................................................................................... 3

2．故障分析 ............................................................................................................................................................ 3

2.1某分行自助业务不能登录故障分析 ...................................................................................................... 3

2.1.1 客户端处分析 .............................................................................................................................. 4 2.1.2 3845R路由器抓包分析 .......................................................................................................... 12 2.1.3 客户端直接接入3560 ............................................................................................................ 17 2.1.4 3560处镜像抓包 ..................................................................................................................... 19 2.1.5 ping包测试 ............................................................................................................................... 22 2.1.6 总结 ............................................................................................................................................ 23 2.2某分行ATM取款机交易失败故障分析 ............................................................................................ 23

2.2.1故障原因定位 ............................................................................................................................ 24 2.2.2市分行广域网链路ATM数据抓取 ........................................................................................ 26 2.2.3核心交换两侧、广域网链路出口处抓包对比分析 .............................................................. 27 2.2.3总结 ............................................................................................................................................. 31

1．故障描述

1.1 某分行自助业务不能登录故障 1.1.1故障描述

某分行自助业务系统上线测试中发现系统登录时多次出现失败，故障表现为在系统初始化连接服务器的时候无法连上，10次连接中有9次都连接不上。

客户和电信网络人员联合排查了一个月均未能准确定位故障根源，业务系统测试又要尽快完成…

1.1.2故障区域网络拓扑

发生故障的网络拓扑结构：

Cisco 3845R

Cisco 6506

WEB Server

Cisco

3560

电信

MPLS VPN

Port Chanel

客户端接入路由

客户端

1.2 某分行ATM取款机交易失败故障 1.2.1故障描述

某分行的ATM取款机不定时会出现存取款交易失败情况，失败返回错误代码是：LOC-TF

，据其开发人员反应是网络传输失败。但是由于客户缺少相应的分析工具，致使该问题持续了数月之久。

1.2.2 故障区域网络拓扑

2．故障分析

2.1某分行自助业务不能登录故障分析

分析思路：

1. 在客户端处捕获正常业务报文和故障时间业务报文对比分析异同

2. 在该支行内部网络的3845R两侧抓取报文分析（银行人员怀疑该路由器有问题） 3. 如果2

步骤没有异常，将客户端接入点更改到连接电信

VPN网络的3560上，测试业务同

时抓包分析

4. 如果3步骤业务正常，那么在3560处镜像电信VPN接口，同时也在客户端抓包分析；如

果业务不正常那么再在该行内部网络设备上排查问题。

2.1.1 客户端处分析

抓包点选取：

1. 正常业务数据包抓取分析

在抓取正常的业务报文时我们发现，该业务的客户端请求一共有两个：

GET /branchweb/index.html HTTP/1.1

GET /branchweb/script/jquery-1.6.4.js HTTP/1.1

那么我们看正常情况下，Get Html文件的情况：

科来官网 http://www.77cn.com.cn

5/ 31

一共大概有130个交互数据包，交易耗时27s左右，数据流传输完整。

再看get js 文件的情况：

科来官网 http://www.77cn.com.cn

7/ 31

同样可以看出，文件传输正常，整个交易耗时10s。 2、故障时间业务数据包分析 先看

Get Html

文件的情况：

科来官网 http://www.77cn.com.cn

9/ 31

可以看出，出现了大量重传数据包，由于个别数据传输不过来，客户端在478s后主动释放了连接，导致交易失败，整个交易时间耗时534s。 再看

get js

文件的情况：

和get html文件的情况类似，出现了大量重传，在超时后客户端主动释放了连接。整个交易耗时534s。

由以上正常和异常交易情况对比，我们可以看出：

造成交易失败的原因是在交易过程中部分数据包一直没有传输到客户端，导致客户端在超时时间到达

后主动释放了连接。

怀疑在网络中部分节点有丢包现象。

2.1.2 3845R路由器抓包分析

该行人员一直怀疑3845有问题，为了排除疑问，我们在该路由器的两端进行抓包分析。

1、路由器处抓包

可以看到，在路由器两侧抓到的会话报文数目是没有异常的（路由器做了

NAT转换）。同时看到两侧

的失败报文情况也一致： 靠近客户端侧：

近服务器侧：

2、客户端处抓包

在客户端处抓到的数据包（由交易的端口号和数据包的

IP标识来定位是同一交易）：

可以看到，客户端处和路由器处不同的地方：路由器处一共有383个报文，而客户端处只有364

个，

并且在客户端发出的

AST包前，客户端没有看到像路由器处那样接收到服务器连续发出的几个重传报

文。

由此我们可以看到： 1、 2、

路由器是没有问题的，它正常转发了两边的数据

路由器侧收到了服务器发来的重传包，但是在客户端处却没有发现这些包，说明这些数据包在出了路由器后被中间网络设备丢掉了。

2.1.3 客户端直接接入3560

客户端直接接入3560后我们看到业务恢复了正常，相关数据包：

整个交易耗时

12s左右，传输数据正常，没有出现丢包情况。

本文来源：https://www.bwwdw.com/article/4rhi.html