华为交换机视频类故障案例集(v1.0)

更新时间：2024-04-04 15:26:01 阅读量：综合文库文档下载

说明：文章内容仅供预览，部分内容可能不全。下载后的文档，内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的，是否完整无缺。

华为交换机视频类故障案例集

交换机视频类故障案例集

? IPTV短时间视频卡顿的故障案例 ................................................................................... 2 ? 带宽不够产生丢包导致视频会议有马赛克的故障案例 ............................................. 11 ? IPTV边缘节点录制节目时出现花屏现象的故障案例 ................................................. 14 ? 盒式设备播放第二个节目就出现花屏现象的故障案例 ............................................. 19 ? 多用户视频点播操作导致黑屏现象的故障案例 ......................................................... 22 ? 解码器问题导致视频卡现象的故障案例 ..................................................................... 26 ? 瞬时流量突发导致视频卡现象的故障案例 ................................................................. 30 ? 组播视频花屏现象的故障案例 ..................................................................................... 34 ? 交换机三层组播观看视频时出现马赛克问题案例 ..................................................... 39 ? 交换机二层组播报文乱序导致花屏的故障案例 ......................................................... 42 ? 组播点播时出现节目画面停顿故障案例 ..................................................................... 45 ? 多路视频同时点播时视频出现卡顿故障案例 ............................................................. 48 ? 盒式交换机部署三层组播业务时视频频繁出现马赛克问题案例 ............................. 50 ? 组播点播黑屏故障案例 ................................................................................................. 52

2014-5-25

第1页, 共56页

华为交换机视频类故障案例集

? IPTV短时间视频卡顿的故障案例

问题现象描述及组网

客户反馈S9300 1/0/11端口下的OLT下挂IPTV用户不定时的出现10秒到1分钟左右的断流卡频，路由器起三层组播并且有查询器功能，S9300做二层组播igmp-snooping，OLT也起二层组播并且也是组播复制点。

.2 问题根因说明

igmp-snooping querier enable使用场景不当，交换机和路由器组播功能配合有问题，路由

器收到另外一个OLT的leave，路由器没有成功收到特定组查询报文的report应答，导致路由器组播表项老化使得视频中断。

.3 问题判断方法

1) S9300起二层组播，并且启用组播查询器功能igmp-snooping querier enable，默认每

60s发送一个查询报文，150s收不到下挂用户应答的report报文就会删除下行组播出端口表项。另外S9300默认10s内收到相同节目的igmp报文会抑制掉。

# 2014-5-25

第2页, 共56页

igmp-snooping enable # vlan 3990 igmp-snooping enable igmp-snooping querier enable multicast-vlan enable display igmp-snooping 。。。 IGMP Snooping Information for VLAN 3990 IGMP Snooping is Enable IGMP Version is Set to default 2 IGMP Query Interval is Set to default 60 IGMP Max Response Interval is Set to default 10 IGMP Robustness is Set to default 2 IGMP Last Member Query Interval is Set to default 1 IGMP Router Port Aging Interval is Set to 180s or holdtime in hello IGMP Filter Group-Policy is Set to default : Permit All IGMP Prompt Leave Disable IGMP Router Alert is Not Required IGMP Send Router Alert Enable IGMP Proxy Disable IGMP Report Suppress Disable IGMP Suppress Time is set to default 10 seconds IGMP Querier Enable IGMP Router Port Learning Enable IGMP SSM-Mapping Disable IGMP Suppress-dynamic-join Disable 华为交换机视频类故障案例集

2) 上行组播路由口是1/0/1，下行端口是1/0/11，观察故障节目239.93.6.109，该节目观

察多次断流后，查看S9300上下行转发表项存活时间比较长，没有老化过，说明S9300和下面OLT的IGMP query和report报文交互没有问题的。

< S9306>display igmp-snooping port-info verbose 。。。 Time of this group has been up : 2d:17h The port information of (0.0.0.0, 239.93.6.109): Time of this source has been up : 2d:17h Port Table on this source(0.0.0.0): No.1 Port name : GE1/0/11 Time of this port has been up as a host-port : 2d:15h Remain time of port expire as dynamic host-port : 00:01:12 2014-5-25

第3页, 共56页

Host-port flags : Dynamic No.2 Port name : GE1/0/18 Time of this port has been up as a host-port : 10:01:38 Remain time of port expire as dynamic host-port : 00:01:13 Host-port flags : Dynamic < S9306>display igmp-snooping router-port vlan 3990 Port Name UpTime Expires Flags --------------------------------------------------------------------- VLAN 3990, 1 router-port(s) GE1/0/1 11w:3d 00:02:17 DYNAMIC 华为交换机视频类故障案例集

3) 继续排查239.93.6.109节目流在从S9300上行进来和下行出去是否正常，在S9300做

端口镜像到观察口，在观察口出方向做过滤，正常时该节目流在上下行端口统计速率显示为3M多。

【说明】对于未知单播、组播、广播的出方向流镜像命令行可以配置，但是功能不生效。当端口流量比较大时，只能使用端口镜像＋过滤方式。 # acl number 4000 rule 5 permit destination-mac 0100-5e5d-066d （239.93.6.109对应的组播mac是0100-5e5d-066d） rule 10 deny ＃ traffic classifier ljx if-match acl 4000 ＃ traffic behavior ljx ＃ traffic policy ljx classifier ljx behavior ljx # observe-port 1 interface GigabitEthernet2/0/47 observe-port 2 interface GigabitEthernet2/0/45 # interface GigabitEthernet1/0/1 （镜像上行所有流到2/0/45） port-mirroring to observe-port 2 inbound # interface GigabitEthernet1/0/11 （镜像下行所有流到2/0/47） port-mirroring to observe-port 1 outbound # 2014-5-25

第4页, 共56页

