OSN7500设备DCN规模过大导致主控复位失败

问题描述

某日对某局点OSN7500（网关网元）设备进行远程升级，发现激活失败，主控在BIOS状态下反复复位，硬插拔单板无效。将该7500的网线拔掉以后，再次复位主控成功。

设备版本：V100R8C02SPC200

无，网管显示激活失败，使用命令行登陆，提示“处于BIOS态，请加载NE软件”，使用命令行加载软件时，加载不成功。

处理过程

1、主控加载软件成功，激活失败，判断可能是主控单板故障。

2、在主控激活过程中，其他单板上下线，导致主控复位失败。

3、主控反复在BIOS态下重启，可能是加载的软件数据异常。

4、主控在BIOS态下重启时，可能受到了来自DCN报文的攻击。

5、DCN过大，大量的ECC信息塞满了主控的消息队列。

根因

DCN规模过大，邮箱通信消息队列溢出。

解决方案

1、激活失败时，通过指示灯发现主控单板反复重启，初步判断单板故障。后更换单板，再次升级激活，主控单板仍在BIOS态下重启。将该单板插入在别的7500设备上，发现已经升级成功，排除单板故障问题。

2、使用新的主控单板插入在该槽位，不做升级，仅进行硬复位，发现主控仍然不能正常启动，判断可能是受到了DCN报文的攻击，将该7500设备的网线拔掉后，单板复位成功。多次测试，发现只要一接上网线，主控就不能正常复位，判断故障跟DCN有关。

3、将该设备的网线接在HUB上，通过HUB再与OSN7500相连，并通过HUB连接一台PC机进行抓包。

4、分析发现日志中对此出现TransCMMsg 记录，且和BIOS下日志errlog中的复位记录能够对应。

BB0中 “ 2013-04-17 [16:19:50] 0x000d 00 0x0008000b bioscm_CBiosCM. 0503 TransCMMsg  ”这一次记录和errlog中“2013-04-17 [16:20:05]    0x18    0xf0000010    0x00000001 ”对应的上。

5、继续通过研发分析TransCMMsg错误打印的函数，发现TransCMMsg在调用如下函数失败，导致主控直接复位：

dwRc = m_pAcc->TransCMMsg(vBuf, pLanHeader->wLength, 0 /*LanHeader.dwDstAddr*/,

(BYTE)(wChanPort + LAN_PORTBASE), byLanMode) ;

m_pISBoard->CheckErrCode(dwRc,VOS_ERR_LEVEL1,MODULE_ID_BIOSCM,"TransCMMsg");

6、BIOS下初始化邮箱通信的消息队列的长度为128，假设在BIOS不处理任何消息的前提下，如果上述函数返回失败，即消息队列中已经存满了128条消息，再有新的消息进来则转发出错从而复位单板。

问题出现时通过抓包的情况来看，每秒包数为5、60包，在BIOS不处理任何消息的情况下，塞满消息队列只需要2秒，在关闭DCN时，问题未重现，此时抓包为每秒10多包，这样在假设BIOS不处理任何消息的情况下，塞满消息队列需要10多秒。

同时分析数据发现，现网ECC子网数为240，远大于NG产品使用建议的64。在这种超大子网划分的场景下，网关网元主控板复位时，下挂网元一直有大规模以太网通信数据进到网关网元主控的ETH口，这就有可能会在主控板在某一时刻消息量过大，而且自身启动过程中其他任务又比较忙的情况下，出现消息队列满而复位。

第二次重现未出现异常复位，是由于把故障网元下的所有网元的网关设置为未配置，减少了此网元和其他网元的通信量，所以单板在启动过程中能够处理过来消息而不复位正常启动到主机。

7、R10C03以前的版本没提升健壮性。在现网这种ECC过大的场景会出现该问题，在R10C03版本针对这个健壮性问题进行了修改。

建议与总结

1、网关网元所带非网关网元数量太多，ECC信息过大

2、在主控重启过程中，BIOS态情况下网管会定时向网管网元发送ECC通讯包（网管并不知道主控处于什么状态）

3、由于网关网元所带ECC信息太大，在主控板重启BIOS时塞满消息队列，突发的信息包过大致使主控板不停复位清理消息队列，从而重复死循环复位操作，主控板无法正常启动

4、当拔掉网线或更改网元网关属性时，设备ETH口不会向主控板发送ECC信息包，从而BIOS正常启动，调用上层软件，最终单板正常启动

5、建议DCN的规模不超过64个。

本章相关技术资料和SDH设备故障处理流程由深圳市鼎为网络技有限公司收集整理（www.szdingwei.net），转载请保留!本公司专注华为SDH光传输设备,SDH传输设备的销售。