PTN案例PPT课件

PTN案例,-传输,1,.,案例一：某运营商PTN网元A光路重新连通后站点无法登录的问题处理,现象描述：某运营商一套PTN网元A由于光路中断故障导致脱管。待光路抢修后，PTN网元A仍为脱管状态。通过U2000网管登录网元A，网管提示找不到设备端口。通知现场施工人员用光功率计测试该设备和上级站点网元的收光都正常。网管查看上级PTN站点网元的IP协议栈管理，可以查到越点数为0的IP包含脱管网元的IP。查看系统DCN管理，该网元A为无法连接状态。告警信息：NE_COMMU_BREAK、NE_NOT_LOGIN,2,.,对PTN网元可能造成脱管的几种原因进行分析：1、光路中断：施工人员到现场测试光路，测试得到网元A和上一级网元的收光都正常，排除光路问题；2、网关网元配置错：网管查看网元A的网关为正确配置，查看DCN管理该网元A的主用网关为正确的网关；3、网元主控问题：现场让施工人员拔插复位和倒换主控交叉板，现象仍然存在，排除主控问题；综上，网元A的硬件和DCN配置都没有问题。考虑到有可能是网元ID重复。通过网元纤缆搜索和命令行工具查询，确认在网元A中断的几天里有新建站点，通过命令行工具查询新建站点，根据实际组网情况其中一个网元ID和网元A一致，但扩展ID不一致，因设计给的扩展ID与网元A重复，导致网元A光路连通后出现无法登录的故障。,3,.,处理过程：1、网管删除网元A和上级节点的链路，重新搜索链路，出现冲突链路；2、查看相关冲突链路的网元有另一片区（扩展ID不一样）的网元；3、将另一片区的网元的链路删除，重新搜索这两个网元的链路，出现同一个网元的同一个光口接着两个不同的站点（详见链路搜索截图）；4、利用命令行工具Navigator查询网元A上级站点的相邻站点扩展ID和ID（:cm-get-coreroute），发现网元A与另一片区的一新建网元扩展ID和ID都重复；5、利用网管将另一片区那个扩展ID重复的新建网元的扩展ID改为正确（不和网元A重复）；6、网管登录网元A可以正常登入，问题处理结束。,4,.,案例二：PTN端口处理机制问题导致VLAN1业务不通,现象描述：组网信息：sw1-ptn950-ptn950-sw2ptn新建eth专线业务，vlan1业务不通，其他业务vlan报文均正常组网图：,5,.,原因分析：分析返回的sw数据配置后发现，sw与ptn互联端口pvid均为vlan1，sw出端口会将vlan1的标签去掉，由于ptn侧端口模式为tagware，端口收到带tag报文将会透传，收到untag的报文将会直接丢弃，导致vlan1业务不通，但是其它vlan业务正常。不同的封装方式和端口模式对数据包的处理方式如下：不同封装方式对数据包的处理方式：设置为“null”时，端口将透传接入的报文。设置为“802.1q”时，端口将识别802.1q标准的报文。设置为“qinq”时，端口将识别qinq标准的报文。不同端口模式对数据包的处理方式：“tagaware”：端口设置成tagaware后，该端口可对带有vlanid（tag）的数据包进行透传。如果数据包不带vlanid（untag），则该包被丢弃。此时“缺省vlanid”和“vlan优先级”没有意义。“access”：端口设置成access后，该端口会把默认的vlanid加到不带vlanid（untag）的数据包上去。如果信号本身带有vlanid（tag），则该包被丢弃。“hybrid”：端口设置成hybrid后，该端口会把默认的vlanid加到不带vlanid（untag）的数据包上去。如果该数据包带有vlanid（tag），则透传该包。,6,.,处理过程：将ptn侧端口的封装方式更改为null，对于端口收到的报文不做检查，直接透传，故障消除建议和总结：1、ptntagware模式对报文的处理规则与交换机trunk模式不同，这点需要特别注意。2、默认情况下sw所有端口都属于vlan1，建议客户不要使用vlan1承载业务。3、必须使用vlan1承载业务情况下，建议将sw端口的pvid修改为非vlan1。4、如果sw侧无法修改数据，可以将ptn端口的封装方式配置为null，但是要注意，封装为null后，需要配置端口独占方式，这样就不能扩展业务了。因此，建议使用hybrid端口，同时注意要在专线业务里透传vlan1。,7,.,案例三：PTN下挂基站业务中断问题处理案例,现象描述：ptn网络通过以太网专线来承载CDMA基站业务，其中一台ptn950下挂的基站业务中断，基站控制器与基站之间不能ping通，由于基站的管理通过其他的路径来通信，所以基站管理是正常的。告警信息：ptn设备上无任何告警，基站控制器上报该基站业务中断。,8,.,原因分析：按照故障现象，可能导致该问题的故障范围为：1、基站问题2、PTN网络的问题3、基站控制器的问题确定好问题引起的范围之后，引起该问题的具体原因，又可以分为：1、配置问题2、线缆问题3、软件问题4、硬件问题需要按照具体的操作，来确认具体的原因，总体思路是先确认故障前后有没有做过什么操作？是运行中出现的问题，还是开局出现的问题？然后再定界，通过故障诊断方法来判断故障的范围，确定故障范围后再确认具体的故障根因。,9,.,处理过程：1、多次使用以太业务的LB测试（包括大包测试），没有丢包，可以判断PTN网络内部是没有问题的。2、BSC、基站都能正确学习到对端的arp。3、在BSCping基站的同时，在PTN950连接基站的端口上做rmon统计，发现报文从端口发送出去了，但是对端没有回应报文，可以判断问题出在PTN950用户侧端口、中间网线或者对端基站设备上。4、在ptn950上连接基站的端口上做内环回，然后再通过BSC去ping基站，同时在PTN950上做rmon统计，发现端口有发有收，可以判断该端口芯片层面是没有问题的。5、将ptn950连接基站的网线不连接基站，替换插到ptn的另外一个端口上（假设原来连接基站的是1口，将对端基站的网线拔过来插到2口上），再通过BSC去ping基站，同时在ptn的两个端口上做rmon统计，发现报文从ptn的1端口发出去了，也从2端口收到了，这样可以判断ptn950用户侧端口的出方向发送是没有问题的，网线的一个方向传输也是没问题的。6、将ptn的业务更改下，使ptn950的2口为用户侧端口，使用第4步的方法继续测试，也能看到报文从2端口发出去了，从1端口收到了，由此可以判断ptn的端口、网线都没有问题，需要在对端基站上找问题了。7、基站一直没有发现异常，最后更换基站的主控板后问题解决。,10,.,案例四：成都移动城域网187-47-金海岸网元一直处于热备份状态，业务无法配置,问题现象187-47-金海岸网元一直处于热备份状态，业务无法配置。原因分析187-47-金海岸备用主控板主控空间不足。,11,.,问题处理1、业务配置人员反映配置业务时，经过187-47-金海岸的TUNNEL无法正常部署，提示网元一直处于热备份状态；2、在该网元管理器里查看单板1+1保护状态，发现主控备份状态一直处于运行态；3、经研发确认，可能是由于备板主控空间不足，无法与主用主控板同步数据库造成该故障，需要对备板主控空间进行清理。4、用Navigator登陆187-47-金海岸，先用:sm-set-nebusy:0,0,0,0,none停止该网元热备份；:hbu-get-backup-info；返回值为0 x00000002。查询主控备份情况，5、:sftm-get-freespace:18,”ofs1”;返回值为0,说明该板空间已被占满。参数18为主控板板位号，6、:sftm-delete-file:18,”/ofs1/license/HBUMSG.TXT”；删除HBUMSG以释放空间。7、空间释放后，主备主控板同步数据库正常，故障消失，告警SYNC_FAIL消除。,12,.,案例五：广安移动接入层PTN设备误启用标准SSM协议导致BSC上报时钟参考源异常告警,问题现象BSC网管上报部分基站出现时钟参考源异常告警，传输侧没有任何告警显示。原因分析1、接入的时钟源质量劣化2、BTS设备提取的时钟与传输设备的时钟的参考源不同。3、传输线路存在误码,13,.,1、怀疑是时钟源信号劣化，但跟踪该时钟源的站点很多，只有少部分站点在BSC侧上报时钟源参考异常的告警，因此排除时钟源的故障。2、与BSC的督导沟通，了解到未上报告警站点的BTS时钟和上报告警的站点都提取的是同一BSC设备的时钟。3、检查PTN的时钟跟踪，逐站检查时钟配置，发现时钟跟踪关系无误；4、通过U2000网管检查故障站点的性能值，发现光功率等指标均正常。5、观察这些站点的共性，发现开通时间均为新开站点，再仔细检查故障站点的时钟配置，发现在“时钟子网设置”里，保护状态为“启用标准SSM协议”，如下图：6、把这些站点的设置改为“停止SSM协议”，如下图：7、告知BSC督导查看告警，经观察，BSC网管的“时钟参考源异常告警”清除。,14,.,案例六：XX移动城域网167-122-国航大厦ARP不通，导致所在环上站点上报MPLS_TUNNEL_LOCV,问题现象167-122-国航大厦所在环上所有站点上报MPLS_TUNNEL_LOCV原因分析167-122-国航大厦地址解析异常,15,.,问题处理1、任选了一条此环上的TUNNEL用traceroutec测试，结果为到167-122-国航大厦就无法再往下PING；2、检查国航大厦所在环上端口收发光是否正常，经检查无异常，查看国航大厦与相邻网元之间光口的接口IP是否在同一网段，经检查无异常；3、进行激光口关断测试，看是否是网管侧与物理侧连纤不一致，经测试无异常。4、对国航大厦主控板进行主备倒换过后，故障解除，该站点能正常进行ARP学习，所在环上站点MPLS_TUNNEL_LOCV告警消除。,16,.,案例七：PTN3900与华为RNC对接手工聚合保护在发生倒换后不能进行业务调整,现象描述：PTN产品因拆环加点网络改造，重新配置业务，修改路由，但是源宿站点都不变。当业务删除重新配置后，发现TD业务没有起来。当前PTN3900设备版本V1R1C03SPC300，网管版本T2000V2R7C03SPC001；对接RNC为华为RNC。原因分析：业务不通，可能有以下原因：1、业务配置问题；2、端口问题；3、无线侧问题；4、PTN设备问题；,17,.,处理过程：第一步：查看告警，新配置的业务没有任何告警上报；第二步：检查PTN业务配置，查看端口、VLAN等信息均没有问题；可以排除业务配置问题。第三步：检查端口设置、流量。发现PTN对NodeB侧有接收没有发送，PTN对接RNC侧没有接受有发送（少量报文）。证明NodeB上行至RNC的报文是通的；是RNC端口没有流量输出吗？第四步：咨询无线工程师，结果是同一个RNC端口的其他未修改业务的站点都没有问题。但是PTN对接RNC的主用端口收不到任何报文；所以现在只有一种可能就是PTN到RNC的保护在修改业务前就倒换了，即当前PTN与RNC的保护状态是倒换的。第五步：查看链路聚合的保护状态，发现果然发生倒换；查看PTN备用端口流量，有大量收发数据。所以修改业务时将业务配置在PTN的主用端口上业务是不通的。导致这一现象的根本原因是PTN与RNC的保护是手工聚合（对端RNC采用的是主备方式），非负载分担，倒换不恢复的方式。,18,.,案例八：PTN950站点ML1单板故障导致CES业务不通,现象描述：某运营商，组网结构为BSC-NE1(SDH设备)-NE2(PTN3900)-NE3(PTN950)-BTS，即BSC与NE1的155M光口对接，同时NE1通过155M光口与NE2(PTN3900)的CO1对接，NE2与NE3是通过PTN网络组网的；由于NE3站点要开通一个2M基站业务，SDH侧和PTN侧分别把业务配置完成后，BSC侧说基站开不起来，传输不通。版本信息：U2000网管：V1R2C01SPC004PTN950版本：V100R002C00SPC300(5.65.02.13)PTN3900版本：V100R002C01SPH505,19,.,原因分析：1、PTN侧TUNNEL不通；2、SDH侧业务配置错误；3、PTN侧业务配置错误；4、NE1和BSC相连的光口时隙不对应，NE1和NE2相连的光口的时隙不对应；5、NE1光口故障；6、NE2(PTN3900)的CO1故障；7、NE3(PTN950)支路板ML1故障。,20,.,处理过程：1、在PTN侧进行TUNNEL测试，连通性都可用；2、首先在NE3(PTN950)的ML1相应的2M端口做内环回，BSC侧工程师说不通；3、由于NE1(SDH设备)是通过光口和BSC对接，同时SDH设备光口不支持某个VC12的环回，所以在NE1上做和BSC相连光口的业务的时隙环回，BSC侧工程师说正常；那么故障应该是SDH设备与PTN这段。4、由于目前PTN设备和网管不支持CO1的VC12通道环回，所以不能通过在NE2(PTN3900)上做VC12通道环回来判断与NE1(SDH设备)相连的通路是否正常；故更换时隙重新配置一条CES业务，然后再把NE3(PTN950)的ML1相应的2M端口做内环回，BSC侧工程师说还不通，那么就应该不是NE1与NE2对接时隙的问题。5、于是再重新配置一条CES业务，更换了NE3(PTN950)的端口，但是还是同一块单板；然后再在NE3(PTN950)的ML1相应的2M端口做内环回，BSC侧工程师说还不通；6、在U2000网管上，用伪随机码PRBS测试，把NE3(PTN950)的ML1相应的2M端口做内环回，在NE2(PTN3900)的CO1相对应的光口的时隙上进行伪随机码PRBS测试，图形显示有红色线条，发现有误码；7、把业务重新配置到NE3(PTN950)的另一块ML1单板上，通过伪随机码测试，无误码，然后把NE3(PTN950)上相应的2M端口做内环回，BSC侧工程师说通了；8、更换NE3(PTN950)上有故障的ML1单板，基站业务开通。,21,.,案例九：EX2单板硬件故障导致对端网元上载超时,现象描述：某日，合作方工程师使用T2000V2R7C03网管上载全网数据，发现其中一个汇聚环中部分PTN3900网元操作超时。组网方式：ABCDEFGA。以上所有网元为PTN3900设备，其中A为网关网元，B、C、D三个站点出现上载超时。原因分析：1、设备主控板故障；2、外纤衰耗过大导致数据丢包；3、单板DCN通道故障；4、网管软件问题；5、主机软件问题。,22,.,处理过程：1、查询相关站点告警、性能和异常事件均正常。2、使用网管分别登录B、C、D三个站点时，提示登录超时，网元脱管变灰，过段时间后可以自动恢复登录。另外使用NAVIAGATOR软件登录网元后，使用命令行查询设备逻辑单板，每次返回的单板信息都不完整。3、由于A和B之间无业务，所以从A配置静态TUNNEL到B，使用OAM中的PING功能，发现有延时丢包现象。4、根据DCN通讯最短路由原则，可以判断C、D是通过B与网关通讯，故障点很大可能是在B与A之间。5、首先静止A至B方向的11槽位EX2单板的2光口，发现以上三个站点可以正常登录。重新上载三个站点，C、D站点恢复正常，而B上载速度相对较慢。主备倒换B的主控单板后，使能A的EX2光口，发现故障现象仍然存在。排除主控可能性。6、考虑到A站点到其它方向的DCN通讯正常，所以排除A主控板故障的可能性。剩余可能性就是两个站点之间的光缆或则EX2单板。7、对调B站点两个方向的EX2单板，故障现象仍然存在，排除该站点EX2单板的可能性。8、将A11槽位EX2单板2光口尾纤和8槽位EX2单板2光口尾纤对调，发现与11槽位EX2单板2光口对接的站点出现丢包现象，而与8槽位EX2单板2光口对接的B未出现丢包现象。排除外纤的可能性。9、以同样方法，对调11槽位EX2单板1光口和2光口的尾纤，排除EX2单板光口的可能性。确认为EX2单板故障。10、现场更换EX2单板后，故障现象消失问题解决。,23,.,在U2000网管创建添加虚拟网元对联纤进行监控,PTN网管上，与落地PTN对接的RNC设备，他们之间的链接关系是否能够在网管上体现，当链路出现问题的时候能够查看到纤缆颜色变化从而判断故障的发生在网管上配置虚拟网元，将RNC虚拟成一个PTN的网元，再创建二