• 全部
  • 经验案例
  • 典型配置
  • 技术公告
  • FAQ
  • 漏洞说明
  • 全部
  • 全部
  • 大数据引擎
  • 知了引擎
产品线
搜索
取消
案例类型
发布者
是否解决
是否官方
时间
搜索引擎
匹配模式
高级搜索

某局点S6800 IGMP-Snooping转发丢包问题

  • 0关注
  • 0收藏 2026浏览
粉丝:29人 关注:5人

组网及说明

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个,其余正常表项因无法处理加入报文无法刷新而超时老化。下驱动一条耗时100ms2600表项删除至少耗时260s,表项里主机端口老化时间为260s

解决方法

一、   临时规避方法:

二层组播大表项情况下根据表项数量配置主机老化时间 :表项数量*0.12,驱动上送IGMP报文速率调大可暂时规避此问题。由于现场是一个纯二层组播应用的场景,因此我们有如下优化建议,做了这些优化,可极大改善:

(1) max-response-time 60 ,默认10秒,修改为60,目的是让终端回应的IGMP更平滑,减少同一时间点进入设备的IGMP报文数量;

(2) host-aging-time 1040,默认260秒,修改为1040秒,老化时间放大;

(3) 通过COPP调大驱动上送CPUIGMP报文数限制到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  

该案例对您是否有帮助:

您的评价:1

若您有关于案例的建议,请反馈:

0 个评论

该案例暂时没有网友评论

编辑评论

举报

×

侵犯我的权益 >
对根叔知了社区有害的内容 >
辱骂、歧视、挑衅等(不友善)

侵犯我的权益

×

泄露了我的隐私 >
侵犯了我企业的权益 >
抄袭了我的内容 >
诽谤我 >
辱骂、歧视、挑衅等(不友善)
骚扰我

泄露了我的隐私

×

您好,当您发现根叔知了上有泄漏您隐私的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您认为哪些内容泄露了您的隐私?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)

侵犯了我企业的权益

×

您好,当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 zhiliao@h3c.com 邮箱,我们会在审核后尽快给您答复。
  • 1. 您举报的内容是什么?(请在邮件中列出您举报的内容和链接地址)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
  • 3. 是哪家企业?(营业执照,单位登记证明等证件)
  • 4. 您与该企业的关系是?(您是企业法人或被授权人,需提供企业委托授权书)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

抄袭了我的内容

×

原文链接或出处

诽谤我

×

您好,当您发现根叔知了上有诽谤您的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您举报的内容以及侵犯了您什么权益?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

对根叔知了社区有害的内容

×

垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载 >
辱骂、歧视、挑衅等(不友善)
骚扰我
诱导投票

不规范转载

×

举报说明

提出建议

    +

亲~登录后才可以操作哦!

确定

亲~检测到您登陆的账号未在http://hclhub.h3c.com进行注册

注册后可访问此模块

跳转hclhub

你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作