点播卡顿故障分析报告.pdf

《点播卡顿故障分析报告.pdf》由会员分享，可在线阅读，更多相关《点播卡顿故障分析报告.pdf（8页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、关于高清互动点播卡故障的分析报告关于高清互动点播卡故障的分析报告一、故障现象：一、故障现象：近段时刻分公司反映，近段时刻分公司反映，高清互动点播业务显现马赛克现象，高清互动点播业务显现马赛克现象， 而且而且故障显现时刻无规律可循，故障显现时刻无规律可循，显现频率超级高，显现频率超级高，严峻阻碍到用户的感知严峻阻碍到用户的感知度。经现场业务观看发觉，度。经现场业务观看发觉， 标清互动点播正常，互联网宽带业务利用标清互动点播正常，互联网宽带业务利用正常，正常，网络延迟及丢包率都在正常范围，网络延迟及丢包率都在正常范围， 但高清互动点播偶然有轻微但高清互动点播偶然有轻微马赛克，用户体验度不行。马赛克

2、，用户体验度不行。二、故障分析及处置：二、故障分析及处置：由于上述两家接入网结构稍有不一样，由于上述两家接入网结构稍有不一样， 咱们针对其网络实际情形进行咱们针对其网络实际情形进行分析，并提出相应处置方法。分析，并提出相应处置方法。一、一、B B 分公司网络结构如下：分公司网络结构如下：分公司是由分公司是由 NE40ENE40E 至分前端机房接入互换机至分前端机房接入互换机 cisco3800cisco3800， 通过千通过千兆链路聚合至长光兆链路聚合至长光 OLTOLT，通过，通过 ONUONU 至广达至广达 EOCEOC，再到用户端接入机顶，再到用户端接入机顶盒。盒。这次测试进程中，这次测

3、试进程中，在分前端机房接入互换机位置进行测试，在分前端机房接入互换机位置进行测试，发觉发觉高清互动点播正常，高清互动点播正常， 经太长光经太长光 OLTOLT 后显现马赛克现象，后显现马赛克现象， 因此咱们将问因此咱们将问题锁定到题锁定到cisco3800cisco3800与长光与长光OLTOLT之间。之间。 在在ONUONU上做端口镜像进行抓包，上做端口镜像进行抓包，对抓取的报文进行码流分析，发此刻对抓取的报文进行码流分析，发此刻 ONUONU 端同意到的视频流不完整，端同意到的视频流不完整，说明在某个环节是有丢包现象：说明在某个环节是有丢包现象：（此处丢包不是整个包抛弃，针对（此处丢包不是

4、整个包抛弃，针对 pingping 的的 IGMPIGMP 协议无任何问题）协议无任何问题） ，针对丢包，初步疑心是由于集合链路或长光针对丢包，初步疑心是由于集合链路或长光 OLTOLT 在在 PONPON 口上显现口上显现丢包致使，丢包致使， 咱们将目前咱们将目前 4 4 个端口的捆绑进行分解，个端口的捆绑进行分解， 单独拿一个千兆链单独拿一个千兆链路来测试互动点播业务路来测试互动点播业务 vlanvlan，在其它业务配置维持不变的情形下，在其它业务配置维持不变的情形下，发觉点播恢复正常，发觉点播恢复正常， 抓包也无显现丢包现象，抓包也无显现丢包现象， 由此分析疑心是板卡或由此分析疑心是板卡

5、或是互换机与是互换机与 OLTOLT 互联的模块问题。互联的模块问题。 将模块及长光将模块及长光 OLTOLT 板卡进行改换后板卡进行改换后发觉仍是有丢包，发觉仍是有丢包， 排除模块及板卡关系引发的数据丢包现象。排除模块及板卡关系引发的数据丢包现象。 随后在随后在cisco3800cisco3800 到长光到长光 OLTOLT 的下连口上进行端口镜像抓包，的下连口上进行端口镜像抓包， 对抓出来的报对抓出来的报文进行码流分析。文进行码流分析。 通过在长光通过在长光 ONUONU 端口上和端口上和 cisco3800cisco3800 下连口同时进下连口同时进行抓包，行抓包， 发觉报文丢失一模一样

