IPRAN工程典型案例集锦.docx
《IPRAN工程典型案例集锦.docx》由会员分享，可在线阅读，更多相关《IPRAN工程典型案例集锦.docx（25页珍藏版）》请在冰点文库上搜索。
IPRAN工程典型案例集锦
IPRAN工程典型案例集锦
目录
引言3
案例1：
带OLT业务问题4
案例2：
基站下载速度受限问题4
2.1VPLSMAC地址表容量问题4
2.2流量监控配置问题5
2.3ARP配置问题5
2.4100MFE口协商问题6
案例3：
3层路由不通，业务中断问题7
3.1网管下配置数据后，部分配置丢失问题7
3.2环回口路由配置问题8
3.3桥接点Ping基站不通8
案例4：
2M业务告警问题9
4.1中间通道问题9
4.2MAC地址匹配问题9
案例5：
TPOAM告警不通问题10
5.1控制字未使能10
5.2二转三业务，线路盘插上框11
5.3标签残留11
5.4通道故障12
5.5带基站数目超过100012
案例6：
BFD不通问题12
6.1通道故障12
6.2互通问题13
案例7：
保护倒换后，业务依然不通14
7.1PTN带分支链保护倒换后业务不通14
7.2S1O1、S1O2单盘工作模式配置问题14
7.33G业务，接入侧倒换后业务不通15
案例8：
2层业务不通15
案例9：
网管下发配置显示超时15
案例10：
硬件故障16
10.1交叉盘SCUO1黑盘问题16
10.2交叉盘SCUO1太阳黑子问题16
10.3NP盘SRAM问题17
10.4R845盘温持续过高18
引言
IPRAN工程商用过程中，无法避免的会在应用过程中出现各类的突发问题，本文产生的目的，是通过对典型工程案例的梳理，为一线运维人员提供排查和解决IPRAN工程问题的思路和方法，方便工程运维人员能够及时对现网存在的隐患和故障进行整改和排查，提高我司IPRAN产品的整体形象。
本文面对的对象为烽火通信公司核心运维人员，请对本文所涉及的相关工程内容进行保密。
版本
日期
作者
备注
V1.0
2014-2-26
zhang
主要为移动、联通静态工程场景，结合对工程一线的技术支撑而形成。
案例1：
带OLT业务问题
【工程现场】
合肥联通
【软件版本】
V2.3SP2版本
【故障分析】
1.通过R860设备承载OLT业务后，发现业务持续不通；
2.对业务流量进行分析，从面板端口进入的报文比较多，但是没有转发到背板上去；
3.登录主控操作系统界面，从主控盘上抓包发现收到有大量PPPoE报文；
4.分析发现，接口盘将OLT业务报文当做信令报文提取，并上送给了主控盘；
✧<小结>
现网如果需要承载OLT的PPPoE类型业务时，请确认下软件版本，开通后业务不通时请联系总部解决。
【解决措施】
1.对OLT报文的提取在V2.3SP3版本中进行了屏蔽；
2.升级到V2.3SP3版本能够支持PPPoE报文的透传；
3.现网版本不便于升级操作的，可以联系总部提供后台命令进行解决；
案例2：
基站下载速度受限问题
2.1VPLSMAC地址表容量问题
【工程现场】
武汉移动
【软件版本】
V2.1.2
【故障分析】
1.从核心ping基站正常，无丢包统计；
2.
3.通过仪表测试，低业务流量时无任何丢包，当加大业务流量时，出现大量丢包；
4.对于移动场景，多个基站共一个网关IP地址，在桥接点会配置VPLS的E-Tree模型，该模型下当没有学习到基站MAC地址时，会将业务报文进行广播；
5.通过检查配置，在业务管理中发现配置的VPLSMAC地址学习表条目数为8。
在该配置模式下，当基站数超过8时，VPLS将学习不到MAC地址而发生广播，大量广播报文存在会导致拥塞而丢包；
✧<小结>
当出现基站速率达不到线速时，直接检查VPLSMAC地址表容量配置。
【解决措施】
1.检查业务管理界面下，VPLS中MAC地址表容量配置数，缺省为1024，如果该数目为8，请根据现网情况进行修改。
2.2流量监控配置问题
【工程现场】
武汉移动
【软件版本】
V2.1.2
【故障分析】
1.通过仪表测试过程中，发现双向流量为1个稳定的固定值；
2.没有VPLS广播地址风暴所产生的广播流量影响；
3.查看网管配置中，对上行业务配置了CIR/PIR限制，并开启了流量监控使能开关；当开启流量监控开关后，将会业务流进行限速约束。
4.调整CIR/PIR限制值后，流量正常；
✧<小结>
E-Line模型下的业务，流量受限时，请检查下CIR/PIR的配置。
【解决措施】
1.修改配置，调整CIR/PIR约束规划。
2.3ARP配置问题
【工程现场】
南通移动
【软件版本】
V2.3SP2
【故障分析】
1.基站业务只能达到几兆的流量；
2.分析VPLS配置，流量监控的配置均未发现明显异常；
3.登录主控盘，查看CPU性能时可以看到CPU占用率一直很高；
4.登录线路盘，查看线路盘上的丢包原因时，有大量未知ARP报文上送丢包；
5.从主控上将报文抓出后，分析其IP地址，发现在主控上存在该ARP配置，但是线路盘上确没有ARP配置数据；
6.进一步分析后，发现主控之前存在动态ARP和静态ARP的配置数据，当手工清除动态ARP后，单盘上响应命令清除ARP配置数据，导致单盘没有了ARP的配置，从而出现未知ARP的丢包；
7.重新补齐ARP配置数据后，流量恢复；之前流量过小的原因为，主控收到线路盘上送的未知ARP报文后，对报文进行软转发，从而导致能够通一部分的数据。
✧<小结>
对现网的巡检，查看主控盘上的CPU占用率情况，查看线路盘上的异常丢包原因等信息，能够很方便的定位出现网的故障。
对于缺少ARP而导致的业务不通等现象，工程上已经反复遇到，线路故障优先查看ARP配置，百试不爽。
【解决措施】
1.重新配置ARP后恢复。
2.4100MFE口协商问题
【工程现场】
武汉移动
【软件版本】
V2.1.2
【故障分析】
1.基站接口为100M，但是流量仅能达到50M流量；
2.登录设备查看100M电口工作状态，工作在100M半双工模式；
3.切换百兆口工作模式后，流量恢复。
✧<小结>
当流量在50M左右而一直无法上去时，可以怀疑是否是由于基站接入侧电口协商模式的问题。
【解决措施】
1.新版本接入侧软件对协商模式进行了优化；
2.通过网管状态，查看当端口协商为100M半双工模式时，请及时进行修复，否则速率将无法达到线速转发。
3.配置时，尽量不要使用自协商模式，而需要选择强制100M模式进行配置。
2.5OTN问题
【工程现场】
咸宁移动
【故障分析】
现场进行试验，从省干到咸宁新开一条业务，使用ftp下载，发现不管是接不接我们的本地网的设备下载速度都很小。
最后确认为OTN问题，省干和地市对接的OTN端口有告警。
【解决措施】
插拔OTN光纤告警消失，故障解决。
基站流量正常。
2.6LSP-Rx的下一跳为NNIlag
【工程现场】
南平移动
【故障分析】
南平移动的主备汇聚站点和主备核心站点的680对接使用了NNIlag。
业务通过本地网的主用汇聚到主核心时LTE基站流量正常。
但主用路径中断，走LSP备用路径后基站流量上不去。
断备用LSP的任何一条路径（即lag成员只有一个的情况下）后流量正常。
原因：
备用路径的nnilag是lsp-Rx的下一跳，他的转发是基于包的，同一个基站的业务报文经过不通的路径到达基站业务包时序紊乱，造成基站丢包重传，流量上不去。
【解决措施】
软件bug，需要支持nnilag的LSP-rx的基于流的转发。
2.7配置问题
【工程问题】
【故障分析】
由于移动部分地市的桥接点和核心点是同一个站点，但无线侧配置为ECMP造成我们设备从两个核心站点收包，下行走VPLS时只有主用站点能够学习到mac地址，造成走备用站点的学习不到mac，搞成业务包广播，对应的基站流量上不去。
【解决措施】
1、核心和汇聚站点分开。
2、MAC地址老化关闭，把业务切到备用学习mac。
此种做法有风险。
案例3：
3层路由不通，业务中断问题
3.1网管下配置数据后，部分配置丢失问题
【工程现场】
乌鲁木齐联通
【软件版本】
V2.1.2升级到V2.3SP3
【故障分析】
1.故障发生在2转3的业务类型中，3G业务受到影响；
2.故障发生时间为网管升级后，下网管配置数据后出现；
3.从汇聚点ping基站业务正常，但是汇聚点ping核心站点ping不通；
4.现网该VRF下所有业务中断，怀疑跟核心节点关联性比较大；
5.将核心节点的zebos配置文件与网管下数据前的配置文件进行比较，发现少了vrf收标签的配置数据；将数据补齐后业务恢复；
✧<小结>
当升级网管下配置数据后，或者替换zebos文件后，出现业务中断现象，直接进行配置文件的数据比对工作，将缺失的配置数据补齐后再进行定位判断。
【解决措施】
1.V2.3SP3中试版本网管已经解决该问题；
3.2环回口路由配置问题
【工程现场】
乌鲁木齐联通
【软件版本】
V2.1.2升级到V2.3SP3
【故障分析】
1.3G基站业务不通，从核心节点ping汇聚节点的接口，Ping不通；
2.查看L3VE接口的路由，均为inactive态，即路由未生效；
3.分析后，对于V2.3SP3即后续版本，需要缺省配置到每个核心节点的环回口路由，否则将无法生成下一跳的路由；
✧<小结>
当升级到V2.3SP3及后续版本后，必须补齐节点间的环回口路由，否则无法生成下一跳的路由。
在3层VRF中，ping是最常用的故障定位方法，当Ping不通时，通过查看其到目的IP的路由，或者直接ping下一跳，通过抓包分析，Ping特定帧长的报文进行分析，并排查出最终的故障原因。
【解决措施】
1.从网管上补齐到每个节点的环回口路由后，业务正常。
3.3桥接点Ping基站不通
【工程现场】
扬州移动
【软件版本】
V2.3SP2
【故障分析】
1.从桥接点ping基站业务不通；
2.VRF内部Ping业务正常；
3.检查L3VE接口配置，发现没有主用、备用槽位号配置；
4.补齐主用、备用槽位号配置后，业务恢复正常；
5.当没有配置主用、备用槽位号时，RCUping包发送过程中在V2.3SP2可能出现选择板卡错误的问题，需要补齐主、备用槽位号配置数据。
✧<小结>
Ping过程中，通过从RCU抓包或者检查配置的方式，分析Ping包是否发送出来，是否发送到正确的槽位上。
【解决措施】
1.补齐主用、备用槽位号配置数据解决。
案例4：
2M业务告警问题
4.1中间通道问题
【工程现场】
毫州联通
【软件版本】
V2.1.1
【故障分析】
1.有一部分2M基站业务闪告告警；
2.由于2M基站业务告警闪断，对于静态业务，判断其逻辑通道应该是正常的，否则不应该只是出现闪断现象，如果逻辑通道故障，直接表现为不通。
判读线路中有部分2M报文丢弃，或者有报文串扰，导致其发生告警闪断现象；
3.登录交叉盘，通过查看交叉盘上的发包计数，存在广播现象，即未插板卡的槽位也不停有发包统计；分析配置，其上配置有VRRP+VPLS，判断该现象为V2.1.1软件版本的一个问题，即将VPLS中MAC地址广播报文也发送给了仿真盘，导致报文串扰而出现业务闪断现象。
✧<小结>
对于2M业务的闪断，通常是2个方面的原因，1个为中间通道有CRC计数，即链路故障；另外一个为报文串扰，出现该现象请留意软件版本。
类似的案例有云南联通，中间通道有CRC误码计数；新疆联通，中间过站的XSK1盘，读取光功率等参数异常，中间链路转发异常。
【解决措施】
1.升级核心节点软件版本至V2.1.2以上版本可以解决。
4.2MAC地址匹配问题
【工程现场】
菲律宾SMART
【软件版本】
V2.3SP2
【故障分析】
1.现场配置的是点对点的E-Line业务模型，即VPWS业务；
2.现网业务持续有告警指示；
3.该ETH所绑定的保护组状态显示正常，即通道正常无丢包；
4.通过源宿节点交叉盘收发报文计数，确认链路正常，报文正常转发到源宿节点；但是查看R865给仿真盘的报文很少；
5.确认是由于R865设备的MAC地址第2个字节为04，底层将该报文当做OAM报文转发给了OAM处理模块，而导致业务故障；
6.修改R865设备mgnt0的MAC地址后恢复正常；
✧<小结>
对于V2.3SP2的软件版本，仿真业务一定要注意设备的MAC地址配置，第2个字节不能为04，否则会出现业务不通的现象；
【解决措施】
1.修改设备的MAC地址，第2个字节不能配置为04；
2.升级软件版本至V2.3SP3及以上版本解决；
案例5：
TPOAM告警不通问题
5.1控制字未使能
【工程现场】
常州联通
【软件版本】
V2.3SP2
【故障分析】
1.VCOAM有告警；
2.检查发现VC上绑定的LSP的OAM并没有告警，但是VCOAM却有告警；
3.对于CES业务，LAG业务，桥接口业务的VCOAM在交叉盘上进行终结；对于FE类业务，VCOAM在落地的接口盘上进行终结。
4.检查配置文件，发现互通的两端设备，一端的MPLS-TP使能，另外一端未使能，导致VCOAM有告警。
✧<小结>
对于这种通道正常，但存在TPOAM告警的问题，现网确实比较难查。
在工程配置过程中，一定要将MPLS-TP使能开关模式打开，以免最后查到是配置问题。
【解决措施】
1.工程业务开通，注意要将MPLS-TP使能开关打开。
5.2二转三业务，线路盘插上框
【工程现场】
常州移动
【软件版本】
V2.3SP2
【故障分析】
1.在二转三的汇聚点，看到交叉盘上存在大量的VC_RDI告警，远端接入侧PW保护组发生倒换；
2.分析该VC所绑定的Tunnel，并没有出现什么异常；
3.出现RDI告警，表明汇聚节点的交叉盘已经收到了远端的VCOAM报文，但是远端并没有收到汇聚节点交叉盘过来的VCOAM报文；
4.查看流量，发现交叉盘的VCOAM并没有转发到线路盘上去；
5.现场线路盘插在上框槽位，分析底层数据，发现故障中断时发生了RCU盘切换动作，下发的配置数据存在问题影响了交叉盘通道流的创建，导致转发异常；
6.复位备用交叉盘后，切换交叉盘解决；
✧<小结>
对于V2.3SP2版本，当定位到交叉盘故障时，通过复位备用交叉盘，并切换交叉盘后能够快速进行业务恢复。
【解决措施】
1.该问题在V2.3SP3版本中进行了修正，升级到该版本解决；
5.3标签残留
【工程现场】
武汉移动
【软件版本】
V2.1.2
【故障分析】
1.在很多接入站点上，查看LSP保护组状态时，收到的APS为3，发送为1，处于倒换状态；
2.查看接入节点OAM信息，有VP_RDI告警，汇聚点有VP_LOC告警；
3.该故障可以判定通道是正常的，但是TPOAM互通问题，故障点发生在源、宿节点；
4.由于很多接入节点出现该现象，汇聚点出故障概率更高；
5.找到一条故障VPOAMID，在zebos文件中进行查找，发现该VPOAMID绑定了多个tunnel，配置文件中存在标签残留；
✧<小结>
一个TPOAMID需要绑定一个FTN表和一个ILM表或者绑定一个l2-circute，如果发现绑定多了，就是配置残留问题。
【解决措施】
1.找到有故障的VPOAMID，从zebos文件中查找是否同一个OAMID绑定了多个条目；
2.如果存在，在底层no掉残留配置，从网管对该业务条目执行增删操作进行恢复。
5.4通道故障
✧<小结>
通道故障，也是造成存在TPOAM出现告警的一个常见杀手，例如：
没有ARP配置数据，或者ARP配置错误，ILM配置残缺，过站单盘故障等都会导致出现TPOAM告警，遇到该告警时，请及时检查中间通道，修复现网隐患。
5.5带基站数目超过1000
【工程现场】
常州移动
【软件版本】
V2.3SP2
【故障分析】
1.业务类型为2转3类业务；
2.当LSP保护组发生倒换后，大量接入侧出现PW层倒换动作，但LSP保护组状态中指示备用路径工作正常；
3.分析现网发现现网所带基站站点数目超过1000个，而R865交叉盘支持保护组数目为1000，当超过后保护组无法进行倒换；
4.通过锁定接入侧PW保护工作状态进行恢复；
【解决措施】
1.锁定接入侧PW保护组工作状态为主用；
2.升级版本至V2.3SP3版本，解决带基站数目超限的问题；
✧<小结>
R865带基站数目过大时，现网中需使用高版本的软件，否则可能会出现意想不到的问题。
案例6：
BFD不通问题
6.1通道故障
【工程现场】
浙江丽水移动
【软件版本】
V2.3SP2
【故障分析】
1.VRF内部起的BFDforLSP，出现部分条目有BFD告警，导致倒换出现异常；
2.对于BFD的工作基本流程，在协商过程中，BFD只会每秒发送1个协商报文进行协商；当协商成功后，将按照BFD发送报文周期进行报文传送；
3.通过逐站查看入tunnel表的状态，看报文是否在增加（注意，性能统计只发生在入口盘），判断BFD报文的转发情况；链路较长时，建议折半站点进行排查，即先排查中间的站点，看计数是否正常；
4.发现在经过1个节点后，报文没有进行转发，登录转发通道的单盘，看到交叉盘上打印异常信息，该交叉盘出现太阳黑子现象，复位后BFD恢复。
✧<小结>
目前的配置规范中，BFD作为VRF中LSP的一种检测手段。
对于BFDforLSP出现告警，通常指示其LSP出现故障，通过对LSP通道的排查，用来定位网内的故障节点。
类似的案例有：
安徽移动，出现中间LSP的下一跳节点没有ARP；云南文山联通，中间有块NP盘出现SRAM故障；
中间的通道故障，还有可能是配置问题，例如：
没有ARP配置，ILM表配置残缺等，都会导致中间通道出现故障，找到故障点后，根据丢包原因查询，能较快的查到通过故障的原因，并进行修复解决。
【解决措施】
1.复位异常交叉盘；
2.升级交叉盘软件版本至V2.3SP3，该版本对太阳黑子问题进行了修正，能够大大降低出故障概率；
6.2互通问题
【工程现场】
南通移动
【软件版本】
V2.3SP2
【故障分析】
1.与EPC互通的BFDforIP跳变；
2.登录交叉盘，查看该BFD收发报文计数，发现收发包数目不一致，收包很少；
3.查看协商的发送周期，确认EPC过来的BFD报文数目没有按照协商周期发送，更换EPC部分板卡后解决。
✧<小结>
对于BFD不通的条目，或者OAM不通的条目，查看BFD/OAM收发报文计数是一个常用办法。
【解决措施】
1.更换友商故障板卡后解决。
案例7：
保护倒换后，业务依然不通
7.1PTN带分支链保护倒换后业务不通
【工程现场】
新疆联通
【软件版本】
V2.3SP3
【故障分析】
1.现网发现所有PTN630带分支链保护，主备LSP均有告警；
2.倒换后业务不通，无法实现倒换动作；
3.查看源、宿节点间配置的TPOAM，均有发送报文计数但没有收包计数，通过tunnel层计数统计，通道正常，但TPOAM不通；
4.联系研发后，定位PTN630版本问题，RP0100版本不支持分支链保护，需升级版本。
✧<小结>
对于接入侧设备，在生命周期维护过程中，有一系列的工程版本发布，全网配合工作过程中，需要特别留意并升级到最新版本，以免由于版本问题出现保护倒换不成功等工程问题。
类似的工程案例有：
有部分版本的PTN620/630PW冗余保护，倒换到备用后控制字不匹配、VLAN动作不一致等现象，升级核心侧设备后，注意升级接入侧设备至最新版本。
【解决措施】
1.升级接入侧设备版本解决；
7.2S1O1、S1O2单盘工作模式配置问题
【故障分析】
1.通过状态，查看LSP保护组已经倒换到备用，但是业务不通；
2.登录设备底层，查看接入侧板卡倒换动作行为不正确，即背板总线受到异常干扰；
3.检查设备上板卡，发现存在S1O1/S1O2等的仿真盘，其上配置设备类型为PTN，而不是IPRAN设备；
4.更改设备类型后，倒换工作正常。
✧<小结>
对于这种保护组工作正常，但是却没有倒换的现象，通常原因为系统总线受到干扰导致，例如将PTN系列的板卡插到了IPRAN设备上或者某些板卡故障而对系统总线造成了干扰等，都会使系统工作不正常。
当初S1O1/S1O2等仿真盘设计过程中，对PTN、IPRAN设备进行了兼容性设计，即可以混插，但由于总线通信协议不匹配，会造成对系统总线的干扰，因此配置过程中，需特别进行留意。
【解决措施】
1.更改S1O1/S1O2盘设备类型后解决。
7.33G业务，接入侧倒换后业务不通
【故障分析】
1.通过查看接入侧倒换状态，PW保护组状态发生了倒换，导向备用汇聚节点；
2.在备汇聚节点的入口盘，查看丢包原因，发现有大量MAC地址不匹配的丢包；
3.检查主备汇聚节点配置文件后，发现主备汇聚节点上配置的L3VE接口MAC地址不一致，导致倒换后业务不通
✧<小结>
在发生倒换后业务不通的现象时，常用分析思路为，一查状态，二查流量，三查丢包原因，3板斧下去，故障原因往往就很明了了。
【解决措施】
1.更改备汇聚节点MAC地址后恢复正常。
案例8：
2层业务不通
【故障分析】
1.下配置后，原先已开通的E-Line业务突然不通；
2.查看业务流量和丢包原因，在接入侧入口即把报文丢弃；
3.检查主控上配置数据，并输入shmplsvcinfo查看配置数据后，发现VPWS配置数据异常，NNI口变成了UNI口，导致E-Line业务通道损坏；
4.检查历史配置数据，发现其修改了对端设备的环回口地址，下发数据后本地tunnel所对映的PeerIp发生改变，从而导致VPWS的NNI口数据未生成，导致通道故障；
5.修改环回口地址后，需要对业务进行增删操作以修复配置数据；
6.重建业务后恢复；
✧<小结>
通过定期比较配置数据，能够很快查出配置方面的问题。
在主控上，常用命令需要牢记，例如：
查看VPWS配置，VPLS配置，FTN表配置，ILM配置，ARP配置，路由配置等，只有保证配置正常的前提下，业务才能正常通信。
对于IPRAN网络，存在TP控制字使能模式和TP控制字不使能模式，曾经有工程出现控制字随意配置的问题，建议工程现网确认配置TP控制字使能，以免出现配置不匹配而造成业务中断的故障。
【解决措施】
1.重建业务进行恢复。
案例9：
网管下发配置显示超时
【故障现场】
新疆移动
【软件版本】
V2.3SP2
【故障分析】
1.下发业务时，网管持续提示下载配置超时；
2
升级会员 