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

　　igmp-snooping querier enable使用场景不当，交换机和路由器组播功能配合有问题，路由器收到另外一个OLT的leave，路由器没有成功收到特定组查询报文的report应答，导致路由器组播表项老化使得视频中断。

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

　　7)至此说明路由器对report报文处理有问题，所以怀疑路由器收发的igmp报文处理有问题，继续在上行口1/0/1端口镜像抓包，用类似的方法把1/0/1入出方向流镜像到2/0/45观察口，在2/0/45出方向过滤igmp报文，用PC只抓igmp报文（如果观察口上有其他流量,可以再PC抓包工具上过滤只抓igmp报文，PC网卡通常是GE的，小几百兆流量一般没问题）

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

　　（3）了解到该上行链路是向运营商申请的专有带宽，怀疑可能带宽不够。通过向运

　　营商申请增加带宽后，不再发生丢包和视频有马赛克的情况，验证了此前的推理。

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

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

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

　　使用PC机在另外一个楼层，连接S5700EI-2交换机同时点播两个组播节目时，VLC就会偶尔出现花屏，马赛克现象。

　　从抓包结果分析，组播源服务器发出高清组播视频流量突发较为严重，虽然平均流量只有5~6Mbit/s，但是在0.001秒的粒度上突发接近350Mbit/s。

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

　　对于只配置三层组播的情况，资源交换机和一些其它厂商的实现不一样，我们的设备默认不开启二层精确转发，要实现精确转发，需同时开启IGMP-Snooping。

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

　　2)这些流量送到S77后在S77上会进行组播复制，每份报文会复制成多份，导致S77需要以几Gbit/s的速率向传输设备发送。由于S77的端口为千兆端口，该速率超过S77的端口带宽，导致S77出现拥塞丢包，导致视频花屏。

　　路由器收到该Leave报文后，会每隔1秒，连续发送2个特定组查询报文给S9300交换机，但交换机此时使能了igmp-snooping查询器功能，会将这2个特定组查询报文丢弃掉。

　　同时S9300具有snooping侦听和查询器功能，自己也会每隔1秒，连续发送2个特定组查询报文只给源IP为192.168.236.50的OLT，即只向端口GE1/0/15定组查询报文。

　　4)当现场发现OLT上断流时，从S9300采集的接口流量速率统计来看，上下行明显没有流，所以确认是S9300上行路由器没有把流发下来（如果故障概率不定时出现，可以借助SecureCRT跑脚本采集信息观察，下面是采集脚本做参考）。

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

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

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

　　2)上行组播路由口是1/0/1，下行端口是1/0/11，观察故障节目239.93.6.109，该节目观察多次断流后，查看S9300上下行转发表项存活时间比较长，没有老化过，说明S9300和下面OLT的IGMP query和report报文交互没有问题的。

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

　　2)将PC接在S3700下点播抓包，并在与编码器相连的S3700的入口做流量统计，抓包中视频流的报文个数与在S3700的入口统计的个数相同，用wireshark分析抓包内容,分析说明存在丢包，说明S3700收到编码器的报文已经出现丢包。

　　3)在编码器和S3700之间加一个第三方交换机点播测试，第三方交换机下接PC点播测试，测试结果说明第三方交换机下挂的PC也存在卡屏，在该PC上抓包分析存在丢包。

　　3)继续排查239.93.6.109节目流在从S9300上行进来和下行出去是否正常，在S9300做端口镜像到观察口，在观察口出方向做过滤，正常时该节目流在上下行端口统计速率显示为3M多。

　　【说明】对于未知单播、组播、广播的出方向流镜像命令行可以配置，但是功能不生效。当端口流量比较大时，只能使用端口镜像＋过滤方式。

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

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

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

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

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

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

　　1)通过wireshark解析发现在ms级别上，流量突发非常厉害。服务器休眠一秒多后以接近1Gbit/s的速率发送视频流量几毫秒后继续进入休眠状态，流量突发非常厉害，如下所示：

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

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

　　2)从PC1直接ping视频服务器上的IP地址，进行icmp报文收发统计，也没有发现丢包，并且交换机上入出端口也没有discard报文丢弃计数。

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

　　通过在S9312出接口进行流镜像抓包，并转换为视频文件确认，从S9312转发出去的组播流正常，为OLT侧问题。

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

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