6、，发觉报文丢失一模一样， 确信数据包是在确信数据包是在 cisco3800cisco3800 上被抛上被抛弃，如以下图所示：弃，如以下图所示：在在 cisco3800cisco3800 端口上面查看详细情形，发觉有端口上面查看详细情形，发觉有 dropsdrops 包在不断增加，包在不断增加，如以下图：如以下图：YN_JJ_DZT_ME3800#show int gi0/1YN_JJ_DZT_ME3800#show int gi0/1Ethernet0 is administratively up, line protocol is upEthernet0 is administrativel

7、y up, line protocol is upHardware is Lance, address is 000C.9952.8180 (bia 000C.9952.8180)Hardware is Lance, address is 000C.9952.8180 (bia 000C.9952.8180)MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255Encap

8、sulation ARPA, loopback not set, keepalive set (10 sec)Encapsulation ARPA, loopback not set, keepalive set (10 sec)ARP type: ARPA, ARP Timeout 04:00:00ARP type: ARPA, ARP Timeout 04:00:00Last input 00:00:00, output 00:00:00, output hang neverLast input 00:00:00, output 00:00:00, output hang neverLas

9、t clearing of show interface counters neverLast clearing of show interface counters neverQueueing strategy: fifoQueueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, Output queue 0/40, 0 drops; input queue 0/75,389611290 drops389611290 drops 5 minute input rate 87611200 bits/sec, 2 p

10、ackets/sec 5 minute input rate 87611200 bits/sec, 2 packets/sec 5 minute output rate 546690113 bits/sec, 2 packets/sec 5 minute output rate 546690113 bits/sec, 2 packets/sec 237272 packets input, 26758701 bytes, 0 no buffer 237272 packets input, 26758701 bytes, 0 no buffer Received 221125 broadcasts

11、, 0 runts, 0 giants, 0 throttles Received 221125 broadcasts, 0 runts, 0 giants, 0 throttles 1 input errors, 0 CRC, 0 frame, 0 overrun, 1 ignored, 0 abort 1 input errors, 0 CRC, 0 frame, 0 overrun, 1 ignored, 0 abort 0 input packets with dribble condition detected 0 input packets with dribble conditi

12、on detected 254166 packets output, 33263412 bytes, 0 underruns 254166 packets output, 33263412 bytes, 0 underruns 2 output errors, 0 collisions, 5 interface resets 2 output errors, 0 collisions, 5 interface resets 0 babbles, 0 late collision, 5 deferred 0 babbles, 0 late collision, 5 deferred 2 lost

13、 carrier, 0 no carrier 2 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out 0 output buffer failures, 0 output buffers swapped out由此能够推断是由此能够推断是 cisco3800cisco3800 出端口已有丢包现象，与出端口已有丢包现象，与 ciscocisco 研发研发联系发觉是由于联系发觉是由于 cisco3800cisco3800 的千兆端口的的千兆端口的 bufferbuffer 满，致使过量的

14、包满，致使过量的包在通过该千兆端口上被抛弃超过的报文。在通过该千兆端口上被抛弃超过的报文。故障分析结论为：故障分析结论为： 由于由于 cisco3800cisco3800 互换机的端口互换机的端口 bufferbuffer 默许值为默许值为 12K12K，当数据包突发流量过大的时候，端口当数据包突发流量过大的时候，端口 bufferbuffer 容易被占满，占满以后容易被占满，占满以后端口会对多余的数据包抛弃。修改端口会对多余的数据包抛弃。修改 cisco3800cisco3800 互换机端口的互换机端口的 bufferbuffer值为值为 491520 bytes491520 bytes 以

15、后，以后，bufferbuffer 空间足够，问题取得解决。空间足够，问题取得解决。参考配置为：参考配置为：class-map match-all Dummyclass-map match-all Dummymatchqos-group 20matchqos-group 20policy-map testpolicy-map testclass Dummyclass Dummyclass class-defaultclass class-defaultqueue-limit 491520 bytesqueue-limit 491520 bytesint range gi 0/1 - 24int

