51学通信技术论坛

标题: 公网DNS Server无响应导致MS业务访问故障 [打印本页]

作者: z36306610 时间: 2011-6-3 23:17:29 标题: 公网DNS Server无响应导致MS业务访问故障

Gb接口中DNS query消息中dest ip代表的是DNS域名解析服务器的地址吗？采集Gb接口时发现DNS超时比较多，就是发两条query，但始终得不到响应，两条dns间隔1s左右，可能是什么原因造成的？请高手指点！

作者: 爱卫生 时间: 2011-6-4 10:44:36

回复 z36306610 的帖子

Gb接口应该不会有DNS消息才对。因为SGSN不需要通过DNS来寻址BSC，无论是Gb Over FR还是Gb Over IP。同样，BSC也不需要通过DNS来寻址SGSN。而Gb接口又没有其他的网元了。
倒是Gn接口有很多流程需要用到DNS。可以参考GPPS网络中哪些流程会涉及到PS网内(Gn网段)的DNS。
但就你说的例子来看，我个人觉得可以排除是BSC和SGSN的DNS交互。
所以我猜应该是MS已经PDP激活成功，访问外部PDN网络时用到的DNS。例如MS要去访问新浪的Server。而一般在激活成功后，GGSN可能会分配两个DNS Server地址给MS。这很好确认。只要能够提供一下抓包。或者你自己看一下，协议栈是不是从下往上，依次是ETH--IP---UDP---NS---BSSGP---LLC----SNDCP----IP---UDP---DNS，如果是这样的话，SNDCP右边即它的上层IP头部中的目的IP就应该是公网的DNS Server地址，应该是公网IP，如果第一个无响应。MS就会去尝试第2个。并且你可以看下应用层DNS里面请求解析的是什么，如果是一个网站的地址，那确认是MS发的无疑。以上就能解释你说的现象了。

作者: z36306610 时间: 2011-6-4 17:10:09

通过统计发现DNS超时比较很高，下面是超时的统计结果，附件中是信令流程，确实是访问外部PDN网络时用到的DNS。这种超时比例这么高一般是什么原因造成的，有什么优化方法，请楼主指教？

排名	DNS IP	请求次数	超时次数	超时占比
1	211.136.20.203	113000	112198	99.29%
2	211.136.17.107	54201	53549	98.80%
3	211.147.6.4	5216	5158	98.89%
4	8.8.4.4	323	317	98.14%
5	8.8.8.8	123	108	87.80%
6	125.39.102.135	94	94	100.00%
7	70.87.197.193	80	76	95.00%
8	193.138.206.157	73	73	100.00%
9	70.85.236.75	75	71	94.67%
10	193.138.247.113	73	71	97.26%

作者: 爱卫生 时间: 2011-6-4 17:50:03

回复 z36306610 的帖子

出现大面积的公网DNS Server故障，这种可能性不大。我估计有可能和Gi防火墙上的NAT会话状态有关。
在做排查时，建议可以将Gi口防火墙作为故障定位分界点，先从Gi口防火墙去ping及traceroute这些公网的DNS Server，如果没有问题，那估计80%以上可能就是防火墙的NAT会话状态表有问题。当然也有可能是PS核心网的Gn接口经过的IP承载网有丢包。如果从Gi口防火墙检测到公网的DNS Server有问题，证明Gi口后面的IP承载网有问题，那就traceroute定位到具体的IP，提交给数据网维护的同事帮忙排查。仅供参考。

作者: z36306610 时间: 2011-6-4 20:16:44

另外一个bsc的情况跟这个差不多
排名 DNS IP 请求次数超时次数超时占比
1 211.136.20.203 113000 112198 99.29%
2 211.136.17.107 54201 53549 98.80%
3 211.147.6.4 5216 5158 98.89%
4 8.8.4.4 323 317 98.14%
5 8.8.8.8 123 108 87.80%
6 125.39.102.135 94 94 100.00%
7 70.87.197.193 80 76 95.00%
8 193.138.206.157 73 73 100.00%
9 70.85.236.75 75 71 94.67%
10 193.138.247.113 73 71 97.26%

作者: z36306610 时间: 2011-6-4 20:18:23