interface GigabitEthernet2/0/45 set flow-stat interval 10 （把接口速率统计周期调整为10s ，默认周期是300s，这样方便可以看节目是否断流） traffic-policy ljx outbound （过滤239.93.6.109流） # # interface GigabitEthernet2/0/47 set flow-stat interval 10 traffic-policy ljx outbound （过滤239.93.6.109流） < S9306>display clock 2013-12-11 17:32:35 Wednesday Time Zone(UTC) : UTC < S9306>display interface GigabitEthernet 2/0/47 GigabitEthernet2/0/47 current state : UP Line protocol current state : UP Description:HUAWEI, Quidway Series, GigabitEthernet2/0/47 Interface Switch Port, PVID : 1, TPID : 8100(Hex), The Maximum Frame Length is 9216 IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0046-4bc5-2ca0 Last physical up time : 2013-12-11 16:09:35 Last physical down time : 2013-12-11 16:09:33 Port Mode: COMMON COPPER Speed : 100, Loopback: NONE Duplex: FULL, Negotiation: ENABLE Mdi : AUTO Last 10 seconds input rate 144 bits/sec, 0 packets/sec Last 10 seconds output rate 3142456 bits/sec, 285 packets/sec Input peak rate 6672 bits/sec, Record time: 2013-12-11 16:22:51 Output peak rate 98437792 bits/sec, Record time: 2013-12-11 16:31:11 华为交换机视频类故障案例集

4) 当现场发现OLT上断流时，从S9300采集的接口流量速率统计来看，上下行明显没

有流，所以确认是S9300上行路由器没有把流发下来（如果故障概率不定时出现，可以借助SecureCRT跑脚本采集信息观察，下面是采集脚本做参考）。

#$language = \#$interface = \'Collect information 'Edit by zhubinghui ' This automatically generated script may need to be ' edited in order to work correctly. crt.Screen.Synchronous = True ' 查看更多信息 2014-5-25

第5页, 共56页

Sub wait_for_More() Dim currline currline = crt.Screen.Get(crt.Screen.CurrentRow, 0, crt.Screen.CurrentRow, 255) '判断是否在用户模式或者系统模式 If (InStr(currline,\ Then crt.Screen.Send chr(32) crt.Screen.Send chr(32) crt.Screen.Send chr(32) End If Do While crt.Screen.WaitForString (\ crt.Screen.Send chr(32) Loop currline = crt.Screen.Get(crt.Screen.CurrentRow, 0, crt.Screen.CurrentRow, 255) '判断是否在用户模式或者系统模式 If (InStr(currline,\ crt.Screen.Send chr(3) End If End Sub ' main procedure Sub Main crt.Screen.Synchronous = True For i = 0 To 1000000 crt.Screen.Send \ wait_for_More crt.sleep(200) crt.Screen.Send \ GigabitEthernet 2/0/45\ wait_for_More crt.sleep(200) crt.Screen.Send \ GigabitEthernet 2/0/47\ wait_for_More crt.sleep(9600) Next 'back_to_user_mode crt.Screen.Synchronous = False 华为交换机视频类故障案例集

2014-5-25

第6页, 共56页

End Sub 华为交换机视频类故障案例集

5) 继续排查路由器，发现是由于收不到OLT report报文老化删除表项的。 6) 继续排查S9300是否把OLT report报文透传给路由器，同样用端口镜像+过滤抓包

239.93.6.109的igmp report报文，经过抓包证实，故障时S9300已经保证每1分钟至少有一个report透传给路由器

＃ acl number 3900 rule 5 permit igmp ＃ traffic classifier igmp_deny if-match any traffic classifier igmp_tj operator and if-match acl 3900 if-match destination-mac 0100-5e5d-066d ＃ traffic behavior igmp_deny deny traffic behavior igmp_tj ＃ traffic policy igmp_tj classifier igmp_tj behavior igmp_tj classifier igmp_deny behavior igmp_deny # interface GigabitEthernet1/0/1 port-mirroring to observe-port 2 outbound # interface GigabitEthernet1/0/11 port-mirroring to observe-port 1 inbound # interface GigabitEthernet2/0/45 set flow-stat interval 10 traffic-policy igmp_tj outbound # interface GigabitEthernet2/0/47 set flow-stat interval 10 traffic-policy igmp_tj outbound 7) 至此说明路由器对report报文处理有问题，所以怀疑路由器收发的igmp报文处理有

问题，继续在上行口1/0/1端口镜像抓包，用类似的方法把1/0/1入出方向流镜像到

2014-5-25

第7页, 共56页

华为交换机视频类故障案例集

2/0/45观察口，在2/0/45出方向过滤igmp报文，用PC只抓igmp报文（如果观察口上有其他流量,可以再PC抓包工具上过滤只抓igmp报文，PC网卡通常是GE的，小几百兆流量一般没问题）

8) 通过抓包分析是另外一个OLT的leave诱发的问题

? S9300下挂多台OLT点播同一个组播组节目时，1/0/15下的OLT离开后，会发送Leave报文。如

时间点4点32分33秒时，源IP为192.168.236.50的OLT发送了组播组为239.93.6.109的leave报文给交换机，同时交换机也会将该leave报文转发给路由器

? 路由器收到该Leave报文后，会每隔1秒，连续发送2个特定组查询报文给S9300交换机，但

交换机此时使能了igmp-snooping查询器功能，会将这2个特定组查询报文丢弃掉。

? 同时S9300具有snooping侦听和查询器功能，自己也会每隔1秒，连续发送2个特定组查询报

文只给源IP为192.168.236.50的OLT，即只向端口GE1/0/15定组查询报文。

但其他OLT点播该组播组的端口，比如GE1/0/11下的OLT设备是收不到特定组查询报文的，也就没办法及时回应report报文给路由器。

? 路由器2秒后收不到report报文，就将整个连接S9300的路由器上端口GigabitEthernet

1/0/2.3990给组播表项老化掉，于是就出现S9300下面GE1/0/11下的OLT设备出现断流的现象。

2014-5-25

第8页, 共56页

华为交换机视频类故障案例集

? 等待后续S9300通用组查询发出来后，GE1/0/11下的OLT设备此时才会回应report报文，重新

点播成功。此时GE1/0/11下的OLT设备总的业务中断时间为16:33:16-16:32:34 = 42秒左右。

9) 去掉S9300上的igmp-snooping querier enable查询器功能，视频流观察正常问题解决。

.4 解决方案

1) 交换机不使能igmp-snooping querier enable二层组播查询器功能；

2) 交换机上使能二层组播查询器功能，但上游路由器须将所有组播业务推流到交换机

上面；

3) 交换机上使能二层组播查询器功能，同时使能代理功能，这样交换机可以代替下游

用户回应report报文。（还是不推荐，理由仍然是避免出现查询器选举的问题）

.5 经验总结

? 交换机一般只在上游设备没有使能查询器的场景下，自身使能查询器，帮助整个二层