16、 range gi 0/1 - 24service-policy output testservice-policy output test二、二、B B 分公司网络拓扑：分公司网络拓扑：分公司是由分前端机房聚集进入互换机华为分公司是由分前端机房聚集进入互换机华为 57105710， OLTOLT 为烽火，为烽火，OLTOLT 以下都类似锦江接入方式以下都类似锦江接入方式 （至（至 ONUONU 后通过广达后通过广达 EOCEOC 至用户机顶盒）至用户机顶盒） ，那时武侯那时武侯 NE40ENE40E 至接入至接入 57105710 是是 20G20G 链路，链路， 而而 57105710 至

17、烽火至烽火 OLTOLT 为为 10G10G链路。链路。 咱们在烽火咱们在烽火 ONUONU 进行测试分析显现马赛克现象，进行测试分析显现马赛克现象， 由于有锦江故由于有锦江故障测试分析，障测试分析， 疑心仍是由于流量太高致使端口溢出显现丢包。疑心仍是由于流量太高致使端口溢出显现丢包。 但咱们但咱们要结合测试现象分析哪个环节显现流量溢出，要结合测试现象分析哪个环节显现流量溢出， 通过量方测试发此刻烽通过量方测试发此刻烽火火 OLTOLT 的万兆上联至各千兆的万兆上联至各千兆 PONPON 口进行内部转换的时候就显现丢包。口进行内部转换的时候就显现丢包。与烽火研发联系分析发觉与烽火研发联系分析发

18、觉: :查看线卡互换芯片的包统计信息，发查看线卡互换芯片的包统计信息，发觉线卡互换芯片的觉线卡互换芯片的PONPON口上持续有因互换芯片的口上持续有因互换芯片的MMUMMU资源受限致资源受限致使的丢包统计，使的丢包统计，疑心是由于业务突发致使的丢包。疑心是由于业务突发致使的丢包。在线卡互换芯在线卡互换芯片的片的 PONPON 口抓包分析，口抓包分析， 单个节目源在某个刹时确实存在较大的突单个节目源在某个刹时确实存在较大的突发，发，具体参见以下图。具体参见以下图。若是单若是单 PONPON 下挂下挂 ONUONU 较多，较多，同时有多个用同时有多个用户观看视频，户观看视频，当多个突发同时发生时，

19、当多个突发同时发生时，确实会因为线卡互换芯片确实会因为线卡互换芯片的的 MMUMMU 竞争致使丢包。竞争致使丢包。进一步分析线卡互换芯片的进一步分析线卡互换芯片的 MMUMMU 配置，发觉包长是配置，发觉包长是 13661366 字字节时（抓包统计中最多的视频报文长度）节时（抓包统计中最多的视频报文长度） ，单个，单个 PONPON 口许诺的突口许诺的突发包数是发包数是 6565 个。考虑到线卡互换芯片的个。考虑到线卡互换芯片的 MMUMMU 资源和配置改动最资源和配置改动最少的原那么，少的原那么，将单将单 PONPON 口许诺的突发包数配置成口许诺的突发包数配置成 256256 个，个， 通

20、过修通过修改后观看发觉互动点播高清恢复正常，再也不显现马赛克现象，改后观看发觉互动点播高清恢复正常，再也不显现马赛克现象，用户的感知度取得大大的提升。用户的感知度取得大大的提升。由此能够推断由此能够推断 B B 分公司故障缘故是由于：分公司故障缘故是由于： 烽火烽火 OLTOLT 的的 PONPON 端端口线卡互换芯片的口线卡互换芯片的 MMUMMU 配置太低致使，配置太低致使， 进行适合的修改后能够恢进行适合的修改后能够恢复正常。复正常。三、总结：三、总结：通过调整后，通过调整后， 进行一段时刻的业务观看及用户报修情形来看，进行一段时刻的业务观看及用户报修情形来看，分分公司由于这两个问题引发