　　IPTV组播花屏问题，也就是丢包问题定位。这种问题按以往的经验一般来说，先看端口上数据流量是否达到带宽限制，端口上是否存在discard丢弃计数，芯片内部是否出现报文丢弃计数，流量突发等情况。再或者配置流量统计，分析入出端口报文相差个数是否明显有区别。

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

　　对于流量突发的情况，建议使用wireshark软件分析报文的瞬时突发值，从而确认是否会导致交换机出现偶尔丢包的情况。

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

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

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

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

　　2)如果客户要求必须配置三层组播，则可以同时配置二三层组播，但是这个要求S5300的版本为R5或者之后的版本，R3及之前的版本不支持二三层组播同时配置。

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

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

　　S5300上都是只配置了三层组播，由于自验交换机只配置三层组播的时候，不默认开启流量的精确转发功能，即多个终端在同一个VLAN，点播不同的节目，一个终端也会同时收到其它终端点播数据流，虽然它不需要。由于终端的处理能力也是有限的，因此当收到太多的数据报文时，终端处理不过来，导致出现马赛克现象

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

　　3)当UT统计出单个丢包时，华为分别提供入接口和出接口上的镜像抓包，若镜像报文中包含该序列号的报文，则认为是UT设备出现丢包，若镜像报文中不包含该序列号的报文，则认为是交换机出现丢包；

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

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

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

　　2)出接口进行镜像抓包，在wireshark上做过滤抓包，并保存为pcap文件，。

　　3)通过工具把pcap文件转换为视频文件，进行播放，发现是否有问题。pcap文件转换为视屏文件步骤如下：

　　b)(2)通过此工具把抓包文件.pcap转换为ts文件，首先点击源文件路径的选择按钮，选择需要转换的抓包文件.pcap。工具会自动算出目标文件路径，然后点击开始转换按钮。详细步骤如下图所示

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

　　当前如果只有一个节目观看时是好的，后续如果节目多起来，那么突发流量将翻番，则马赛克现象将更为严重，此时交换机端口上固有带宽仅为1Gbit/s。

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

　　set flow-stat interval 10（把接口速率统计周期调整为10s，默认周期是300s，这样方便可以看节目是否断流）

　　上面表格中的测试结果非常清楚地显示当ME设备出现统计到单个丢包情况时，交换机上入方向和出方向镜像抓包均没有出现丢包，报文完整，交换机不存在转发丢包的情况。

　　本次测试对于UT前期反馈单个丢包的现象，可以确认华为交换机上不存在丢包，是UT自身ME设备有问题。

　　3)如果无法抓包，则可以尝试down掉Eth-trunk中的成员端口，只保留一个up的端口，观察问题是否可以解决，如果可以解决，也基本可以确定是S93从多个端口收到同一个组播流导致的。

　　1)down掉上游Eth-trunk端口的成员端口，只保留一个up的端口(在流量没有超过带宽的前提下)，可以暂时规避该问题；

　　1)对于花屏问题，一般是由于丢包或者重复报文导致的，而丢包的可能性又大于重复报文，因此首先判断设备上是否存在丢包现象，可以通过在上下游端口配置流量统计进行判断；也可以通过抓包判断是否有丢包现象，同时也可以判断是否有重复报文的问题；

　　2)在本案例中，问题的原因为报文乱序，可以通过在上游的Eth-turnk所有成员端口内配置端口镜像抓包，观察对于同一条流，是否每个成员端口都有报文到S93，如果每个端口都有流量进来，则S93上转发时无法保证报文的顺序；

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

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

　　这些流量送到S77后在S77上会进行组播复制，每份报文会复制成多份，导致S77需要以几Gbit/s的速率向传输设备发送。由于S77的端口为千兆端口，该速率超过S77的端口带宽，导致S77出现拥塞丢包，导致视频花屏。

　　交换机的转发缓存，并不会长时间缓存报文（这边长时间是指5ms以上），如果突发和拥塞到一定程度，交换机只会丢包产生花屏等现象，交换机缓存不会引起视频的卡顿。

　　交换机流量峰值清除需要用reset statistics-peak interface GigabitEthernetx/x/x ,而reset counters interface只能清除接口统计计数和速率，不能清除峰值记录。如果以前发生过流量突发并且记录接口1G的峰值，就算当前有突发没有达到历史峰值是不会刷新历史记录的。这一点可能会对定位方向产生误导，延长定位时间。

　　视频流量存在突发，服务器收到突发流量时向交换机发送交换机发送PAUSE，交换机使能pause帧的情况下会短暂暂停发送流量，导致流量拥塞在交换机上，出现拥塞丢包。

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

