【交换机】用户点播组播视频卡故障类排查思路及信息收集

1）故障现象

S26做组播环境测试，测试环境较为简单：组播源—S86—S57—千兆—S26—百兆—PC，用户网关在57上，S26的配置仅开启了组播监听，风暴控制关闭，组播会出现马赛克现象，但看CCTV1视频不卡，看CCTV5才会卡。

设备配置如下：

interface FastEthernet 0/1

 switchport access vlan 18

 no storm-control broadcast

 no storm-control unicast

 spanning-tree bpduguard enable

 spanning-tree portfast

interface GigabitEthernet 0/25

 switchport mode trunk

 medium-type fiber

 spanning-tree bpdufilter enable

ip igmp profile 1

 permit

 range 239.251.192.0 239.251.207.255

!

ip igmp snooping ivgl

ip igmp snooping vlan 18 mrouter interface GigabitEthernet 0/25

ip igmp snooping suppression enable

 

2）故障处理流程

a.步骤1  查看设备组播表项是否正常，是否存在组播表项时有时无的情况

组播表项是否正常是组播能否正常转发的前提，当组播表项反复添加删除的时候则可能会导致组播转发断流。

三层设备：show ip mroute，show ip pim dense-mode/spare-mode mroute；二层设备：show ip igmp snooping gda-table，查看点播的组是否存在频繁变化。

组播表项的增删通常是由于收到了剪枝报文、用户离开组、表项老化时间的到达导致，可重点关注。

三层设备：debug ip pim dense-mode all，debug ip pim sparse-mode events/packet；二层设备：debug igmp-snp events/packet

 

b.步骤2  确认丢包的节点

确认丢包的方法通常有如下思考和处理方式：

       在设备的不同层次上接PC进行测试，查看在哪个层次的设备上即已经发生了丢包。

       查看端口计数确认是否有nobuffer丢帧或HOL溢出，并且存在增长。

       show interface counter，show interface

       在PC上捉包，确认报文接受是否和发送的报文一致，部分情况下可能由于服务器发包异常或PC端软件问题导致

       使用替换法进行设备替换测试

以上方法需要根据实际情况灵活使用。

c.步骤3 

在经过以上步骤排查仍然未能解决问题，则可以拨打4008111000获取支持，收集以下信息连同前面的操作信息一同反馈给工程师处理。

       客户组播应用模型

       设备配置

       设备上的组播表项

       按照以上1-2步骤排查的相关信息

       按照以上1-2步骤排查相关的捉包数据

3）本次故障解析：

a.组播丢包先确认组播表项是否正常，是全局问题还是单个PC的问题。如担心组播表项异常（例如老化更新），可创建静态表项。

b.判定是节目问题还是设备问题导致的马赛克现象，为确定组播丢包在哪里，现场可将PC直接接入S57，查看是否出现马赛克，结果S57接入看CCTV1、5均不会出现马赛克，初步判断跟节目源没有太大关系。

c.那么可以确定在S26上发生了丢包了，进一步查看上层端口计数发现一切正常。需要进入底层进行查看，可以对比发现看CCTV1不卡的时候，底层没有HOL计数，但看CCTV5的时候，底层出现了较多HOL溢出。（关于SD的使用请联系4008中心支持）

 

S26-Test(sd)#sh show cou

RUC.ge4  :  628,352     +130,128  519/s

RDBGC0.ge4 :  877,970     +180,898  700/s

RUC.fe1  :    2,071         +377    2/s

RDBGC1.fe1 :       65    +9

HOLD.fe1 :    5,604       +1,975   15/s 每秒有15个包被丢弃。

GRMCA.fe1 :       65    +9

GRBCA.fe1 :      130    +1

以上信息能够充分证明，视频马赛克正是由于HOL溢出所致。现场环境中，千兆口为Ingress口，百兆口为Egress口，根据我们之前分析的HOL溢出的可能性即为此千兆口向百兆口发包速率太快所致。

 

为了证明由于此原因所致，我们将26与57互联的端口打开流控（接口下配置flow-control on），马上恢复正常，并在PC上同时点播3个节目，都不会出现卡的现象。因为在pause帧的作用下，57这边发包速率会降低，最终不会发生HOL阻塞的现象。 同时，我们还做了另外一个测试，将26与S57的接口修改为100M，那么S57的发包速率也降低了，且26上成为100M口接口向100M接口发包，26上的用户也不会出现马赛克的现象

4）分析为什么CCTV5视频会导致HOL溢出,但CCTV1视频却不会？而且视频码流大概为3Mb/s即可满足组播视频的效果。为何百兆口还会发生HOL拥塞？

     我们使用仪表模拟组播报文的转发情况，在千兆口使用仪表发送100Mb/s的组播流，百兆口接受，但底层调试的结果，也没有发现出现HOL的情况。从交换机的缓冲区设计来说，也足以满足百兆端口百兆转发的性能需求。为何现场会出现“3Mb/s”的组播情况下，依然会出现组播丢包的情况？

     因为我们所讲的100Mb/s为平均速率，但如果组播流的猝发速率超出了交换机所能承受的范围，一样会导致底层出现HOL丢包。我们继续使用仪表进行了模拟测试，在千兆口发送猝发报文，猝发速率达到300Mb/s的时候，由于百兆出口不能够承受300Mb/s的猝发速率，导致HOL阻塞，底层的HOL溢出已经非常严重了。3Mb/s所指只是视频源码流的速率，由编码器发出的时候，有些编码器的编码可能是变码，部分可能会定码，所以最终组播视频流的发送速率也并不一致，在实际网络中传输的时候由于中间设备的缓冲、发送功能也会导致数据发送速率根据接口的速率相应发生变化。而且在现场测试环境中，26和57之间的接口为trunk口，也会接受到其他一些数据流，导致超出了接口出队列，产生了HOL溢出。这也就是出现CCTV1不卡，而CCTV5卡的原因所在。