Q：物联网地址池不足导致附着成功率降低
A：1.在MME上下载faillog文件，通过工具解析为csv文件后，对内容进行分析，发现大量的异常记录，cmiotfz.sh这个APN存在大量的资源不足导致的附着异常，起初认为是物联网APN在非nb-iot MME下接入导致的。
异常记录如下：
IMSI MSISDN APN Name External Cause Value
460042790305652 861440079035652 cmiotfz.sh Insufficient resources
460042830810639 861440083080639 cmiotfz.sh Insufficient resources
460042779105092 861440077915092 cmiotfz.sh Insufficient resources
460042779105133 861440077915133 cmiotfz.sh Insufficient resources
460042807200894 861440080720894 cmiotfz.sh Insufficient resources
460042779204028 861440077924028 cmiotfz.sh Insufficient resources
460042790305611 861440079035611 cmiotfz.sh Insufficient resources
2.根据异常记录的IMSI，在CTS上开启用户跟踪，发现失败的原因为地址池资源不足导致
----------------------------------------------------------------------------------------------------
106 CSMME36BZX-COMBO_MMEGNGP_SGSN_63 UMAC 2018-09-05 11:45:19.060 GTPv2 Create Session Response 接收460042830810838 861440083080838 221.177.175.1 221.177.168.23 IMSI=460042830810838,MSISDN=861440083080838
_________________________________________________________________
|
******** | Create Session Response
******** | GTP Header
010----- | GTP Version: 2
---0---- | Piggybacking flag: 0
----1--- | TEID flag: 1
-----000 | Spare: 0
00100001 | GTP V2 Message Type: Create Session Response(0x21)
00000000 00100010 | Message Length: 34 (Bytes)
******** | Tunnel Endpoint Identifier(TEID): 0x67A065E4
******** | Sequence number: 0x095784
00000000 | Spare: 0
******** | Cause
00000000 00000010 | Length: 2 (Bytes)
0000---- | Spare: 0x00
----0000 | Instance Value: 0x00
01010100 | Cause: All dynamic addresses are occupied(0x54)
0000000- | Spare: 0x00
-------1 | Cause Source: 0x01
******** | Bearer Contexts List (num 0):
00000000 00001011 | Length: 11 (Bytes)
0000---- | Spare: 0x00
----0000 | Instance Value: 0x00
******** | EPS Bearer ID
00000000 00000001 | Length: 1 (Bytes)
0000---- | Spare: 0x00
----0000 | Instance Value: 0x00
0000---- | Spare: 0x00
----0101 | EPS Bearer ID: 0x05
******** | Cause
00000000 00000010 | Length: 2 (Bytes)
0000---- | Spare: 0x00
----0000 | Instance Value: 0x00
01010100 | Cause: All dynamic addresses are occupied(0x54)
0000000- | Spare: 0x00
-------1 | Cause Source: 0x01
******** | Recovery
00000000 00000001 | Length: 1 (Bytes)
0000---- | Spare: 0x00
----0000 | Instance Value: 0x00
00001101 | Restart Counter: 13
__________________|______________________________________________
0000000000h: 48 21 00 22 67 A0 65 E4 09 57 84 00 02 00 02 00
0000000010h: 54 01 5D 00 0B 00 49 00 01 00 05 02 00 02 00 54
0000000020h: 01 03 00 01 00 0D
_________________________________________________________________
增加对应APN地址池资源后，附着成功率恢复。
Q：实例化MFVO时NFVO_02虚机反复不断自动硬重启
A：1. 在NFVO_02虚机硬重启过程中，快速进入控制台，立即按下任意键，修改grub，将虚机的串口加入到启动信息打印的配置中，控制台页面看到NFVO_02虚机是无法处理系统盘。 2. 删除NFVO_02虚机其系统云盘，手工在TECS网页上重创NFVO_02虚机的系统盘，创建时需选取清零标志；然后手工重建NFVO_02虚机，虚机不再自动硬重启。 3. 定位该问题是稀疏拷贝功能导致的，稀疏拷贝功能可加快从镜像创建云盘的速度，但当云盘上有脏数据时，可能会导致需要数据与原始镜像不一致，从而NFVO_02虚机无法进入操作系统。 4.TECS上关闭稀疏拷贝功能，在主备控制节点上分别执行： openstack-config --set /etc/cinder/cinder.conf DEFAULT enable_sparse_copy False ----关闭稀疏拷贝 systemctl restart openstack-cinder-volume -----重启cinder-volume服务
Q：NFVO客户端登陆强制退出
A：测试IPOS数值如下： [root@NFVO_2_1 ~]# time dd if=/dev/zero of=/home/dd.dat bs=128kB count=10000 conv=fsync 记录了10000+0 的读入 记录了10000+0 的写出 1280000000字节(1.3 GB)已复制，8.9 MB/秒 [root@NFVO_2_1 ~]# time dd if=/dev/zero of=/mnt/dd.dat bs=128kB count=10000 conv=fsync 记录了10000+0 的读入 记录了10000+0 的写出 1280000000字节(1.3 GB)已复制，17.5 MB/秒 从测试结果来看，IPOS太低，低于40MB/秒。 IPOS低于产品的最低要求（最低要求为40MB/秒），导致了这个故障，需要硬件解决提升速度。
Q：ZXUN xGW-发送过多ARP会导致5960的CPU冲高
A：现场进行业务割接之前的巡检，发现低通域3框59交换机CPU利用率达到47%左右，处于非正常状态，此时还没有承载PS业务。经过在5960上面抓包，发现是vGW内部媒体面每2秒发送一次免费arp， 24块PFU中的每一个PFU都在发送，导致导致59CPU处于较忙的状态。
1，首先查看告警信息，判断5960 CPU使用率过高。
2，在高通量5960上面进行抓包，发现是现网中某些网元发送大量的免费arp报文；
3，核对MAC地址和接口IP地址，发现是vGW网元发送该报文，该局共有20多块PFU，大量免费arp在OF域的vnet中广播复制，导致59CPU处于较忙的状态。
4. 关闭该免费ARP的发送。
vGW(config-xgw)#end
vGW#olleh
vGW(config-corporation)#su 18
vGW(config-corporation)#
vGW#
vGW#conf t
Enter configuration commands, one per line. End with CTRL/Z.
vGW(config)#xgw
vGW(config-xgw)#list 2082
Index Current Default Comment
2082 0 2 <0,1800> Free Arp Sending interval for I
nnerMedia(RAW)(unit Second).
vGW(config-xgw)#sof
vGW(config-xgw)#softpara 2082 0
vGW(config-xgw)#Q：ZXUN xGW-用户申告话单文件中出现了上个月的用户话单
A：检查PGW缓存话单文件，发现PGW话单积压较多; 检查PGW的当前和历史告警，发现其中一个CPU频繁出“与CG断链”告警。 确定是由该CPU故障，导致PGW话单积压。且由于链路时好时坏，在链路恢复正常时可能会导致PGW回吐之前的话单。 更换该CPU所在子卡后恢复。
Q：ZXUN xGW-全网QCI如何进行规划进行规划
A：QCI是承载级别的参数，用于区分业务或者用户级别的资源调度。现网中涉及该参数的有HSS，UE、eNodeB、MME、SGW/PGW及PCRF，现网中HSS签约、PCRF上管控策略对该参数规划不一致，eNodeB上的调度方式不一致，都会造成用户体验差异，为满足市场QoS产品推广需求，用户全网体验须一致，因此对QCI进行全网规划。 QCI有9个取值（可扩展1-254）
Q：MANO-某项目在进行实例化过程中，虚机全部启动成功，但在初始化OMP时，提示初始化OMP超时;
A：查询VNFM日志如下： 17:02:33,225:[INFO][<a70b6a42-c262-4e29-86b9-82145bf30279>[vnfinitiation]:s_vnfm.vnfinitiation.instOmmOmpAckBiz:459]:[VNF instantiation] handle instance omp ack start 17:02:33,225:[INFO][<a70b6a42-c262-4e29-86b9-82145bf30279>[vnfinitiation]:s_vnfm.vnfinitiation.instOmmOmpAckBiz:460]:[VNF instantiation] omp_ack_data="info":"Event[5000011] timeout on OMP side, please contact the related developers!!!", "process":"240", "vnfinstid":"f9f1a2c5-c4b9-4117-ac1f-304dc6fadae4", "sessionid":"f9f1a2c5-c4b9-4117-ac1f-304dc6fadae4-1-0e524884-58e5-11e8-991a-fa163e285b26", "oper_id":"20180516164224582929", "action":"inst vnf", 17:02:33,225:[INFO][<a70b6a42-c262-4e29-86b9-82145bf30279>[vnfinitiation]:s_vnfm.vnfinitiation.instOmmOmpAckBiz:470]:[VNF instantiation] vnfinst_id=f9f1a2c5-c4b9-4117-ac1f-304dc6fadae4,session_id=f9f1a2c5-c4b9-4117-ac1f-304dc6fadae4-1-0e524884-58e5-11e8-991a-fa163e285b26,action=inst vnf,process=240,oper_id=20180516164224582929,info=Event[5000011] timeout on OMP side, please contact the related developers!!!,pkg_id= 17:02:33,236:[INFO][<a70b6a42-c262-4e29-86b9-82145bf30279>[vnfinitiation]:s_vnfm.vnfinitiation.instOmmOmpAckBiz:110]:add_omp_inst_progress progress=255, cache_info_progress=83 根据实例化的策略流程Event5000011是VNFM初始化OMP; 收集OMP的日志信息，反馈研发分析，发现VNFM上等待OMM和OMP初始化的时间过短导致初始化OMP失败。 查询VNFM上的默认配置如下： /home/ngomm/vnfm_3/server/nfvpub/config/vmanager.ini vnfm.ommrep = 120 vnfm.omprep = 120 vnfm.inst.vnfreported.interval = 600 /home/ngomm/vnfm_3/server/conf/deploy-comm-conf.properties vnfm.ommrep=600 vnfm.omprep=600 vnfm.inst.vnfreported.interval=600 根据研发建议，将vmanager.ini和deploy-comm-conf.properties中的时间修改为30分钟，如下所示： /home/ngomm/vnfm_3/server/nfvpub/config/vmanager.ini vnfm.ommrep = 1800 vnfm.omprep = 1800 vnfm.inst.vnfreported.interval = 1800 /home/ngomm/vnfm_3/server/conf/deploy-comm-conf.properties vnfm.ommrep=1800 vnfm.omprep=1800 vnfm.inst.vnfreported.interval=1800 然后重启VNFM进程。 cd /home/ngomm ./killall.sh ./run.sh 重启VNFM后，重新进行实例化成功，问题解决。
Q：ZXUN CSCF-SSH OMM 7788 端口报 no matching key错误
A：1、根据报错来看，内容大概是说两端的密钥算法不同，这是属于客户端问题，需要第三方SSH厂商检查他们是否支持标准的SSH加密算法，一般来说CGSL和RHEL、CENTOS一样，都是使用标准的ssh加密算法； 2、该问题编辑客户端侧操作系统 /etc/ssh/ssh_config文件，添加 diffie-hellman-group1-sha1 到相应位置，让其支持这个算法后，ssh 7788端口登陆正常。
Q：USPP HLRe CMM单板上报SNTP时钟同步超门限告警如何处理？
A：登录CMM手工进行时间同步，消除时间差 1、使用 root/root telnet CMMIP 24端口; 2、syscfg进入配置模式; 3、使用syn_clock进行时间同步.
Q：SSS网管服务器硬盘空间占用过大告警问题如何处理？
A：1、从告警分析，告警是指SSS的后台OMM网管硬盘占用过大，登录系统使用df -h查询硬盘使用情况;
2、从结果来看，/目录占用达到93%，因此出现一级严重告警;
3、继续分析哪个目录占用空间大，使用命令 du --max-depth=1 -h 查询当前路径的一级目录的空间占用情况，发现/var/log占用约20G;
4、继续查看log目录下哪些文件较大，使用ll命令;
5、从查询结果来看，btmp、secure两个文件差不多一共20G左右，是导致硬盘占用过大的主要原因，问题基本定位需要对这两个文件进行处理;
6、通过查询得知，secure和btmp两个文件作用如下
1)/var/log/secure：记录登录系统存取数据的文件;
例如:pop3，ssh，telnet，ftp等都会记录在此.
2)/ar/log/btmp：记录登录到服务器的信息记录，由于被编码过，必须以last解析;
例如:lastb | awk '{ print $3}' | sort | uniq -c | sort -nr | more
7、可见这两个文件主要用于记录一些登录日志，属于安全加固的要求，可以对文件进行清空处理;
8、使用命令清空文件命令，将两个日志文件清空:
cat /dev/null > secure
cat /dev/null > btmp
清空后查询硬盘占用降低，SSS的告警也在一个硬盘空间的检测周期后恢复，至此问题解决。
Q：ZXUN USPP-SOAP接口营帐受理失败如何处理？
A：1、将BOSS受理指令与平时的受理正常的开户指令进行对比，发现<HLRSN>1</HLRSN>这个字段带的值不一致； 2、<HLRSN>1</HLRSN>需要与管理域的ID一致，BOSS新放号指令中携带错误，未与HSS匹配，导致受理失败，BOSS调整后放号成功。
Q：ZXUN USPP-IMS HSS 放号失败提示Can not find the database
A：1. 检查UDS状态，所有节点状态正常，包括DSA/DST节点； 2.检查号段配置，号段配置无误； 3.检查DSA组及分布情况，配置无误； 4.按照工程数据设置规范，再次检查UDS配置情况，没有发现问题； 再次检查开户要求，发现开户时需要配置客户的sub ID， 检查DSA号码类型配置，配置为： DN&IMSI&PVI&PUI&WPSI&SERVERID&SP；怀疑是没有添加支持SUBID的类型。放号测试时不配置SUB ID 放号成功。 5.修改DSA号码类型配置,将SUBID添加至IDSA号码类型中，再次按照客户要求，放号时携带SUBID， 放号成功。
Q：ZXUN RCP-PCRF产生SNTP同步失败告警
A：1.SHOW SNTPSRV检查NTP服务器参数与规划的一致; 2.OMM上NETSTAT检查其他服务是否绑定了show SNTPSRV的NTP服务器端口，未发现其他服务; 3.关闭chost ,kill -9 2260；修改SNTPSRV中的数据，和原有一致即可; 4.查看本地服务器启动失败告警是否消失; 5.未消失的话，可以采用如下方法恢复： 5.1 在omm 上service ntpd stop；ntpq -p检查; 5.2 在omm上关闭set NTPSTAT,停止服务器端功能; 5.3 修改SNTPSRV中的数据，和原有一致即可; 5.4 在omm上关闭set NTPSTAT,开启服务器端功能; 5.5 在omm 上service ntpd start；ntpq -p检查. 6.在查看告警是否消失，接下来处理sntp时钟同步告警: 6.1 查看sntp配置，确认更新周期为30分钟; 6.2 UPD TIME发起强制更新; 6.3 等待一个同步周期后，SHOW TIME 查看时间已经同步并且SNTP告警消失.
Q：郁金香弹性云系统-TECS告警接入NFVO如何配置？
A：1.对于P8版本，请通过iptables -L -n -v |grep udp检查1161端口是否已放通。
2.新增允许通过规则
[root@Controller0115 ]#iptables -A INPUT -p udp --dport 1161 -j ACCEPT
[root@Controller0115 ]#iptables -A OUTPUT -p udp --sport 1161 -j ACCEPT
3.保存安全规则到配置文件
[root@Controller0115 ]#iptables-save > /etc/sysconfig/iptables
4.检查配置已经生效
[root@Controller0115 sysconfig]# iptables -L -n -v |grep udp
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1161
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:1161
Q：ZXUN XGW 与OCS对接无法触发向OCS发送CCR消息
A：1、检查到OCS的链路，在XGW通过 show pgw diameter link-state ，可以看到到OCS的链路都是open的状态，说明到OCS的链路都是正常; 2、检查在线计费的配置数据，各个配置数据已经正确配置； 3、确认数据配置无误后，检查软参参数，进入特权配置模式，查看软参244，软参设置为0，也就是当存在CC值时才会启用在线计费，而现场对接的HSS并未下发CC值，所以在线计费失效； 4、ZTE_XGW_21(config-xgw-pgw)#softpara 244 1 把软参改为1后，在线计费生效，查看用户信令跟踪，发现PGW已经向OCS发送CCR消息了。
Q：郁金香弹性云系统Openstack-TECS_多路径错误问题如何处理？
A：1、应该是之前在该主机创建过云盘，后来删掉了，但主机上的记录没有删掉，因此用multipath命令查看还能看到，需要手工删除。 2、在主机上可以通过./rescanHost.sh -r luns=0命令删除，但这样会把所有lunId为0的盘都删掉： cd /opt/multipath/tools ./rescanHost.sh -r luns=0 说明：-r 表示删除，luns=0，表示待删除的盘lunId为0，也就是现场的要删除的盘的四元组的最后一位。 3、使用echo 1>/sys/block/sdd/device/delete命令对上面有问题的盘一个一个进行删除： [root@host-10-126-35-72 tools]# multipath -ll Oct 12 10:31:27 | sdd: alua not supported Oct 12 10:31:27 | sde: alua not supported Oct 12 10:31:27 | sdc: alua not supported Oct 12 10:31:27 | sdb: alua not supported mpatha (360002ac000000000000003fa0001a2d3) dm-2 3PARdata,VV size=20.000G features='0' hwhandler='1 alua' wp=rw |-+- policy='spp-rr 0' prio=0 status=enabled | |- 2:0:0:0 sdd 8:48 failed faulty running | `- 2:0:1:0 sde 8:64 failed faulty running `-+- policy='spp-rr 0' prio=0 status=enabled |- 0:0:1:0 sdc 8:32 failed faulty running `- 0:0:0:0 sdb 8:16 failed faulty running [root@host-10-126-35-72 tools]# echo 1>/sys/block/sdd/device/delete [root@host-10-126-35-72 tools]# echo 1>/sys/block/sde/device/delete [root@host-10-126-35-72 tools]# multipath -ll Oct 12 10:40:33 | sdc: alua not supported Oct 12 10:40:33 | sdb: alua not supported mpatha (360002ac000000000000003fa0001a2d3) dm-2 3PARdata,VV size=20.000G features='0' hwhandler='1 alua' wp=rw `-+- policy='spp-rr 0' prio=0 status=enabled |- 0:0:1:0 sdc 8:32 failed faulty running `- 0:0:0:0 sdb 8:16 failed faulty running [root@host-10-126-35-72 tools]# echo 1>/sys/block/sdc/device/delete [root@host-10-126-35-72 tools]# echo 1>/sys/block/sdb/device/delete [root@host-10-126-35-72 tools]# multipath -ll [root@host-10-126-35-72 tools]# cd /sys/block/ [root@host-10-126-35-72 block]# ls -l total 0 lrwxrwxrwx 1 root root 0 Oct 6 19:09 dm-0 -> ../devices/virtual/block/dm-0 lrwxrwxrwx 1 root root 0 Oct 6 19:09 dm-1 -> ../devices/virtual/block/dm-1 lrwxrwxrwx 1 root root 0 Oct 6 19:09 sda -> ../devices/pci0000:00/0000:00:02.2/0000:07:00.0/host1/target1:0:0/1:0:0:0/block/sda 4、删除后再使用multipath命令查询，确认多路径已删除： [root@host-10-126-35-72 block]# multipath -ll [root@host-10-126-35-72 block]#
Q：虚拟化管理和编排-工具安装NFVO卡死问题如何处理？
A：删除mano-installation\apache-tomcat-8.0.32\webapps\ZTEAutoDeployer\runtime目录下文件重新打开工具部署。
Q：ZXUN xGW-冗余文件导致EMS硬盘使用超门限告警问题如何处理?
A：对XGW的/datadisk0/dpi_tool文件夹内容进行查询，发现都是通过EMS的PGW pool功能进行DPI批量加载的过程中产生的文件，EMS的备份任务会同步这个文件夹保存相关文件。导致硬盘占用空间超大。
查询结果如下：
CSSAE-GW06BZX#cd /datadisk0/dpi_tool
CSSAE-GW06BZX#dir
Directory of MPU-0/21/0: /datadisk0/dpi_tool
269851320 KB total (252928860 KB free)
attribute size date time name
1 <DIR> 4096 09-14-2017 05:46 .
2 <DIR> 4096 09-14-2017 05:46 ..
3 ---- 601 10-19-2016 01:02 dpiconfig.xml
4 ---- 2917165 10-19-2016 01:02 treat.zip
5 <DIR> 4096 10-19-2016 01:02 backup
6 ---- 28567011 04-20-2016 15:06 DPI_POOL_20160420120711.bin
.....
XGW的DPI文件会保存在sysdisk0下，这个目录下的文件并没有使用到，手动通过命令删除XGW的/datadisk0/dpi_tool的冗余文件后，EMS硬盘超标问题解决。
Q：ZXUN xGW-如何实现只针对国际漫游用户输出SGW-CDR话单设置？
A：在SGW下执行如下命令： home-plmn mcc 460 mnc 00 name cmcc46000 cdr-filt enable home-plmn mcc 460 mnc 02 name cmcc46002 cdr-filt enable home-plmn mcc 460 mnc 04 name cmcc46004 cdr-filt enable home-plmn mcc 460 mnc 07 name cmcc46007 cdr-filt enable
Q：ZXUN CSCF-如何取消网管登录时的验证码？
A：使用下面指令进行关闭，同样适用于其它V4系统的网元（AS、MGCF、MGW等） SET CHECKCODE:SWITCH="OFF";
Q：ZXUN uMAC-MME默认IMSI鉴权关闭导致终端附着失败
A：1、检查MME的IMSI默认鉴权配置（SHOW MME IMSI AUTH DEFAULT），发现IMSI和GUTI附着的鉴权都为关闭状态， 新增针对测试IMSI的鉴权配置： ADD MME IMSI AUTH:IMSI="460XXXXXXXXXX",SERVICETYPE="IMSIATTACH",AUTHTYPE="Force"; ADD MME IMSI AUTH:IMSI="460XXXXXXXXXX",SERVICETYPE="GUTI",AUTHTYPE="Force"; 2、新增以上配置后，重新测试，UE响应ESM information request消息，用户正常附着。
Q：ZXUN USPP-OMM操作日志导出备份方法?
A：当前USPP系统中，OMM操作日志主要有如下两种方法实现导出。 1.命令SET LOGCLEAR PARAM设置操作日志导出及清理相关参数。同时，通过转储导出文件的设置，将导出文件转储到第三方平台保存。 命令示例如下： SET LOGCLEAR PARAM:CMDLOGDAY=60,SECLOGDAY=60,SYSLOGDAY=60,MAXCOUNT=12,CLEARINGTIME="02:00",IFEXPORT="YES",EXPORTFILENUM=4,IFUPLOAD="YES",FTPPATH="ftp://10.42.225.225/tmp",FTPUSER="root"; 通过命令中参数设定，可以定时将网管数据库中超过保存天数的日志数据导出为文件，并根据需要转储到第三方平台。 2.通过命令ADD AUTO STRATEGY配置定时备份策略，命令中可以选择对日志数据进行备份，但是此备份结果无法直接通过文本方式打开查看，需要恢复到网管系统中后通过网管命令查看。 命令示例如下： ADD AUTO STRATEGY:ID=1,NAME="CMD LOG",OUTPUTPATH="/tmp",BASEFILENAME="CMDLOG",TIME="03:00",SETID=1027; 其中SETID参数通过SHOW SYS SET命令查看。 命令 (No.2): SHOW SYS SET 系统对象集合编号 系统对象集合名称 ----------------------------------- 2 告警数据 1025 性能数据 1027 日志数据 1029 自动备份策略 5000 NTP配置 5001 设备巡检数据 5002 用户设备跟踪数据 1400000 基本配置数据 1400001 IP协议栈配置数据 1400099 网管数据库文件 ----------------------------------- 记录数 10
Q：ZXUN CSCF-刷新注册时出现403失败码情况
A：1、通过终端本地抓包，终端向核心网发送REGISTER消息，核心网返回403错误； 2、在S-CSCF网元打开失败观察，双击失败展开所有失败，可以发现value为154133197的失败描述为：UC_REG CSeq Is Not Larger Than The Before CSeq； 3、通过第二步的失败描述，可以发现后一次CSeq的值不比前一次大。根据该失败，将注册请求的CSeq增大，然后重新发起注册，注册正常。
Q：ZXUN CSCF-NCMM时间同步超出告警门限处理
A：1、首先登陆到OMM登陆到NCMM单板上，查看NCMM日期配置情况，NCMM地址计算方式为：主备单板浮动地址=位于左边槽位单板物理地址+30； 2、登陆后，确认NCMM时间已经配置SNTP； 3、查询下NCMM当前时间，发现NCMM当前时间与SNTP服务器时间存有时间差； 4、通过 syn_clock 命令同步SNTP服务器时间后告警消除。
Q：ZXUN SSS-拨0上话务台后备用号码话机来电显示长号码而不是短号码，用户要求显示短号码
A：1、拨测跟踪信令发现，SCSCF发给AGCF的信令中，号码显示字段中的PAI是7位长号码，查看该备用号码签约有被叫彩铃和挂机短信； 2、备用号码5508344签约有挂机短信和被叫彩铃。 3、备用号码5508344去掉挂机短信后拨测正常。
Q：固网IMS开局，注册流程中CSCF网元不下发无401消息，导致注册失败。
A：1.信令跟踪发现S-CSCF不下发401鉴权； 2.检查401相关配置,在配置管理——策略数据配置——安全策略配置，查看“初始register请求的安全比例”一项配置异常 3.该项配置修改为100，重启光猫再次注册，出现401消息，且注册成功。
Q：ZXUN USPP-如何设置OMM客户端采用HTTPS方式登录?
A：启用https方式登录，参照以下执行操作：
1、登录网管服务器机器，在/home/ngomm下建立文件.htaccess，输入以下内容：
RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]
2、同时编辑/etc/httpd/conf/httpd.conf，/home/ngomm/config/bakhttp下的文件，修改以下内容：
<Directory "/home/ngomm">
Options Indexes FollowSymLinks
AllowOverride None——————修改为All
Order allow,deny
Allow from all
</Directory>
<Directory "/home/ngomm/*">
Options FollowSymLinks
AllowOverride None——————修改为All
Order allow,deny
Allow from all
</Directory>
3、使用service httpd restart命令重启apache。
启用HTTPS方式登录则无法再使用HTTP方式登录，修改登录方式对系统无影响。Q：MRFP网管服务器admin账号密码丢失如何处理？
A：1、一般系统的admin密码可以通过对admin账号的清空进行重置操作， 操作方法如下： 使用root用户登陆网管服务,“******”标注的地方需要根据实际清空填写。 [root@MRFP01-OMM02 ~]# cd /home/ngomm_data/ngomm_db/******/ [root@MRFP01-OMM02 ngmgw_w_71]# sqlite3 sqlite_sm.db SQLite version 3.6.17 Enter ".help" for instructions sqlite> update sm_user_table set userpasswd='b6b23b3e294a7fe4f0ef9a0489e61c1e' where userid=0; sqlite> .q 2、密码清空后，需要重启网管进程才生效。
Q：SBC收到核心网发的invite消息之后马上回了400 Bad Request。
A：1、查看400 Bad Request 消息中带有失败码，X-ZTE-Cause: "SBC-5711"， SDP中a行有语法错误，应该是对方发的invite消息有问题； 2、对比正常的消息，除了ptime参数过小，其他的都一致。正常消息中为a=ptime:20， 而本消息中为a=ptime:2。媒体打包时长为2ms太短了，需要对端修改此参数值 3、RFC4566 中ptime的解释为This gives the length of time in milliseconds represented by the media in a packet. 就是一个数据包中媒体的时长，以毫秒为单位。例如：ptime:20就是定义为20毫秒。虽然没有明确定义取值范围，但2ms明显是不合理的，通常取值为10的整数倍，G711媒体时长默认20ms，G.726媒体时长默认是10ms，G.729媒体时长默认是30ms等。
Q：针对漫入测试号码在MME上做扩展APN，配置完成后，无法正确解析到pgw地址。
A：1、配置完扩展APN后，跟踪消息，发现MME发起了DNS查询； 2、DNS上并没有配置相关APN的解析数据，所以pgw地址解析失败； 3、检查扩展配置ADD MME EXAPN中，有如下两项： Support Roaming User Extend when Visited PLMN Access Support Roaming User Extend when Home PLMN Access 配置均为no； 4、至此发现问题所在，因为配置的号码为国际漫游号码，所以需要在ADD MME EXAPN指令中把这两项开关打开，问题解决。
Q：ICSCF出现很多数据区容量告警，持续1秒自动恢复。
A：1.查看ICSCF注册和会话全局话务统计，发现注册全局话务统计里面，在某些统计时间段内“初始注册尝试次数”明显比正常时候大了好几倍，初步判断是注册风暴导致ICSCF数据区告警。 2.在ICSCF上跟踪注册即时话务，告警出现时，发现大量相同的号码在同一时间多次注册失败、接入主机地址不是本省PCSCF的IP。 3.检查ICSCF的路由分析，由于之前在两套ICSCF上，对外省CSCF入口的uri分析gz.ctcims.cn，删除sip方法里面的register（禁止本省固网IMS用户漫游出去），但这个分析子里面还有条ctcims.cn分析是查询DNS。而此时，在外省有设备尝试模拟本省的IMS号码进行大量注册，icscf收到消息后，分析匹配到了ctcims.cn查询DNS（ctcims.cn这条URI的分析还包含了register方法），所以送给另一个ICSCF。另一个ICSCF收到消息后进行同样处理，送回来，导致注册循环。 4.将ctcims.cn这条uri的分析里面的register方法删掉后，问题解决。
Q：ZXUN iCX-V4 CU客户端admin账户密码忘记了，需要重置为admin。
A：1、首先确认密码所在的配置文件，位于：/global/bill/data下的agent-cg-plat-data.xml文件中，并备份该文件； 2、账户admin对应的密码位置为： <primary name="PK_R_USER"> <field>NAME</field> </primary> <primary name="PK_R_USERID"> <field>ID</field> </primary> <record> <NAME>admin</NAME> <ID>0</ID> <PASSWORD>1646d696e6</PASSWORD> <ROLEID>0</ROLEID> 3、用vi编辑该文件，修改admin账户的密码为1646d696e6，标示密码为admin的密文； 4、修改完毕后，重新启动计费进程bill-app资源后再次登陆生效。
Q：ZXUN SSS-VOLTE用户补卡做被叫，通话提示为空号。
A：1、HSS查询用户为VOLTE用户，用户状态正常。 2、在SSS网元查询VOLTE用户注册状态正常，查询用户的BOSS指令记录，发现用户签约的无条件前转业务，前转号码为31311...,格式不符合规范。 3、IMS网元SSS对用户呼转业务进行修改规范格式后，问题解决。
Q：MME通过OSPF对接其他网元的时候，路由发布失败。
A：1、在PE和CE检查，已经学习到两端的路由，且从CE ping两端都能ping通，基本定位在两端的设备配置或者路由问题。 2、从对端trace MME，只能到达CE，从MME trace对端，一跳都没有，基本定位在MME侧的路由或者配置问题。 3、在MME上show ip ospf database查询路由表数据库，MME已经收到CE发布的指向对端业务地址的路由条目，其类型为type-5。 4、但是在MME上show ip route vpn查询路由表，没有指向对端业务地址的路由。 原因是PE与CE之间启用了BGP，而MME的ospf使用了vrf，当通过BGP方式向ospf发布路由的时候，基于vrf的ospf只会检查这条路由，并不安装路由表。MME上需要关闭vrflite检查功能，才能正确安装路由表。 在MME增加如下配置解决： 1、进入ipstack； 2、router ospf命令进入对应ospf； 3、执行命令set capability vrflite 关闭该检查功能。
Q：ZXUN xGW-244软参的开闭对用户在线计费还是离线计费的影响
A：某局反馈在测试过程中，有些号码是后付费用户，按照流程，PGW不应该跟OCS有CCR-CCA交互，直接走离线计费上CG，但跟踪用户发现后付费用户依然跟OCS发送CCR，OCS回复CCA。 1、通过在PGW上执行show pgw subscriber-dynamic-info +用户IMSI或者MSISDN，看到当前EPS PDN charging characteristics字段为normal，确定该用户是后付费用户。 2、当CC值设定之后，还需要打开或关闭软参244，才能控制其按照/不按照CC字段去实现在线或者直接离线计费。 3、将244软参修改为0 enable，使之按照CC字段设定来计费，normal生效，问题即解决。 xGW01(config-xgw-pgw)#softpara 244 0
Q：虚拟化管理和编排(MANO)-OMP建链超时导致EMS实例化失败。
A：实例化EMS时，各模块的虚机已经启动，但是实例化失败，提示：Ompservice模块未收到OMP的注册请求消息。 建链超时，进行如下检查： 1、检查EMS和VNFM之间的网络平面vnflink是否互通，如果不互通，则处理互通问题； 2、如果以上链路是通的，可能是EMS那边启动超时，需要修改一下VNFM超时定时器，适量增加。 问题解决： 1、VNFM可以ping通OMP分配的IP，说明链路没有问题，应该是启动超时问题； 2、进入VNFM的服务器目录：/home/ngomm/vnfm_3/server/nfvpub/config/ cd /home/ngomm/vnfm_3/server/nfvpub/config/ 3、修改vmanager.ini文件中vnfm.omprep值，现场修改为1200s后，EMS建链成功，实例化成功。
Q：虚拟化管理和编排-实例化VNFM上传版本进度无变化问题处理。
A：实例化VNFM，上传版本包至导入进度40%时停止，长时间等待之后依然没有变化，进行如下分析： 1、采集/home/3part_tools/catalog/catalog/works/logs路径下所有文件，查看catalog日志，提示版本包已存在，在蓝图中心发现有发布状态的包，但是软件仓库里面没有这个包； 2、经过查询job信息列表看，后台实际已经很快就上报包已存在的错了，但是前端界面因为缓存原因未刷新进度，这个是前端有缓存进度不能及时刷新所致 。 解决方法：清除IE缓存即可解决这个问题。
Q：ZXUN SBC-SBC等待终端会话刷新消息超时释放会话
A：分析信令终端向SSS发的INVITE消息中，没有带”Supported: timer”，表明终端不支持会话刷新，不符合规范。所以信令第2767和2817条，SSS向终端回的200中没有会话刷新的协商结果。SBC上默认的“无信令检测释放呼叫的检测时长(call expire-time)”为半小时，半小时没有收到终端或核心网发的会话刷新消息，便发BYE消息释放了呼叫 所以该问题有两种解决方案：一是，解决终端不支持会话刷新的问题；二是，将SBC“无信令检测释放呼叫的检测时长”设置为系统最大值48小时，这是国际规范规定的最大通话时长，完全可以满足，据统计，95%以上的通话都在30分钟内。
Q：ZXUN SBC-不转发prack造成早释率过高影响接通率问题分析
A：分析现网接通率原因时，发现用户早释行为约占7%左右，对接通率影响较大，计划通过分析早释行为，从而达到提升接通率的目的。 由于终端问题不好控制和规范，网络重点进行了问题攻关，针对终端异常改变端口问题，提出了启用SBC纠错功能的网络侧兼容解决方案：中兴SBC不解析终端改变后的端口，利用终端注册时与网络协商的端口进行通信。现网采用该方案对分步骤在现网进行了验证，验证结果显示：该方案可以兼容此类终端修改端口造成的异常早释问题。我省实施该方案后，由于PRACK消息未转发造成的呼叫早释情况大幅度降低，有效提升了客户感知，全网VoLTE接通率提升0.8个百分点左右。 网络侧兼容功能开启方法：SPE(config-increte)#set switch 61 1
Q：ZXUN SBC-ISBC用户外呼省际VOLTE用户不通原因分析
A：ISBC接入的专线用户反映，拨打部分VOLTE手机用户有时无法打通，听不到回铃音。
经过定位发现：ISBC接收到接入侧送上来的呼叫后，把呼叫转送本省VOLTE核心网10.184.34.1，非precondition流程ISBC收到本省VOLTE转发的580消息后转给了主叫侧设备，整个流程就是一个固网外呼的流程，并且为非precondition流程，本信令中ISBC和本省VOLTE核心网处理流程都正常。
ISBC外呼为固话流程，通过VOLTE转接话务时，ISBC外呼为非precondition流程，要求被叫方回180消息，如果被叫方回了183消息，且消息中不带100-REL指示，主叫方收到183消息后不会有响应，还要继续等待被叫回180响应，因被叫流程有问题，没有回180消息，超时后释放呼叫，此问题需要被叫方规范流程。 Q：ZXUN iCX-入局invite携带参数不完整导致呼叫失败问题处理一例
A：某地开通voice over wifi业务，测试中发现某些情况下用户通过在wifi网络下注册到ims网络后呼叫CS用户时，发送给MGCF设备invite后直接返回了400错误，呼叫失败 查看信令跟踪，MGCF收到invite后立即返回了400错误 分析得知，这个country字段属于扩展字段，但是该参数一旦出现，则必须要赋值，不允许为空；如果该字段为空，sip协议栈编解码模块在解码时就会报错； 需要终端按照正常处理上报，在country参数中赋值。
Q：ZXUN uMAC- TECS2.0组网虚拟化uMAC出现虚机状态不一致告警
A：uMAC查询虚机状态不一致告警出现，网元查询是通过vnflink去vnfm查询的，出现这个告警，先要到MANO上查看是否能查到这个虚机的状态信息，如果查不到，再通过API接口到TECS上查询最底层的虚机状态信息； 最终解决方案 日志文件定时清理功能，在Director新版本解决，彻底解决建议升级Director版本。 临时规避方案 1. 手工删除/var/log/nginx/access.log文件。 2. 日常巡检操作中增加Director容器内 占用的检查。
Q：ZXUN uMAC-诺基亚HSS重启后中兴MME下的用户更新位置流程反复失败问题
A：失败突增的时间点是凌晨1点，通常这个时间点是割接操作的时间，怀疑有HSS重启操作。联系客户核心网维护人员，了解该地当天凌晨H省W市爱立信HSS进行过版本升级。 通过H省维护人员联系Z省维护人员，确认当天诺基亚HSS确有割接操作。通过Z省维护人员联系诺基亚工程师分析信令，证实与Service-Selection AVP的M标志位有关。 1、在中兴MME上把反复失败的用户detach，让用户重新附着。附着流程中ULR无需携带Active-APN，最终用户附着成功，不再出现反复ULR失败。 2、可以在中兴MME上配置AVP编辑，把Service-Selection的M标志位置为“1”。
Q：ZXUN iCX-关口局TDM物理资源割接后EC资源使用数量异常问题处理一例
A：某局使用我司V4设备替换现网我司V3关口局设备，在割接PSTN方向的话务后，出现EC资源急剧下降的现象，而且实际拨打测试也能够很容易复现出来听到自己回声的情况。 总结EC资源在V3和V4 Server上的处理方式如下：(下面的中继开关，指的是中继指示器中的“包含回声抑制”标签） V4出局： 中继开关打开时，ccSimpleControlECIndi简化回声抑制开关不打开的情况下，保留电路时关闭EC。后续出局侧收到ANM后，如果后向ACM/ANM中指示没有插入EC，则我们才插入EC。
Q：ZXUN iCX-某局反馈开启灵活话务控制功能后未能按照配置的限呼比例进行话务控制问题处理一例
A：首先确认V4上的灵活话务控制配置方法正确，为人机命令方式触发的话务控制； 查询中继组话务统计，发现的确存在v4上未按照比例而V3按照比例限制呼叫的情况，如下： 再次确认相关的配置数据正确无误的情况下，开始分析V4和V3的功能实现差异； 一个粒度内试呼次数仅88次，现场配置了40个CMP模块，平均分配到每个CMP的呼叫为2个，这样的情况下尽管配置的是按照90%的比例限制呼叫，但是如果CMP在该粒度内放通一次呼叫，则本粒度内统计数据就会显示只有50%的比例被限制。 V4的设备RMP和CMP分离模式下，在中继话务量较小的情况下，无法严格按照配置的百分比来灵活话务控制，如果现场有类似需求，可以根据中继组配置黑白名单方式来实现。
Q：ZXUN USPP-GT灵活变换不生效
A：经研发所内定位和测试，该问题为网管问题 SET GT:GT="8613000000",GTSL=1；使用此命令修改GT引用的灵活变换配置时，会同步修改Virtual GT Support（分局向GT变换）为support。导致GT变换的时候报错，查询GT灵活变换配置查找失败。（支持分局向GT变换的时候，查找GT灵活变换的配置索引为灵活变换配置ID+局向ID，由于灵活变换配置的局向都是0，所以会匹配不到；不支持分局向GT变换的时候，查找GT灵活变换的配置索引为灵活变换配置ID） 现场暂时规避方法，使GT配置灵活变换策略1生效，可以通过删除GT翻译配置，新增GT翻译配置来规避（新增不会被强制修改VGT参数）。
Q：ZXUN uMAC-MSC侧端口限制导致SRVCC不成功问题分析
A：某新开局，进行VOLTE的SRVCC业务对接，MME侧及MSC相关配置完成后，进行业务测试时SRVCC不成功，核查相关配置数据，均无异常，需要尽快分析解决该问题，以免影响业务测试。 1.MME侧关于SRCCC数据配置问题； 2.MSC与MME数据对接配置问题， 3.MME与MSC路由不可达问题； MSC侧需要放开端口，经MSC侧研发给出相关修改方案，将MSC侧的PORT端口修改为MME侧提供的端口后，MME侧获得SRVCC PS to CS Response消息，业务测试正常如下，问题得到解决；
Q：ZXUN iMG- MRFP网元云盘部署过程提示vol_type已存在问题分析及处理方法
A：mano发送创建云盘都是异步命令，第一次创建该类型云盘，还没有创建成功，第二个创建同类型的不同云盘命令也发送出去，此时第二个创建云盘命令会首先检查该云盘类型是不存在的，不存在该类型时也会发送创建命令时，但是此时因为上一个已经创建了，就会出现报错重复。后续版本解决。规避方法：首先在tecs上把这些云盘类型全部提前创建，当NFVO实例化时检查发现都已存在，则就不会再发创建云盘类型命令，也不会出现重复情况。 按照mano研发的建议，手工创建mrfp info文件要求的四个云盘类型后（并关联后端），成功实例化！ 本维护经验可让各位童鞋了解到，在存在多个磁阵后端的时候，可以通过云硬盘类型关联相应后端，从而实现不通VM部署在不同磁阵上的目的。前提是业务网元支持后端类型选择。
Q：ZXUN xGW-用户投诉上网速率慢问题处理
A：核实xGW的用户面的数据跟踪，看是否存在数据包的重传或者丢包的现象。因xGW上的数据跟踪包括去Gi口的数据包，也同时包括去无线eNodeB的数据包，根据数据包的分析，没有出现数据包重传或者丢包的现象，如下： 经对有限的信息进行分析的结果，目前基本可以排除核心网影响速率的问题，排除签约问题，影响速率的主要问题就是xGW的数据包传输，但是可以确认我们的xGW的数据包是正常的，所以基本可以排除核心网的问题，需要无线协助进行排除； 经过无线侧排查，无线侧发现用户所在位置的eNodeB因无线网络优化，在白天进行相关参数的修改，可能影响了用户体验。无线测试现场进行测试发现速率确实很慢，经无线回退数据后，速率测试正常，客户联系用户确认后，用户也反馈速率正常，问题得到了解决
Q：ZXUN xGW-不限速业务被PGW限速
A：现场签约了这个业务后测试发现，所有业务都被限速了，包括白名单网站的业务也被限速了。 采集现场配置和信令、数据跟踪相关信息进行分析 可以看出，通过DNS解析后，优先去匹配domain id的一级规则，而domain id的一级规则里，没有配8080端口，导致匹配这个一级规则失败了，从而去匹配默认的通配规则了。 增加一条8080端口的domain id的一级规则后，问题解决。
Q：ZXUN SSS-爱立信HSS 补充业务签约HSS回5015问题
A：SSS初始放号的时候，只放basic数据，不放telservices/IMS-ODB-Information/ATCFInfo，但会发UDR查询，爱立信返回的UDA中无ServiceData，后续业务订阅对SequenceNumber判断出现分歧 结论：爱立信对于UDA消息中ServiceData判断不符合3GPP TS 29.328 6.1.1和3GPP TS 29.328 6.1.2标准规范。 对于没有开通的业务，让UDA带回的消息中不添加空ServiceData数据。即关闭6802开关进行适配： SET SYS GLOBPARA:IDX=6802,CURVAL="0",3=0; 这个只能是临时规避是存在隐患的，最终解决需要爱立信HSS按照协议出版本解决。
Q：ZXWN MSCS-号码分析配置错误导致放音失败
A：用户反映 在用户无应答场景时， 部分端局下主叫用户无法正常听到 ”。。用户暂时无法接听。。“ 的提示音 内部信令可以看到：ev_timer_1定时器超时的流程，dwTimerParam=0x00052095 ，低2字节的0x2095表示数据区的索引，也就是图中的8341（十进制）。高2字节用于内部表示是哪个协议定时器超时了，0x0005是BICC代码内部对定时器的编号，5表示BICC_T9。ISUP有自己的编号，9表示ISUP_T9，通过信令看主叫局拆线也是因为定时器超时触发的拆线。 所以目前可以得出部分结论，被叫局60s后定时器超时所以触发放音，而主叫局60s后定时器也超时要触发拆线。 最终解决问题的手段很简单，但是过程还是很曲折的。所以开局时尽可能的按照数据规范配置数据。还是可以有效避免后期的陷阱的。
Q：ZXWN MSCS-CS_业务_DTMF传送方式配置不合理导致DTMF二次收号异常问题的处理
A：A国某国际局点关口局，该国端局用户拨打本国和其他国家的公共号码二次收号都没有问题，但唯独拨打B国用户时二次收号有问题。 局方是虚拟运营商，只有关口局，对接其他运营商的端局。该运营商在A国和B国分别有一个局点，两个局之间有互通，A国端局用户如果拨B国端局用户时，二次收号从A过关口局GMGW直接送到B国关口局GMGW，而如果拨打其他国家的话，会先送到国际关口局。 初步怀疑问题应该出在A国和B国两GMGW之间配置。 RFC2833跨局呼叫需要强制带外方式，让现场把A局MSCS上到B局的500局向的"DTMF Transfer Type"参数改为"FORCE-Out-band"，修改后测试，问题解决。从信令上看，ANM消息后会再发出带DTMF的APM消息，这样才是正常的带外方式。
Q：ZXUN xGW-实例化vGW虚机状态error一例分析及解决
A：TECS2.0、DVS组网环境下，xGW实例化时部署的所有虚机（MPU、PFU、PGW、SLB、STU、CDB等）状态都error，TECS OpenStack上发现虚机都没有选择到计算节点。 从现象上看，所有的虚机都error，问题可能出在info文件配置错误、虚拟环境资源不足等原因上，需要通过查看日志具体分析。 查看nova-scheduler.log调度日志。根据虚机的uuid号来查找（命令grep -r 'uuid' *），如下图，可以看到Filter PciPassthroughFilter returned 0 hosts for instance。该提示说明虚机所选择的网络类型出错，DVS环境下网络应该选择“normal”类型。基于此检查info文件，发现确系这个原因导致的。修改之后，xGW实例化成功。
Q：ZXUN xGW-用户使用第三方代理实现免费上网问题分析及处理方法
A：1、DPI DNS sheet中有些域名带有通配符“*”，PGW无法发起解析；部分域名解析结果存在重复，可能会导致互斥；有些域名实际已经不用，DNS服务器不能返回解析结果。为解决这些问题，可将所有FRAUD类型的域名全部合并到同一个DOMAIN ID下。这样做还可以简化DPI规则引用FRAUD ID的配置，一举两得。
2、PGW 574软参取值范围0-4，默认值为0，表示关闭该功能。值1-4含义如下，通常建议取值为2。
1) 无论当前dnsmap表中是否已经有该域名记录，都主动进行dns同步，该Dns响应不发给用户。
2) 若当前dnsmap表中已经有该域名记录，不主动进行dns同步，该Dns响应不发给用户。
3) 无论当前dnsmap表中是否已经有该域名记录，都主动进行dns同步，该Dns响应发给用户。
4) 若当前dnsmap表中已经有该域名记录，不主动进行dns同步，该Dns响应发给用户。
Q：ZXUN uMAC- ODB测试的几个问题
A：HSS 上的show epcopt中“MME/S4SGSN不支持特性导致漫游限制时的处理方式”（EPCRRDTUFACTION）四个值如下： • Contain RRDTUF AVP in ULA(RRDTUFAVP):表示在ULA消息中返回RRDTUF。 • Return User Unknown(USERUNKNOWN):表示在ULA消息中返回未知用户错误。 • Return Roaming Restricted(ROAMRESTRICT):表示在ULA消息中返回漫游限制错误。 • Do not contain RRDTUF AVP in ULA(NORRDTUFAVP):表示在ULA消息中不返回RRDTUF。
Q：ZXUN uMAC-MME Pool中各MME用户分布不均匀问题处理方法
A：业务严重不均衡，造成各MME负荷不均匀。 所以其归属区的128个以后的LAC区域下的用户可能会进入重新分配的流程而分到其它MME上，因而导致用户不均衡。 找到了问题原因后，最终的解决方法需要无线eNodeB升级版本增加能够存储的ServedGUMMEIs数目。 因此另外一个临时解决方案就是在SGSN/MME侧进行LAC数据的重新添加。先将所有的3G LAC数据添加，最后再添加2G的LAC数据。并且目前的3G LAC数据还没有达到128个，因此这样的方法可以有效使所有3G LAC映射的ServedGUMMEIs下发给eNodeB。
Q：ZXUN xGW-xGW 分区域割接预付费用户到OCS一例
A：某运营商新上线的OCS设备，但要求预付费用户分区域割接，也就是仅割接区域的用户才能送OCS,其他未割接区域用户不能送往OCS 了解到各区域的号码段是不一样的，对于这种割接方式，目前只有通过对用户号码进行预付费分析才能满足 1，先通过一个测试APN ztetest进行测试，如果通过在部署到商用APN上 2，先配置触发优先级模板 3，进入APN进行绑定优先级模板 4，默认关闭预付费功能开关5，按计费特殊和号码端进行预付费分析
Q：如何访问客户门户？
A：中兴知识库是在支持客户的过程中创建的解决方案库。 我们的许多客户发现，通过在这里搜索，您可以快速解决他们的问题。
Q：什么是中兴客户门户？
A：有关中兴产品的所有技术问题或疑问，请联系技术支持。 对于与帐户，订阅或授权相关的所有问题，请联系客服中心。
Q：郁金香弹性云系统-未关闭导致虚机网络不通的问题分析及解决方法
A：测试发现把6槽位的O迁移到2-4槽的任一位置，网络都是正常的，初步怀疑是6槽位的网卡安装错位、DVS绑定模式错误、后插交换板配置错误导致。 首先通过查询6槽位刀片的网卡是否安装错位。 刀片BIOS里Intel(R) VT-d是否设置为Disable，该功能必须关闭。分别检查了1槽和6槽的BIOS设置，第二批安装的硬件没有关闭VT-d功能。在手动关闭了这个功能后，迁移虚机到6槽位，网络通信正常，问题解决。同时现场将第二批安装的其它刀片也做了BIOS检查。 上面介绍了在DVS组网环境下检查虚机网络不通的常见方法，外场如果使用一键安装工具操作，VT-d功能都已关闭，最常见的还是网卡安装错位和DVS绑定模式错误导致。
Q：郁金香弹性云系统Openstack-云主机控制台故障解决方法一例
A：登录云主机控制台，提示failed to connect to server，控制台登录失败 对云主机进行迁移，迁移到另外一台服务器，控制台能正常启动，可以判断该故障是由于计算节点引起的。 计算节点需要检查的配置不多，重点检查/etc/nova/nova.conf文件配置 通过检查发现/etc/nova/nova.conf文件配置中vncserver_proxyclient_address=pcserver09实际是pcserver10，配置错误造成的，又由于该配置是通过读取/etc/hosts获取到的，由于/etc/hosts主机名和地址对应关系错误造成生成/etc/nova/nova.conf配置时候报错 修改为vncserver_proxyclient_address=pcserver10（实际主机名） 重启服务
Q：郁金香弹性云系统-计算节点扩容失败提示“provider*.rpm”不存在问题的分析处理
A：某据点扩容计算节点，OS安装成功后部署TECS失败，上报provider*.rpm does not exist in /var/tfg-sys/docker/docker_rpm 计算节点扩容比较简单，遇到这种问题还是第一次，下面将给出分析。 计算节点扩容操作非常简单，只要HA环境正常，基本都是一次性扩容成功。本例问题说明计算节点扩容需要check一下provider版本包，同时，如果扩容遇到问题，建议去分析容器下的api日志，找到具体失败原因再着手解决。
Q：郁金香弹性云系统-TECS DVS增加托管网口
A：DVS增加托管网口，可以实现与传统域主机互通。 环境描述：TECS+ 测试PC机 DVS原只使用一个物理网口，增加一个托管口，实现与外部PC机的互通。 一、DVS版本升级，如果版本较低需要升级DVS版本 二、dvs增加托管口
Q：智能云数据中心管理系统- 控制节点双机状态有failed项问题分析处理
A：TECS 2.0环境使用磁阵作为控制节点共享卷，在环境掉电或网络中断的情况下，控制节点双机状态会出现failed项（crm_mon -1查看），导致云环境异常。 外场环境要保证控制节点与磁阵间网络正常，如需要下电上电，务必按照如下顺序： 下电：计算节点--->控制节点--->交换机和磁阵 上电：交换机和磁阵--->控制节点--->计算节点 即便在异常掉电或网络中断的情况，也要严格按照上电顺序操作。
Q：ZXUN uMAC-ZXUN uMAC_EPC网络iPhone7 Plus手机无法完成LTE Attach
A：海外某新建局反馈iPhone 7 Plus手机无法在新建LTE网络完成附着，并提供了MME网元的信令跟踪。
首先分析信令，发现只要MME向手机发ID请求（IMEI），无线eNodeB就直接回复UEContextReleaseRequest消息。由于我们并不清楚这个期间，手机到底发了什么消息给eNodeB，导致eNodeB触发了UEContextReleaseRequest流程。
由于无线总是返回同一个失败码的UEContextReleaseRequest消息，在核心网完成内部排查后，我们将问题转给了现场无线同事排查，最终无线的排查结果是：Uecapabilityinformation消息中能力信息长度是759，超过当前eNodeB版本的限制（740），是无线侧的已知问题，需要升级版本解决。
iPhone 7 Plus手机Uecapabilityinformation消息中能力信息长度是759，这个参数在eNodeB上有限制，如果超过eNodeB所支持的最大值，可能导致附着失败。Q：ZXWN MSCS-CS数据业务问题定位信息采集方法总结
A：在外场CS data业务相对比较少见，一般维护人员相对比较生疏，一旦出现这样的业务场景问题，不知道如何采集信息反馈给后方研发协助定，因此，本文总结了该场景下的信息采集方法，便于外场引用参考。 CS数据业务出现故障需要定位，需要抓取MSCs&MGW用户信令，内部消息，和媒体码流以及IWF进程的打印。 1. MSCS用户信令和内部信令 2. MGW用户信令抓取
Q：ZXUN CSCF-网元SNTP不能同步一案例
A：某局CSCF网管报SNTP同步失败故障 经检查该SNTP同步架构为公司标准的三层NTP同步架构即： 使用vi /etc/ntp.conf 修改配置增加 需要增加server地址的restrict restrict 30.255.26.100 需要说明的是这个restrict配置如果omm做server需要增加OMP\CMM\独立单板的IP地址段，如果OMM作为客户端，需要增加上级U31的IP地址段。
Q：ZXWN MSCS-WCN核心网CS对接随路信令R2协议一例
A：某项目，根据局方需求，与临接局对接一条专用R2线路，走800专线，一条E1，30个时隙； 完成配置、对接之后，该线路可以正常使用。但过一段时间后发现，在仍有空闲CIC的情况下，新的呼叫无法拨入，无法占用上这些CIC。 在对无法占用的空闲CIC进行BLOCK、UBLOCK操作之后，或者对该DTB单板重启之后，CIC可以重新被占用。呼叫恢复正常。 R2是一个相当老的协议，而且在业界有多种版本存在，几乎每个厂商都会有自己的定义和版本，所以在进行R2协议对接时，一定要搞清楚对端的R2是哪个版本，对端的R2是按什么规范，最好知道它的信令处理流程，才能在对接时注意调整我司R2的信令规范，以达到双方匹配。
