分享机顶盒收到多份组播流的处理建议

scwy_pyh_py

故障概述：

针对前期机顶盒收到多份组播流而引起节目卡顿的故障（广元老城、东坝用户和成都贝森），省NOC光网组和数据组组织进行了专题分析。通过分析确认此类故障的原因是因为数据配置或组网方式的不规范，导致机顶盒会收到2份（甚至多份）组播流，造成重复消耗带宽资源，引起带宽不足或机顶盒同时处理多份报文处理能力不足。

通过分析，认为在现网上主要有三种情况会造成这类问题，但是可以通过规范配置数据和组网方式的方法来解决。具体分析如下：

情况一：

OLT/大二层交换机是双/多链路上行到BAS(或2平面的SR)设备，且没有启用链路聚合功能；同时这些链路都允许VLAN 3990通过，BAS上对应的端口上也配置有VLAN 3990的组播子端口。用户发起组播（直播）请求时，这些请求都会被转发到BAS的多个组播子端口上，而这些子端口都会响应用户请求下发组播流。造成机顶盒会收到多份组播流引起卡顿。

处理方法：OLT/大二层交换机一旦使用双/多链路上行时，必须对上行链路启用链路聚合。

情况二：

两/多台大二层交换机在2层打通，且这些互联的大二层交换机端口都允许VLAN 3990通过。用户发起组播（直播）请求时，这些请求除了会被本台大二层交换机提交给实际对应的BAS组播子端口外，还会被转发给其他大二层交换机到达其他的BAS组播子端口，这些BAS子端口都会响应用户请求下发组播流。造成机顶盒会收到多份组播流引起卡顿。

处理方法：对各台大二层交换机的互联端口数据进行清理，确保组播VLAN(VLAN 3990)不会在大二层交换机之间互通。清理原则是：组播VLAN不能做为默认配置添加到大二层交换机的所有端口上，而只应该添加于大二层交换机的以下端口：至BAS或2平面SR的上行端口和连接各台开通了IPTV业务的OLT/DSLAM设备的下行端口。

情况三：

大二层交换机双/多挂在两/多台BAS（或2平面的SR）之下，对上行到每台BAS的组播VLAN没有进行规划，而都使用VLAN 3990。用户发起组播（直播）请求时，这些请求就会被转发给每台BAS，这些BAS都会响应用户请求下发组播流。造成机顶盒会收到多份组播流引起卡顿。

处理方法：对于这种情况，根本的解决办法是通过增加大二层交换机，改变拓扑结构为树形来解决。但新建设备需要时间，在新设备到位并具备运营能力前，有两种临时的解决方案。

方案一：关闭其中一台BAS的组播子接口，由另一台BAS提供全部大二层下用户的组播服务。这种方案的好处是结构简单，可靠；缺点是当提供服务的BAS故障，或至大二层链路中断时，此大二层下全部IPTV业务用户都将受影响。

方案二：在两台BAS的下行组播子接口启用PIM协议，根据协议协商出此共享网段的组播转发路由器。这种结构的好处是当一台BAS或链路中断时，此大二层设备下的IPTV用户只是部分受影响；缺点是结果相对复杂，且不同厂家设备之间的兼容性（主要涉及计时器设置）不易验证。