dns解析失败
-
2023年3月17日发(作者：新华字典免费版)-------------精选文档-----------------
可编辑
案例1：鉴权配置错误导致4G用户附着失败
现象描述：
U国某局点反映用运营商4G旧终端能够上网，而用新终端（如华为AscendP1LTE、E392
及其他终端）不能附着到网络，所以需要分析是什么原因导致新终端附着不到网络。
USN版本：V900R011C01SPC300
告警信息：
原因分析：
USN上的告警时GTPC隧道路径断，查看USN配置，发现37.110.209.209的地址描述是
DESC="Gn/S10/S11controlplane"，基本可以排除问题是由此告警导致的。
从问题现象来看，可能的原因有：
1）终端的问题。
2）USN少配置数据，导致新终端不能接入网络。
3）HSS签约数据问题，可能限制了终端的类型，导致某类终端不能接入4G网络。
处理过程：
1）查看新终端附着不成功的跟踪文件，发现失败原因都是
eMM-cause:uE-security-capabilities-mismatch，UE的安全能力不匹配，很有可能是加
密没有开启导致的。
-------------精选文档-----------------
可编辑
2）查看配置ADDS1USRSECPARA:IMSIPRE="DEFAULT",SECPLC=NEVER;设置了所有
的用户都不鉴权加密，按照协议规定，所有的4G用户都是应该开启鉴权加密的，产品文档
也写了的。所以开启鉴权加密进行测试。
3）开启鉴权加密后，测试仍然失败，失败原因值是
eMM-cause:message-not-compatible-with-the-protocol-state，当前协议状态下消息
不可得。
从后面的消息中又发现了timeout的现象，超时原因是等待attachcomplete消息超
时
4）查看协议23401，第23步，协议规定MME在收到InitialContextResponse消息和
AttachComplete后才会给SGW发送ModifyBearerRequest消息，很显然，问题出现在
UE没有及时的给MME发送attachcomplete消息。
ceptionofboth,theInitialContextResponsemessageinstep21and
theAttachCompletemessageinstep22,thenewMMEsendsaModifyBearer
Request(EPSBearerIdentity,eNodeBaddress,eNodeBTEID,HandoverIndication)
-------------精选文档-----------------
可编辑
messagetotheServingGW.
5）旧终端是上的了网的，所以问题肯定在新终端上，那是不是因为新终端有问题呢，不支
持协议？问题陷入了僵局。这个时候用旧的终端连4G网络，发现也上不了网了。问题一下
子陷入了两难。观察跟踪文件。HSS回复鉴权拒绝的消息给MME。
6）询问一线测试工程师，发现他是RMVUSR之后出现旧终端测试失败的，那么用新终端
测试会是怎么样呢？新终端测试仍然拒绝，而且原因值和旧终端一致，鉴权拒绝。看来问题
终于有了一致性了。
7）用旧终端不开启鉴权保护能上网，开启了鉴权保护就不能上网，而且原因值是鉴
权拒绝，那么问题应该是出现在HSS上了，和HSS工程师做过沟通之后，发现他选的卡的类
型是SIM，而不是USIM，按照之前2/3G的概念，SIM卡鉴权是取3元组的，而4GEPC网络
鉴权是4元组，而USN现在还不支持3元组向4元组进行转换，所以鉴权肯定是失败的。所以
-------------精选文档-----------------
可编辑
3GPP协议推荐4G里面选USIM卡，这样3G用户就能够顺利过渡到4G这是因为3G里面的鉴
权5元组能够转为4元组。
8）将卡的类型变更为USIM后，新旧终端都能够接入网络了。
案例点评：
从整个问题的处理看，纠结于终端的原因花了很长的时间，但是后面终于还是发现了鉴权拒
绝的原因，从而根因于HSS签约数据的问题，4G网络中使用的卡的类型不再是SIM卡。EPC
网络现在要求都是鉴权加密，所以现在的时候也都支持加密。此案例中新终端是强制了加密
的，旧终端没有强制，所以用SIM卡附着新终端是上不了网，而不强制加密的旧终端则能上
网。
案例2：USN9810未配置相应TAC导致用户附着失败问题
现象描述：
新建局LTE网络，无线侧安装完站点后，用户测试上网失败，无线侧跟踪消息显示，用户附
着被拒绝，无法上网。
告警信息：
无
原因分析：
登陆USN9810，打开用户跟踪对话框，输入用户IMSI号码跟踪消息：
1、从跟踪到的消息看到下图信息；
-------------精选文档-----------------
可编辑
UE发起AttachRequset消息，并且MME向HSS发起鉴权请求（Authentication
InformationRequest）得到响应（AuthenticationInformationAnswer），由MME向
HSS发起的跟踪区更新请求消息看出，UE鉴权通过HSS的签约数据没有问题。
2、从跟踪消息中看到如下图信息：
UE附着被拒绝（AttachReject），双击该条消息，从具体信息中得到下图信息，
用户被拒绝是由于APN未知或错误。
3、根据2步骤定位的原因，直接找到SM-DNS的解析消息：
双击SM-DNS的消息，从具体信息中得到如下图的信息，
从图中看到要解析的两个FQDN（由APN和TAC构造所得），具体配置在ADDDNSN
命令下。
4、在USN9810的LMT客户端的USN网元下，输入LSTDNSN，查看相关配置如下，主要
查看FQDN构造：
操作结果如下:
-------------精选文档-----------------
可编辑
-------------------------
FQDNHostName索引网元类型接口类型S5接
口协议类型
1S
460.3GPPNETWORK.
ORG2PGWS5GTP
(结果个数=2)
从查询结果中看出，TAC的配置跟消息带上来的不一致，消息中TAC为2541，配置中为0001，
由该原因导致DNS解析失败。
处理过程：
1、添加TAC对应的TALST(ADDTALST)：
ADDTALST:TALISTID=1,TAI="460032541",DESC="to-S1";
2、添加DNS的A解析记录（ADDIPV4DNSH，如果之前配置，则无需再加）：
ADDIPV4DNSH:HSINDEX=1,HOSTNAME="",
ADDRSECTION=SECTION1,IPV4ADDR1="115.169.148.178",PRIORITY1=127,
WEIGHT1=127;
3、添加DNS的NAPTR解析记录（ADDDNSN)，保证TAC配置正确，并且跟A记录的主机
名索引保持一致:
ADDDNSN:
FQDN="",
HSINDEX=1,ENTITY=SGW,INTYPE=S11,S5PROTOCOL=GTP,S8PROTOCOL=GTP,
PRIORITY=0,WEIGHT=100;
-------------精选文档-----------------
可编辑
执行完以上三步后，用户可以正常上网。
建议与总结：
配置置USN9810的数据时，要严格按照数据规划完整的添加需要配置的TALST，并正确添
加相应的DNS数据配置。A解析记录中，主要注意正确配置主机名与相应网元（SGW、PGW
等）的IP地址对应关系，NAPTR解析记录中，主要注意正确配置TAC，正确引用A解析记录。
案例3：PCC配置错误导致UGW基于三四层专有承载无法建立问题
现象描述：
按照UGW9811V900R010C01SPC520T的设备验收测试手册，有一项基于三四层专有承载
的建立，配置三四层规则，并将相应的user-profile-group绑定到apn下，测试时，需要由
UGW触发专有承载建立，但专有承载未建立。
以上配置数据配置完毕后，数据卡连接网络，在电脑上ping公网地址，专有承载没有建立。
告警信息：
无
原因分析：
1、网络侧触发专有承载的建立有三种方式：
（1)PCC动态用户由PCRF下发动态规则触发专有承载建立；
（2)PCC静态用户由PCRF下发预定义规则触发专有承载建立；
-------------精选文档-----------------
可编辑
（3)PCC静态用户由UGW触发专有承载建立；
该项测试中使用第三种方式触发专有承载。
2、跟踪消息中发现用户再激活时向PCRF发送了CCR消息，并且PCRF回了CCA消息
（CCR/CCA通过DRA转接），如图1所示，并且CCA消息显示该用户未在PCRF中签约；
图1
3、对于PCC静态用户由PGW发起专有承载建立的原则为，用户上线后，不应该向PCRF发
起CCR，而是根据APN下绑定的user-profile-group匹配相应规则进行专有承载的建立，但
APN下的PCC开关必须打开，因为在V900R010C01SPC520T版本中，非PCC用户无法建
立专有承载；
4、如果UGW向PCRF发起CCR，那么UGW就会以第二种方式建立专有承载（PCC静态用户
由PCRF下发预定义规则触发专有承载建立），而不会匹配APN下的user-profile-group，
CCA中没有下发预定义规则名，规则匹配失败，专有承载未建立；
5、UGW为什么会向PCRF发起CCR，通过检查APN下的配置发现，APN下绑定了如下两条
命令：
pcc-template-bindingpcc_template_1
第一条为APN下绑定的到PCRF的域路由，第二条为APN下绑定的PCC模板，如此一来，当
用户在该APN下激活时，UGW都要到PCRF申请用户策略，所以向PCRF发起CCR，并期望
-------------精选文档-----------------
可编辑
CCA中回复策略，CCA中没有策略，专有承载无法建立；
处理过程：
将APN下的PCRF域路由和PCC模板删掉，然后用户下线重新上线，在电脑上ping公网地址，
专有承载建立成功，如下图所示：
UGW向MME发起createbearrequest，MME向UGW回复createbearresponse，并且
UGW没有向PCRF发起消息；
案例点评：
对于基于三四层和七层的专有建立，首先必须要在APN下打开PCC开关，非PCC用户无法建
立专有承载；其次要删掉PCRF相关的PCC模板和域路由，否则UGW会向PCRF请求策略，
如果PCRF没有给该用户签约或未配置相应的预定义规则，专有承载不会建立；最后UGW上
的相应DPI规则要配置正确。
案例4：X国TAU被拒绝，原因为UEidentitycannotbederivedbythe
network
现象描述：
X国反馈从在TAU流程中被MME拒绝，原因值为UEidentitycannotbederivedbythe
network。
-------------精选文档-----------------
可编辑
告警信息：
无
原因分析：
1)UE驻留在LTE，发起CSFB流程
2)UE回落后，在2/3GSGSN发起了RAU，到本端查询上下文信息，可以看到对端SGSN
的地址为C917AFC1，也就是201.23.175.193
-------------精选文档-----------------
可编辑
3)UE完成CS业务后，TAU回4G，为了获取上下文信息，需要通过DNS查询2/3GSGSN
的地址
4)使用DNS查询结果中的地址.0C(201.23.191.12)发起SGSNContext
Request,但是对端返回失败，原因为cause-ie:imsi-not-known(194)
-------------精选文档-----------------
可编辑
5)MME下发位置更新拒绝，原因为
eMM-cause:uE-identity-cannot-be-derived-by-the-network(9)
3GPPTS24.301有相关描述如下：
5.5.3.3.5Combinedtrackingareaupdatingprocedurenotacceptedbythenetwork
#9(UEidentitycannotbederivedbythenetwork);
TheUEshallsettheEPSupdatestatustoEU2NOTUPDATED(andshallstoreit
accordingtosubclause5.1.3.3)andshalldeleteanyGUTI,lastvisitedregisteredTAI,
halldeletethelistofequivalentPLMNsandenterthe
stateEMM-DEREGISTERED.
-------------精选文档-----------------
可编辑
以上就是说MME获取不了UE的身份，拒绝TAU请求，TAU失败后，UE会自动发起attach
流程
处理过程：
1）随机取了12次CSFB后的TAU过程进行分析，发现其中有4次成功，8次失败，所
有失败和上面描述失败流程是一样的，都是由于进行SGSNContextRequest时对端返回
失败（原因为imsi-not-known）
2）进一步分析发现，失败的8次DNS解析后使用的对端SGSN地址都是191网段，也
就是201.23.191.*,而成功的4次使用的都是175网段，也就是地址201.23.175.*
因此可以确认191网段的SGSN有问题，需要一线排查SGSN的DNS配置是否正确，近
期是否做过相关配置操作
3）排查发现10月4日当天，SGSN上有操作，添加了191网段的SGSN，但是在对应的
DNS没有添加相应的配置信息，导致TAU时MME无法获取到UE的信息，进而导致TAU
失败
4）在191网段的SGSN的DNS添加相应的配置信息，CSFB过程中的TAU成功，问题
解决。
案例5：由于hostfile文件配置不规范导致的TAU失败
现象描述：
某局点两个TA之间存在TAU失败的情况，同一时间发现，在另外两个TA之间却可以
-------------精选文档-----------------
可编辑
正常的进行TAU。
现网PS10.0版本EPC组网，两台MME，一台融合UGW。现网已经开启终端能力识别
功能，4G终端统一激活在融合UGW上。
告警信息：
无
原因分析：
推断问题可能的原因如下：
TA数据在DNS上没有配置完全，有漏配的情况；虽然TA配置完整，但是解析的结果
存在问题，没有按照预期选择正确的SGW；
1）首先排查了DNS的配置，确认现场反馈的两个TA（93D0和931C）都是在DNS
上配置了的，并且配置完全符合要求。
进行单用户跟踪测试，跟踪信令发现TAUReject的消息，错误原因值为：
no-EPS-bearer-context-activated，如下图：
附着的时候，PGW返回：
-------------精选文档-----------------
可编辑
TAU的时候，
从上面可以看出，PGW确实作为锚点，一直没有改变过，DNS解析的目的地址为同
一个。2）同步在UGW上做了跟踪，如下：
-------------精选文档-----------------
可编辑
在出错的时间区间，发现有两次激活请求，但是没有去激活的消息，导致重复激活。
由于重复的激活，同一个用户同一个承载ID，SGW拒绝。但在同一个SGW的情况下，
MME发起第二次重复异常行为。
3）排查本地hostfile配置。由于开局的时候未使用DNS服务器解析，统一使用的
hostfile，后来在DNS增加4G解析数据后，又没有及时删除本地hostfile，导致目前
其实部分DNS解析还是通过本地hostfile进行的。
4）根据优先级，MME优选hostfile的配置来解析93D0，问题的关键在于，hostfile
中的SGW主机名与DNS服务器中的标准配置是不一致的。
首先看附着的时候，在931C跟踪区下的DNS返回，这个时候使用的是DNS服务器查
询：
-------------精选文档-----------------
可编辑
TAU的时候，也就是在跟踪区93D0下，DNS查询的结果，这个时候使用的是hostfile
中的配置：
从这两个解析结果可看出，同一个SGW在不同的TA下却对应了不同的主机名，这样
MME就认为是不同的SGW，出现了重复激活的现象，进而TAU失败。
处理过程：
这个问题的根本原因是hostfile的配置未按照规范进行，TA下解析出的SGW主机名
与规范不一致。而出现问题的两个TA一个采用DNS服务器解析，一个采用本地
hostfile解析，这样必然导致解析出的SGW主机名结果不一致，MME误认为是SGW
-------------精选文档-----------------
可编辑
变更，触发重复激活。根据问题分析，在两台MME上删除了所有的TA相关的hostfile
配置，清除MME上的DNS缓存后，现场测试正常，TAU成功。
案例6：由于PCRF在CCA消息中下发信元错误导致UGW动态规则加载
失败
现象描述：
PCRF下发动态规则，UGW加载失败，导致激活失败
告警信息：
无
原因分析：
1、可能导致UGW动态规则加载失败的原因：
A、对端链路异常无响应，没有回复CCA
B、CCA消息异常导致rule安装失败
C、GX接口配置错误
2、通过跟踪消息可以看到CCA消息，排除PCRF无响应的原因：
-------------精选文档-----------------
可编辑
3、排查GX接口配置，配置正确
4、分析CCA消息，发现Charging-rule-install里面缺少必要的信元：RG/SID，
reporting-level，bearer-id
5、同时Flow-info不符合协议要求：FlowInformation中携带了两个Flowdescription
处理过程：
-------------精选文档-----------------
可编辑
PCRF下发正确的信元后问题解决。
案例点评：
此类问题一般情况下是信元带的不正确导致的，可先参考协议进行排查。
案例7：DNSserver和DNSN中主机名命名不同，导致EnodeB间切换
失败
现象描述：
T国B局点phase0新建两个PS站点，配置分别为1*USN+1*UGW+2DNS，在PAT
测试阶段，发现EnodeB之间切换失败，UGW上打印出来的消息为"SPChangetoSP
fail"，USN上流程失败在HOpreparationfailure。
-------------精选文档-----------------
可编辑
告警信息：
无
原因分析：
1、从USN和UGWtrace上发现，UGW在createsessionresponse消息中拒绝了建立会
话请求。
UGW上面打印出来的免维护消息是“SPchangetoSPfailure”。
-------------精选文档-----------------
可编辑
2、对比HO流程中建立会话请求消息和附着流程中建立会话请求消息发现，SGW地址相同
（0A50823E）。根据Enodeb切换流程，如果服务的SGW不变，不应该发起createsession
request消息。
总结：MME在此发起了错误的createsessionrequest流程，该用户已经在此SGW中建立
了一个默认会话，所以SGW返回reject，从而HO失败。
处理过程：
1、为什么服务的SGW地址一样，MME依然发起createsessionrequest流程？查看
DNS请求消息发现HO流程中DNS请求消息携带的是改变了的TAC和attach流程中
DNS查询结果。
2、DNS查询结果如下所示，DNS返回的是通过TAC查询出的SGW的hostname，并
且和上次的hostname不一样。
-------------精选文档-----------------
可编辑
3、查看USN和DNS配置发现“-
”FQDN是在USN
DNSN中配置的，而
是在
server中配置了，而两边配置的hostname名字不一样。
4、删除USN中DNSN配置，将
配置加
入至DNSserver中，再次测试切换，问题得到解决。
建议与总结：
MME不是根据SGWIP地址决定是否SGW是否改变，而是根据解析的hostname。
理解流程细节，能够有效的解决问题。
案例8：友商SGWDeleteSessionRequest报文中bearer-id错误导致
会话去活失败
现象描述：
-------------精选文档-----------------
可编辑
我司UGW9811V900R001C05作为PGW，与N公司SGW做对接测试。信令交互过
程如图1：
图中最后PGW发给SGW的DeleteSessionResponse消息中回复失败，原因值为
context-not-found，如图2：
告警信息：
无
原因分析：
1）PGW回复失败消息，从PGW入手，查看失败原因值，为context-not-found。
2）在PGW上access-view下执行displaypdpcontext命令，发现存在缺省承载，没有
专有承载。
3）查看对应的请求消息，即SGW发给PGW的DeleteSessionRequest消息，发现
eps-bearer-id值为0x6，为专有承载，如图3。前面通过displaypdpcontext命令查询
已经知道只有缺省承载，因此必然找不到上下文而失败。
-------------精选文档-----------------
可编辑
4）分析此时PGW上只有缺省承载是否正确：从图1中的信令交互过程，SGW已经通过
DeleteBearerCommand消息出发PGW删除之前建立的专有承载，因此此时已经没
有专有承载，SGW的eps-bearer-id值是错误的。
5）按协议描述，SGW不会发送DeleteBearerRequest消息，只有DeleteSession
Request消息的场景，而DeleteSessionRequest消息请求删除会话，携带的
eps-bearer-id只能为0x5。
6）进一步测试，发现如果没有建立过专有承载，则SGW在DeleteBearerRequest消息
中携带的eps-bearer-id值为0x5，可见SGW的实现上对该信元的值只增不减，导致
问题出现。
处理过程：
SGW侧通过补丁修改DeleteSessionRequest消息中eps-bearer-id信元值为0x5，问题解
决。
案例点评：
对于信令交互失败类问题，先从回复失败消息的信元入手，通过分析失败原因值、内部调试
信息计数器，找到失败原因，从信令交互消息中确认交互失败的根因在哪个信元，对症下药，
-------------精选文档-----------------
可编辑
最终解决问题。
案例9：UGW配置专有承载规则后附着失败
现象描述：
某实验局中，配置完USN、UGW后，用户附着正常。增加专有承载配置完成后，初始的时
候，专有承载能正常建立，但第二天继续测试的时候，MME拒掉UE附着，默认承载建立失
败，提示错误为networkfailure。
告警信息：
无
原因分析：
第一天测试完后，到第二天重新测试期间，设备没有做任何改动，也看不到任何新增告警。
分析认为没有加识别库，因此无法建立专有承载；但是加载协议识别库后，依旧不能成功附
着。
处理过程：
后发现未添加兜底过滤器，添加filterfilter-anyl34-protocolany后，设备附着成功，专
有承载激活成功。
案例点评：
兜底规则，没有增加兜底规则，设备无法附着，导致没法激活。难道说如果用户访问的业务
不符合任何一个规则，就应该上不了网吗，我想不是的，至少应该有默认承载可以用，实际
上我们添加兜底规则也是这个目的。
-------------精选文档-----------------
可编辑
案例10：预定义规则优先级设置不合理导致专有承载建立失败
现象描述：
某局点UGW与友商E的PCRF进行专有承载建立测试验证时，发现专有承载建立不成功。
告警信息：
无
原因分析：
1.用户跟踪：PCC用户在激活时，PGW会发CCR消息给PCRF，PCRF回复的CCA消
息里携带规则，该规则名称与PGW上的预定义规则名称相同。所以需要进行用户跟
踪确保PCRF下发了规则名称，从用户跟踪来看，PCRF下发了一个规则：qci6
2.检查PGW上关于预定义规则qci6的相关配置，配置没有问题，测试时使用的业务
肯定是能够命中filter-grouphsp的，可以通过displaypcc-session-info进行验证。
ruleqci6filter-grouphspqos-service-propertyqci6priority59999
qos-service-propertyqci6qci4arp4pre-emption-capabilitydisable
pre-emption-vulnerabilityenablegbruplk2000gbrdnlk2000mbruplk3000
mbrdnlk3000
-------------精选文档-----------------
可编辑
3.分析业务不触发PGW发起专有承载建立的原因：业务数据流没有匹配ruleqci6，
使用pstoolkits工具里的免维护报文浏览工具进行验证：
再次进行用户跟踪，勾选免维护。使用工具解析跟踪，查看解析结果excel表的
rulename列，发现没有qci6，说明用户业务报文没有匹配中qci6规则，这就是专有
承载建立不成功的原因。访问视频的server地址包含在filter-grouphsp里面却没有
匹配上规则唯一有可能的原因是业务报文先匹配的其他高优先级的rule，将ruleqci
的优先级适当调高（数值改小），再进行测试，专载建立成功。
处理过程：
由于预定义规则的优先级设置不合理导致规则匹配失败，进而导致专有承载建立失败。适当
调节预定义规则的优先级后，问题解决。
案例点评：
理解PCC业务原理，利用工具辅助问题定位。