浅谈PTN网络建设与运维经验.docVIP

浅谈PTN网络建设与运维经验 　　中图分类号：TN711 文献标识码：A 文章编号： 　　概述 　　近些年以来，随着3G网络建设的持续开展，原有的SDH、MSTP网络已不能满足资源需求。城域传送网必然向PTN演进，整个IP网和宽带接入将随着全业务的推进更加靠近用户、更加提高用户的感知度。PTN技术继承了SDH的电信级特性和二层设备的统计复用、组播等技术理念，又具备分组核心，解决了TD基站及未来LTE基站大带宽的需求，能够提供层次化的QoS，为后续业务精细化运营提供有效支撑；并且PTN技术也延续了MSTP网络在保护、监控、管理以及端到端业务配置方面的优势，保证了网络的承载质量。 　　目前PTN技术在已经进入了大规模部署和实际应用阶段。而在实际部署当中，会遇到哪些难点和问题？设备存在哪些缺陷或隐患？如何对告警和故障进行诊断？业务保护选择哪些方式？如何维护好PTN网络？这些问题都会成为PTN实际部署和日常运营维护中的焦点。 　　本文结合PTN网络的建设和运维经验，介绍了两例PTN网络故障的案例，并进行分析总结。 　　技术概述： 　　PTN 利用PWE3（Pseudo Wire Emulation Edge-to-Edge）技术实现面向连接的业务承载，采用针对电信承载网优化的 MPLS（Multiprotocol Label Switching）转发技术，配以完善的OAM（Operation, Administration and Maintenance）和保护倒换机制，集中了分组传送网和SDH 传送网的优点，实现了电信级别的业务。 　　MPLS_TUNNEL_LOCV告警未及时处理导致业务全阻案例 　　故障现象 　　如下图所示，PTN网络全球通至惠东移动之间的光缆由于外力施工被挖断，导致光路中断，惠东移动下挂站点基站业务全部中断；通过网管检查，发现受影响业务配置的保护隧道为惠东移动往白花方向，但由于保护隧道不通，且存在MPLS_TUNNEL_LOCV告警，导致APS保护倒换无法生效，从而导致业务全阻。 　　 　　故障分析处理 　　通过对保护隧道做LSP Trace-route之后发现，白花站点没有上报响应事件，确认白花到惠东移动这段隧道不通，之后查看了ARP信息，发现白花7槽EX2单板到惠东移动11槽EX2单板之间对应端口没有学习到ARP信息。 　　由于白花网元7槽位EX2单板端口被置坏，端口置坏后通过该端口动态学习到的ARP信息会被删除。并且协议模块也不会再通过该端口进行ARP学习。 　　而保护隧道上存在的 MPLS_TUNNEL_LOCV告警，产生的原因也是保护隧道上的单板端口被置坏， ARP学习受到影响，保护隧道因为缺少ARP信息而无法正常工作，从而产生告警。 　　为抢通业务，通过网管配置静态ARP地址，随后保护隧道告警消除，业务也得到恢复。 　　 　　后期更换了白花网元7槽位EX2单板，并将单板返回厂家进行分析测试。分析结果如下：单板回板后可以正常上线，业务测试未出现问题 分析单板log，log中记录的为TM芯片外挂RLDRAM有ECC错误。RLDRAM为TM芯片外接的RAM，TM在处理报文时会使用此RAM进行缓存，如果RLDRAM存在异常，将影响数据的正常存取，进而影响TM芯片接口arp表项的学习和存取； 对单板TM芯片外挂RAM进行检测，未发现异常，说明常温下此芯片功能正常； 对单板进行高温测试，对TM芯片 RAM进行检测，发现TM芯片外挂的位号为U17的RLDRAM检测失败，个别地址空间读写错误。怀疑RLDRAM芯片失效引起； 为了进一步确认此RAM是否失效，将RLDRAM与其他芯片进行对调测试，发现故障现象跟随芯片走，确认此片RLDRAM失效； 该问题原因是RLDRAM芯片个体失效，在高温时部分地址空间读写错误。 　　引申分析 　　本次故障的原因主要是保护隧道产生MPLS_TUNNEL_LOCV告警时，没有及时进行处理，当主用隧道光路中断时业务无法倒换引起。 　　因此，当网络中出现TUNNEL_MPLS_LOCV告警时，业务不一定受到影响，但是如果不及时处理该告警，当另一路由也出现异常时，业务就必然会出现全阻。以下就该告警的原因及处理方法做简要说明： 　　MPLS_TUNNEL_LOCV为Tunnel连通性丢失告警。连续3个周期内没有收到希望的CV/FFD报文时出现此告警。如果TUNNEL是单向的，则该告警都是出现在TUNNEL的收向网元上。该告警产生时，会触发MPLS APS倒换，将业务倒换到保护Tunnel。 　　告警MPLS_TUNNEL_LOCV产生的可能原因如下，其中前三种原因最为常见。 　　原因1：物理链路故障，包括站点停电脱管等原因。 　　原因2：Et