服务热线
189-2347-0832

中兴S385 您当前所处位置: 首页 > 新闻资讯 > 行业技术

OSN2000 设备EMS1单板数据业务不定期中断

发布时间:2018-05-25

问题描述

某OSN2000 设备9槽EMS1单板,一旦port2接入交换机、摄像头和视频分析仪之后,业务会不定期出现中断,故障发生时,该网元及其下游的业务全部中断。故障后通过删除vb业务后重新创建业务后,业务可以恢复。


处理过程

1. 规避方案:更改故障网桥的业务配置,将偶数VB的业务改配到奇数VB上。

2. 根本解决方案:微码发布解决版本合入正式版本。


根因

1、 现网故障时,查询故障网元9-EMS1单板的丢包信息,确认是因为报文的vlan不在vlan过滤表之内。可能原因是报文所带的vlan不对,也可能是业务配置的vlan不对。

2、 查询单板的配置,确认9-ems1的vb2配置的vlan过滤表是102,与业务报文的vlan保持一致。

3、 进一步查询单板的VB参数表,对应VB2的vb参数表已经被改写。如下截图中的0x67311地址表示vb2的vb参数表,正常配置的值为全0,这里已经被改成了随机的值。导致VB的网桥模式被改成了1D网桥模式。

4、 结合上述的理论分析和采集的数据可以确认,故障时,微码表项vb参数表被异常改写成了1d网桥,微码根据4095的vlan过滤表去转发报文,但是实际上又没有配置4095的vlan过滤表,从而导致了1017类型的丢包,业务中断。

5、 进一步分析故障数据、软件代码和芯片微码,最终确认问题原因是由于微码的缺陷导致。


但是,在什么的业务场景下会出现该故障呢?原因分析如下:

1、微码专网业务处理流程错误,按照V2R5版本的流程处理,先去读取QOS流分类表,但是OSN2000 EMS1的微码表项是按照V2R4版本定义的,实际没有QOS流分类表,结果就把报文的内容当成微码表项处理了。OSN2000的car使能和car_index都通过读取端口流分类表的,如果报文内容中的相应bit位正好吻合条件时,微码就会错误的刷新0x63810~0x7380f之间的表项。

2、按照微码的错误处理流程,微码会把报文的第29个字节的第6bit当做car使能位处理,把第31和32字节当做car_index处理。如果报文的第29个字节的第6bit等于1,微码就会认为car是使能的,就会根据第31和32字节的值刷新CAR参数表,记录报文的时标,记录地址为0x63810+(WORD)car_index*2+1。

3、对于武本问题网络上出现了类似上图的报文,第27和28字节等于0x1D80(加上默认vlan后从vctrunk进入的报文),或者第31和32字节等于0x1D80(从ip口进入的报文),就会改写0x63810+0x1D80*2+1=0x67311这个地址的微码表项,正好对应VB2的VB参数表,结果导致VB2的视频监控业务中断。实验室模拟发送符合此条件的报文,发送一段时间之后,业务果然发生中断,现象与现网完全一致。


建议与总结

1. 本故障的根本原因在于:

微码的专网业务处理流程错误,误把报文内容当作端口流分类表处理,从而误改写了VB参数表,将网桥模式有1q改成了1d网桥,导致业务中断。

2. OSN2000设备的EMS1单板数据业务发生故障的事情,建议先分析清楚业务场景,如果业务场景与此故障场景一致的话,在解决方案的正式版本推出前可以优先考虑规避方案。