网络实现组播协议交互过程。如果二层网络中还存在其他的查询器设备，则建议交换机上不再使能查询器，避免出现查询器选举的问题。

? 通过现象先定界问题所在的设备；合理使用流统计、端口镜像，尽量先用统计，后现

场抓包；现象不定期出现，可以借助SecureCRT等工具跑脚本采查询采集信息。 ? 当在流统计或镜像过滤过程中，用到组播IP转换成组播MAC的，可以找一个组播IP地

址和组播MAC的转换工具。

.6 涉及产品和版本

系列框式交换机 X3 型态&版本 S23&33&53 V100R002 S23&33&53 V100R003 S23&33&53 V100R005 S23&33&53&63 V100R006 S33&53&63 V200R001 S33&53&63 V200R002 S33&53&63 V200R003 X7 2014-5-25

是否适用是是是是是是是是第9页, 共56页

S27&37&57 V100R005

华为交换机视频类故障案例集

S27&37&57&67 V100R006 S37&57&67 V200R001 S37&57&67 V200R002 S37&57&67 V200R003 盒式交换机 X3 S9300 V100R001 S9300 V100R002 S9300 V100R003 S9300 V100R006 S9300&9300E V200R001 S9300&9300E V200R002 S9300&9300E V200R003 X7 S7700 V100R003 S7700 V100R006 S7700&9700 V200R001 S7700&9700 V200R002 S7700&9700 V200R003

是是是是是是是是是是是是是是是是 2014-5-25

第10页, 共56页

华为交换机视频类故障案例集

? 带宽不够产生丢包导致视频会议有马赛克的故障案例

问题现象描述及组网

外围设备视频会议有马赛克花屏的现象，外围设备通过因特网ping视频服务器有丢包的情况。

Internet 交换机视频服务器 .2 问题根因说明

向运营商省请的专用带宽不够，导致丢包。

.3 问题判断方法

（1）检查是否MAC、ARP漂移

当交换机上出现路由出端口变化、IP地址冲突等问题时，会出现ARP、MAC地址漂移等问题，也会导致下接设备出现ping丢包的问题。此时需要检查路由、ARP、MAC出端口是否在频繁变化，命令行如下： display ip routing-table x.x.x.x display arp | include x.x.x.x

display mac-address xxxx-xxxx-xxxx

通过检查没有发现MAC和ARP漂移的情况。

（2）对上行口和下行口做流量统计

在上层软件没有收到报文的时候，可以通过在端口下配置流量统计的方法来确认报文的收发情况，命令行如下：

1) 先定义acl，匹配ping的源、目的IP地址： acl number 3333

rule 5 permit icmp source x.x.x.x 0 destination y.y.y.y 0 rule 10 permit icmp source y.y.y.y 0 destination x.x.x.x 0

2) 再定义流分类、行为和traffic policy： #

traffic classifier 3333

2014-5-25

第11页, 共56页

华为交换机视频类故障案例集

if-match acl 3333 #

traffic behavior 3333 statistic enable #

traffic policy 3333

classifier 3333 behavior 3333 #

3) 然后在端口下应用该策略，对该端口的出入方向报文的收发进行统计： interface GigabitEthernet XXX traffic-policy 3333 inbound traffic-policy 3333 outbound

显示统计结果：

display traffic policy statistics interface GigabitEthernet XXX in/out

display traffic policy statistics interface GigabitEthernet XXX in/out verbose rule-based

通过此流量统计发现数据报文在交换机内没有丢，ping包的个数在进入交换机上行口之前已经丢失。说明是上行网络有丢包。

（3）了解到该上行链路是向运营商申请的专有带宽，怀疑可能带宽不够。通过向运营商申请增加带宽后，不再发生丢包和视频有马赛克的情况，验证了此前的推理。

.4 解决方案

增加上行带宽，不再发生丢包和视频有马赛克的情况。

.5 经验总结

流量统计是定位丢包问题最简便的手段，能迅速定位出故障发生的位置。

.6 涉及产品和版本

系列框式交换机 X3 型态&版本 S23&33&53 V100R002 S23&33&53 V100R003 S23&33&53 V100R005 S23&33&53&63 V100R006 S33&53&63 V200R001 S33&53&63 V200R002 S33&53&63 V200R003 2014-5-25 是否适用是是是是是是是第12页, 共56页

华为交换机视频类故障案例集

X7 S27&37&57 V100R005 S27&37&57&67 V100R006 S37&57&67 V200R001 S37&57&67 V200R002 S37&57&67 V200R003 是是是是是是是是是是是是是是是是是盒式交换机 X3 S9300 V100R001 S9300 V100R002 S9300 V100R003 S9300 V100R006 S9300&9300E V200R001 S9300&9300E V200R002 S9300&9300E V200R003 X7 S7700 V100R003 S7700 V100R006 S7700&9700 V200R001 S7700&9700 V200R002 S7700&9700 V200R003

2014-5-25

第13页, 共56页

华为交换机视频类故障案例集

? IPTV边缘节点录制节目时出现花屏现象的故障案例

问题现象描述及组网

某局点前期使用S6500交换机下挂UT斯达康IPTV平台，用户点播IPTV卡且很严重，定位原因为S6500板间转发性能导致；后此局点临时从华为自己的IPTV平台项目中抽一台S9300设备做测试，更换后稍有好转，但是还会存在花屏现象，时间不固定，每次时间约2秒钟左右。

IPTV组网拓扑图如下：

某局点IPTV平台采用UT斯达康的设备，从中心站点通过骨干网单播拉流到边缘节点，数据流先从交换机转发到MRS服务器，然后转换为组播数据流后，再会送给S9300交换机，通过二层组播功能，将不同频道分发到15台ME设备进行节目录制。

该IPTV局点出现节目出现马赛克现象，经过三方对该现象的确认，出现马赛克的丢包原因主要有3种：

1) IPTV中心节点组播源的报文可能出现丢包； 2) IPTV中心节点到边缘节点之间骨干网可能出现丢包；

2014-5-25

第14页, 共56页

华为交换机视频类故障案例集

3) IPTV边缘节点中S9300到ME设备之间组播报文可能出现丢包；

本次三方主要为了确认第三种出现丢包的原因，并根据前期UT方的测试报告：发现ME设备同MRS设备相比，统计出每隔一段时间数据流量中会发现少1，2个报文，该丢包是第三种丢包原因的主要现象。

.2 问题根因说明

