问：GGSN PDP上下文吊死

yonka

不知道用吊死这个词是否合适

情况是这样的：
    在一些很少见的故障情况下，GGSN上会有一些PDP 上下文被“吊死”，即GTP PATH正常，但是这部分PDP上下文不对用户流量做任何响应。也就是说用户报文到了GGSN后不作任何处理。

想问下，这种情况下用户怎么样才能恢复上网功能？
关掉浏览器发起去激活然后重新打开重新激活可以吗？（那如果GGSN对针对这部分PDP上下文的去激活消息也不做响应呢？）

hycl5410

既然是故障情况，那么正常流程可能就无法完成。
那就试呗，先从UE侧主动去激活，
不行的话，GGSN单独对这个PDP去激活，
再不行那就开CSR吧。。。

yonka

hycl5410 发表于 2012-6-20 09:38
既然是故障情况，那么正常流程可能就无法完成。
那就试呗，先从UE侧主动去激活，
不行的话，GGSN单独对这 ...

唉~
CSR这东西耗时耗力~
而且解决问题的概率越来越低~~

- -！

hycl5410

yonka 发表于 2012-6-20 09:49
唉~
CSR这东西耗时耗力~
而且解决问题的概率越来越低~~

不耗时耗力能得到root cause？
在论坛上发发帖子问问题，没log靠经验来分析得到的solution你敢用么？
就拿你这个case来说，前两招不好使的情况下怎么办？
况且你不知道问题原因在哪里，更别说解决了。

爱卫生

hycl5410 发表于 2012-6-20 10:09
不耗时耗力能得到root cause？
在论坛上发发帖子问问题，没log靠经验来分析得到的solution你敢用么？
就 ...

完全赞同H大侠的观点。

这就好比找医生看病，如果只是根据病人的描述来断病，很容易造成误判。即使是再经验丰富的医生也会犯错。最准确的方法还是要依赖先进的仪器例如做CT、照X光等才能完全判断病情对症下药，这就好比要troubleshooting，一定要有log或者抓包以及做相关的测试才能定位，否则光凭描述的讨论，最多能作为30%的参考。

tony9492

还是跟踪一下，对具体log进行分析能得到更多的信息，pdp激活肯定是由于业务触发的，按你说的无响应的话，不知道能不能得到cause值来帮助判断，应该多接口联合抓数据看看，和正常的流程对比一下，看看有什么问题；
另外对于GGSN上PDP的吊死，有没有进行大量的数据统计，看看有没有用户、物理网元等维度的集中度，便于定位问题。

langzifeng06

用户下线之后重新激活就可以了，因为根据说的，GGSN并没有对用户PDP上下文激活的请求进行响应，所以我们可以确定用户终端并没有收到网络侧分配给它的IP地址，因此用户重新激活，重新获取IP就可以上网了

yonka

langzifeng06 发表于 2012-6-25 13:09
用户下线之后重新激活就可以了，因为根据说的，GGSN并没有对用户PDP上下文激活的请求进行响应，所以我们可以 ...

我是说已经激活PDP的用户呢

因为吊死的原因，不会向SGSN发送去激活PDP的消息
SGSN发送PDP去激活到GGSN也不会响应

你的意思是终端去激活，然后SGSN侧执行...

规范里对GGSN不响应去激活消息是怎么定义的？

谢谢