故障案例分析

网管案例

1.1 U31网管查询版本号显示问题

故障现象：

OTN网络使用U31网管查询并导出全网8000设备的单板版本信息，只显示

大版本号，不能显示小版本号。

故障分析：

U31网管提供了单板小版本号查询，以及在单板配置报表中查询小版本号并打

印输出的功能，方便升级或其他操作的资料核对应用场景。

解决方法：

1. 单板小版本号查询

（1）打开单板软件版本查询小版本号开关

..\ems\ums-client\procs\ppus\bn.ppu\bn-core.pmu\ican-clnt-boar

dview.par\conf\ini\BoardviewConf.ini文件，找到

ZTEBoardVerDetail=false，将值改为true。

（2）查询单板版本

单板视图中，对要查询的单板右键菜单，选择单板软件版本查询，

即可看到单板版本详细信息。

图0-1 当前运行版本（含小版本号）

1.2 M820设备电层1+1保护故障

故障现象：

某日，某地OTN设备“A网元-B网元”之间光纤发生双向中断，绝大部分业务自

动倒换成功，但有两条GE业务倒换失败，经过现场紧急处理，两小时后业务恢

复正常。其中一条业务倒换失败的原因是由于WASON版本太低，保护组数目超

过限制，是已知问题。另一条业务倒换失败的原因是由于升级CSU逻辑程序引

起，本文将对这个故障进行分析。

故障分析：

故障具体表现为，保护组发生了单边倒换，B网元倒换成功，另一侧A网元未发

生倒换，在网管上查询A网元交叉及保护组状态都显示未发生倒换，在网管进

行“强制倒换/人工倒换”均提示操作优先级过低，倒换失败。

故障原因

研发分析为升级CSU的逻辑程序时，导致SMUB的背板信号失效，进而导致了后

来的保护倒换失败。

解决方法：

由于故障保护组拒绝“人工倒换/强制倒换”，最大的可能性是备用路径上有

告警。

1.首先在网管检查保护路径上的告警。

梳理“工作-保护”业务路径，保护路径上的告警情况如下。

保护路径的SMUB上只存在A网元往B网元方向的PM_BDI告警，这个告警是由于A

网元未发生倒换，交叉仍在工作路径上，因此COM 0-3-13还是从SMUB 0-3-5

上获取数据帧，由于工作路径光纤断开，所以COM 0-3-13检测到ODU AIS，回

送PM_BDI到保护路径SMUB 0-3-6产生的。PM_BDI是反向告警，根据倒换原理，

它不作为倒换触发的条件，不会影响倒换。

2.接着排查背板通道状态。

在网管查询A网元站点CSU的背板通道状态，发现SMUB0-3-6的背板通道状态

“LOS”，经与研发确认，这个背板通道“LOS”为正常现象，它产生的条件是：

在SMUB->COM方向上没有配保护交叉。见下图，

B网元两块SMUB的背板通道状态也是“LOS”，正是由于这两个单板SMUB->COM 的方向没有配置保护交叉，见下图

如将SMUB->COM方向的保护交叉配上，背板通道状态将恢复为“正常”，因此背板通道状态不能作为判断保护组状态的依据。

这里解释一下为什么部分保护组没有配置保护交叉。因为这些保护组是在E300网管上配置的，5月份将E300升级到U31，因为U31在功能上有一些限制，保护交叉无法恢复，但是这并不会影响业务倒换。

注：这个问题今年的U31大集成版本已经改进，可以从E300数据库将保护交叉直接导入。

3.telnet WASON上确认保护组的状态。

在网管配置界面查询到保护组ID为131，根据这个ID，在WASON上采集了保护组状态信息，见下图

WASON的打印信息表明，在工作通道，SMUB 0-3-5的光口和背板端口上报了告警，告警类型为a0a2，分别对应工作路径断纤产生的光口LOS和背板电发送口

的ODU LOFLOM，导致工作通道为SF信号失效告警状态，该状态与实际情况吻合。

而在保护通道，也是SF信号失效告警状态！这是明显的异常，对于WASON来讲，

单板地址3ff表示CSU0-3-7单板，端口4a06表示同子架的SMUB 0-3-6产生了

a0a2告警，对于CSU来讲，上报a0a2告警就表示检测到SMUB 0-3-6的背板信号

有问题。

4. IC复位SMUB，现场故障解决。

当即对SMUB 0-3-6进行IC复位，IC复位起来后，保护组倒换到保护路径，客户

确认业务恢复正常。

1.3 OLA站点监控正常但OA2异常

故障现象：

某网络新开局阶段，准备开通一条备用光路上的3个OLA站点，按照计划，

现在准备开通其中的2个OLA站点：偃师、巩义。网络当时的拓扑如图6-1

所示。

图0-2 网络拓扑图

准备在网管上通过OTN便捷开通方式，从洛阳开通偃师、巩义。但在开通过

程中遇到奇怪的现象：偃师、巩义两个站点已经可以在网管上正常管理，但偃

师站点收巩义方向的OA板收光异常，收光功率甚至为+2dB。此时上街站点

还没开通，正常的话，偃师收巩义应为无光或弱光。

故障分析：

两个站点的连纤图如图6-2所示。

网管上核查巩义发偃师方向的OA板卡（0-1-6-EONA18）的输出光功率为-1.3dB，而偃师收巩义方向的OA板卡（0-1-6-EONA18）的接收光功率为+2dB。怀疑偃师站点连纤有误，可能把SOSCB的输出光接到OA板IN口，但现场人员插拔SOSCB上的尾纤，对OA板输入光功率没有影响。相反对端站点SOSCB对应的光口无光，说明SOSCB连纤正确。

接着核查OA板线路侧连纤情况，让现场人员拔掉巩义0-1-6-EONA18板卡OUT口的线路尾纤，发现偃师0-1-6-EONA18板卡仍然有接收光，且光功率不变！而且两站点监控光正常，巩义站点居然没有掉线！

但拔巩义0-1-28-EONA18板卡OUT口的尾纤时，发现偃师0-1-6-EONA18报输入无光告警，于是发现问题所在：巩义站点线路侧尾纤接线错误，用同一块OA板卡（0-1-28-EONA18）收发偃师站点；巩义0-1-28-EONA18输出光功率为15dB，两站点之间线路侧衰耗约13dB，故偃师OA板卡输入+2dB

现场错误的连纤方式如图6-3所示。