经过三方确认好抓包方案后，经过24小时不间断抓包，结论如下：

交换机上入方向和出方向镜像抓包均没有出现丢包，报文完整，交换机不存在转发丢包

的情况。

局点所出现的IPTV节目概率马赛克花屏的现象是由于UT的ME设备在报文处理上存在问题导致，和华为的交换机没有关系，这个结论UT已经认可。

.3 问题判断方法

在基于UT前期的测试报告结论之下，三方协商进行了如下拓扑图测试单个丢包的现象：

1) 华为增加一台镜像交换机，使用两台笔记本，笔记本A用于抓取S9300入端口的报

文；笔记本B用于抓取S9300出端口的报文；

2014-5-25

第15页, 共56页

华为交换机视频类故障案例集

2) UT选取其中一台ME设备，继续使用软件统计收到报文的丢包情况；

3) 当UT统计出单个丢包时，华为分别提供入接口和出接口上的镜像抓包，若镜像报

文中包含该序列号的报文，则认为是UT设备出现丢包，若镜像报文中不包含该序列号的报文，则认为是交换机出现丢包；测试结果如下：时间点 10:28:12 12:46:21 12:58:18 13:35:10 13:37:13 15:04:41 16:08:10 18:00:06 丢包序列号 64442 36564 22060 54255 8651 38924 39808 18235 ME监控丢包有有有有有没监控没监控有 ME重传有有没发现有有有有有华为抓包分析没发现丢包没发现丢包没发现丢包没发现丢包没发现丢包没发现丢包没发现丢包没发现丢包上面表格中的测试结果非常清楚地显示当ME设备出现统计到单个丢包情况时，交换机上入方向和出方向镜像抓包均没有出现丢包，报文完整，交换机不存在转发丢包的情况。

.4 解决方案

本次测试对于UT前期反馈单个丢包的现象，可以确认华为交换机上不存在丢包，是UT

自身ME设备有问题。

后续由UT厂商提供对应的补丁解决ME设备上偶尔出现丢包的现象。

.5 经验总结

IPTV组播花屏问题，也就是丢包问题定位。这种问题按以往的经验一般来说，先看端口

上数据流量是否达到带宽限制，端口上是否存在discard丢弃计数，芯片内部是否出现报文丢弃计数，流量突发等情况。再或者配置流量统计，分析入出端口报文相差个数是否明显有

2014-5-25

第16页, 共56页

华为交换机视频类故障案例集

区别。

但是这次IPTV场景中，ME设备录制节目是循环轮换的，也就是出端口不是固定，导致按照上述操作定位问题很困难。于是采用端口镜像的方式，固定选择某一个的端口抓包，不过这样做耗时会比较长。但三方都认可该方案的前提下，也只能这么证明我们的设备没有问题。

.6 涉及产品和版本

系列框式交换机 X3 型态&版本 S23&33&53 V100R002 S23&33&53 V100R003 S23&33&53 V100R005 S23&33&53&63 V100R006 S33&53&63 V200R001 S33&53&63 V200R002 S33&53&63 V200R003 X7 S27&37&57 V100R005 S27&37&57&67 V100R006 S37&57&67 V200R001 S37&57&67 V200R002 S37&57&67 V200R003 盒式交换机 X3 S9300 V100R001 S9300 V100R002 S9300 V100R003 S9300 V100R006 S9300&9300E V200R001 S9300&9300E V200R002 S9300&9300E V200R003 X7 S7700 V100R003 S7700 V100R006 S7700&9700 V200R001 2014-5-25

是否适用否否是是是是是是是是是是否是是是是是是是是是第17页, 共56页

华为交换机视频类故障案例集

S7700&9700 V200R002 S7700&9700 V200R003

是是 2014-5-25

第18页, 共56页

华为交换机视频类故障案例集

? 盒式设备播放第二个节目就出现花屏现象的故障案例

问题现象描述及组网

某企业网用户反馈使用PC机在靠近组播源的S5700EI-1交换机点播组播节目时，VLC中显示画面正常，无马赛克现象。

使用PC机在另外一个楼层，连接S5700EI-2交换机同时点播两个组播节目时，VLC就

会偶尔出现花屏，马赛克现象。

组播源S5700EI-1S5700EI-2PC机

.2 问题根因说明

从抓包结果分析，组播源服务器发出高清组播视频流量突发较为严重，虽然平均流量只

有5~6Mbit/s，但是在0.001秒的粒度上突发接近350Mbit/s。

该流量送到S5700EI-2交换机后，由于S5700EI-2交换机部分端口还加入了VLAN 1，存在大量其他单播或者广播流量，可能会导致S5700EI-2交换机出端口上的流量在某个瞬间超过带宽，当端口上的缓存耗尽时，就会出现突发丢包，从而导致视频马赛克。

.3 问题判断方法

在S5700-2交换机上对组播节目227.77.82.20组地址进行抓包

1) 报文均为UDP格式，不包含RTP头部，wireshark抓包软件显示该UDP组播流带宽

约为5.1Mbps；

2014-5-25

第19页, 共56页

华为交换机视频类故障案例集

2) 报文波形流量图（X轴单位为0.001秒，Y轴单位为Bits/Tick）此时计算出来流量带宽突发最高峰值约为350000/0.001=350Mbps

.4 解决方案

当前如果只有一个节目观看时是好的，后续如果节目多起来，那么突发流量将翻番，则

马赛克现象将更为严重，此时交换机端口上固有带宽仅为1Gbit/s。

由于上图显示服务器发包在某一瞬间会将流量发出来，而其他大部分时间是空闲状态。因此建议客户更新组播源服务器网卡的驱动程序，并调整的发包模式，将其调整为平稳发包模式。

另外建议将端口都退出VLAN 1，减少无关的单播和广播流量影响。

2014-5-25

第20页, 共56页

华为交换机视频类故障案例集

.5 经验总结

对于流量突发的情况，建议使用wireshark软件分析报文的瞬时突发值，从而确认是否

会导致交换机出现偶尔丢包的情况。

.6 涉及产品和版本

是否适用否否是是是是是是是是是是否是是是是是是是是是是是第21页, 共56页

华为交换机视频类故障案例集

? 多用户视频点播操作导致黑屏现象的故障案例

问题现象描述及组网

某局点出现IPTV视频点播黑屏问题，在77下挂RPR环下接两台以上PC时，出现视频点播黑屏问题，如果只挂一台PC时，视频播放没问题。

