PTN故障定位指导.ppt

PTN故障定位指导,Page2,常见故障分类,用户操作错误：原因可能是版本不配套、当前版本尚未支持某些特性、用户未按照规定的步骤进行配置、源端和宿端的CES/PW/Tunnel参数匹配不上、业务被误删除等等；软件缺陷：原因可能是配置未下发单板/芯片、资源分配冲突、模块之间耦合处理不正确、异常处理不正确等等；,返回,Page3,常见故障分类,硬件连接错误：原因可能是单板/子卡未插紧、物理板/子卡和逻辑子卡不匹配、电缆/光纤/网线损坏或连接错误等等；硬件版本缺陷：原因可能是单板某些PCB版本不支持某些特性、某些PCB版本存在已知缺陷等等；硬件故障：原因可能是单板元器件/芯片损坏、单板元器件寿命到期等等；,返回,Page4,常见故障分类,PW/Tunnel故障：原因可能是PW/Tunneldown、PW/Tunnel相关的表项被错误改写、业务流经的物理链路中断等等；报文拥塞：原因可能是带宽配置过小、同优先级的报文流量过大导致丢包等等；,返回,Page5,MLPPP简介及常见故障定位,PPP简介PPP（Point-to-PointProtocol）：在支持全双工的同步或异步的点到点链路上提供传送和封装网络层数据包的数据链路层协议。MP简介ML-PPP（Multilink-PPP）：ML-PPP属于PPP的扩展协议。通过MLPPP协议可将多个物理链路捆绑成一个逻辑链路，扩展传输带宽。MLPPP属于位于PPP和网络协议层之间的高级数据链接协议。,Page6,MLPPP简介及常见故障定位,MLPPP是作为网络侧使用的，作为业务（如CES/ATM等）的承载工具。关于MLPPP定位手段，主要是定位协议不通的情况，如果协议通，MLPPP的使命基本结束了，网络侧传输业务，上网络后，MLPPP是不做动作的，可以说是直接透传到对端的,Page7,MLPPP常见故障,MLPPPDOWN查询当前告警,确认是否存在物理端口告警如E1端口:T_RLOSVC12通道:BIP_EXC/V5_VCAIS/TU_AIS_VC12/LP_UNEQ_VC12/TU_LOP_VC12光口:R_LOS查看处理板、子卡、接口板状态是否正常；逻辑物理是否一致两端是否对MP组设置了IP，且IP地址处于同一网段如果没有相关告警，PPP及MP都没有UP，请检查一下连线确定连线正确1两端创建的PPP使用的VC12通道是否相同,如果两端MP组使用的通道号不一致，协议是不会起来的芯片侧相应的VC12通道帧格式是否为framer,如果为unframer,则PPP是不会通的.芯片侧相应的VC12通道V5字节是否设置,Page8,IMA简介及常见故障定位,IMA业务的网络配置实例,Page9,IMA常见故障,IMA组无法协商：查询本端和对端的IMA链路的E1帧格式是否一致；不一致则设置成一致，如果告警存在则进行下一步处理；查询该通道是否有E1信号丢失告警；如果有请消除此告警，如果告警依然存在，则进行下一步处理；查询IMA组链路的状态；如果异常则进行下一步处理；通过环回设备电缆的方法检查本通设备是否工作正常；如果异常则进行下一步处理。若告警未消除，硬复位或插拔该单板，查看告警是否消除。若告警仍未消除，则本单板故障，更换该单板，告警会自动消除。如果步骤4正常,则是由于对接参数不匹配引起的协商问题.需要检查如下参数:信元加扰使能IMA链路时钟模式IMA组帧长版本E1帧16时隙使能,Page10,IMA常见故障,经典案例资阳开局测试E1时隙模式不一致导致对接IMA组协商不成功1现象和问题描述NODEB上的IMA组跟我们的3900设备IMA组对接不成功。2、关键过程、根本原因分析2.1首先是查询两边设备的IMA组属性，包括trunk号，链路号，帧格式，查询后发现上面信息是匹配的.2.2使用IMA组端口环回，想先尝试一下自己跟自己协商是否ok，首先排除一下是否芯片自己出现问题,结果是自环是没有问题的.根据这个情况就可以断定问题的根源应该是配置不匹配导致的.2.3查询最小集活链路数是1,排除由于最小集活链路数不足引起的IMA组协商不上的问题.2.4检查E1帧格式,发现两端都是CRC-4,排除帧格式不一致问题.2.5继续查询是ATM信元是否否加扰,发现两端加扰模式都是”使能加扰”,模式一致,排除加扰模式不一致引起的IMA问题.2.6查询IMA组的时钟模式,发现两端都采用ITC模式.派出了时钟模式不一直引起的IMA问题.2.7根据2.3的结论重新逐一确认两端的配置问题,而且在沟通中得知之前NODEB跟C01B028版本协商是ok的,很显然就想到了我们关于IMA组修改了一个用户可设置的时隙问题.最后经过对比确认是时隙的问题,因为在C02B028版本中我们IMA组的时隙默认是使用30个时隙(16时隙不使能),而且是不可配置的.到了C03版本以后我们把这个接口体现给用户了,而且默认配置是31时隙的(16时隙使能),这个主要是兼顾ppp一直以来31时隙的问题.3、结论、解决方案需要用户去设置链路的时隙,可以修改我们设备上的IMA组时隙或者是修改对端的IMA组时隙,只要保证两端一致性就可以.问题原因：更新了软件版本后IMA组的默认时隙做了调整导致的问题.解决方案：用户可以根据对方的时隙来设置我们设备上IMA组的时隙,不过如果是配置了业务后才发现IMA组协商不起来的话,需要首先删除业务和删除IMA组后才能修改链路上的时隙.,Page11,MPLS传送,MPLS模块面对最多的问题就是业务不通.对于这类问题,主要可以分为两大类原因:配置错误和软硬件BUG.所以再处理这类为题的时候,要做到充分了解环境组网,而且要在此基础上明确数据的流向,要找到报文在哪一跳出的问题.定位到网元后,在检查配置.明确数据流向,可以先根据以太业务的VLAN,ATM业务的VPI/VCI等信息确定是那条业务出问题,在看其V-NNI侧挂在哪条PW上.此时,我们找到对应的PW后,对于ATM和CES业务,可以先进行PWVCCV的Ping操作.因为目前的PWVCCV实现中,回应报文走的是IP通道,因此需要在两端网元分别Ping一次,如果两端Ping都没有超时,可以判断网络测没有问题.,Page12,MPLS传送,动态Tunnel相关问题：Tunnel创建失败或者TunnelDown链路两端的IP是否设置正确IS-IS是否已经使能光纤是否连接正确NNI端口之间的二层属性设置是否一致(tag/access/hybrid)查询是否有相关链路级告警并清除掉TUNNEL路由约束是否配置正确。,Page13,动态PW相关问题,PW状态不UP的问题。检查两端PW的IDMTU等值是否相同是否配置有LDP对等体如果TUNNEL和PW都UP了，业务不通，则需要检查PW和TUNNEL是否都使能了。,Page14,MPLS案例,土耳其沃达丰TUNNL没有使能导致ATM业务中断1现象和问题描述土耳其沃达丰在对某条Tunnel进行优化操作后，业务断了2.定位流程在网上出现这种业务不通时，应该先进行以下基本配置状态检查，然后再用更深层次的方法定位：1.首先在网管上检查Tunnel和PW的状态（up/down）。2.发现状态没有异常，继续检查PWPING和TUNNLPING。3.TUNNELPING得通，PWPING不通，检查Tunnel和PW的配置，发现没有问题。4.进一步检查发现Tunnel没有使能,Page15,以太业务简介及常见故障定位,以太业务的网络配置实例,Page16,以太业务常见故障定位,以太网业务不通检查是否有硬件错误告警检查是否有光口相关告警检查端口的工作模式是否匹配检查端口和业务的MTU值是否配置正确检查端口的tag属性是否配置正确(tag/access/hybrid)检查业务配置是否正确，例如VLAN信息等配置其他配置检查(例如专网的相关属性是否配置正确)专线业务可以通过业务OAM来检测业务的通断，专网业务可以查看学习到的MAC地址来判断业务的通断。,Page17,VDF六区广播风暴问题,现象和问题描述2009.2.27星期五下午13:30分左右，西班牙VDF六区出现大面积广播风暴，一个小时后知会华为工程师，半小时后恢复了所有业务，但问题根因不明，只好临时采取了规避措施。当晚VDF将业务回切到TELEFONICA。,Page18,VDF六区广播风暴问题,二、关键过程、根本原因分析图为业务逻辑组网1、检查水平分割配置。为了阻止广播流量，临时采用断掉环路物理光纤（60014和60012之间的链路）来消除广播风暴，此刻业务全部恢复。在逻辑组网中（如图），60013和60014做为专网的核心结点，与PTN60010、60017、60031、60018和60012构建一个专网，为了专网环路保护，组网中只在PTN60010、60017、60031、60018和60012上建立水平分割组，隔离PW之间的流量。配置是正常的。,Page19,VDF六区广播风暴问题,2、分析完组网后，在PTN60014和60013上都配置水平分割组，再恢复60014和60012的物理链路，flow_over消失。但PTN60012上的DSLAM上网业务始终没有恢复。3、拔插PTN60014上与TELE2对接的11号单板。在拔插过程中，DSLAM业务恢复。当单板起来后，业务又不通了。4、采取紧急处理，shutdownPTN60014上与TELE2对接的10GE端口。所有业务恢复。5、怀疑广播报文来之TELE2网络。在分析了TELE2侧组网后，怀疑TELE2设备与PTN60013和60014引起的环路。6、查看专网60013和60014uni流量通过端口流量统计，确实有大量流量从PTN60013的uni出去，但没有flow_over告警。,Page20,VDF六区广播风暴问题,7、怀疑CISCO交换机STP状态出错要求VDF工程师提供CISCO交换机的端口配置，发现端口上有MSTP协议配置。而我们专网的配置并没有透传普通的BPDU报文，怀疑CISCO的两个10GE端口的STP状态都为forwarding，导致环路在TELE2和PTN60013、60014上产生。8、2.28临晨1点在现网进行修改专网配置来消除环路，有3种方案A将PTN60013和60014的uni端口和PW130014加入水平分割B删除PTN60013和60014之间的PW130014（跟A方案很相似）C配置端口独占的专网业务，透传CISCO设备的BPDU报文但最终三种方案测试都不通过，西班牙本地员工一直用“VLANBLOCKED”来告诉我们PTN60012上的DSLAM上网业务没有恢复。2点45分，DSLAM上网业务重新切回Telefonica网络，留下VLAN90的业务来供我方测试。7点，VDF关闭TELE2与PTN相连的两个10GE端口。一晚的所有尝试均告失败。之后分析到CISCO设备使用私有的PVST（pervlanstp）协议，BPDU报文自带VLAN，PTN专网可以透传。问题应该不在CISCO交换机上。,Page21,VDF六区广播风暴问题,9、找到突破口，发现大环上60010上uni端口有flow_over告警。3月2日，重新分析整网告警时，发现PTN60010上出现了两处flow_over告警，其中一处出现在uni端口。从此处分析到，如果此处uni端口被环回，那么一切现象都能解释通过。经确认，VDF工程师发现此uni端口远端的DWDM设备有环回。10、在实验室模拟测试成功，使用环路检测和广播抑制方案避免环路再次发生11、当晚12点VDF工程师在现网重新广播风暴成功（大概只试了10s左右），证实了环路来自PTN网络之外的DWDM设备。在配置广播抑制和环路检测后，所有业务切回PTN网络。,Page22,VDF六区广播风暴问题,三、结论、解决方案原因：PTN3900/1900的专网中，各PW之间默认是转发，通过PW间复制来进行专网保护。而在非核心结点使用一个水平分割组，来避免环路。当非核心结点的一个uni侧出现了环路，广播风暴将会迅速蔓延到专网上。解决方案：1、在各uni端口配置广播抑制和环路检测功能。2、所有结点配置水平分割。彻底消除广播风暴隐患。,Page23,CES常见故障,CES业务中断/损伤原因主要包括以下几种，我们的定位工作也就主要围绕这几个方面展开：配置错误时钟不同步时延过大时延抖动过大,Page24,配置错误,查询CES业务PW装帧时间：主要检查源端和宿端的PW装帧时间是否一致。查询CES业务抖动缓冲时间：主要检查抖动缓冲时间能否承受从源端发到宿端所产生的时延（如果用户没有修改此配置，且业务流经的节点小于3站时，可以不考虑）。查询E1成帧模式：主要检查配置业务的E1端口成帧模式是否和对端设备匹配，只有UDT业务才能配置为unframe，其他业务必须配置为double-frame/crc4-multiframe。查询CD1光口V5字节：如果业务使用的VC12通道V5字节不匹配，业务将不通。,Page25,时钟不同步,设备不同源：原因可能是网元或仪表跟踪的不是同一个时钟源、时钟源故障等等；时钟源瞬间跳动：原因可能是物理链路出现异常、网络流量剧变导致时钟恢复不稳定等等；主要检查业务流经的所有网元时钟域是否相同，如果不相同，长时间测试可能有误码。,Page26,时延抖动过大,最长的报文延时时间与最短的报文延时时间差别过大，超出抖动缓冲区容忍极限：原因可能是业务流经的设备过多、CES业务的抖动缓冲区过小、网络流量剧变、网络拥塞、中间网络设备调度算法有缺陷等等；,Page27,典型案例,PCBver.A的MQ1子卡不支持CES业务自适应模式：【问题现象】：一条两站的远程CES业务，一端配置为外部时钟模式并自环，一端配为自适应模式并与仪表对接，业务配完后，仪表显示LOF告警。【问题原因】：配了自适应模式业务的MQ1子卡为PCBver.A，该版本的PL263使用EP2C50逻辑芯片，未集成CES时钟补丁，因此无法恢复出2M时钟出来，下行不是以2M速率发E1帧，仪表无法定到E1帧。【解决办法】：更换PCBver.B的MQ1子卡（PL263使用EP2C70逻辑芯片）即可。,Page28,典型案例（续）,E1电缆接错导致CES业务不通：【问题现象】：多条两站的远程CES业务串接起来，一端自环，一端与仪表对接，业务配完后，仪表显示LSS告警，查询单板告警，发现有一条CES业务使用的E1端口有LOS告警。【问题原因】：该E1电缆RX连错，导致LOS告警，单板往系统侧插AIS。【解决办法】：重新连接E1电缆即可。,Page29,典型案例（续）,Tunnel带宽不够导致CES业务持续误码：【问题现象】：一条两站的CES上MLPPP业务，时隙为15个，业务配完后，仪表显示业务通，删掉业务，重新创建31个时隙的业务，仪表检测到持续误码。【问题原因】：MLPPP组只有一个PPP成员，带宽不足以承载一条CES业务，导致大量PW报文被丢弃。【解决办法】：MLPPP组再添加一个成员后业务通。,Page30,典型案例（续）,多网元的时钟源不同导致长时间测试有少量误码：【问题现象】：数码通测试环境，组网如下图所示，约两个多小时后出现1s的LSS告警，查询PW性能计数，发现有jitterbuffer溢出的计数，【问题原因】：1900网元和ANT仪表分别跟踪不同的时钟源，长时间运行后随着时钟漂移和时延抖动，产生滑帧。【解决办法】：ATN仪表改为跟踪RX时钟即可。,Page31,典型案例（续）,E1成帧模式不匹配导致CES业务不通：【问题现象】：一条两站的远程CES业务，一端自环，一端与仪表对接，业务配完后，仪表显示LSS告警，查询单板告警，发现CES业务使用的E1端口有LMFA告警。【问题原因】：CES类型为SDT且E1端口为CRC4-multiframe模式，而仪表设置为Unframe模式，芯片无法正确定帧。【解决办法】：将仪表设置为PCM31C模式即可。,Page32,典型案例,PCBver.A的MQ1子卡不支持CES业务自适应模式：【问题现象】：一条两站的远程CES业务，一端配置为外部时钟模式并自环，一端配为自适应模式并与仪表对接，业务配完后，仪表显示LOF告警。【问题原因】：配了自适应模式业务的MQ1子卡为PCBver.A，该版本的PL263使用EP2C50逻辑芯片，未集成CES时钟补丁，因此无法恢复出2M时钟出来，下行不是以2M速率发E1帧，仪表无法定到E1帧。【解决办法】：更换PCBver.B的MQ1子卡（PL263使用EP2C70逻辑芯片）即可。,Page33,典型案例（续）,E1电缆接错导致CES业务不通：【问题现象】：多条两站的远程CES业务串接起来，一端自环，一端与仪表对接，业务配完后，仪表显示LSS告警，查询单板告警，发现有一条CES业务使用的E1端口有LOS告警。【问题原因】：该E1电缆RX连错，导致LOS告警，单板往系统侧插AIS。【解决办法