飞信登陆失败案例.docVIP

飞信登陆失败案例 一、问题描述 今年集团测试中，在GGSN6下面进行飞信登陆测试偶尔出现超时失败，忙时成功率极低（成功率低至10%），由于问题涉及整个GGSN，因此核心网侧引起可能性较大。从Um口抓包协议看，终端向31发送SYN报文请求建立连接，但一直无响应，连接最终超时中断。 二、Gi口外侧抓包分析 抓包环境： 抓包方法：将GGSN6对应的6509交换机端口连接到成域网并做好镜像端口;远程使用tcpdump –i eth0 –w name.cap等指令通过SSH软件抓取Gi口数据，通过用户IP筛选出单用户数据。 经过对比Um口和Gi口外侧同时捕获的数据包，发现如果飞信登陆成功，则2份捕获的数据包能同时看到数据协议；如果飞信登陆失败，Um口捕获的数据包可以看到数据协议，而Gi口外侧捕获的数据包则看不到数据协议。 飞信登陆成功时，Gi口中创系统捕获的数据包： Um口CDS软件捕获的数据包： 事件列表 而飞信登陆失败时，Gi口外侧没有任何数据经过，问题定位为Gi口外侧以下网络引起。对此进一步对Um口IP层协议进行深入分析： 通过回放CDS数据，发现捕获的数据包中，9次飞信登陆失败网关都向终端发送过RST报文，（RST含义：（Reset the connection）用于复位因某种原因引起出现的错误连接，也用来拒绝非法数据和请求。接收到RST时候，通常发生了某些错误HTTP/1.1 200 OK 报文均标志着[ZTEOSE]字样，如下图： 初步怀疑失败与[ZTEOSE]有关 三、WAPGW数据分析 从WAPGW数据分析，发现全部飞信登陆失败以及WAPGW回应RST报文的飞信（有[ZTEOSE]标志）都是经由“中兴网关”处理，如下图： WAPGW记录： CDS测试记录： 而登陆成功则全部走“NOKIA”网关： WAPGW记录： CDS测试记录： 四、问题定位 经检查，GGSN6链接两个WAP网关： “中兴”与“NOKIA”WAP网关，“中兴”WAP网关起到话务分担作用，当话务较高时，部分WAP业务将由“中兴”WAP网关处理。经检查，问题是由于“中兴”WAP网关处理飞信协议出现异常引起。经WAPGW厂家处理后问题解决。