.2 问题根因说明

组播服务器发出视频流量突发非常严重，虽然平均流量只有10Mbit/s，但是在毫秒粒度上突发接近1Gbit/s，该流量送到S77后，S77的组播会将该流量复制成多份发送给传输设备，导致S77发送给传输的超过S77带宽，当S77的缓存耗尽时，出现突发丢包，导致视频黑屏。

.3 问题判断方法

当出现问题时，可以在连接视频服务器的交换机入口进行抓包，通过wireshark进行解析。

1) 通过wireshark解析发现在ms级别上，流量突发非常厉害。服务器休眠一秒多后以

2014-5-25

第22页, 共56页

华为交换机视频类故障案例集

接近1Gbit/s的速率发送视频流量几毫秒后继续进入休眠状态，流量突发非常厉害，如下所示：

如上图所示，0.23s时组播源服务器以1Gbit/s的速度向77发送流量。

0.23s发包后停止，知道0.94s时，再次以1Gbit/s的速率想77发包。

和上面描述一样，0.94后发包停止，直到1.83s时，再次以接近1Gbit/s的速率发包。

2014-5-25

第23页, 共56页

华为交换机视频类故障案例集

2) 这些流量送到S77后在S77上会进行组播复制，每份报文会复制成多份，导致S77

需要以几Gbit/s的速率向传输设备发送。由于S77的端口为千兆端口，该速率超过S77的端口带宽，导致S77出现拥塞丢包，导致视频花屏。

.4 解决方案

修改服务器发包方式，减少流量突发。

2014-5-25

第24页, 共56页

华为交换机视频类故障案例集

.5 经验总结

当交换机连接视频服务器，下挂用户进行点播，交换机充当组播复制点，视频服务器由于编码原因出现大量突发时就会引起黑屏等现象，需要改变服务器的编码方式。

.6 涉及产品和版本

是否适用否否是是是是是是是是是是否是是是是是是是是是是是第25页, 共56页

华为交换机视频类故障案例集

? 解码器问题导致视频卡现象的故障案例

问题现象描述及组网

1) 现象：

摄像头将监控数据传送到S3700，S3700做二层转发，经交换机S9303、S9312和S5700将视频监控流传送到监控设备，在监控设备上发现监控画面很卡。 2) 组网：

FE09FE102/0/4TRUNK37TRUNK37TRUNK1TRUNK550/0/16cameraS3700S9303S9312S5700PC

.2 问题根因说明

由于解码器发出来的视频流存在丢包导致监控画面很卡。

.3 问题判断方法

1) 根据客户反馈的卡屏现象，在S3700的FE09和FE10，S9303的端口GE2/0/4和

ETH-TRUNK37，S9312的端口ETH-TRUNK37和ETH-TRUNK55，S5700的端口ETH-TRUNK1和GE0/0/16上做流量统计，比较流量统计结果在S3700到监控设置之前的链路上没有丢包，但是仍能看到卡屏，说明卡屏与这段链路无关; 流量统计配置方法：

? 配置acl，匹配组播目的IP地址：

acl number 3333

rule 5 permit udp destination 238.4.0.50 0 //238.4.0.50为视频流的组播组地址

? 配置流策略：

traffic classifier 3333 if-match acl 3333 #

traffic behavior 3333 statistic enable #

traffic policy 3333

classifier 3333 behavior 3333

2014-5-25

第26页, 共56页

华为交换机视频类故障案例集

? 将流策略应用在端口的出入方向对收发报文进行统计： interface GigabitEthernet X/X/X traffic-policy 3333 inbound traffic-policy 3333 outbound 显示统计结果：

display traffic policy statistics interface GigabitEthernet X/X/X in/out

display traffic policy statistics interface GigabitEthernet X/X/X in/out verbose rule-based

2) 将PC接在S3700下点播抓包，并在与编码器相连的S3700的入口做流量统计，抓包中

视频流的报文个数与在S3700的入口统计的个数相同，用wireshark分析抓包内容,分析说明存在丢包，说明S3700收到编码器的报文已经出现丢包。

3) 在编码器和S3700之间加一个第三方交换机点播测试，第三方交换机下接PC点播测

试，测试结果说明第三方交换机下挂的PC也存在卡屏，在该PC上抓包分析存在丢包。

2014-5-25

第27页, 共56页

华为交换机视频类故障案例集

4) 通过以上点播测试和抓包说明编码器发出的视频流已经存在丢包，需要编码器厂商

分析根因。

.4 解决方案

排除交换机问题，需要编码器厂商分析定位根因。

.5 经验总结

? 对于卡屏问题分析方法一是配置流量统计分析，二是抓包分析，三是逐段测试，对

于卡屏现象不稳定的情况必须逐段抓包分析。

? 现网问题涉及其他设备厂家时，要采取先定界再分析的策略。

.6 涉及产品和版本

系列框式交换机 X3 型态&版本 S23&33&53 V100R002 S23&33&53 V100R003 S23&33&53 V100R005 S23&33&53&63 V100R006 2014-5-25

是否适用否否是是第28页, 共56页

华为交换机视频类故障案例集

S33&53&63 V200R001 S33&53&63 V200R002 S33&53&63 V200R003 X7 S27&37&57 V100R005 S27&37&57&67 V100R006 S37&57&67 V200R001 S37&57&67 V200R002 S37&57&67 V200R003 盒式交换机 X3 S9300 V100R001 S9300 V100R002 S9300 V100R003 S9300 V100R006 S9300&9300E V200R001 S9300&9300E V200R002 S9300&9300E V200R003 X7 S7700 V100R003 S7700 V100R006 S7700&9700 V200R001 S7700&9700 V200R002 S7700&9700 V200R003

是是是是是是是是否是是是是是是是是是是是 2014-5-25

第29页, 共56页

华为交换机视频类故障案例集

? 瞬时流量突发导致视频卡现象的故障案例

问题现象描述及组网

视频服务器和摄像头之间用组播协议来点播，视频流在视频平台服务器上转换成单播流，观测PC1、PC2是从视频服务器点播单播流观看，存储设备也是从视频服务器保存的单播流。

从PC1实时从平台服务器上点播视频会卡，PC2实时点播不卡，但PC1从视频存储上的点播也不卡。

.2 问题根因说明

视频转发平台服务器会产生TCP报文的流量突发，视频服务器的GE出端口瞬时流量接

