华为传输扩展ECC不通的解决办法.doc

扩展ECC不通的一个解决方法
关于新建子架间可以互通ECC，而不能与原有子架通ECC的问题
----引用A站督导邮件：
“在本次扩容工程中A站遇到一个很奇怪的问题，以本人知识水平无法得
出解释。虽然现在已经正常，但做为一个工程现场的督导，我想有责任有义务对该问题进行
描述与反馈。以便今后的工作中遇到类似的问题，也有一个实际的案例可以参考。希望各位同仁及同行“前辈”指教。

本次工程A站新增两个320G波分子架（以下简称新设备），分别对应两个不同方向。原有6个子架（以下简称老设备），2个方向各3个，分属不同机柜。通过以太网口走ECC自动路由与网管通信。

新设备的网线分别插在两个方向老设备下的HUB上。

对设备进行加电后，分别对新设备两个子架按照要求进行相关设置，包括初始化网元、设置IP、子网掩码、网关，及用命令:cm-set-lanautoecc:open;打开ECC自动路由功能，
然后复位。

但发现新设备和老设备之间ECC始终不通。但两个新设备之间能通ECC。之后检查相关设置，无误。

老设备6个子架IP分别为：132.37.6.98 到 132.37.6.103
ID对应为：24,25,97,26,27,98
子网掩码均为：255.255.255.224
网关均为 ：132.37.6.97

新设备2个子架IP分别为：132.37.6.106 和 132.37.6.107
ID对应为：106，107
子网掩码均为：255.255.255.224
网关均为 ：132.37.6.97

以上数据显示所有网元均属同一网段。拔掉新设备网线，用电脑PIN G132.37.6.106 和
132.37.6.107。均不通，说明该IP在网络上没有冲突。

查询主机版本：
老设备均为：
OptiX 1600G BIOS 8.07.01 Jan 15 2003 09:40:04
NeSoft(D) 5.08.01.31 <May 19 2003 15:11:09>
新设备均为：
OptiX 1600G BIOS 8.07.03 May 23 2003 09:30:07
NeSoft(D) 5.08.01.31 <May 19 2003 15:11:09>

以上数据均正常。后来再次复位、插拔主控板，对设备从新初始化、从新设置。用尽所有办法，
问题依然存在。

第二天，问题任然存在，没得到解决。

第三天早上到机房，打开电脑，对设备进行查询时，发现ECC通了。问题消失。查询相关设置
，任然是同样的设置。硬件及网线连线方式均无变化。

希望我的描述能对大家在今后的工作中有所帮助~！”

以上是A站督导反馈的在做A站工程时，发现两个新建子架间能互通ECC，旧机架之间能互通ECC，而新旧子架间无法互通ECC的情况。费了老大的劲也没能搞定，直到10月13日的早上突然一通百通了？！
同样的问题在B站再次出现，在现场处理的过程中，发现B站的故障情况与A站的完全一致，折腾了两个小时没有任何结果。于是将A站点站点（共8个子架）的相关设置、告警、性能等通通查了一遍，终于发现了一个问题：10月13日，虽然A站督导肯定无人对网元进行了任何操作，但上午8点23分左右，一个旧子架的主机因人为误操作或本身异常发生了一次复位，如下：

#24:lognew:1,"nesoft"
@@@@@@@@@@@@@@@@@ Message from 0x00090018 (9.0.24 589848) @@@@@@@@@@@@@@@@@@

#24:szhw[A1-1 ][][2004-10-25 0:38:0]>
:errlog

ResetLog:: total reset times = 9
No.0: 1990-1-1 5:50:8
No.1: 1990-1-1 6:4:55
No.2: 1990-1-1 6:13:34
No.3: 1990-1-1 10:42:26
No.4: 1990-1-1 12:39:15
No.5: 2004-2-5 17:4:39
No.6: 1990-1-1 0:0:16
No.7: 2004-9-27 17:17:38
No.8: 2004-10-13 8:23:41

# 1990-1-1 5:50:8
fatal task errorcode=ffffffff, Line 717 in vos_err.cpp
# 1990-1-1 6:4:33
fatal task errorcode=ffffffff, Line 3368 in mml_cmdline.cpp
# 1990-1-1 6:13:12
fatal task errorcode=ffffffff, Line 3368 in mml_cmdline.cpp
# 1990-1-1 10:42:4
fatal task errorcode=70008, Line 2619 in cm_net.cpp
# 1990-1-1 12:38:53
fatal task errorcode=70008, Line 2619 in cm_net.cpp

# 2004-2-5 17:4:17
fatal task errorcode=ffffffff, Line 3368 in mml_cmdline.cpp
# 1990-1-1 0:0:16
fatal task errorcode=ffffffff, Line 717 in vos_err.cpp
# 2004-9-27 17:17:16
fatal task errorcode=70001, Line 389 in qx_pronedata.cp
# 2004-10-13 8:23:19
fatal task errorcode=70001, Line 389 in qx_pronedata.cp

#24:szhw [A1-1 ][][2004-10-25 0:38:3]>
#25:lognew:1,"nesoft"
@@@@@@@@@@@@@@@@@ Message from 0x00090019 (9.0.25 589849) @@@@@@@@@@@@@@@@@@

10月13日上午，也就是现场督导反馈说“第三天早上到机房，打开电脑，对设备进行查询时，发现ECC通了。问题消失。查询相关设置”的时间。
由此提醒我，旧子架的那次主机复位可能是解决问题的关键。查询B站的任意一个旧子架的自动扩展ECC情况，发现是OPEN状态的。
我于是下发了这样两条命令：
:cm-set-lanautoecc:open //打开自动扩展ECC
:reset; //主机复位
复位完成后再次查询，不出所料，新老子架间的扩展ECC通了。
无意中总结发现了解决这个问题的一个方法，但这个问题存在偶发性，这次工程，涉及站点众多，目前出现该问题的也就是A站与B站。按照常理分析，旧子架运行状态稳定，扩展ECC应该就没有问题，主机复位到底在这其中扮演了一个什么样的角色，是软/硬件的小BUG还是其他什么原因呢？

《最终分析结论》：
因为自动扩展ECC建立的前提是搜索到其它的网元的IP，然后由IP较小的主动连接IP较大的。由于5.8.1.31版本一个网元最多只能找到四个网元，6个网元运行稳定以后，如果新接入网元的IP较大的话，老子架就没有能力再和新子架建立连接了，所以就通不了。
将老的子架复位后，网元搜索会重新进行，所有网元之间的通讯可以重新组织，所以新老网元之间可以建立通信。如果新接入网元的IP比老子架网元的IP小的话，不需要复位老子架，就应该可以通的。