承载网对接故障处理指南和典型案例分析.ppt

1、2020/8/8,核心网与数通对接故障处理和典型案例分析,Page 2,WCDMA网络总体组网图,说明：目前在联通WCDMA现网网络中，IU-PS口、Gn口、Gi口、Mc口等接口采用IP承载，实际组网需要和相关数通设备进行对接。,A,Iu-CS,Iu-PS,Mc,Mc,Gn,Gi,Nb,Nc,Gb,Abis,Iub,Gr,C/D,C/D,HLR,MSC Server,MGW,SGSN,GGSN,RNC,PSTN,Internet,GMSC Server,2G,接入,CS,其它网络,BSC,MGW,3G,接入,PS,承载通道,信令通道,BTS,Page 3,UMG8900,承载骨干网,CE,计费

2、系统,LANSwitch,MSoftX3000,FE,iGWB,CE,PE,LANSWITCH,DCN,M2000,核心网CS局端组网详细拓扑图,PE,LANSwitch,FE,FE,FE,GE,GE,GE,GE,VRRP,说明：1、如果PE路由器下面为CE路由器，而非交换机，则VRRP一般设置在CE路由器上，CE与PE之间运行OSPF。 2、目前现网Nb口还没有IP化，上图主要是描述信令承载的组网结构。后续IP化，建议UMG出GE口直连CE设备，承载媒体流业务。,OSPF,Page 4,核心网对接相关协议应用说明,1、ARP：ARP（Address Resolution Protocol,地

3、址解析协议），工作原理是本端IP接口板对其配置的默认网关发送ARP包，网关回送ARP响应。如果长时间无法获得响应，就判断这条路径可能存在问题，自动倒换相关接口板。ARP探测主要目的是为了避免某传输路径有问题而物理层检测不到的情况，导致不能正常切换。主要用于MSC server和LSW交换机组网情况下，对信令承载通道的安全保护。 2、VRRP：VRRP（Virtual Router Redundancy Protocol，虚拟路由冗余协议）是用于解决组网可靠性的问题。它保证当主机的下一跳路由器故障时，可以及时由另一台路由器来代替，从而保持通讯的连续性和可靠性。主要用于MSC server/MGW