近1G,视频服务器端口收发报文处理存在性能问题。

.3 问题判断方法

1) 从PC2直接点播视频转发平台的节目，是单播视频流，发现没有卡顿现象；视频转

发平台视频流会保存到存储服务器中，从PC1看存储上的节目，也是单播视频流，也没有卡顿现象。这说明视频服务器到探头的转发路径上，用组播协议得到的视频流是不存在丢包的，也就是说交换机上没有丢包。只有通过PC1点播，组播流经过S7703-01和视频转发服务器链接的端口才会出现视频卡顿。

2) 从PC1 直接ping 视频服务器上的IP地址，进行icmp报文收发统计，也没有发现丢

包，并且交换机上入出端口也没有discard报文丢弃计数。

2014-5-25

第30页, 共56页

华为交换机视频类故障案例集

3) 视频转发平台和S7703-01有多个口相连，用reset statistics-peak interface

GigabitEthernet x/x/x命令每清楚一次接口流量峰值统计，几十秒之后就立即发现入方向流量峰值很快又达到1G，但接口的平均速率只有300~400M左右，说明从视频转发服务器到交换机S7703-01方向，有比较严重的流量突发。

< S7703-01>display inter GigabitEthernet 3/1/0 GigabitEthernet3/1/0 current state : UP Line protocol current state : UP ? Last 10 seconds input rate 345130200 bits/sec, 49443 packets/sec Last 10 seconds output rate 306197808 bits/sec, 41913 packets/sec Input peak rate 999933024 bits/sec, Record time: 2013-11-14 17:24:21 Output peak rate 355142968 bits/sec, Record time: 2013-11-14 15:34:17 < S7703-01>display inter GigabitEthernet 3/1/1 GigabitEthernet3/1/1 current state : UP Line protocol current state : UP ? Last 10 seconds input rate 321374384 bits/sec, 47312 packets/sec Last 10 seconds output rate 306858824 bits/sec, 42055 packets/sec Input peak rate 999995680 bits/sec, Record time: 2013-11-14 16:49:14 Output peak rate 358174496 bits/sec, Record time: 2013-11-14 15:34:17 < S7703-01>display inter GigabitEthernet 3/1/2 GigabitEthernet3/1/2 current state : UP Line protocol current state : UP ?. Last 10 seconds input rate 328014680 bits/sec, 47277 packets/sec Last 10 seconds output rate 308390488 bits/sec, 41988 packets/sec Input peak rate 999848352 bits/sec, Record time: 2013-11-14 17:47:55 Output peak rate 367085600 bits/sec, Record time: 2013-11-14 15:34:17 4) 把其中的一个端口扩成两端口的eth-trunk聚合口，从PC1点播视频卡顿现象消失，

后续其他端口做同样的聚合困绑，卡顿现象消失。

< -S7703-01>display inter GigabitEthernet 3/1/3 GigabitEthernet3/1/3 current state : UP Line protocol current state : UP ? Last 300 seconds input rate 128330832 bits/sec, 16365 packets/sec Last 300 seconds output rate 175319944 bits/sec, 25651 packets/sec Input peak rate 323658664 bits/sec, Record time: 2013-11-14 17:29:09 2014-5-25

第31页, 共56页

Output peak rate 208935920 bits/sec, Record time: 2013-11-14 16:28:31 < -S7703-01>display inter GigabitEthernet 3/1/13 GigabitEthernet3/1/13 current state : UP Line protocol current state : UP ?. Last 300 seconds input rate 256911728 bits/sec, 32761 packets/sec Last 300 seconds output rate 138585992 bits/sec, 24796 packets/sec Input peak rate 638283240 bits/sec, Record time: 2013-11-14 17:29:09 Output peak rate 174871448 bits/sec, Record time: 2013-11-14 16:50:41 华为交换机视频类故障案例集

5) 综上所述，交换机转发没有丢包，卡顿是因为视频转发服务器转发性能存在问题。

.4 解决方案

视频服务器存在流量突发，单端口捆绑成聚合口解决。

.5 经验总结

? 交换机的转发缓存，并不会长时间缓存报文（这边长时间是指5ms以上），如果突

发和拥塞到一定程度，交换机只会丢包产生花屏等现象，交换机缓存不会引起视频的卡顿。

? 交换机流量峰值清除需要用reset statistics-peak interface GigabitEthernet x/x/x , 而

reset counters interface 只能清除接口统计计数和速率，不能清除峰值记录。如果以前发生过流量突发并且记录接口1G的峰值，就算当前有突发没有达到历史峰值是不会刷新历史记录的。这一点可能会对定位方向产生误导，延长定位时间。 ? 可以借助wireshark抓包工具，对视频流进行抓包，通过wireshark的statistics菜单下IO

Graph图查看报文是否有突发。

.6 涉及产品和版本

系列框式交换机 X3 型态&版本 S23&33&53 V100R002 S23&33&53 V100R003 S23&33&53 V100R005 S23&33&53&63 V100R006 S33&53&63 V200R001 2014-5-25

是否适用否否是是是第32页, 共56页

华为交换机视频类故障案例集

S33&53&63 V200R002 S33&53&63 V200R003 X7 S27&37&57 V100R005 S27&37&57&67 V100R006 S37&57&67 V200R001 S37&57&67 V200R002 S37&57&67 V200R003 盒式交换机 X3 S9300 V100R001 S9300 V100R002 S9300 V100R003 S9300 V100R006 S9300&9300E V200R001 S9300&9300E V200R002 S9300&9300E V200R003 X7 S7700 V100R003 S7700 V100R006 S7700&9700 V200R001 S7700&9700 V200R002 S7700&9700 V200R003 是是是是是是是否是是是是是是是是是是是 2014-5-25

第33页, 共56页

华为交换机视频类故障案例集

? 组播视频花屏现象的故障案例

问题现象描述及组网

S9312-1S9312-2OLTOLT

S9312做DR，起三层组播，转发组播流到OLT。OLT与S9312之间通过汇聚口连接，在OLT侧发现组播流有卡顿现象。

.2 问题根因说明

通过在S9312出接口进行流镜像抓包，并转换为视频文件确认，从S9312转发出去的组

播流正常，为OLT侧问题。

.3 问题判断方法

1) 采集组播表项，未发现问题：

