《硅谷》杂志:传送网元脱管定位思路及处理方案 |
2013-01-18 13:44 作者:郝振林 王 杰 来源:硅谷网-《硅谷》杂志 HV: 编辑: 【搜索试试】
|
|
据《硅谷》杂志2012年第21期刊文称,网元脱管是传送网络维护中经常碰到的问题。虽然有时网元脱管并不会影响传送业务,但当网元脱管时,对于传送网隐患的发现会起到很大阻碍,需要尽快处理,否则有可能发展成为业务中断重大事故。将通过案例及告警分析对网元托管的处理提供思路。
关键词:传送网;网元;网管;脱管
0前言
日常问题处理中,脱管问题是网络较多的问题之一,脱管问题原因很多,所需要具备的技能较为综合,包括设备ECC通信原理、网管与设备通信原理等等,有一个清晰的思路,是找到问题症结的关键,本文总结囊括了网元脱管的多种场景,包括各种原因的分析,希望通过本文的学习能够进一步掌握各种脱管问题的分析处理方法。
1脱管的定义及网管与设备的通信机制和检测机制
脱管就是网管无法对网元(主机)进行正常的管理。其现象主要表现为:网元变灰、网元无法登录。
网管与网关网元会建立socket连接,socket连接检测仅仅是检测网管与网关网元之间的socket连接是否正常,这个检测仅对Qx类型网关网元进行,如果连续3次(每次36秒)未响应,再第4次下发就会置socket中断,上报GNE_CONNECT_FAIL告警;网管与网关网元和非网关网元之间都会进行DCN检测,对网元下发Qx/TL1消息,需要网元进行Qx/TL1响应,如果网元连续2次(60秒一次)未响应,在第3次下发时就会置网元通信中断,上报NE_COMMU_BREAK告警;网管会对网关网元以及非网关网元下发登录命令,如果失败则上报NE_NOT_LOGIN告警。
3各种故障定位处理
3.1上报NE_NOT_LOGIN告警
网管登录不上网元,但并不代表网管与网元之前的通信不通,告警是检测后立即上报的;而上报NE_COMMU_BREAK告警表示网元通信不通,同样肯定会伴随NE_NOT_LOGIN告警,该告警至少要2分钟(2×60秒)才会上报;而上报GNE_CONNECT_FAIL告警表示网关通信失效,与该网关相关的非网关网元应该有脱管现象,该告警从检测故障起108秒(3×36秒)才会上报;
nDCNTestTimeoutCount参数,该参数即上面提到的DCN检测的参数,缺省为2,即连续2次(60秒一次)未响应,第三次置网元通信中断。可以在ems.cfg中增加nDCNTestTimeoutCount=2这一行,把该参数改大可以缓解网管上网元频繁脱管的现象,但该方法治标不治本,无法根本解决DCN网络差的问题,一般是不建议使用的。
3.2单个网元脱管和多个网元脱管
脱管有单个网元脱管和多个网元脱管,单网元脱管的原因一般有:网元ID冲突、主控故障、光板故障、网元用户不正确、所属网关设置不正确等等;单网元脱管的定位可以参考以下流程图:
3.3ECC风暴
ECC风暴的根本原因是ECC本身不适合大组网导致的,组网过大,路由计算下降,当网络变化时,路由广播信息不断在整个网络中广播,造成路由不断重算,导致路由表收敛时间过长。根本解决ECC风暴的方法是ECC划分,保证性能的情况下要求小于等于64个网元,基本可用的情况下要求小于或等于80个网元。
3.4GNE_MGR_LIMIT_OVER告警
该告警是检测网管侧网关网元所管理的非网关网元数目,超过缺省的64个则会上报该告警,起到提醒用户组网过大避免发生ECC风暴的作用,若现网很难做到64个网元以下,那么处理该告警的方法可以通过修改ems.cfg配置文件,增加GneMgrLimitLevel=64一行,把值修改为比实际非网关网元数量大的值即可,但不建议一味改大,否则该告警的作用将失去意义,建议尽量别超过100;确实不需要该告警作为提醒,也可以对该告警进行过滤处理。
3.5网关网元脱管
网关网元也脱管的情况下,此时需要检查网管到网关之间的DCN是否正常,可以先从网管服务器上ping脱管网关的IP地址,若不通则需要确认网管服务器到网关网元的具体DCN网络的组网,然后逐步排查DCN网络的故障,DCN网络组网种类繁多,具体的定位方法在此就不过多进行赘述。如果能够ping通网关网元,但是还是无法登录,那么可以从服务器上尝试使用navigator工具来登录网元,判断是否为网管问题导致,如果navigator工具也无法登录,可以通过telnet网关网元IP1400,测试网管与网关之间TCP通信的1400端口是否通,如果不通需要检查服务器操作系统上的防火墙以及杀毒软件等设置是否存在禁用端口的情况。
3.6网元互踢脱管
查询互踢根源,需先定位确认确实存在互踢,且不明互踢源是从哪台网管哪个地方登录过来的,可以切换另一个网元用户登录,然后查询该互踢根源来自何处,查询方法如下:1)对于OSP平台R10之后的版本,可以通过网元操作日志看出,网元操作日志会记录登录其终端的IP地址,查询方法:log-query:SCCID,"oplog";2)通过Tei、CON-ON值结合cm-get-lanconinifo信息查找,首先通过:sm-get-curuser查询当前登录的用户,然后通过:sm-get-user:"userid"查询该用户的详细信息,其中字段Tei的信息取高位减去0x11,如0x1f090023,高位0x1f减去0x11等于0x0e,那么其CON-ON的值就是0x0e,Tei后面的0x090023就是网关网元的ID,说明该用户是通过0x090023网关登录过来的;然后到该网关上去查:cm-get-lanconinfo就可以查到与该网关有连接的所有终端信息,根据刚才计算得出的CON-ON位0x0e找出对应的一条记录,那条记录的IP地址即为互踢根源的终端网管。
3.7SECU_ALM告警(用户非法登录告警)
此告警是由于除该网元用户外,存在其他不合法的网元用户或密码尝试登录该设备,处理该告警最简单的方法就是屏蔽。一般产生该告警往往是设备经过升级数据库或者更换主控后导致的,网管根据此前用户自行创建的网元用户去登录设备,设备没有对应的用户导致上报SECU_ALM告警。
3.8ECC误码
频繁脱管或者间歇性脱管的问题,若排除了互踢或ECC风暴等原因外,那么就需要检查是否存在ECC误码了,查看ECC误码使用:cm-get-chanerror:SCCNO,检查相应链路上的ECC通道看是否存在误码,对于命令的输出结果,主要关注LG、NO、CR、AB、UN、MFR这几项是否有值,多次查询值是否在不断增加,特别是脱管发生后值是否有增加,如果是则表示存在ECC误码;需要进一步通过SDH性能检查相关的链路上是否存在误码,处理相应的误码直至问题解决。
4结束语
通过对网元的脱管处理的深入学习与了解,给我们的日常维护工作带来了极大的方便,但是我自知尚有好多不足与不解之处,希望能够得到大家的批评与指导。在以后的工作中把更多的理论与实际的问题结合起来,把我们的工作搞好。 |
|
|
|
【对“《硅谷》杂志:传送网元脱管定位思路及处理方案”发布评论】 |
版权及免责声明:
① 本网站部分投稿来源于“网友”,涉及投资、理财、消费等内容,请亲们反复甄别,切勿轻信。本网站部分由赞助商提供的内容属于【广告】性质,仅供阅读,不构成具体实施建议,请谨慎对待。据此操作,风险自担。
② 内容来源注明“硅谷网”及其相关称谓的文字、图片和音视频,版权均属本网站所有,任何媒体、网站或个人需经本网站许可方可复制或转载,并在使用时必须注明来源【硅谷网】或对应来源,违者本网站将依法追究责任。
③ 注明来源为各大报纸、杂志、网站及其他媒体的文章,文章原作者享有著作权,本网站转载其他媒体稿件是为传播更多的信息,并不代表赞同其观点和对其真实性负责,本网站不承担此类稿件侵权行为的连带责任。
④ 本网站不对非自身发布内容的真实性、合法性、准确性作担保。若硅谷网因为自身和转载内容,涉及到侵权、违法等问题,请有关单位或个人速与本网站取得联系(联系电话:01057255600),我们将第一时间核实处理。
|
|
|
|