10.253.102.83(组播源) ---> 200.31.253.83(H3C S6800-4C) ---> 接收者有四台(10.253.102.1/2/3/4)
某局点客户反馈,最近不定时出现一个二层组播转发丢包的问题,异常组播组地址为237.1.1.3,断流后不定时自动恢复。经过流统确认,组播报文就是丢弃在这台开启二层组播的S6800设备上。(注:客户业务特殊应用,组播用来作为应用的心跳报文,丢一个包就会导致业务出问题,需重启应用才可以恢复)
1、查看收集的诊断信息,发现设备上igmp-snooping表项有9K左右。
=============display igmp-snooping group verbose===============
Total 9446 entries.
2、通过流量统计确认故障时报文是丢弃在设备上的,而查看底层,并没有出现拥塞丢包的记录。查看设备配置,现场配置了igmp-snooping drop-unknown,因此丢弃的可能就是故障时设备上没有igmp-snooping表项。而设备上没有igmp-snooping表项有三种可能:
1) 当接收者收到设备发送的查询报文时,接收者没有回复IGMP成员关系报告报文;
2) 当接收者收到设备发送的查询报文时,接收者回复了IGMP成员关系报告报文,设备收到后因某种原因没有正常处理;
3) 接收者主动发送离开报文;
3、继续分析诊断,发现IPV4_IGMP报文上送CPU存在超阈值丢包的情况,但不确认丢包数是否发生在故障时候。
===============debug rxtx softcar show slot 1===============
ID Type RcvPps Rcv_All DisPkt_All Pps Dyn Swi Hash ACLmax
0 ROOT 0 3497 0 1000 S On SMAC 0
5 UNKNOWN_IPV4MC 0 0 0 300 S On SMAC 8
6 UNKNOWN_IPV6MC 0 0 0 300 S On SMAC 8
7 IPV4_MC_RIP 0 0 0 500 D On SMAC 8
8 IPV4_BC_RIP 0 0 0 500 D On SMAC 8
14 IPV4_MC_PIM 0 0 0 500 S On SMAC 8
15 IPV4_UC_PIM 0 0 0 500 S On SMAC 8
16 IPV4_IGMP 21 1200936946 252148 500 S On SMAC 8
4、结合现场全天跑脚本以及所有端口抓包收集的信息分析,最终确认,故障时驱动层面存在概率性上送丢包的情况(受igmpv3报文数量的影响),而一个igmpv3成员关系报告报文又携带了加入很多组的消息,导致平台igmp-snooping表项无法及时刷新导致表项老化删除掉,进而导致了现场出现丢包的情况。
=======================================================
display clock
06:24:48.796 BJ Thu 06/27/2019
Time Zone : BJ add 08:00:00
=======================================================
debug rxtx softcar show slot 1
ID Type RcvPps Rcv_All DisPkt_All Pps Dyn Swi Hash ACLmax
16 IPV4_IGMP 111 1319447017 267125 500 S On SMAC 8
=======================================================
display clock
06:31:19.891 BJ Thu 06/27/2019
Time Zone : BJ add 08:00:00
=======================================================
debug rxtx softcar show slot 1
ID Type RcvPps Rcv_All DisPkt_All Pps Dyn Swi Hash ACLmax
16 IPV4_IGMP135 1319471567 267948 500 S On SMAC 8
5、平台MCS为单线程,处理大量表项删除时无法处理其他组加入报文。一旦连续删除表项达2600个,其余正常表项因无法处理加入报文无法刷新而超时老化。下驱动一条耗时100ms,2600表项删除至少耗时260s,表项里主机端口老化时间为260s
一、
二层组播大表项情况下根据表项数量配置主机老化时间 :表项数量*0.12,驱动上送IGMP报文速率调大可暂时规避此问题。由于现场是一个纯二层组播应用的场景,因此我们有如下优化建议,做了这些优化,可极大改善:
(1) max-response-time 60 ,默认10秒,修改为60,目的是让终端回应的IGMP更平滑,减少同一时间点进入设备的IGMP报文数量;
(2) host-aging-time 1040,默认260秒,修改为1040秒,老化时间放大;
(3) 通过COPP调大驱动上送CPU的IGMP报文数限制到2000,默认500;(COPP配置方式参考文档下方)
二、
1、从根本上规避并解决此问题,需优化平台下驱动耗时,且平台处理表项删除时需能够处理加入报文。已给研发提需求。
注:COPP配置方法如下:
#
traffic classifier IGMP operator and
if-match control-plane protocol igmp
#
traffic behavior igmp
car cir pps 2000 cbs 62976 ebs 0 green pass red discard yellow pass
#
qos policy igmp
classifier IGMP behavior igmp
#
control-plane slot 2
qos apply policy igmp inbound
#
[NSX_self_cert-classifier-IGMP]dis qos policy control-plane pre-defined slot 2
Pre-defined policy information slot 2
Protocol Priority Bandwidth Group
Default N/A 1000 (pps) N/A
IS-IS 37 1000 (pps) critical
VRRP 40 1000 (pps) important
OSPF Multicast 35 2000 (pps) critical
OSPF Unicast 35 2000 (pps) critical
IGMP 19 2000 (pps) important该案例暂时没有网友评论
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作