排名 DNS IP 请求次数超时次数超时占比
1 211.136.20.203 39151 38864 99.27%
2 211.137.191.26 36895 858 2.33%
3 211.136.17.107 11534 11424 99.05%
4 10.0.0.172 438 438 100.00%
5 210.44.144.44 351 332 94.59%
6 118.123.115.9 268 268 100.00%
7 61.135.167.182 236 13 5.51%
8 10.221.115.30 192 192 100.00%
9 10.221.165.95 168 167 99.40%

作者: z36306610 时间: 2011-6-5 00:02:39

版主你好，请问dns解析不成功，是不是用户就无法登陆相关网页，DNS成功率低还会影响哪些指标？谢谢！

作者: 爱卫生 时间: 2011-6-5 13:16:39

本帖最后由爱卫生于 2011-6-5 17:15 编辑

回复 z36306610 的帖子

是的，如果DNS Server解不出来，用户肯定就什么页面也看不到。看到的应该就是手机的浏览器始终在连接中，但过了10秒左右就会连接失败，浏览器自动退出。在你的例子里，就是用户请求解析mtalk.google.com。但解析不出来，就无法访问了。
至于影响的指标，我想知道你关心的是哪些指标。因为站在PS核心网的角度，通常关心的指标就是附着成功率还有PDP激活成功率，还有RAU成功率等等。像这几项都不会受到影响的。因为MS既然能给外部公网的DNS Server发解析请求，代表附着和PDP激活都已经成功了。不论MS发多少个DNS解析请求以及没有得到DNS Server响应，都不涉及附着和PDP激活。所以没有任何影响。
所以，如果你还有什么指标需要关心的，也可以列出来，大家一起分析。

作者: z36306610 时间: 2011-6-5 17:06:59

了解，谢了！{:soso_e183:}

作者: 爱卫生 时间: 2011-6-5 20:21:45

回复 z36306610 的帖子

这个案例和无Cause Code---Gi口后的应用服务器无响应这个帖子的案例还比较相似。仅供参考。

作者: crist8308 时间: 2011-9-20 15:44:46

谢谢斑竹和各位高手的解答，又学了不少。
我有一个相关的问题：
假设我遇到的情况是DNS服务器超时，那么应该我抓包的结果是在2条DNS Standard Query消息后，没有任何的流程进行(包括TCP握手、以及后续的所有流程)，是么？

但我在做MS主动测试的时候(我做测试的方式是不停地进行上网操作)，在Gi口采集数据的结果发现DNS查询确实没有响应，但后续还有TCP的建立及数据包捕捉到(我采用的方式是用PDP激活后的APN分配的地址来识别该用户)。不知这种情况是不是DNS查询成功和不成功的数据混合在一起呢？
以下附上数据包的片段。

作者: 爱卫生 时间: 2011-9-20 22:13:01

回复 crist8308 的帖子

  呵呵。这个抓包确实是比较怪。感觉不应该啊。我解释不了哦。
  从抓包来看，确实是DNS没响应，确发起了后续的TCP连接。我也查了下TCP连接的目的IP，确实应该是属于sina网的。我感觉如果抓包没有漏的话，确实和正常的流程不大一样。因为发起TCP连接需要对端的目的IP，而不能根据对端域名来发起。所以手机一定要知道sina网服务器的IP地址才能发起TCP连接，但看包DNS又没有应答。那手机怎么知道sina服务器的地址的呢？
  会不会手机的应用程序里存放了sina网的IP地址呢？或者换一个网址试试呢？
  你还可以做个实验，在本地PC访问一个之前从未访问过的网站（例如www.google.com.my Google马来西亚站，这样可以保证本地没有缓存)，就会看到首先是DNS解析过程，然后再就是到google网站的TCP连接过程。

作者: arrowbroken 时间: 2011-10-11 16:40:48

回复爱卫生的帖子

楼主，我分析了一下 packet, 发现很多下行的包都没有，比如DNS QUERY response, ,TCP SYN ACK, FIN以及HTTP 200 OK for HTTP GET 都没有，但是这些包肯定是有的。简单来看，整个文件里只有171.17.11.227发出的包，没有收到的包。我想楼主是不是做的镜像miror抓包，只做了一个方向的镜像，没有做另外一个方向的包。

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