华为CES业务不通或误码问题定位指导课件

2023/3/14CES业务不通或误码问题定位指导目录定位示意图常见告警说明CES业务性能说明配置参数要求典型案例信息采集定位示意图Page3一看告警，二查计数，三检配置，四做倒换，五测PRBS；常见告警说明(续）Page5告警名称常见原因及解决方法CES_LOSPKT_EXC网络侧丢包，伴随有ces_jtrudr.网络抖动导致报文乱序。伴随有ces_jtrovr.CES_MISORDERPKT_EXC一般会有ces_jtrovr。原因:1.多收了报文。例如：1+1保护配置不一致。2.网络抖动导致报文乱序。CES_STRAYPKT_EXC使能RTP头后,SSRC域不对。CES_MALPKT_EXCLEN域不对，两端装帧时间或时隙数不一致使能RTP头后，PT域不对。CES_JTRUDR_EXC通常伴随着DOWN_E1_AIS告警。一般是丢包引起。网络侧抖动过大，尝试调大JitterBuffer。CES_JTROVR_EXC参见CES_MISORDERPKT_EXC网络侧抖动过大，尝试调大JitterBuffer。备注:建议直接查看性能。这些告警都是性能越过高门限后上报告警，降到低门限后结束告警。有告警时，需要结合其他性能来判断故障原因。常见告警说明(续）Page6告警名称常见原因及解决方法CESPW_REMOTE_LOSPKT远端检查到丢包。表示本段->远端方向有丢包。查看对端性能，按丢包问题处理。CESPW_OPPOSITE_RAI远端UNI侧端口接收到了RAI告警。CESPW_OPPOSITE_ACFAULT远端UNI侧端口接收到了物理告警：LOS/LFA/LMFA/UP_E1_AIS备注：这3个告警必须CES业务两端都使能告警透传才会产生。这里的远端指的是端到端配置的CES业务的另一端。CES业务性能说明Page7CES线段是CES业务封装成包的点到对端的解封装的点。这段路径上业务都是包。ces_xxxpkt在端点检测。PW段是NNI侧单板统计业务性能点。pw_xxx性能在端点检测。

在解封装之后有一个JitterBuffer，它的作用是吸收网络侧抖动。ces_jtrudr/ces_jtrovr在端点检测。Tunnel性能对于定位单个业务不通问题帮助不大。使能PW性能监控的时候，不允许使能Tunnel性能。反之亦然。PRBS段是做NNI方向的PRBS的测试点。它基本上已经靠近端口，能够测出中间节点的丢包，改包问题。

当然也支持UNI方向的测试，可以测试线路侧的故障。配置参数要求参数要求帧格式(FrameFormat)本地业务如果不选择时隙，那么帧格式必须是unframe的。如果要选择时隙，也就是配置fractionale1业务，必须选择成frame的帧格式。(R2新特性)远端业务（分两种：STAOP-E1和CESoPSN)SATOP-E1，帧格式必须是unframe,可以承载任意帧格式的业务CESoPSN,帧格式必须是double-frame/crc4-multiframe,需要保持和对接设备帧格式一致。如果要在一个端口配置多条CES业务，也就是FractionalE1业务，必须选择CESoPSN这种传送方式。时隙数业务的总时隙数大于等于2装帧时间(LoadTime)要求两端一致（端到端配置时网管自动完成）抖动缓存(JitterBuffer)使用缺省值8000us即可。修改时，建议至少修改成装帧时间的2倍。Page10典型案例物理接口参数不匹配导致业务持续误码；带宽不足导致CES业务断断续续；中间SDH网络保护错误导致CES业务报文乱序中断；时钟不同步导致CES业务长时间测试误码；网络抖动过大导致CES业务误码；改包导致基站业务中断；中间网络丢包导致业务中断Page11故障案例——物理接口参数不匹配【问题现象】：客户配置了两站CES业务，NNI侧穿越第三方以太网络，无线设备检测到较高的误码率。PTN1900RBSFEE1PTN3900PTN3900BSCMetroEthernetGEGEGEPSNACACGEcSTM-1OSN3500E11+1MSP1:1APSWorktunnelProtectiontunnelPage13故障案例——带宽不足【问题现象】：客户配置了两站的远程CES业务，NNI侧为POS端口，刚开始CES业务通，但后来所有CES业务断断续续。【怀疑点】：新增业务后引起同一路径的其他CES业务都出现断断续续，最常见的是带宽不足；【定位过程】：(1)检查源端和宿端，无告警上报；(2)查询所有CES业务的CES_LOSPKTS性能计数都持续增长，很有可能是带宽不足；(3)检查网元NNI接口配置，POS端口模式为155M;(4)原来有60条业务，后来客户增加了几条业务，总流量超过了POS带宽；(5)将部分业务删除改建到另外一个POS端口，所有业务恢复正常；【定位小结】：在实际组网应用中，必须考虑网络带宽是否满足业务需求；Page14故障案例——中间SDH网络保护配置错误【问题现象】：客户配置两站的CES业务，网络侧POS端口，中间穿越A厂商的SDH网络，CES业务持续中断。PTN1900RBSE1PTN3900BSCSDHNetworkPOSE1POSA厂商A厂商Page15故障案例——中间SDH网络保护配置错误【定位过程】：(1)检查PTN3900设备，网元持续上报CES_MISORDERPKT_EXC告警；(2)检查设备内部CES接收到的PW包数量大约是正常值的2倍，同时有上溢告警，这说明收到了多余的报文；(3)检查NNI接口，POS端口的收发计数却是大致相等的；(4)一线工程师检查物理连线，看到PTN3900有两个POS端口与A厂商设备对接，于是拔掉没有配置业务的端口光纤，发现业务恢复正常，CES_MISORDERPKT_EXC告警消失，再重新插上，业务再次中断，又开始上报告警，这说明多余的报文是从这个没有配置业务的端口进来的，这个端口虽然没有配置业务，但配置了layer3属性和MPLS使能，所以不会丢弃这些多余的报文，这些多余的报文搅乱了正常的报文序列；(5)整改A厂商的网络保护配置后，业务恢复正常；【定位小结】：出现故障时，注意检查和第三方网络对接的相关接口；Page17故障案例——时钟不同步【怀疑点】：业务没有中断但周期性（分钟级别）地出现误码，最常见的是时钟没有跟踪正确。【分析过程】：(1)检查PTN设备，除了PTN3900有CLK_NO_TRACE_MODE告警（说明网元时钟处于自由震荡状态），无其他告警；(2)查询PTN设备的CES性能计数发现，每次出现误码时都有CES_JTRUDR计数但无PW丢包或乱序计数；使能CES业务历史性能，从历史性能上看到每周期ces_jtrudr计数基本相等。(3)检查时钟同步关系如下图所示，3900、1900网元和ANT仪表分别跟踪不同的时钟源，长时间运行后随着时钟漂移和时延抖动，导致缓冲区溢出，产生滑帧。(4)将仪表时钟源改为“Receiveclock”后，没有再出现误码。Page18故障案例——时钟不同步【定位小结】：CES业务要求时钟同步，因此在实际组网应用中必须优先考虑时钟跟踪关系；必须保证基站、接入PTN、落地PTN、BSC四台设备的时钟一致，中间设备的时钟不关心。PTN1900RBSPTN3900BSCPTNNetworkGEPage19故障案例——网络时延抖动过大【问题现象】：客户配置了多站的远程CES业务，NNI侧为MLPPP端口，CES业务断断续续出现误码。【怀疑点】：低速NNI接口承载的CES业务没有中断但断断续续，通常有两种情况：(1)长包引入较大的时延抖动；(2)带宽不足；【定位过程】：(1)检查PTN设备，无告警上报；(2)查询CES业务的性能，没有丢包，但CES_JTRUDR/CES_JTROVER性能计数持续增长；(3)检查网元配置，发现MLPPP只有一个E1成员，Tunnel和PW都是动态的，并且邻居节点很多;(4)由于动态IS-IS协议报文较多且达到960字节，按照理论计算，MLPPP每传输一个960字节的报文（加上开销）超过4ms，即每发送一个这样的包引入超过4ms的抖动，超过CES业务的抖动缓冲能力（正负4ms）；(5)增大CES抖动缓冲时间，误码消失；【定位小结】：如果NNI接口为小带宽的低速接口，而且还承载其他长包，很有可能引入较大抖动，影响CES业务Page21故障案例——中间网络丢包导致业务中断【问题现象】：客户反馈多个业务中断，查看性能，都是从基站到BSC方向丢包。【怀疑点】：光功率异常、链路故障、单板故障【定位过程】：(1)查看告警，有两个端口有光功率异常告警IN_PWR_ABN。但告警方向是从BSC到基站方向，和实际丢包方向不一致。做单向LSPPING证实了这一点。(2)找到几个业务经过的共同链路，有两段，依次进行L3VPNPING，找到故障链路。(3)客户确认中间有波分链路，但需要我们继续排查。(4)查看该段链路的端口性能，发现1024字节长度没有报文，因此做L3VPNPING，选择报文长度为1024，发送100个报文，结果在对端PTN端口的1024报文统计性能上，只收到68个报文，说明这个方向有丢包。同时对端回应了68个1024字节长度报文，而本端也收到了68个1024字节长度的报文，说明回来的方向没有丢包。(5)最后客户确认中间波分链路有误码告警。【定位小结】：合理利用端口性能和LSP/PW/L3VPNPING，可以迅速帮助我们对问题进行定界。Page22业务恢复如果客户急于恢复业务，而故障原因短时间内无法定位清楚，可考虑如下方法先将故障排除：(1)将业务从工作通道倒换到保护通道；(2)删建业务或新增业务；(3)修改业务路径；(4)复位设备；(5)更换设备；Page23故障处理——故障信息采集基本故障信息采集完整故障信息采集Page25故障处理——完整故障信息采集恢复业务后，采集完整故障信息返回研发分