4、和LSW交换机/CE设备组网情况下，对信令承载通道的安全保护。 3、BFD：BFD（Bidirectional Forwarding Detection，双向转发检测）用于快速检测、监控网络中链路或者IP路由的转发连通状况。主要用于MGW、SGSN、GGSN和承载网路由器连接组网情况下，快速进行媒体流/用户面业务的倒换保护。 4、OSPF: OSPF(OPEN SHORTEST PATH FIRST，开放最短路径优先）协议，主要运行于LSW三层交换机和AR路由器之间，在设备或链路故障情况下进行IP路由自动收敛。,Page 5,IP承载网对接问题总体定位思路及方法,1、及时监控检测故障 通过M2

5、000网管查看相关事件、故障告警（链路故障、TG脱网、丢包率高等）； 通过相关的承载网性能测试软件（如安捷伦的Application Analyzer 简称AA）对承载网系列QOS指标（如时延、抖动、丢包等）进行综合测试和监控。 2、判断故障是否与承载网相关 Msoftx3000维护台的PING 跟踪、Trace route功能; Msoftx3000以太网端口状态信息查询（如DSP FESTATUS、DSP IPSTAT等）; UMG8900维护台的PING 跟踪、Trace route功能； UMG8900以太网端口状态信息查询（如DSP IPIF、DSP IPFWD、DSP ROUTE、

6、DSP BFD等）; 3、进一步分析判断故障原因 业务完全中断（信令层面承载故障）， 检查单板及相连的LSW或CE设备状态、FE/GE端口状态、端口工作模式配置、丢错包统计等； 业务质量差（媒体流层面承载故障），检查相关单板及相连的AR路由器、分析业务流量模型、设备转发性能、UMG上语音质量告警等； 业务单通或双不通，UMG ping功能、查看语音编解码/EC配置，端口环回、录音等。,Page 6,对接案例一,案例1：MGW与MGC连接中断问题定位分析 【现象描述】MGW与MGC连接中断 ，网关无法正常注册到MGC。 【告警信息】H248链路/M3UA链路中断；MGW退出服务 【原因分析】 H

7、248&UA链路故障的可能原因以下几种情况： MSC Server故障、链路参数配置错误； 防火墙配置问题、IP承载网网络故障； 端口丢包/错包、端口down、端口协商模式问题 UMG网关解析失败、集中转发故障； IP承载网网络故障；,Page 7,对接案例一（续）,【处理过程】： 对Server故障。检查对接server的运行状态 。 防火墙配置：重点检查ACL的配置及过滤规则，根据LST FIREWALL和LST ACL的结果，确认是否是防火墙将UMG和Server过滤导致不通。 端口down：对于主备配置端口down将导致单板倒换，对于单配或者备用异常的情况下，端口down将直接导致链路

8、中断。端口丢包或错包可能造成链路检测超时，从而导致中断。 网关解析失败：在告警台检查确认告警日志是否存在3266号（The gateway resolving failed ）告警，网关解析失败可能造成链路检测超时，从而导致中断。 网络故障解决网路故障可以按照分段分析的原则：步骤 1：链路本端IP地址PING下一跳地址，看是否能够PING通。PING不通说明UMG和下一跳之间出现问题，需要分析UMG内部问题。步骤 2：使用本端IP地址PING对段IP地址（MGC上的地址），如果PING不通，说明和承载网相关，需要联合承载网专家一起处理。,Page 8,对接案例二,案例2：由于数通设备丢包问题导

9、致UMG上出现信令链路故障 【现象描述】：某局UMG和MSOFTX3000按照分离式组网，通过IP承载网连接，两端都是通过3528交换机连接NE40路由器并接入IP承载网。UMG于凌晨割接入网后，观察运行情况一切正常，但到早晨7点左右话务量逐渐升高时，出现大量PPU信令链路故障告警。 【告警信息】：信令链路故障告警重要告警 【原因分析】：1、IP承载网的抖动造成偶然的链路故障，出现告警到自动恢复间隔时间为6秒；2、UMG上连到交换机3528的端口模式和对方设置不一致；3、IP承载网的某一段存在问题。,Page 9,对接案例二（续）,【处理过程】：1、因为之前在其他局点出现过类似的问题，将最大允

10、许心跳丢失数调整为5次，延长H.248链路的心跳允许的响应时间，但操作后告警未恢复；2、通过信令跟踪及查看UMG系统日志，发现是H.248心跳连接长时间没有得到响应而被置为DOWN状态所致，因此怀疑和IP承载网通道相关。 3、比对UMG和3528之间的端口速率及双工方式等设置，发现两端一致，没有问题；4、通过MSOFTX3000对本端NE40进行PING操作，无丢包现象：PING对端UMG的NE40，无丢包；PING对端UMG有丢包，确定问题出现在UMG和NE40之间； 5、从NE40侧PING对端的3528有丢包，确定问题出现在对端NE40和3528之间；5、协同数通工程师查看3528和NE

11、40的设置，发现3528上连到NE40的端口的双工方式设成了自协商，而NE40上对应的端口设成了强制全双工；6、修改3528上的端口为强制全双工，问题解决！ 【建议与总结】： 1、在处理类似故障时，要首先详细了解具体的局端设备组网及物理连线情况，然后逐段排查。 2、端口协商模式不一致是核心网和承载网数通设备对接中的比较常见一个问题，在日常的工程维护期间需要重点检查和关注。,Page 10,对接案例三,案例4：因VRRP地址冲突导致BICC链路中断问题 【现象描述】：某大区SS1 BICC链路中断，导致落地话务中断 【告警信息】：BICC链路故障告警 【原因分析】：1、SS自身信令模块问题，导致

12、BICC链路中断； 2、SS本端IFM接口问题，导致IP承载及BICC链路中断； 3、IP承载网的某一段存在问题。 【处理过程】： 1、检查SS1相关单板模块的状态，结果正常； 2、检查SS1的IFM单板及后插板FE口，状态正常； 3、登录到和SS1相连的3526E检查，发现有IP冲突的异常打印信息（ IP ADDRESS 10.0.38.1 COLLISION WITH VRRP VIRTUAL IPADDRESS ON VLAN20,SOURCED BY 00D0-5938-50EA）,Page 11,对接案例三（续）,4、进一步分析冲突的IP地址，根据SS1的配置，10.0.38.1是与

13、SS1相连的两台3536E的虚拟VRRP地址，为MSX3000和UMG8900的缺省路由地址。3526E出现的打印异常信息表示收到异常的VRRP包，VRRP包是别的路由器发来的，用于广播自己的状态，实现主、备路由器的功能。从打印信息看这个路由器的物理地址是00D0-5938-50EA。 5、由此，确认是一台未知设备的IP地址与3526E交换机上的VRRP IP相同，引起IP地址冲突导致BICC链路中断。检查相关的物理连线，发现机房内存在一个未知的网线错误的接到了3526E设备上，将该网线断开后，地址冲突现象消失，BICC链路恢复正常，故障解决。 【建议与总结】： 1、将3526E上不用的物理端

14、口全部禁止，这样别的路由器即使接入也无法干扰我们设备的运行，在真正需要使用这些端口时才将其打开； 2、与设备维护人员强调说明，软交换网配套的CE/交换机等为核心网业务专用，严禁其他设备接入，同时采用在这些设备上贴上醒目的标签等方法警示，以防止误接入。,Page 12,对接案例四,案例5：某局UMG8900上行承载网两根发光纤故障导致网关失去注册 【现象描述】某运营商NGN长途汇接局UMG8900网关，采用GE口上行至两个NE80路由器平面（承载网）注册到SOFTX3000，UMG8900通过两组光纤两条信令路由上行至NE80路由器。故障现象为两组光纤中的两根发光纤同时损坏，导致至承载网两个平面

15、均不通，网关注册失去注册，整个TG网关下的业务全部中断。 【告警信息】UMG退出服务紧急告警、H248链路故障告警、UMG与软交换SS失去连接。 【原因分析】：1、目前，网关设备对GE口物理状态故障的检测机制是只检测收光告警，不检测发光告警。因此，如果一条光路上如果发光光纤故障，网关本端是感知不到的，需要对端数通设备配合检查确认； 2、G10单板至数通设备NE80路由器之间的两根发光纤故障，导致UMG中继网关失去注册脱网离线。,Page 13,对接案例四（续）,【处理过程】： 1、检查UMG网关至NE80路由器之间是否连通：登录故障的UMG8900设备维护台，利用Ping命令，检查UMG8900的下一跳网关是否能够连通，检查结果是不能够连通。 2、排查UMG网关至NE80路由器之间的光纤接点：找到TG网关至NE80之间的ODF架，以ODF架为界，用光纤测试仪分别对NE80侧做环回测试和对TG网关侧做环回测试。测试结果发现TG网关侧没有发光。 3、用同样的方法，对另外一块G10单板的光口上进