51学通信技术论坛

标题: 关于数据投诉骤增原因的求助，急急急！ [打印本页]

作者: 杨昭 时间: 2014-3-5 17:13:29 标题: 关于数据投诉骤增原因的求助，急急急！

本帖最后由杨昭于 2014-3-6 13:05 编辑

现象描述：最近西安地区的数据网投诉量比以往翻了好几倍，目前尚未查出原因，现在上传一个Gn口的数据抓包，请高手指点，看能否分析出是哪些网元出了问题，目前初步怀疑是核心网元的问题，因为最近做过SGSN还是GGSN的相关操作（具体不是很确定），因为无线侧的问题不会导致投诉数量比正常情况翻好多倍的，并且无线侧统计的业务量变化并不是特别大，请高手指点迷津，不胜感激！

[attach]3165[/attach]

作者: kinghighland 时间: 2014-3-6 11:10:19

压缩包里的pcap文件只有24字节

作者: 杨昭 时间: 2014-3-6 13:06:20

kinghighland 发表于 2014-3-6 11:10
压缩包里的pcap文件只有24字节

重新上传了一个，希望大侠指点，谢谢！

作者: hrbqby 时间: 2014-3-7 09:40:43

请检查一下GGSN网元里的关于内容计费配置，发现到10.0.0.72交互有异常。

作者: 杨昭 时间: 2014-3-7 10:47:45

本帖最后由杨昭于 2014-3-7 10:48 编辑

hrbqby 发表于 2014-3-7 09:40
请检查一下GGSN网元里的关于内容计费配置，发现到10.0.0.72交互有异常。

大侠，您好，首先非常感谢您回复我的帖子，然后我想追问几个问题：第一：内容计费配置有问题和上网的异常有多少关联，大多数客户反应老掉线，上不去网。
第二：您是从那几条packet里面看到的GGSN的内容计费存在问题，是如何分析的；
谢谢！

作者: kinghighland 时间: 2014-3-7 10:56:47

本帖最后由 kinghighland 于 2014-3-7 11:02 编辑

就凭这0.01秒的数据怎么可以分析投诉原因？而且也不知道客户投诉的内容是啥？

gn接口信令很少，通常看不出啥毛病，适合于统计所谓的“上网日志”，为“资费类投诉”提供访问记录。
如果确认是核心网问题，还是结合你说的SGSN/GGSN做的调整去分析吧
如果未必是核心网的问题，建议在Gb/Iups抓包作分析

作者: kinghighland 时间: 2014-3-7 11:04:50

杨昭发表于 2014-3-7 10:47
大侠，您好，首先非常感谢您回复我的帖子，然后我想追问几个问题：第一：内容计费配置有问题和上网的异常 ...

计费不会影响上网的，除非欠费了

作者: hrbqby 时间: 2014-3-7 11:09:33

杨昭发表于 2014-3-7 10:47
大侠，您好，首先非常感谢您回复我的帖子，然后我想追问几个问题：第一：内容计费配置有问题和上网的异常 ...

举例：#255包核心网与10.0.0.172 回送的包有异常。具体你需要抓某个用户的行为包在分析一下。
内容计费限定了数据流的好多CONTAINER ，包括（ip，协议号，端口号，URI，X-online-host 等。。。) ,势必影响用户上网体验。

作者: GPRSengineer 时间: 2014-3-7 12:47:48

内容计费功能是GGSN的一个增强功能。该功能通过对IP报文的DPI对报文进行分析从而将用户流量进行归类并按照业务进行计费。生成还业务标示的用户自费话单。
GGSN在进行内容计费的时候会导致IP报文传输的延迟，但是并不修改该IP报文，也不会少发包，也不会多发包。

结论：
1. 在GGSN上开启了内容计费规则之后，会导致IP报文传输的延迟增大，但是IP数据报的内容不会受影响。也就是说不管内容计费的规则配置是否错误，开通了内容计费，就会导致延时增加。
2. 因为内容计费不修改IP报文，也不丢弃IP报文。所以内容计费规则配置错误会导致计费出现错误，但是不会导致业务出现故障。

作者: GPRSengineer 时间: 2014-3-7 13:20:02

