OSN3500 SSN4GSCC主控不能识别问题
问题描述
线网一台OSN 3500设备（版本18.50，非网关网元），之前主主控有主控重复复位故障。为将故障排除，需将主备两块主控（都是SSN1GSCC01，在本例中编号：主主控A、备主控B）都拔下来，插入新主控（SSN1GSCC01，编号C），版本匹配并下载数据后，原有故障消除。
但将原17槽备用主控（B）插回后，单板不能识别，现象为：17槽备主控（B）STAT灯红，网元没有异常告警，网元不能识别物理板，当时怀疑原主备主控都故障，就将两个主控（A、B）都返回维修。等备用主控备件到达后（SSN1GSCC02，版本已提前降级到18.50，编号D），插入17槽，发现故障现象没有变化。
用:cfg-get-phybd查询物理单板，返回：
BID BOARD-TYPE
…… ……
16 bpa
18 gscc
…… ……
网元不能识别17槽位的备用主控（D）。
用:cfg-set-oamport:COM,open;打开COM口后，ping网元单板，17槽不通，其他槽位通。
用:cfg-add-board:17,gscc手动添加GSCC逻辑单板并验证:cfg-verify，17槽上报COMMUN_FAIL，参数：0x01 0x00 0x03 0xff 0xff
但将原17槽备用主控（B）插回后，单板不能识别，现象为：17槽备主控（B）STAT灯红，网元没有异常告警，网元不能识别物理板，当时怀疑原主备主控都故障，就将两个主控（A、B）都返回维修。等备用主控备件到达后（SSN1GSCC02，版本已提前降级到18.50，编号D），插入17槽，发现故障现象没有变化。
用:cfg-get-phybd查询物理单板，返回：
BID BOARD-TYPE
…… ……
16 bpa
18 gscc
…… ……
网元不能识别17槽位的备用主控（D）。
用:cfg-set-oamport:COM,open;打开COM口后，ping网元单板，17槽不通，其他槽位通。
用:cfg-add-board:17,gscc手动添加GSCC逻辑单板并验证:cfg-verify，17槽上报COMMUN_FAIL，参数：0x01 0x00 0x03 0xff 0xff
告警信息
STAT灯红
COMMUN_FAIL
处理过程
1、将所带去的N1GSCC02（D）插入17槽，故障依旧。
2、更换AUX板，故障依旧，排除AUX故障原因。（后来查询资料证明，该故障与AUX无关）
3、将带去的SL4A线路板插入17槽，网元能正常识别，且添加逻辑单板后，能正常上线。说明17槽备板至少部分工作正常（三根状态线和部分数据线）。
4、将17槽备主控（D）跳线成BIOS态（N1GSCC02跳线方法为取下J12、J13跳线，插入J9、J10），插入17槽。能ping通，且能用FTP登陆上。登陆后，删除OSF1、OSF2目录下的PREVPDT文件，硬复位单板后，单板自动执行清库操作。清库完毕后，拨回正常态，单板依然起不来。17槽GSCC02（D）重新拨回BIOS态，采集单板数据，交给研发分析。
5、研发分析后，认为主主控和背板的嫌疑比较大。带上另外一个新的N1GSCC02（E），再次去现场定位故障（此时有2块N1GSCC02）：
5.1、新GSCC02插入17槽（E），起不来。启动过程中用CoolTest工具查询寄存器
dwReadHardwareStatus(11)
返回值为：
Value = 0 = 0x1
说明主备主控间网口状态异常，排除第一块GSCC02（D）硬件故障问题。
5.2、取下两块GSCC（C、E），将GSCC02（D，18.50版本的）插入18槽，正常启动，下载网元数据成功。
5.3、将原18槽GSCC01（C）插入17槽，起不来。报17槽COMMUN_FAIL。
5.4、将17槽GSCC01（C）取出，插入新的GSCC02单板（E），单板上线，网元能识别GSCC。确定是原GSCC01主控板（C）故障。（C主控10M以太网通信模块故障，导致C当主主控时，不能与备主控建立通信，备主控不能上线。C当备主控时，也不能与主主控通信。更换新主控E后，问题就解决。）
5.5、将版本统一到18.50后，查询：
:hbu-get-backup-info
返回：
Backup-Info : 0x00000003
同步成功。
:hsc-get-work;
返回：
Work-Status : 18 Good 17 Good
主备状态正常。
5.6、手动下发主备倒换命令，主备成功倒换。故障排除。
2、更换AUX板，故障依旧，排除AUX故障原因。（后来查询资料证明，该故障与AUX无关）
3、将带去的SL4A线路板插入17槽，网元能正常识别，且添加逻辑单板后，能正常上线。说明17槽备板至少部分工作正常（三根状态线和部分数据线）。
4、将17槽备主控（D）跳线成BIOS态（N1GSCC02跳线方法为取下J12、J13跳线，插入J9、J10），插入17槽。能ping通，且能用FTP登陆上。登陆后，删除OSF1、OSF2目录下的PREVPDT文件，硬复位单板后，单板自动执行清库操作。清库完毕后，拨回正常态，单板依然起不来。17槽GSCC02（D）重新拨回BIOS态，采集单板数据，交给研发分析。
5、研发分析后，认为主主控和背板的嫌疑比较大。带上另外一个新的N1GSCC02（E），再次去现场定位故障（此时有2块N1GSCC02）：
5.1、新GSCC02插入17槽（E），起不来。启动过程中用CoolTest工具查询寄存器
dwReadHardwareStatus(11)
返回值为：
Value = 0 = 0x1
说明主备主控间网口状态异常，排除第一块GSCC02（D）硬件故障问题。
5.2、取下两块GSCC（C、E），将GSCC02（D，18.50版本的）插入18槽，正常启动，下载网元数据成功。
5.3、将原18槽GSCC01（C）插入17槽，起不来。报17槽COMMUN_FAIL。
5.4、将17槽GSCC01（C）取出，插入新的GSCC02单板（E），单板上线，网元能识别GSCC。确定是原GSCC01主控板（C）故障。（C主控10M以太网通信模块故障，导致C当主主控时，不能与备主控建立通信，备主控不能上线。C当备主控时，也不能与主主控通信。更换新主控E后，问题就解决。）
5.5、将版本统一到18.50后，查询：
:hbu-get-backup-info
返回：
Backup-Info : 0x00000003
同步成功。
:hsc-get-work;
返回：
Work-Status : 18 Good 17 Good
主备状态正常。
5.6、手动下发主备倒换命令，主备成功倒换。故障排除。
根因
OSN 7500/3500/2500/1500板间通讯有二种方式（具体见图1）
1）单板间2路HDLC通道，遵从HDLC协议，接口电气规范为RS485。
2）1路LAN SWITCH通道。
图1. OSN 3500主控板通信实现原理
LAN SWITCH通道传递的是主机和单板之间的正常配置信息和单板向主机上报的告警、性能，相当于老产品中的邮箱。其中主备主控间备份数据用的是10M速率，其他以太网速率都是100M。
485通道主要实现与复用段、SNCP、TPS相关的功能，速率为4Mbits/s。
A通道：用于复用段保护相关的SD、SF事件、K字节、倒换页面的传递。
B通道：用于SNCP、TPS倒换、S1字节相关信息的传递，另外在线路板检测到交叉板送过来的总线信号有问题时线路板会通过B通道传递交叉倒换信息，促使交叉板发生一次倒换。
根据告警信息，COMMUN_FAIL 第三个参数为0x03。指的是17号板以太网的通讯失败告警。即para3为3时表示以太网的通讯失败告警。
由此分析，故障原因可能如下：
1、新带来的备主控故障。
2、原故障换上去的主主控故障。
3、AUX故障。
4、背板故障。
1）单板间2路HDLC通道，遵从HDLC协议，接口电气规范为RS485。
2）1路LAN SWITCH通道。
图1. OSN 3500主控板通信实现原理
LAN SWITCH通道传递的是主机和单板之间的正常配置信息和单板向主机上报的告警、性能，相当于老产品中的邮箱。其中主备主控间备份数据用的是10M速率，其他以太网速率都是100M。
485通道主要实现与复用段、SNCP、TPS相关的功能，速率为4Mbits/s。
A通道：用于复用段保护相关的SD、SF事件、K字节、倒换页面的传递。
B通道：用于SNCP、TPS倒换、S1字节相关信息的传递，另外在线路板检测到交叉板送过来的总线信号有问题时线路板会通过B通道传递交叉倒换信息，促使交叉板发生一次倒换。
根据告警信息，COMMUN_FAIL 第三个参数为0x03。指的是17号板以太网的通讯失败告警。即para3为3时表示以太网的通讯失败告警。
由此分析，故障原因可能如下：
1、新带来的备主控故障。
2、原故障换上去的主主控故障。
3、AUX故障。
4、背板故障。
解决方案
建议与总结
1、主控板与系统其它的单板主要是通过以太网进行通信，各单板和两块主控板的板间通信以太网都与AUX板相连，所以从物理上主备主控板同时都可以与其它各单板通信。（见图1）
但为了保持主备主控板的数据一致，备用主控板的板间通信没有使用，它与线路板的数据完全来源于主用主控板（通过下面提到的10M以太网通信）。对于板间通信的网口，两块主控板的MAC地址不同，IP地址不同，以OSN3500为例：18板位的IP为：192.168.0.18；17板位的IP地址为：192.168.0.17。这个网口的默认网段为：192.168.0.XXX，子网掩码为：255.255.255.0。
网管接口也是如此，不同的是备用主控板的网管以太网口完全是关闭的，只有在成为主板后才打开，保证同时只有一个主控板与网管相连。对于网管通信的网口，两块主控板的MAC地址相同，IP地址相同。这个网口的默认网段为：129.9.XXX.XXX。
主备主控板间还有一个10M的以太网进行主备通信，备板的数据基本上都是通过这个网口从主板获得的。这个网口的默认网段为：10.108.7.XXX。XXX与板位号一致。
2、COMMUN_FAIL告警与AUX板的关系：
COMMUN_FAIL告警参数3的意义：0x01表示RS485通道1。0x02表示RS485通道2。0x03表示板间以太网通信。
如果COMMUN_FAIL告警发生在主控板上，则告警与AUX没有关系；
如果COMMUN_FAIL告警发生在其他单板上，且参数3为0x03，则告警有可能与AUX有关系。
3、主控板三根状态线：（图2）
图2：NG-SDH三根状态线
在位状态信号线：互送板在位状态，板在位或者不在位，这个状态是逻辑运行的结果，可读不可写；
工作状态信号线：互送板工作状态，板工作状态为好或者坏，这个状态是由硬件和软件共同决定；
主备状态信号线：互送板主备状态，是主板还是备板，这个状态是逻辑运行的结果，可读不可写。
本案例中，由于17槽位插SL4A单板，能正常识别并开工，所以状态线没有问题。
4、不能完全相信维护备件，备件也有可能是坏的，处理故障时要大胆怀疑。
总结：
该故障原因其实很简单，但重点在分析和定位的过程。原理清楚，材料、资源准备充分，才能快速定位故障。另外，不能盲目相信备件就是完好的，该怀疑时就要怀疑。
但为了保持主备主控板的数据一致，备用主控板的板间通信没有使用，它与线路板的数据完全来源于主用主控板（通过下面提到的10M以太网通信）。对于板间通信的网口，两块主控板的MAC地址不同，IP地址不同，以OSN3500为例：18板位的IP为：192.168.0.18；17板位的IP地址为：192.168.0.17。这个网口的默认网段为：192.168.0.XXX，子网掩码为：255.255.255.0。
网管接口也是如此，不同的是备用主控板的网管以太网口完全是关闭的，只有在成为主板后才打开，保证同时只有一个主控板与网管相连。对于网管通信的网口，两块主控板的MAC地址相同，IP地址相同。这个网口的默认网段为：129.9.XXX.XXX。
主备主控板间还有一个10M的以太网进行主备通信，备板的数据基本上都是通过这个网口从主板获得的。这个网口的默认网段为：10.108.7.XXX。XXX与板位号一致。
2、COMMUN_FAIL告警与AUX板的关系：
COMMUN_FAIL告警参数3的意义：0x01表示RS485通道1。0x02表示RS485通道2。0x03表示板间以太网通信。
如果COMMUN_FAIL告警发生在主控板上，则告警与AUX没有关系；
如果COMMUN_FAIL告警发生在其他单板上，且参数3为0x03，则告警有可能与AUX有关系。
3、主控板三根状态线：（图2）
图2：NG-SDH三根状态线
在位状态信号线：互送板在位状态，板在位或者不在位，这个状态是逻辑运行的结果，可读不可写；
工作状态信号线：互送板工作状态，板工作状态为好或者坏，这个状态是由硬件和软件共同决定；
主备状态信号线：互送板主备状态，是主板还是备板，这个状态是逻辑运行的结果，可读不可写。
本案例中，由于17槽位插SL4A单板，能正常识别并开工，所以状态线没有问题。
4、不能完全相信维护备件，备件也有可能是坏的，处理故障时要大胆怀疑。
总结：
该故障原因其实很简单，但重点在分析和定位的过程。原理清楚，材料、资源准备充分，才能快速定位故障。另外，不能盲目相信备件就是完好的，该怀疑时就要怀疑。
销售OSN3500 SSN1GSCC_产品报价_销售厂家_产品特性_产品描述_华为SDH传输设备销售
供应OSN3500 SSN1GSCC_故障处理_安装调测_技术指标_技术参数_华为SDH传输设备销售
- 上一篇：OSN3500 SSN1SXCSA和SSN4GSCC版本不配套业务倒换失败 2018-5-20
- 下一篇：OSN3500 SSN3EGS2配置EPLAN业务接入点延时过大 2018-5-20