[Quidway]display multicast forwarding-table 233.50.200.205 Multicast Forwarding Table of VPN-Instance: public net Total 159 entries, 1 matched 00001. (122.229.7.172, 233.50.200.205) MID: 29, Flags: 0x0:0 2014-5-25

第34页, 共56页

华为交换机视频类故障案例集

Uptime: 6w:0d, Timeout in: 00:03:23 Incoming interface: Vlanif350 List of 1 outgoing interfaces: 1: Vlanif210 Matched 478278011 packets(657770030160 bytes), Wrong If 0 packets Forwarded 478278011 packets(657770030160 bytes)

2) 出接口进行镜像抓包，在wireshark上做过滤抓包，并保存为pcap文件，。 3) 通过工具把pcap文件转换为视频文件，进行播放，发现是否有问题。pcap文件转换

为视屏文件步骤如下：

a) 首先下载转发工具，工具名为 “抓包文件转TS工具”。

b) (2) 通过此工具把抓包文件.pcap转换为ts文件，首先点击源文件路径的选

择按钮，选择需要转换的抓包文件.pcap。工具会自动算出目标文件路径，然后点击开始转换按钮。详细步骤如下图所示 ? 打开cap2mpg工具

? 点击源文件路径选择按钮，会弹出选择文件对话框。

2014-5-25

第35页, 共56页

华为交换机视频类故障案例集

? 点击开始转换按钮。

? 转换成功，界面如下：

2014-5-25

第36页, 共56页

华为交换机视频类故障案例集

.4 解决方案

不涉及。

.5 经验总结

? 对于组播视频花屏的问题，首先需要查看出端口是否有拥塞丢包。 ? 如果没有拥塞丢包，则查看组播表项是否异常，即出接口是否稳定。 ? 通过在出接口进行流镜像抓包，并转换为视频文件，确认是否有问题。

.6 涉及产品和版本

是否适用否否是是是是是是是是是是否是是是是是是是第37页, 共56页

S7700 V100R003

华为交换机视频类故障案例集

S7700 V100R006 S7700&9700 V200R001 S7700&9700 V200R002 S7700&9700 V200R003

是是是是 2014-5-25

第38页, 共56页

华为交换机视频类故障案例集

? 交换机三层组播观看视频时出现马赛克问题案例

问题现象描述及组网

组网如图所示，组播源和S5300直接相连，S5300上配置三层组播，通过同一个VLANIF下挂接收者，两个接收者为监控终端，分别负责监控不通的节目信息。客户反馈，在监控的过程中频繁出现马赛克现象。

.2 问题根因说明

由于在S5300上只配置了三层组播，生成的转发表项中，下行出端口为VLANIF，在S5300

的实现中，只配置三层组播是无法实现流量的精确转发的，即组播流量会向出端口VLANIF对应的VLAN中所有物理端口转发，而两个监控终端是通过同一个VLAN接入到S5300的，因此第二个监控终端可以收到第一个监控终端所监控的节目，虽然自己不希望监控这些节目，同样，第一个监控终端也可以收到第二个监控终端所监控的节目流。

由于监控终端的处理能力也是有限制的，收到大量报文导致终端无法及时处理，产生马赛克现象。

.3 问题判断方法

判断方法比较简单，只需要检查配置三层组播的VLANIF对应的VLAN视图下，是否配

置igmp-snooping enable即可。

.4 解决方案

1) 将三层组播修改为二层组播即可实现流量的精确转发；

2014-5-25

第39页, 共56页

华为交换机视频类故障案例集

2) 如果客户要求必须配置三层组播，则可以同时配置二三层组播，但是这个要求S5300

的版本为R5或者之后的版本，R3及之前的版本不支持二三层组播同时配置。

.5 经验总结

马赛克问题一般是由于丢包或者重复报文导致的。丢包的原因一般有： 1) 流量较大，出端口产生拥塞导致丢包；

2) 入端口配置了限速，当业务高峰期流量较大时，入端口限速导致丢包。报文重复的原因一般有：

1) 只配置三层组播，无法实现流量的精确转发，建议同时配置igmp-snooping； 2) 存在多个组播源发送相同的组播数据流，此时需要对网络进行整改或者要求接收者

点播节目时能够指定组播源的地址。

.6 涉及产品和版本

是否适用否否是是是是是是是是是是否是是是第40页, 共56页

华为交换机视频类故障案例集

S9300&9300E V200R001 S9300&9300E V200R002 S9300&9300E V200R003 X7 S7700 V100R003 S7700 V100R006 S7700&9700 V200R001 S7700&9700 V200R002 S7700&9700 V200R003 是是是是是是是是 2014-5-25

第41页, 共56页

华为交换机视频类故障案例集

? 交换机二层组播报文乱序导致花屏的故障案例

问题现象描述及组网

组网:

eth-trunk eth-trunk

Source-----------------------------S9300------------------------Receiver

组网简化为如图所示，S93和上游组播源、下游接收者均通过Eth-trunk相连，下游接收者反馈有马赛克、花屏现象，而在S93上通过流量统计，并没有发现报文在S93上被丢弃的问题，通过在S93下游抓包发现报文存在乱序现象，导致接收终端无法正常处理报文。

.2 问题根因说明

终端出现花屏的原因为一般有丢包、重复包和报文乱序三种，本问题的原因通过抓包发现为报文乱序导致。而报文问题原因为组播源在向S93发送组播数据报文时，对端设备的Eth-trunk链路不是逐流转发，因此出现同一条组播流会从不同Eth-trunk端口进入S9300，此时就会出现乱序。这样在S93上转发时，无法保证转发出去的报文的顺序，最终导致出现花屏的问题。

.3 问题判断方法

1) 对于花屏问题，一般是由于丢包或者重复报文导致的，而丢包的可能性又大于重复

报文，因此首先判断设备上是否存在丢包现象，可以通过在上下游端口配置流量统计进行判断；也可以通过抓包判断是否有丢包现象，同时也可以判断是否有重复报文的问题；

2) 在本案例中，问题的原因为报文乱序，可以通过在上游的Eth-turnk所有成员端口内

配置端口镜像抓包，观察对于同一条流，是否每个成员端口都有报文到S93，如果每个端口都有流量进来，则S93上转发时无法保证报文的顺序；

3) 如果无法抓包，则可以尝试down掉Eth-trunk中的成员端口，只保留一个up的端口，

观察问题是否可以解决，如果可以解决，也基本可以确定是S93从多个端口收到同

