华为SDH设备维护操作经验

1华为SDH设备维护操作经验忻州通信分公司索云峰我从98年参加工作以来，一直从事传输维护工作。在近6年的设备维护中，亲眼目睹、亲身感受着通信事业日新月异的发展。融身于其中，我也在努力的学习、不断的探索，紧紧跟着通信事业飞速发展的步伐，使自己在传输维护水平上尽量处于排头兵的位置。2000年、2002年的华为B培及A培，使自己在理论和实践上均获得了长足的进步。在学习和工作过程中，我发现经验的积累更为重要。因此，我把在华为设备维护中的一些维护经验、案例处理及一些疑问写出来供大家参考。目前忻州传输网设备中，华为设备占较大的比重，从98年到现在，华为设备从155、622到2500＋以及现在的10G和波分，新设备在不断增加，而旧的设备也不可能在短时间内淘汰，致使忻州传输网形成现在的新老设备共存局面。维护中发现的问题也是层出不穷。案例1：某日神池局扩容时出现业务无法配置的情况，虚线表示新扩容的交换点，组网如图所示：神池18义井19庄儿上20环城105西口子235东湖150大严备151八角1522神池局原来配置为：11（sys1）、12(sys2)、13(sys3)槽位各有一块SL1,分别对义井、环城、西口子，现在在14槽位增加一块SL1，对东湖、大严备和八角各开16个2M，业务配置如下：原有业务：:cfg-create-vc12:sys1,t1,1&&16,sys1,gw1,1&&16;//对义井、庄儿上:cfg-create-vc12:sys1,gw1,1&&16,sys1,t1,1&&16;:cfg-create-vc12:sys2,t2,1&&16,sys2,gw1,17&&32;//对环城:cfg-create-vc12:sys2,gw1,17&&32,sys2,t2,1&&16;:cfg-create-vc12:sys3,t3,1&&16,sys3,gw1,33&&48;//对西口子:cfg-create-vc12:sys3,gw1,33&&48,sys3,t3,1&&16;新增业务如下：:cfg-create-vc12:sys4,t4,1&&16,sys4,ge1,1&&16;//对东湖:cfg-create-vc12:sys4,ge1,1&&16,sys4,t4,1&&16;:cfg-create-vc12:sys4,t5,1&&16,sys4,ge1,33&&48;//对大严备:cfg-create-vc12:sys4,ge1,33&&48,sys4,t5,1&&16;:cfg-create-vc12:sys4,t6,1&&15,sys4,ge1,49&&63;//对八角:cfg-create-vc12:sys4,ge1,49&&63,sys4,t6,1&&15;现象描述：在网元18下大严备业务时，原先配置为：:cfg-create-vc12:sys4,t6,1&&16,sys4,ge1,17&&32;:cfg-create-vc12:sys4,ge1,17&&32,sys4,t4,1&&16;但是当下发时，提示“共用入总线冲突”。原因分析：查询设备属性，原来神池局设备为155/622一型子架，交叉板为XC1,通过查询华为资料得知，一型子架的线路槽位11和13公用一根总线，12和14槽位公用一根总线，8个支路槽位分别是1和5、2和6、3和7、4和8各共用一根总线。交叉能力为6×6VC4这是一型子架的特点。因为此原因，造成业务下发时错误。3处理方法：更改业务配置，使业务的配置避开共用总线的限制。因为SYS2即12槽位已使用了17－32时隙，故只要避开17－32时隙即可。经验总结：SBS155/622为华为早期产品，受共用总线和交叉能力的限制。所以在新旧混合的设备组网或扩容中，一定要注意此设备的特点。否则可能造成使预期的网络规划无法实现，以免造成不必要的浪费。建议在网络改造时，如果此类设备暂时不能退网，应尽量将这类设备尽量放置在网络的边缘节点上。案例2：由于告警没有自动上报，造成告警无法及时发现，致使故障没有及时解决。目前忻州市局通过路由器对县局华为农话网络进行集中监控，原平局和定襄局分设二级网管。某日，原平局的一个2000门交换点在晚上1：00左右，由于交叉板故障造成全阻。忻州局的网管上没有发现任何告警，等到交换中心反映上来时，距障碍发生已很长时间，造成很大损失。上级部门严令查明原因。原因分析：点击此网元，发现网元处于未登录状态，于是立即打电话询问原平局是否有人对此网元操作过。原来原平局维护人员在操作网管时，误将网管上的网关网元删除，造成其他网元不能登录，于是将所有的网元全部删除，重新创建后做了上载，而创建网元时用的是默认的用户名：“root”和密码：“password”，由于使用的是和忻州网管同样的超级用户名，致使忻州网管用户被踢出，所以未及时发现告警。这是造成此次故障的主要原因。处理方法：将原平的网管的所有网元登录用户都改为原来的超级用户4名“yuanping”，问题解决。经验和教训：保证中心局网管对其所监控的网元的告警信息进行实时监控的条件是确保中心局的网管始终处于登录状态，为此，一定要做到以下几点：1、不同的网管新建网元时一定要使用不同的用户。2、通过中心局的集中网管给分设的二级网管指定网元用户名，并指定专人管理。3、如果因维护需要对网元进行业务修改等操作时，一定要与中心网管的系统管理员取得联系，得到允许时再进行操作，并将所做的操作汇报上级网管中心。案例3：由于设备升级造成部分站点短时间全阻的问题。忻州局东环10G组网如下：如图所示：忻州、定襄、五台、繁峙、代县、原平10G设备组成两纤双向复用段保护环，每个站点下挂2500+设备。忻州10G定襄10G五台10G繁峙10G代县10G原平10G2500+2500+2500+2500+2500+2500+10G两纤复用段保护环5障碍现象：某日，对网上设备进行主机软件和单板升级。正常情况下，对主机软件升级应该不会造成业务阻断，但是对主机软件升级时，首先停止了全网协议。待到忻州和定襄的主机软件升级完成时，网管上发现原平、代县、繁峙业务全阻，忻州和定襄有APS_INDI告警，检查复用段状态，发现忻州站为“倒换西向”、定襄站为“倒换东向”。将两站的复用段协议停止后，业务恢复正常。这是什么原因呢？原因分析：查询复用段协议状态，发现忻州和定襄的协议为启动状态，而其他四个站点为停止状态。因此怀疑是复用段协议启动造成倒换不成功引起。原来当主机软件升级后，由于主控复位导致了复用段协议的重新启动，影响了业务。当忻州站主机软件升级完成后复用段协议启动时，由于其两侧的站复用段协议是停止状态，忻州站发出的用于检测环路是否正常的K字节在环上不能穿通回到忻州站，而且其它站对忻州站发出的K字节也不会有响应。这种情况下忻州站认为两侧网元失效，因此协议启动并进入双端失效的状态，但是双端失效并不会改变交叉板的数据。但在定襄站升级完成协议启动时，由于忻州站收到了定襄站的K字节，忻州站认为其东向正常，所以进入了倒换西向；而且定襄站也进入倒换东向。在两站协议都启动后，将出现忻州站倒换状态为“倒换西向”、定襄站为“倒换东向”的现象。结论：原来主机软件升级后，复用段协议会自动重启。由于协议启动造成网络发生保护倒换，而此时有的站点协议处于停止状态，因6而倒换不成功，造成部分站点阻断。因此，主机软件升级时，不应该停止全网的协议。案例4：由于交叉板损坏造成部分站点业务不通。原平局组网如下所示：原平为中心局，其他各站对它都有业务，其中轩岗为SNCP节点。业务流向为西发东收（逆时针方向）。障碍现象：某日，石寺交换点掉电，交换机房反映，原平到矿务局的业务全阻。但是从传输网管上却没有任何告警。故障分析：开始怀疑是网管告警不能上报告警，但是用网管和命令行查询，原平和轩岗均无任何告警。用HP37742A在线检测也正常。因此怀疑是交换问题。但是，交换经过重新配置、换板均不能解决。于是重新定位到传输的问题。矿务局2M做环回，在原平局用2M误码仪终端测试，发现屏幕菜单的”sync”显示：“lost”,而通道正常时应显原平70西镇71后沙城72大牛店73上阳武74轩岗75龙宫76段家堡77石寺78崞阳79薛孤80矿务局90两纤单向通道保护环7示”found”,说明从仪表发出的伪随机码在收端收不到。因此怀疑从原平到轩岗的备环方向的站点上某个站的交叉不好。于是用更改业务法进行判断。首先，从原平到西镇配置一条2M双向业务，测试正常。当配置到大牛店时，发现仪表显示又成了“lost”,初步断定是大牛店的交叉板故障。带上备板到大牛店交换点更换交叉后，矿务局的业务恢复。经验总结：当发生故障时，仅仅靠网管分析有时并不能真正定位出故障所在，结合仪表分析是一种有效的故障处理方法。以上四个案例是我在维护中遇到的比较典型的故障，尤其是案例4最具有代表性。在这里我把我的处理障碍的思路和方法写出来供大家参考，以便于大家在遇到类似障碍时，能够快速准确的定位出故障所在，从而尽量缩短障碍历时、提升维护质量。