GPON网元脱管故障.docVIP

GPON网元脱管故障 ——两台9806H上线就导致所处OLT及OLT下的其它有网元管理不上 一、故障现象 OLT下挂有多台F820和F620，ONU业务和管理运行正常。 但当开通两台9806H时，只要9806H注册成功并配通了管理通道后，OLT与该OLT下其它网元（F820）全部脱管（在网管上显示网元链路中断），只有这两台9806H管理正常。脱管的网元业务未受影响。 二、故障处理及分析 （1）出现故障时，9806H所处的OLT本身脱管；OLT下除9806H外所有的ONU脱管，但这些脱管的ONU在OLT上注册状态正常、所带业务也正常；同一个交换机下的另一台OLT也受影响脱管（管理VLAN和IP段相同）。由此定位故障影响同一个广播域下的网元管理通道。 （2）将两台9806H从OLT上去注册或将其管理VLAN删除，所有脱管网元管理恢复正常。初步确定故障触发点为9806H。 （3）当9806H上线导致其它网元脱管时，登录任一台9806H，可以ping通和telnet登录脱管的网元。通过9806H telnet到F820上，查看mac学习情况和arp表都正常，但ping网关不通；通过9806H telnet到C220上，ping网关不通，show mac发现在0/1/3:2下学习到了网关MAC：0018.82d2.6828 30 Dynamic gpon-onu_0/1/3:2 vport 1； 同时查看OLT上告警show logging alarm显示有MAC冲突： An alarm 19714 level 6 occurred at 18:12:01 07/31/2010 8 sent by MCP %ARP% The arp packet of mac address 00d0.d09e.6736（OLT带内MAC）, which conflicts with our mac address of vlan30, is discarded 由此推断可能是9806H侧出现环路或用户上报异常MAC； （4）检查两台9806H，发现在并没有带业务，删除9806H上宽带数据，只保留了一个管理通道，故障依旧。排除用户侧环路可能； （5）检查两台9806H的配置发现上联口模式都配置成了cascade（级联）模式，按要求，GPND小卡上行时，9806H要求上联模式为link-aggregation（聚合）；而EPND小卡上行时才要求配置为cascade模式。将uplink-mode 改为link-aggregation后，脱管网元恢复正常，故障消失。 三、故障原因 当GPON上行的9806H上联口采用cascade（主备级联）模式时，5/1和5/2两个上联口会成环，导致故障；改成link-aggregation（链路聚合）模式后，5/1和5/2两个上联口捆绑成一个聚合组上联，问题消失。 在9806HV2.0P4T1、P4T4、P4T5、P4T8版本发布说明中，都明确要求9806H采用GPND上联小卡时，上联模式要改为link-aggregation模式。 现场这两台9806H之所以上联模式被改为cascade，是因为在进行宽带业务配置时，使用了9806H EPON下的开局脚本，将缺省为link-aggregation的上联模式改为了cascade： config system hostname SY-AZXQ-B-8-9806H uplink-mode cascade master-port 5/1 add-vlan 1048-1095 vlan 1048-1095 5/1-2 tag 四、解决方法 GPON网络中，9806H上联模式设置为link-aggregation模式。 五、故障总结 海口移动GPON网络中，两台9806H上线就导致所处OLT及OLT下的其它有网元管理不上的问题，是由于工程开局过程中，错误配置9806H上联口模式形成环路导致，改成正常配置后故障解决。 内部公开▲ 本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播