2014-5-25

第42页, 共56页

华为交换机视频类故障案例集

一个组播流导致的。

.4 解决方案

1) down掉上游Eth-trunk端口的成员端口，只保留一个up的端口(在流量没有超过带宽

的前提下)，可以暂时规避该问题；

2) 从上游找问题的根本原因，保证同一条流只通过一个端口发到S93上，可以彻底解

决该问题。

.5 经验总结

对于报文乱序的问题，由于在交换机上走的是硬件转发流程，一般不会出现在S93上转发导致乱序的问题，需要从上游检查是否同一条流是从多个端口到达交换机。

.6 涉及产品和版本

是否适用否否是是是是是是是是是是否是是第43页, 共56页

华为交换机视频类故障案例集

S9300 V100R006 S9300&9300E V200R001 S9300&9300E V200R002 S9300&9300E V200R003 X7 S7700 V100R003 S7700 V100R006 S7700&9700 V200R001 S7700&9700 V200R002 S7700&9700 V200R003 是是是是是是是是是 2014-5-25

第44页, 共56页

华为交换机视频类故障案例集

? 组播点播时出现节目画面停顿故障案例

问题现象描述及组网

S3300下挂多个S2300，均在同一vlan204内，在204下配置igmp-snooping，客户反馈，在S2300下挂用户点播接收组播节目，发现观看的组播节目画面停顿的现象比较严重，但是直接在S3300下挂用户时，此时用户点播就可以正常观看组播节目。

.2 问题根因说明

S3300下挂了6台S2300，看了一下S23端口的流量，发现进来有较多的广播报文，带宽

利用率大概在30%多，在S2300端口上也看到有丢包计数，判断此时的广播流量过大影响导致组播丢包。

.3 问题判断方法

点播组播发现节目画面出现停顿现象，说明组播数据转发异常，存在丢包、多包或者重

包的情况。

定位思路和顺序如下：

1) 先判断数据报文大概是在哪台设备上出现中断或者丢包，这里根据客户返回的信息

可以判断出问题的设备在S2300上面；

2) 收集当前设备版本补丁、形态、配置信息，分析是否存在已知问题；

2014-5-25

第45页, 共56页

华为交换机视频类故障案例集

3) 收集设备上端口流量是否正常，是否存在丢包计数； 4) 方便的话，在端口上做流量统计或者镜像抓包；

该问题发现端口上存在丢包计数，并且入端口流量较大，且广播类型报文过多，所以可能是S2300之间存在广播报文导致端口导致流量突发，从而组播报文出现丢包，影响点播质量。

.4 解决方案

在S3300上的vlan204下的端口配置端口隔离，问题解决。

.5 经验总结

在位于汇聚层交换机设备上，如果下挂接入交换机较多，且均在同一VLAN时，为了防

止广播报文洪泛，建议汇聚交换机端口上可以配置端口隔离，防止广播流量占用带宽，相互影响。

.6 涉及产品和版本

是否适用否否是是是是是是是是是是否是第46页, 共56页

华为交换机视频类故障案例集

S9300 V100R003 S9300 V100R006 S9300&9300E V200R001 S9300&9300E V200R002 S9300&9300E V200R003 X7 S7700 V100R003 S7700 V100R006 S7700&9700 V200R001 S7700&9700 V200R002 S7700&9700 V200R003 是是是是是是是是是是 2014-5-25

第47页, 共56页

华为交换机视频类故障案例集

? 多路视频同时点播时视频出现卡顿故障案例

问题现象描述及组网

摄像头S1728GWR摄像头SERVER

如上图所示，多个监控摄像头通过S1728GWR交换机和服务器Server之间连接。监控摄像头实时将监控数据流量发送给server记录。当多路视频同时发送时，从server上看到的监控视频有卡顿情况。

。

.2 问题根因说明

视频流量存在突发，服务器收到突发流量时向交换机发送交换机发送PAUSE，交换机

使能pause帧的情况下会短暂暂停发送流量，导致流量拥塞在交换机上，出现拥塞丢包。

.3 问题判断方法

1) 流量存在突发，比如视频流量、组播流量、服务器发出的大流量报文。

2) 交换机使能流控，而且交换机上存在拥塞计数，收流的服务器网卡使能了流控，而

且有PAUSE帧计数。

.4 解决方案

关闭服务器网卡流控，服务器缓存比交换机大，突发的流量缓存到服务器上，避免拥塞

丢包。

.5 涉及产品和版本

系列框式交换机 2014-5-25

X3 型态&版本 S23&33&53 V100R002

是否适用否第48页, 共56页

华为交换机视频类故障案例集

S23&33&53 V100R003 S23&33&53 V100R005 S23&33&53&63 V100R006 S33&53&63 V200R001 S33&53&63 V200R002 S33&53&63 V200R003 X7 S27&37&57 V100R005 S27&37&57&67 V100R006 S37&57&67 V200R001 S37&57&67 V200R002 S37&57&67 V200R003 盒式交换机 X3 S9300 V100R001 S9300 V100R002 S9300 V100R003 S9300 V100R006 S9300&9300E V200R001 S9300&9300E V200R002 S9300&9300E V200R003 X7 S7700 V100R003 S7700 V100R006 S7700&9700 V200R001 S7700&9700 V200R002 S7700&9700 V200R003 否是是是是是是是是是是否是是是是是是是是是是是 2014-5-25

第49页, 共56页

华为交换机视频类故障案例集

? 盒式交换机部署三层组播业务时视频频繁出现马赛克问题案例

问题现象描述及组网

1) 组网概要拓扑:

组播源---(1到7端口)S5352(45-48端口)--- ETH-TRUNK1--- (21-24)S5328(1)----客户端

2) 现象:

S5352和S5328之间起用PIM SM，客户端通过IGMP点播客户端能够收到节目，但开通高清节目后，频繁出现马塞克现象。在客户端PING组播源没有任何丢包,时延不大20左右。

.2 问题根因说明

S5300上都是只配置了三层组播，由于自验交换机只配置三层组播的时候，不默认开启

流量的精确转发功能，即多个终端在同一个VLAN，点播不同的节目，一个终端也会同时收到其它终端点播数据流，虽然它不需要。由于终端的处理能力也是有限的，因此当收到太多的数据报文时，终端处理不过来，导致出现马赛克现象

.3 问题定位步骤及判断方法