21、的高清互动业务故障已大体排除。公司由于这两个问题引发的高清互动业务故障已大体排除。由上两家分公司故障分析来看，由上两家分公司故障分析来看， 最全然的缘故都是由于网络中进行数最全然的缘故都是由于网络中进行数据传输时，据传输时， 突发数据流量超过设备自身的端口而设备端口缓存处置能突发数据流量超过设备自身的端口而设备端口缓存处置能力及方式方式各异，力及方式方式各异，致使数据报文的抛弃。致使数据报文的抛弃。由于咱们标清互动，由于咱们标清互动，互联互联网及专网业务都是依照网及专网业务都是依照 TCP/IPTCP/IP 协议进行传输，即便显现丢包，都能协议进行传输，即便显现丢包，都能够进行快速重传，够进行

22、快速重传， 整个业务可不能受阻碍，整个业务可不能受阻碍， 用户感知不到报文的重传，用户感知不到报文的重传，从而能有更好的业务体验。从而能有更好的业务体验。 而公司高清互动利用而公司高清互动利用 UDPUDP 报文，报文， 若是设备若是设备的端口的端口 bufferbuffer 或或 OLTOLT 的的 MMUMMU 值太低，就会显现丢包情形，可不能进值太低，就会显现丢包情形，可不能进行重传，行重传， 表现出来的现象确实是业务显现高清马赛克，表现出来的现象确实是业务显现高清马赛克，用户的体验中用户的体验中意度将直线下降。针对这些问题，意度将直线下降。针对这些问题，目前咱们从互动平台效劳器出来的流

23、量进行抓包情形如下：目前咱们从互动平台效劳器出来的流量进行抓包情形如下：3 3，针对互换机，路由器，针对互换机，路由器，OLTOLT 等数通设备进行采购及入围测试的时等数通设备进行采购及入围测试的时候必然对设备端口候必然对设备端口 bufferbuffer 及及 oltolt 的的 MMUMMU 值类似这些参数值进行严格值类似这些参数值进行严格要求及测试要求及测试 （由于前期咱们都无要求，（由于前期咱们都无要求， 此刻有些设备厂家全然就可不此刻有些设备厂家全然就可不能进行更改，能进行更改， 由于参数的更改会涉及到研发升级处置，由于参数的更改会涉及到研发升级处置， 会涉及到很多会涉及到很多资金的

24、投入）资金的投入） 。尽管咱们能通事后台命令进行相关数据增大调整，但。尽管咱们能通事后台命令进行相关数据增大调整，但咱们也不能将设备的端口咱们也不能将设备的端口 bufferbuffer 及及 oltolt 的的 MMUMMU 值无穷制放大，当修值无穷制放大，当修改的数据超过必然阈值，改的数据超过必然阈值， 在网络显现拥塞时，在网络显现拥塞时， 咱们的标清及互联网业咱们的标清及互联网业务会受阻碍，务会受阻碍，那个时候网络延迟会增加，那个时候网络延迟会增加，网络时延抖动会增加，网络时延抖动会增加，增加增加重传次数，重传次数，致使设备压力剧增，致使设备压力剧增，显现死机等更为严峻的问题。显现死机等

25、更为严峻的问题。因此目因此目前临时更改设备的端口前临时更改设备的端口 bufferbuffer 及及 oltolt 的的 MMUMMU 值也只能在规定阈值内值也只能在规定阈值内进行修改，确保能解决高清互动业务故障的同时，不阻碍标清互动、进行修改，确保能解决高清互动业务故障的同时，不阻碍标清互动、宽带等业务，无穷制修改是不可行。宽带等业务，无穷制修改是不可行。总之需做到既提升用户感知，又能尽可能将目前网络中设备的性总之需做到既提升用户感知，又能尽可能将目前网络中设备的性能最大化利用，紧缩公司建设投资。应转变“重建设，轻运维”的观能最大化利用，紧缩公司建设投资。应转变“重建设，轻运维”的观念，成立“端到端”的运维意识，增强网络优化工作随业务承载要求念，成立“端到端”的运维意识，增强网络优化工作随业务承载要求的转变而转变，需要长期持续的进行，进而不断改善用户业务体验。的转变而转变，需要长期持续的进行，进而不断改善用户业务体验。