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

EPCN网络中机顶盒点播卡处理经验案例

2012-06-28 发表
  • 0关注
  • 0收藏 1257浏览
粉丝:2人 关注:1人

EPCN网络中高清机顶盒点播卡处理经验案例

一、   组网:

在某广电高清互动电视项目中,采取IPTV方式进行高清的互动点播业务,其上下行数据传输,采取H3C EPON+EPCN方式传输。其EPON网络头端为S7600 Olt板,终端ONU采取ET254G千兆ONU;其EPCN采取新一代设备,头端采取CC720E ,终端采用CB303A。下图为单个终端的组网示意图。

图一-1 网示意图

由上图可知,机顶盒点播高清节目,上行点播指令经过CB303ACC720EET254-GS76到点播服务器,节目数据流下行从远端服务器10.254.251.14UDP点播流经过S76ET254-GCC720ECB303A到机顶盒。

二、   问题描述:

机顶盒点播高清节目时,大概率会出现点播视频卡,不流畅情况。

如果将机顶盒接入在ONU下或EPCN头端CC720E侧,则不会出现点播卡问题。

三、   过程分析:

现场通过同时在EPON网络端和EPCN网络端的抓包分析,在EPON网络中,高清点播流量平滑,流量稳定在9-10Mbps,如下图所示。

2 正常点播情况下的流量图

但经过EPCN网络后机顶盒客户端点播情况,如下图所示,流量呈锯齿状并有明显的跌落。

3 异常点播情况下的流量图

如下图4所示,经过抓包分析,点播流使用UDP协议进行传输,从UDP的上层协议中可以看出,数据有丢失“SKIPS=14”,如下所示。经过对比EPCN头端处的抓包情况,与上层协议记录的丢失的数据吻合。

4 UDP数据包丢失

经过EPCN网络后为什么数据会有丢失情况,是什么导致了EPCN网络中数据丢包?

问题集中在EPCN网络上,需要排查有那些原因引起丢包。经过排查EPCNCable网路配置,没在Cable上做限速,也没有在以太网口上做限速;高清业务带宽只有9-10Mbps,也未超过单个终端100Mbps的带宽;机顶盒与CB303A的以太网口协商为100M全双工,也没有异常协商问题;其他配置上可以引起丢包的原因只有广播风暴抑制功能,但是高清点播的数据为单播数据,应该不会触发广播风暴抑制功能,但经过实验和CB303A的端口统计信息证明,将广播风暴抑制关闭后现象消失,经过多次测试证明,关闭广播风暴有效。

广播风暴抑制功能开启后,Cable网桥可以有效地抑制广播流量,避免网络拥塞,保证网络业务的正常运行,所以关闭广播风暴抑制不是最恰当的解决方案。

分析引起终端广播风暴抑制的条件,可能的原因有:

n  在终端所在的二层网络内有广播报文泛洪,广播报文被抑制。

n  在终端所在的二层网络内,有未知的单播报文,当接收端未学习到目的地址MAC将在全网进行广播,而被广播抑制功能抑制。

根据终端抓包排查,二层网络中并未出现广播报文泛洪情况,排除第一种情况;第二种情况,经过在EPCN头端查看MAC表项,发现MAC地址已经学习超过1.2K,超过终端的表项,如下图所示。

文本框: <H3C>display mac-address count&#13;&#10;Reading entire MAC table. Please wait...&#13;&#10;1280 mac address(es) found&#13;&#10;

我们将已经导出1.2KMAC地址,通过终端MAC地址算法计算,之后得出了MAC地址哈希冲突所导致的溢出情况,详细分析如下:

EPCN CB303A终端的MAC地址算法:总共有512index,每个index中能放置4个经过哈希算法后的MAC地址,每个index中超过4个的mac地址会放置到另外16MAC地址的空间中,如果这16个空间的MAC地址也满了,新增的冲突MAC就无法再学习了。如下图所描述:

hash_count中已看出有88index已超过4mac地址,另外16mac地址的空间也已经被占满了,这时增加的mac地址经过哈希后,只要落在这88index中,就会溢出,导致不学习。最坏的情况如果机顶盒连续的几个mac地址经过哈希都映射在学满的几个index中,就会出现新加入的机顶盒mac地址无法学习到情况。

我们再看下CB303A的工作过程,正常情况下,设备启动时,CB303A设备交换芯片MAC地址表是空的,此时S76网关发送一个帧给机顶盒,那么当CB303A设备交换芯片接收此帧的时候,查看源地址(S76网关),并将它添加到MAC地址表中,但是设备并不知道机顶盒在哪个端口上(MAC地址表中没有机顶盒的MAC地址),所以这个帧就是未知单播帧,设备交换芯片会泛洪这个帧,直到机顶盒MAC回应他所在端口, 然后以单播方式正常传输。异常情况下,由于现网中存在1.2k左右的MAC地址,使CB303A终端学习后出现溢出现象,当终端交换芯片学习超过其容量表项的MAC后,机顶盒的MAC不被交换芯片所学习,导致单播报文在交换芯片中以广播方式传输,并被终端的广播风暴抑制功能所抑制。

四、   解决方法:

1、这个问题是由于EPCN终端所在管理VLAN网络的MAC地址过多造成,过多的MAC在同一个二层下,会产生大量的广播导致网络传输效率低下,建议合理规划二层设备数量。

我司EPCN设备可以远程情况下修改管理VLANIP地址。方法:在WEB页面向导:系统管理→管理接口,同时更改管理VLANIP地址。

注意:CC600E需要升级到V100R010及以后版本;CC620E需升级到V100R002及以后版本;CC720E需升级到V100R002及以后版本;CC600可通过远程导入配置文件进行修改;

2、将每个汇聚层设备,例如S76S75ES65划分一个管理VLAN,修改OLT上端的配置,在OLT上做端口隔离。

 

 

该案例对您是否有帮助:

您的评价:1

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

作者在2019-06-10对此案例进行了修订
0 个评论

该案例暂时没有网友评论

编辑评论

举报

×

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

侵犯我的权益

×

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

泄露了我的隐私

×

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

侵犯了我企业的权益

×

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

抄袭了我的内容

×

原文链接或出处

诽谤我

×

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

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

×

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

不规范转载

×

举报说明

提出建议

    +

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

确定

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

注册后可访问此模块

跳转hclhub

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