使用wireshark打开此文件的话，wireskark判断#255包的故障是“TCP Previous segment lost”。这个故障wireshark总共发现42个，其中有21个与10.0.0.172这个地址有关（全部是下行流量）。
10.0.0.172这个地址是WAP网关使用的IP地址。
通过对整个采集包进行分析，总共抓了2052个IP包，其中有413个包和10.0.0.172有关。可以看出“TCP Previous segment lost”在10.0.0.172上发生的比较多。

建议：
查一查WAP网关。

作者: kinghighland 时间: 2014-3-7 15:37:31

GPRSengineer 发表于 2014-3-7 13:20
使用wireshark打开此文件的话，wireskark判断#255包的故障是“TCP Previous segment lost”。这个故障wires ...

恐怕previous segment lost和抓包只有10ms有关，这么短的时间远远不够一次回路应答，在应答流程方面没有分析价值

作者: wangtianyi 时间: 2014-3-7 18:01:49

兄弟，贵州这边现在上网掉线问题也是直线上升，应该和你的问题现象一样。是不是SGSN不停的建立PDP，删除PDP，而且都是成功呢？我们正在研究是为什么会不停的发起这些信令，怀疑是SGSN侧负荷分担问题的配置导致的，还在继续排查中~~

作者: kinghighland 时间: 2014-3-7 18:44:34

本帖最后由 kinghighland 于 2014-3-7 18:49 编辑

wangtianyi 发表于 2014-3-7 18:01
兄弟，贵州这边现在上网掉线问题也是直线上升，应该和你的问题现象一样。是不是SGSN不停的建立PDP，删除PDP ...

假设这么一个场景，也许会引发这个现象：

假设PCC策略制定有严重错误，导致大批用户被错误的去活，用户在被去活之后重新发起激活（SGSN不停建立PDP），然后SGSN根据PCC策略再去活（不停删除PDP）。

这里面有不少未知的因素：比如是否有GGSN参与其中（GGSN根据业务类型发现不符合PCC策略而发起去活），比如SGSN从PCC拿到的配额和策略是怎样的

需要综合很多信息才能进一步做判断

比如是否同时有大量的RAU失败、附着消息数大量增加
在香港见过一例，核心网故障导致大量用户发生RAU失败，然后全部重新做附着，但大量被拒绝，所以短期之内附着消息数增加N倍，成功率很低

作者: ccc123 时间: 2014-3-9 10:18:37

跟进中。有个问题，如果GGSN ,与pcc计费网关中发现用户欠费，拒绝用户上网，那么GGSN发起拒绝后，用户是否还能尝试上网吗？多长时间尝试一次哪？我感觉应该是pcc跟hlr交换，拒绝登陆pcn网才多，不知道大家有什么看法发表一下了。多谢。。。。

作者: kinghighland 时间: 2014-3-9 17:47:22

ccc123 发表于 2014-3-9 10:18
跟进中。有个问题，如果GGSN ,与pcc计费网关中发现用户欠费，拒绝用户上网，那么GGSN发起拒绝后，用户是否还 ...

如果是流量超了额度，那么对于内容计费的业务则需要单独处理，比如免费的彩信还可以用，这就是说你还得允许用户还可以激活，才能继续用彩信。

作者: kinghighland 时间: 2014-3-9 21:34:19

如果GGSN的内容计费的策略配置不当，这种问题会影响到设备处理能力，在此情况下会导致业务降级，请参考下帖内容
http://gprshome.com/forum.php?mo ... p;tid=1177#lastpost

作者: 杨昭 时间: 2014-3-10 11:43:41

kinghighland 发表于 2014-3-9 21:34
如果GGSN的内容计费的策略配置不当，这种问题会影响到设备处理能力，在此情况下会导致业务降级，请参考下帖 ...

非常感谢！

作者: flyda7805055 时间: 2014-3-11 09:20:17

最近我所在地市GPRS广义投诉也有所上涨，但是我们这边分析出来的跟最近QQ游戏应用的GET成功率下降有关，供参考

欢迎光临 51学通信技术论坛 (http://www.51xuetongxin.com/bbs/)