某局点S5800 IRF2堆叠分裂问题案例分析
一、 组网:
客户组网拓扑示意图如上所示,两台S5800做IRF2堆叠作为接入层设备下挂服务器。
S5800设备采用R1211版本。
二、 问题描述:
客户发现S5800堆叠下挂服务器业务中断,后经过排查是由于S5800堆叠分裂引起业务中断,重启S5800堆叠后业务恢复。
三、 过程分析:
为了定位问题原因,通过现场收集了两台S5800的诊断信息。
经过详细的分析S5800诊断信息,确认S5800堆叠分裂是由于堆叠运行过程中,slot2上出现无法正常接收堆叠(STM)心跳报文,引起整个堆叠分裂。
从诊断信息可以看到slot2堆叠口心跳报文超时,堆叠口进入静默态:
=================display irf topology===========================
Topology Info
---------------------------------------------------------------
IRF-Port1 IRF-Port2
Switch Link neighbor Link neighbor Belong To
2 TIMEOUT -- TIMEOUT -- 3822-d673-93cf
堆叠口进入静默态后,会持续发送检测报文以检测该端口是否恢复,但是只看到2个堆叠口发送报文,没有看到接收报文:
1> Send detect pkt on stk_pt 2, src_addr 3822-d673-93ce, Tm -955045982
2> Send detect pkt on stk_pt 1, src_addr 3822-d673-93ce, Tm -955044983
3> Send detect pkt on stk_pt 2, src_addr 3822-d673-93ce, Tm -955044982
4> Send detect pkt on stk_pt 1, src_addr 3822-d673-93ce, Tm -955043983
5> Send detect pkt on stk_pt 2, src_addr 3822-d673-93ce, Tm -955043982
6> Send detect pkt on stk_pt 1, src_addr 3822-d673-93ce, Tm -955042983
7> Send detect pkt on stk_pt 2, src_addr 3822-d673-93ce, Tm -955042982
8> Send detect pkt on stk_pt 1, src_addr 3822-d673-93ce, Tm -955041983
9> Send detect pkt on stk_pt 2, src_addr 3822-d673-93ce, Tm -955041982
slot1的STM报文收、发正常的:
1> Send detect pkt on stk_pt 2, src_addr 3822-d673-73e0, Tm -954174740
2> Recv detect pkt on stk_pt 2, src_addr 3822-d673-93ce, Tm -954174386
3> Recv detect pkt on stk_pt 1, src_addr 3822-d673-93ce, Tm -954174386
4> Send detect pkt on stk_pt 2, src_addr 3822-d673-93ce, Tm -954174385
5> Send detect pkt on stk_pt 1, src_addr 3822-d673-93ce, Tm -954174385
6> Send detect pkt on stk_pt 1, src_addr 3822-d673-73e0, Tm -954173742
7> Send detect pkt on stk_pt 2, src_addr 3822-d673-73e0, Tm -954173742
8> Recv detect pkt on stk_pt 2, src_addr 3822-d673-93ce, Tm -954173391
进一步查看诊断信息,发现slot2不收包的原因如下:
CPU口的7队列,2队列出现拥塞,拥塞的原因是CPU口无法及时处理该队列收到的报文,导致后续报文无法处理,由于该队列缓冲有一定限制,所以后续报文会由于拥塞全部丢弃,软件无法及时处理报文的原因是软件不够健壮,对于存在收、发报文空中断的情况处理不够周全导致的。
DROP_PKT_CNT(0).cpu0[0xe200040]=0:
DROP_PKT_CNT(1).cpu0[0xe200041]=0:
DROP_PKT_CNT(2).cpu0[0xe200042]=0x1e74d:
DROP_PKT_CNT(3).cpu0[0xe200043]=0:
DROP_PKT_CNT(4).cpu0[0xe200044]=0:
DROP_PKT_CNT(5).cpu0[0xe200045]=0:
DROP_PKT_CNT(6).cpu0[0xe200046]=0:
DROP_PKT_CNT(7).cpu0[0xe200047]=0x183da:
DROP_PKT_CNT(8).cpu0[0xe200048]=0:
DROP_PKT_CNT(9).cpu0[0xe200049]=0:
DROP_PKT_CNT(10).cpu0[0xe20004a]=0:
DROP_PKT_CNT(11).cpu0[0xe20004b]=0:
DROP_PKT_CNT(12).cpu0[0xe20004c]=0:
通过实验室模拟,发现当设备有大量突发报文,同时表项更新操作比较频繁的时候,会极小概率出现报文收发空中断的情况,出现该问题后,该芯片的CPU收包出现错误,类似于堆叠的心跳这样的协议报文会无法正常接受,从而出现协议中断,出现了堆叠分裂,或者堆叠配置无法完成的情况。
四、 解决方法:
R1211P06版本已经针对该问题,增强了软件健壮性,完善了空中断的处理,请现场升级R1211P06及其后版本。通过此案例希望大家能够对堆叠协议报文的收发机制有所了解。
该案例暂时没有网友评论
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作