LONDM1+SIPI故障问题的解决.docx
《LONDM1+SIPI故障问题的解决.docx》由会员分享，可在线阅读，更多相关《LONDM1+SIPI故障问题的解决.docx（8页珍藏版）》请在冰豆网上搜索。
LONDM1+SIPI故障问题的解决
LONDM1SIPI故障的解决
故障现象：
XX陇南网元LONDM1SIPI板突然故障，和OMP单板之间的连接中断，单板不断重启。
导致TISDS2（关口局）到LONDM1的全部4条偶联中断，M3UA局向不可达，MGW退出服务。
SIPI单板在MGW上呈主备配置，用于转发数据链路层的数据报文。
由于MGW到MSCSERVER之间的偶联都是双路径，每个路径经过的路由都有BFD保护，且SIPI单板是主备配置，原则上不应该出现所有偶联中断的情况。
原因分析：
分析判断可能原因：
1、静态路由设置有误。
2、BFD设置未激活。
3、主备SIPI单板同时故障。
4、CE配置了比静态路由优先级更高的路由。
原因排查：
1、静态路由设置有误。
从MGW侧PING对端的MSC接口地址，发现有大约60%的丢包率。
因此怀疑有一条静态路由失效后，仍有数据包沿着这条路由发送。
但检查静态路由设置并未发现问题：
------
Dest/pfxlenGwinterfaceOwnertos/pri/tag/flags/type/rte_flags/act/bfd/weight10.55.84.0/2410.55.76.1610:
1:
421:
1:
1static0/1/3/0/0/0upenable
10.55.84.0/2410.55.76.330:
1:
321:
1:
1static0/1/3/0/0/0downdisable
从输出结果来看，通过10.55.76.33转发的路由已经失效，MGW不可能通过该路由发送数据包。
2、BFD设置未激活。
其次怀疑BFD设置未能生效，导致数据包仍沿着故障的路由发送。
在MGW上检查BFD会话设置
NO.5NOTIFYCLIENT
Command:
NOTIFYCLIENT
信息
------
SrcIPDestIPVPNIDOPTMODEHOPSTATDIAG
10.55.76.3410.55.76.330Asynch1HopUpDETECT_EXPIRED
10.55.76.16210.55.76.1610Asynch1HopUpDETECT_EXPIRED
10.58.76.1810.58.76.170Asynch1HopUpDETECT_EXPIRED
10.58.76.14610.58.76.1450Asynch1HopUpDETECT_EXPIRED可以看到，到下一跳的路由均激活了BFD保护。
而且从故障发生时的告警来看，有BFD会话中断的告警：
3、主备SIPI单板同时故障。
检查告警日志，未发现主备单板均故障的情况。
4、CE上存在级别更高的路由
故障发生后，通过检查CE发现，到MGW端故障的接口地址，配置有比静态路由优先级更高的直联路由
故障定位：
观察性能统计数据，从SIPIMAC端口性能数据可以证实：
在插拔SIPI单板之前，MGW已经将路由的下一跳切换到1架2框4槽SIPI对应的承载网端口（具体表现为SIPI对外端口发送报文增加，且大于SCTP需要发送的报文），但是此时接收报文数量远远小于发送报文的数量；直至19:
21分插拔1架2框3槽SIPI单板，1架2框3槽SIPI上电外部端口恢复正常之后，可以观察到3槽SIPI外部端口接收报文和4槽位发送报文数目大致相等，由此可见，承载设备在1架2框3槽SIPI对应端口检测到故障时，并未将报文转发到正常的4槽位对应的端口，导致此次故障的发生；
图4：
MAC端口性能数据
在12日凌晨1:
05分复现了此故障，在1架2框3槽SIPI到CE接口的BFDdown的情况下，承载网不能及时将业务报文转发给正常的1架2框4槽SIPI对应端口，导致网关退服；
9月19日，中兴研发工程师来到现场支持定位分析，根据和移动公司CE维护工程师交流，发现CE上对MGW配置的路由如下（以CE1为例）
序号
路由类型
目的网段
下一跳
优先级
1
直连路由
10.55.76.32/28
10.55.76.33
0
2
静态路由
10.55.76.32/28
10.55.76.126
200
3
静态路由
10.55.76.160/28
10.55.76.34
1
从上述配置上看CE上对于MGW的路由默认走的是高优先级的直连路由，也就是说只要CE端口UP，直连路由就是生效的，不受BFD控制。
这就完全能我们前面分析对应起来了：
ØSIPI3故障时，MGW侧BFD检测到断链，路由发生倒换，发送流量100%切换到SIPI4上。
Ø由于CE1上高优先级的直连路由不受BFD控制，只要SIPI3没复位，CE1端口是UP的，就会走直连路由，由于这时候SIPI3有故障，导致丢包。
Ø当SIPI3复位后，CE1端口DOWN了，直连路由被闭掉，报文通过CE之间的级联口转发到CE2，再通过CE2上的直连路由发到SIPI4，这样偶联又能够恢复，而等SIPI3重新起来，CE1的端口又UP起来，CE1又会通过有问题的直连路由走，周而复始循环导致偶联不停震荡，CE上LOG看端口也UP、DOWN震荡了几次。
Ø由于CE1上部分流量走直连路由丢包了，所以我们看到SIPI4的性能统计在故障时刻发送比接收要多。
Ø现场将故障SIPI3插拔了一下之后故障恢复。
Ø最后现场更换故障SIPI3，当将新的SIPI单板插上时，由于硬件上电比软件上电速度要快，物理端口先UP起来了，但软件还没上电完成，BFD也还恢复，但是由于CE1上端口UP起来之后直连路由就已经生效了，开始往SIPI3发包，导致丢包偶联断，MGW退服30秒，等30秒之后软件也完成上电，BFD链路恢复，故障就恢复了。
综上所述：
1架2框3槽位的SIPI存在异常，且CE上数据配置会导致BFD保护功能不起作用，SIPI故障时，路由不能正确切换，报文不能被正常送达信令处理单板SMP，导致信令阻断，网关退服；系统能自动检测到1架2框3槽位的SIPI异常并试图恢复业务，但是软复位无效；1架2框3槽位单板的硬件故障原因需要现场将单板发回研发中心继续分析，给出最终硬件故障结论；
9月19日下午，中兴公司研发工程师会同移动公司网管中心、IP承载网维护工程师一起在陇南DM2MGW上进行测试验证：
通过将一块SIPI上的BFD、静态路由、IP地址都删除，但保持端口UP，复现了偶联断链现象。
再将CE上对应连接SIPI的端口关掉，偶联恢复。
模拟复现了上次故障的情况。
同时通过在两种状态TRACE到MGW业务地址的路由，也验证了上述故障分析。
测试步骤如下：
1.在CE1上TRACE到MGW侧路由，确认是走的直连路由。
2.将CE1上连接SIPI3的端口关闭，MGW侧BFD检测到断链，路由发生切换，偶联不会断链，从CE1上TRACE到MGW侧路由，确认走的是CE之间的级联端口到CE2，再SIPI4。
3.恢复CE1配置，将MGW侧SIPI3上BFD、地址删除，模拟故障时软件不能正常转发但是硬件有信号。
4.完成步骤2后复现出了故障现象，偶联断链，检查CE1确认BFD断，但直连路由还是生效的，检查CE1接口的ARP表，无法学习到MGW侧的业务IP的MAC地址。
5.从CE1TRACE到MGW的业务地址，一跳都不通，报文在CE1上被丢弃。
6.将CE1上连接SIPI3的端口关闭，直连路由失效，偶联断链恢复。
测试情况说明：
通过测试复现了故障，并验证了对故障的分析结论，同时整个操作中故障复现和故障恢复都没有对RPU进行操作，也证明复位RPU的操作同本次故障没有联系。
解决措施：
根据和厂家技术人员的讨论，最佳的解决办法是激活每个SCTP偶联上的“链路切换”功能，将不同的偶联分担到不同的平面上，这样当一个平面故障时可以保证偶联不会全断，网关不会退服。
测试过程截图：
1.将SIPI3单板插上后出现网管退服32秒，验证故障出现（单板21号早上已经被拔下来了）。
2.将SIPI3拔下，未出现异常。
3.打开MSCS、MGW的偶联“链路切换功能”开关。
4.将SIPI3单板再次插上，没有再出现网关退服现象。
5.将SIPI3的IP地址删除。
6.没有在出现网关退服现象。
经验总结：
这次故障的处理，有很多值得总结的经验：
1、BFD虽然有很强的保护功能，但对端的CE设备如果设置了优先级更高的路由，那么BFD就被绕开了，不会起到任何效果。
2、类似的网关切换测试应该做的更加详细（这次的SIPI板故障，但端口始终呈UP状态的情况，以前没有遇到过，未做过类似的测试）。
升级会员 