　　现场将视频源服务器修改为UDP模式问题解决。再次在77的入端口做端口镜像抓包，通过wireshark解析后确认流量发送比较平稳，突发比较小，不会导致93的发送速率超过端口带宽，不会出现视频黑屏问题。流量解析情况如下所示：

　　对于组播复制要关注组播源的发包方式，定位问题时可以查看端口的报文计数，查看是否有discard丢包（514单板除外）。

　　1)只配置三层组播，无法实现流量的精确转发，建议同时配置igmp-snooping；

　　2)存在多个组播源发送相同的组播数据流，此时需要对网络进行整改或者要求接收者点播节目时能够指定组播源的地址。

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

　　对于卡屏问题分析方法一是配置流量统计分析，二是抓包分析，三是逐段测试，对于卡屏现象不稳定的情况必须逐段抓包分析。

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

　　当在流统计或镜像过滤过程中，用到组播IP转换成组播MAC的，可以找一个组播IP地址和组播MAC的转换工具。

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

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

　　交换机一般只在上游设备没有使能查询器的场景下，自身使能查询器，帮助整个二层网络实现组播协议交互过程。如果二层网络中还存在其他的查询器设备，则建议交换机上不再使能查询器，避免出现查询器选举的问题。

　　通过现象先定界问题所在的设备；合理使用流统计、端口镜像，尽量先用统计，后现场抓包；现象不定期出现，可以借助SecureCRT等工具跑脚本采查询采集信息。

　　4)把其中的一个端口扩成两端口的eth-trunk聚合口，从PC1点播视频卡顿现象消失，后续其他端口做同样的聚合困绑，卡顿现象消失。

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

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

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

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

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

　　2)报文波形流量图（X轴单位为0.001秒，Y轴单位为Bits/Tick）

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

　　1)马赛克的原因一般都是由于丢包导致的，但是该问题中，通过在两台设备上检查端口丢包计数，没有丢包信息。

　　2)另外在两台S5300上做流量统计，在有马赛克出现时，设备上出入方向的流量完全一致，也没有丢包，判断问题不是突发流量导致的。

　　3)由于是开通高清节目，就会出现马赛克，检查设备上的配置，查看S5300上使能了IGMP的VLANIF对应的VLAN内是否同时使能了IGMP-Snooping功能，如果没有使能，则马赛克很有可能是因为组播流量没有精确转发导致。

　　5)继续排查路由器，发现是由于收不到OLT report报文老化删除表项的。

　　6)继续排查S9300是否把OLT report报文透传给路由器，同样用端口镜像过滤抓包239.93.6.109的igmp report报文，经过抓包证实，故障时S9300已经保证每1分钟至少有一个report透传给路由器

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

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

　　3)交换机上使能二层组播查询器功能，同时使能代理功能，这样交换机可以代替下游用户回应report报文。（还是不推荐，理由仍然是避免出现查询器选举的问题）

　　视频转发平台服务器会产生TCP报文的流量突发，视频服务器的GE出端口瞬时流量接近1G,视频服务器端口收发报文处理存在性能问题。

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

　　S9300下挂多台OLT点播同一个组播组节目时，1/0/15下的OLT离开后，会发送Leave报文。如时间点4点32分33秒时，源IP为192.168.236.50的OLT发送了组播组为239.93.6.109的leave报文给交换机，同时交换机也会将该leave报文转发给路由器

　　1)S9300起二层组播，并且启用组播查询器功能igmp-snooping querier enable，默认每60s发送一个查询报文，150s收不到下挂用户应答的report报文就会删除下行组播出端口表项。另外S9300默认10s内收到相同节目的igmp报文会抑制掉。

　　在位于汇聚层交换机设备上，如果下挂接入交换机较多，且均在同一VLAN时，为了防止广播报文洪泛，建议汇聚交换机端口上可以配置端口隔离，防止广播流量占用带宽，相互影响。

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

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

　　在77连接组播源的端口入方向镜像抓包，通过wireshark解析发现在ms级别上，流量突发非常厉害。服务器休眠一秒多后以接近1Gbit/s的速率发送视频流量几毫秒后继续进入休眠状态，流量突发非常厉害，如下所示：

　　S3300下挂了6台S2300，看了一下S23端口的流量，发现进来有较多的广播报文，带宽利用率大概在30%多，在S2300端口上也看到有丢包计数，判断此时的广播流量过大影响导致组播丢包。

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