《FTTH故障处理集锦.doc》由会员分享，可在线阅读，更多相关《FTTH故障处理集锦.doc（36页珍藏版）》请在三一办公上搜索。
1、烽火FTTH故障处理集锦1、基本数据业务故障分类查找1.1 PPPoE 拨号678 错误【问题现象】用户使用PPPoE 拨号上网，不成功。出现“678”错误。【原因分析】错误码说明：不能连接到PPPOE 接入服务器。过程为先由用户主机广播一个发起分组（PADI），之后接入集中器发送单播的给予分组（PADO ）。用户和BRAS 链路中任何一个环节有问题，都可能导致678 故障。原因主要有：1. 用户侧：a. 网络线路连接错误；b. 网卡工作不正常。包括网卡驱动问题、网卡损坏、或者网卡未插紧等;c. 拨号软件问题；2. 接入设备段：a. ONU 设备未配置数据或配置数据未下发；b. ONU 设备问
2、题；c. 对广播包的抑制；3. 上游设备：a. BAS 故障；b. 上联口上联交换设备未能透传广播包； 【解决方法】出现PPPoE 拨号“678”错误可以按照以下的方法进行排查:1. 检查用户侧网络连接情况和网卡状况。a. 网卡状况可以采用ping 同一网段的其他设备验证；b. 观察Modem 状态，可采用重启Modem 检验；c. 重新安装拨号软件或重新创建拨号连接；如果上述方法不能解决问题，可转入步骤2 。2. 查看ONU 状况。a. 查看ONU 状态灯的情况，包括检查电源状况，注册情况。如果REG 灯不亮，表明ONU 未注册，此时可以检查光功率是否达到要求。b. 检查ONU 是否得到配置
3、，如果ONU 没有得到配置，需要通过网管重新下发配置；如果配置正常，可以采用从ONU ping OLT 验证ONU 至OLT 的链路状况。3. 检查上游设备运行情况。a. 包括上联交换设备是否拦截了广播包，以及BAS 的运行情况。b. BAS 设置PPPoE 账号绑定也可能造成此错误。总结： 造成此问题的原因是从用户端到上联服务器整个链路中的某一个环节连接不通。可能造成问题的原因比较复杂，需要检查从用户至BAS 的链路，可采用抓包法进行定位。【现网案例】某FTTH 工程AN5116-02 设备下有ADSL 用户PPPoE 拨号上网出现“678”错误。现场检查话机与ADSL 猫还有电脑之间的连接
4、线路正常，没发现有松动与接触不良的现象，可以先排除是线路造成的故障。检查电脑网卡，驱动正常不显示有黄色叹号。检查网卡的运行情况，使用另外一台PC 与用户PC 直连，手动配置为同一网段IP 地址，互ping不通。确认用户网卡原因。打开机箱仔细查看网卡与主板的接口是否有接触不良或未插紧的情况，拔下网卡，重装驱动，重新创建拨号连接后，可以正常拨号。总结：此案例中，由于用户网卡接触不良使用户PC 无法连接至PPPoE 服务器，导致拨号时出现“678”错误。1.2 PPPoE 拨号691 错误【问题现象】用户使用PPPoE 拨号上网，不成功。出现“691”错误。【原因分析】错误代码说明：输入的用户名和密
5、码不对，无法建立连接。主要原因有：1. 帐号和密码输入不正确。比如“0”和“o”、“z”和“2”没有正确区分；2. 欠费。帐号被运营商停机会出现691 错误；3. 用户数限制。当一个帐号在在已登录状态时不能再使用此账户拨号。4. 绑定较验错误。运营商一般会将用户的帐号与设备端口或MAC 地址做绑定，更换位置或PC 后无法使用，会出现691 错误； 【解决方法】出现PPPoE 拨号“691”错误可以按照以下的方法进行排查：1. 首先确认是否为用户个人原因，用户名密码输入错误等与密码本身无关的行为导致拨号不成功；2. 如果仍然报告“691”错误，需要局方提供此账号的详细信息。包括是否欠费， 是否有
6、绑定，在错误发生时是否为未登录状态。总结： 认证系统对账户的限制可能会造成拨号失败，上报“691”错误。另外此问题一般与我方设备无关。【现网案例】某FTTH 工程AN5116-02 设备下有ADSL 用户反映计算机更换网卡之后PPPoE 拨号上网出现“691”错误。现场确认用户用户名密码输入正确，拨号仍然不成功。联系局方确认此账户已经做了MAC 地址绑定。用户更换网卡之后MAC 地址改变，导致拨号不成功。在局方更新绑定了所绑定的MAC 地址后，用户拨号成功。1.3 PADI 包不出上联【问题现象】用户PPPoE 拨号失败，出现“678”错误。分析发现用户发出的发起分组（PADI ）没有出上联口
7、，此时其他业务正常。【原因分析】此问题为用户主机发出的广播的发起分组（ PADI ）没有从OLT 送出。发起分组（PADI ）是广播包，有两种情况，一、整个OLT 内丢包严重，即丢包与是否为广播包无关；二、单播包基本没有丢包现象，但是有很多广播包丢失。由于此时其他业务正常，排除普遍严重丢包的可能性。广播包在PON 系统内丢失原因可能有以下两种：1. ONU 或OLT 所设置的广播包抑制的门限值过小。2. PON 系统内部有异常的广播源，发送大量广播包，导致正常的广播包被抑制。【解决方法】可能的原因及解决办法主要有以下几种：1. 检查ONU 、线卡以及上联盘的广播包抑制参数设置。适当加大门限，同
8、时抓包检查效果。2. 如果单纯改变门限值不能使问题有明显改善，可以尝试关闭所有的对广播包的抑制。在上联口处抓包，观察广播包的数量。如果发现有大量异常的广播包，基本可以断定PON 内部存在异常的广播源，一般在实际应用中，为了防止广播包泛滥，对广播包都是有限制的，例如允许广播包的数量200 个/秒，如果有主机发送大量异常广播包，就会导致正常的发起分组（PADI ）被丢弃。3. 下一步需要找到异常源，对其进行抑制，限制其上行广播包的数量。【现网案例】【现象与4.1 现网案例相同】某FTTH 工程AN5116-02 设备下有ADSL 用户PPPoE 拨号上网出现“678”错误。在按照4.1 现网案例中
9、所述方法进行处理之后，故障没有解决。下一步检查接入设备。首先是ONU 的配置情况。如果ONU 没有得到配置，通过网管重新对该ONU 下配置。如果有配置正确，检查ONU 到OLT 的联通情况。方法为从ONU ping 线卡，如果不通则需要检查ONU 到OLT 的链路；如果能通证明连接正常。下一步检查数据包是否到达上联交换设备。通过上联口镜像抓包，发现用户PC 发出的发起分组（PADI ）没有从上联盘送出。由此基本定位为发起分组（PADI ）被PON 系统丢弃。然后查找广播包被丢弃原因。首先检查OLT 和ONU 对广播包的抑制，发现所设置的抑制门限是可接受的值。之后关闭广播包的抑制功能，上联口抓到
10、大量的异常的广播报文，确定广播源之后对其做了广播包限制后，问题得到解决。1.4 上网频繁掉线【问题现象】PPPoE 拨号成功，上网中频繁掉线。【原因分析】掉线最直接的原因为主机没有及时收到对端发送的回应报文。可能由多种原因引起。主要有以下原因：1. 线路条件差，协议数据丢包造成掉线。2. PON 系统丢包致使协议包丢失。包括环回导致的丢包。3. 诸如ARP 欺骗的非线路原因导致收不到对端的协议报文导致掉线。例如ARP 伪造网关攻击。【解决方法】在确定故障现象之后，1. 如果用户线路环境较差，在不改变线路条件的情况下，可以通过取消“ 回声抑制”、对限速进行限速等功能，尽量改善线路质量。2. 另外
11、，用户线路的质量好坏对上网影响也很大，如使用了劣质的网线，网线进行了缠绕等，针对用户线路具体情况采取措施。3. 如果是PON 系统内丢包导致，检查PON 系统是否工作正常，并检查是否有内部环路。4. 在确定用户线路良好而且PON 系统无丢包的情况下，需要排查是否存在类似ARP 攻击的问题。这种情况一般出现在多用户使用路由器拨号共享上网的情况下。【现网案例】某工程用户反映总是PPPoE 连接掉线，最多一天5，6 次，有时几天都不出现。整个北京其他使用的EPON 上网的用户没有反映掉线问题，此台EPON 系统下的只有此用户反映掉线问题。在楼道的ONU 机房内，换过此用户的ONU 端口，换过不同的0
12、7ONU ，用户还是反映掉线问题。在ONU 端口处抓包找到掉线的原因。正常流程为上层华为BRAS 定时发送ppp lcp reques 心跳包，下层用户PC 回复ppp lcp reply，而在ONU 端口通过接HUB 抓包，发现上层华为BRAS 在多次发送ppp lcp request 心跳包，并长时间未收到相应包后，华为BRAS 会发起ppp lcp termination request 心跳终止包，接着发起PPPOE PADT 拆线命令，用户PPPOE 拨号掉线，就此基本可以判定用户掉线与07 ONU 和OLT 设备无关。分析可能是网线的原因或者用户PC 的原因。建议用户：1、升级配置
13、。使CPU 负荷正常，能正常处理PPPOE 协议。2、使用路由器。用路由器能完成PPPOE 拨号，不会因PC 性能原因导致掉线。1.5 上网下载速度慢【问题现象】 上网、下载速度慢。【原因分析】能够导致上网、下载速度慢的可能原因有很多，下面列举几种典型的原因：1. 用户线路质量差。2. 网络环路导致了网络性能的下降。3. 设备某端口进行了限速，导致了数据流量的瓶颈。4. 网络受到攻击，如ARP 攻击。例如ARP 扫描，网络中出现大量ARP 请求广播包， 几乎都是对网段内的所有主机进行扫描。大量的ARP 请求广播可能会占用网络带宽资源，会影响用户上网浏览网页、下载速度，甚至会出现丢包的现象。【解
14、决方法】首先检查用户线路是否连接良好，如无连接问题可查看设备配置是否启用了限速导致了数据量的瓶颈，如有则将限速放开；上述两种措施不能解决时可通过抓包观察系统内部是否存在异常包或环路情况。【现网案例】某工程用户反映浏览网页慢，玩在线游戏的时延大下载速度慢，2M 账号下载速度只有20KB/s 、10KB/s 。在上联口做镜像进行抓包，发现有大量的ARP 包，由于烽火设备默认出厂主控盘的广播包抑制为150 包/秒，而这里抓到的ARP 包数量在以140 包/秒150 包/秒之间的速度在快速增长，因此不排除实际的ARP 广播包增长的速度会快很多，(-) 通过在设备内部MAC 地址表学习中，发现这些ARP
15、 包的大部分来源于上行设备下发的广播包及少部分下行设备发送的上行广播包。由于EPON 内部对于收到的上下行广播包抑制到150 包/秒，此时， 系统内部的大量地广播包可能会造成正常用户PPPOE 发出的广播包也会被抑制掉，近而会出现偶尔无法正常拨号及上网速度慢的现象。初步解决方案为对上游的广播包进行控制。找出大量发ARP 广播包的源MAC 地址，然后在烽火OLT 设备上启用Q0S 机制，原理是只要烽火OLT 设备收到了带有非法源MAC 的下行ARP 广播包都一律在GSWC 盘上采取丢弃处理，从而可以减少对下行设备用户造成的影响。但是这种过滤需要提供源MAC 地址，在源MAC 很多且不确定的情况下
16、就不能方便的使用了。1.6 DHCP 认证用户主机无法获取IP 【问题现象】DHCP 用户无法获得IP 地址。【原因分析】DHCP 在IP 地址分配过程中主要有四个阶段：发现阶段、提供阶段、选择阶段和确认阶段。任何阶段出现问题都会导致主机无法获取到IP 地址。可能原因主要有以下几种：1. 网络故障，无法连接到DHCP 服务器。2. DHCP 服务器关闭或无可用IP 地址。3. 用户计算机网卡损坏。4. 其他。例如网络中存在异常攻击者。【解决方法】首先应该确定故障发生的范围，DHCP 服务器下，个别用户还是很多用户无法获得IP 地址。如果是个别用户有此问题，基本可以确定DHCP 服务器的运行状态
17、正常，OLT 以上至DHCP 服务器链路正常。需要检查包括用户PC、ONU 业务配置、广播包抑制等设置是否正常。在检测DHCP 服务器连通性时，可以手工配个IP 地址，再ping DHCP 服务器，如果可以ping 通，改回自动获取ip 的模式，在本机运行arpd 清除缓存。如果出现很多用户无法获得IP 地址，或者获取过程缓( -) 慢，需要检查DHCP 服务器， 以及OLT 上联口和DHCP 服务器之间的路由器的设置。【现网案例】某工程使用DHCP 方式分配IP 地址，有用户反映计算机自动获取不到IP 地址。同OLT 下没有其他用户上报此问题。由于此OLT 下其他用户没有此问题，所以可以确定
18、DHCP 服务器运行正常，上联至DHCP 服务器链路正常，OLT 广播包抑制正常。排查重点主要在用户侧，以及我们PON 系统的端口级配置。到达现场后，用户描述突然出现这种情况，之前的操作已经记不清楚。检查用户计算机设置时，发现用户计算机“DHCP Client”处于为禁用状态。启动此服务后，能够正常获得IP 地址，故障得到解决。 1.7 IP 地址冲突【问题现象】使用PPPoE 拨号成功，系统提示“IP 地址冲突” 。【原因分析】1. DHCP 服务器在进行IP 地址的分配时，会先确认所分配的IP 地址没有被网络上其他设备所使用。DHCP 服务器通过发送ICMP Echo Request （P
19、ing ）报文对分配的IP 进行探测，如果在规定的时间内没有收到应答，则再次进行探测，达到规定的次数后，仍然没有收到回应，则将此IP 分配给提出申请的主机。如果检测到冲突，则记录IP 冲突，重新分配IP。因此，在正常情况下，即使有多个DHCP 服务器，也不会产生IP 冲突，然而如果网络中存在伪造的和非法的DHCP 服务器为主机分配IP 地址，就会产生IP 地址冲突的情况。【解决方法】通过抓包确定非法DHCP 服务的MAC 地址，抑制非法DHCP 服务器提供的IP 分配， 如在OLT 上开启DHCP Snooying 功能，防止用户从非法或伪造的DHCP 服务器上获得错误的IP 地址。【现网案例
20、】某工程有用户反映PC 提示系统与网络IP 地址冲突。现场抓包发现大量OLT 下行广播包，尤其IP 地址：192.168.18.1 及MAC 地址：00:33:44:5e:69:50 和IP 地址：192.168.1.1 及MAC 地址：00:33:44:66:9b:35 提供不明DHCP 服务造成用户IP 冲突。抓包情况如下图： 由于网络使用PPPoE 认证方式。从上面的抓包可以看到，网络中存在异常的DHCP 服务提供者，为主机分配IP 地址。导致网络出现IP 地址冲突。解决方案为开启OLT 的DHCP Snooping 功能，可完成OLT 对假冒DHCP Server 的屏蔽作用，确保客户
21、端从合法的DHCP Server 获取IP 地址。1.8 PPPoE 拨号成功，但不能上网【问题现象】用户使用PPPoE 方式拨号上网，拨号成功，但不能上网。【原因分析】一般情况下，PPPoE 拨号成功之后，PPPoE 服务器会分配IP 地址、网关、DNS 等设置。而正常的上网过程包括：url 通过DNS 解析为IP 地址，用户通过网关与目标主机通信。可能的原因有：1.DNS 服务器设置错误；2.DNS 服务器故障；3.用户防火墙设置错误；4.用户浏览器设置错误；例如代理服务器设置。【解决方法】定位方法如下：1. 首先确认用户设置无误，例如有无代理设置，防火墙设置等。2. 查看用户IP 配置的
22、获得情况，包含IP 地址、掩码、网关、DNS 服务器等。3. 确认正确获得之后，验证是否能够正常获得DNS 服务器；具体方法为使用ping 命令ping DNS 服务器，a. 如果不通，则需检查DNS 服务器的连接情况，同时可以ping 某个外网IP ，例如 的IP 地址，以验证为DNS 服务器故障。如果能通，则基本可以断定是DNS 服务的故障。如果不通，则需检查上游BAS 至INTERNET 的连接情况。b. 如果正常能通，这时再尝试ping 某个外网服务器的IP，如果能通，继续ping 此IP 所对应的URL( 例如) ，如果不通，则可断定原因是DNS 服务器不能提供域名解析服务导致不能上
23、网，这时需检查是否DNS 服务器出现故障。定位问题之后，之后进行针对性的解决。如果是有用户错误设置引起，应对用户的设置进行更正；如果是DNS 服务器或是PPPoE 服务器问题，可以向局方提供证据，协助解决。【现网案例】某工程突发大量用户反映拨号成功但是网页打不开。由于此故障涉及大量用户，基本可以断定与用户端设置无关。到达现场，确认PPPoE 拨号完成后IP 地址的获得情况正常。网关可以ping 通。之后ping DNS 服务器，偶尔可以ping 通，但丢包延时很大。抛开DNS 服务器后，直接ping 某知名网站的IP 地址，发现延时正常，无丢包。至此，基本确定原因为DNS 服务器故障。后局方确
24、认，DNS 短时间内收到大量的地址解析请求，导致DNS 瘫痪。DNS 服务器恢复之后，用户均可正常上网。1.9 高峰期浏览网页慢【问题现象】高峰期网页打开速度慢。【原因分析】高峰期网页打开速度慢，高峰期相对于平常时段流量更大，可能的原因有：1. OLT 上下行总带宽不足。平常时段网速较快，高峰时段总带宽不足产生瓶颈，导致浏览网页慢。2. 用户量过多，超过设备处理能力。单PON 口总上下行流量有限，在用户过多的情况下，会导致用户数据被丢弃。【解决方法】在遇到此类问题是，要确定用户的数量，高峰时段流量情况、上游带宽的分配情况。解决方法有：1 如果高峰时段的上下行流量已经接近或达到设备处理极限，则出
25、现浏览网页慢是正常的情况。此时的解决方法是增加设备数量，对用户进行分流。2 增加上游设备的处理能力。【现网案例】某工程通过试点后大规模应用时，用户反映有些时段上网速度慢。用户反映的时段多为晚上710 点，也就是上网的高峰时段。在试点阶段总带宽分配比较少，当时ONU 数量比较少，(-) 基本可满足试点要求，不存在速度慢的情况。但大规模应用以后，ONU 数量剧增，用户数量也大量增加，而局端并未对总带宽做出调整，所以总带宽不足，造成上网速度慢。2、基本组播业务故障分类查找2.1 图像卡和马赛克【问题现象】在使用IPTV 业务观看电视节目时，会出现图像卡和马赛克现象【IPTV 常见组网模式】 【原因分
26、析】使用IPTV 业务观看电视节目时，出现卡或是马赛克的现象，可以断定物理通路是好的，而之所以会出现此类情况，多由丢包和组播流的反复通断引起，结合上图和组播机制，可能原因有如下几个方面： （1）首先确定是否为组播源的问题（2）用户电视机与机顶盒的线路连接不良，致使外界干扰造成视频传输线中信号的畸变（3） ONU 的接收光功率不在正常范围内，光功率不稳造成数据丢包（4） 由于速率限制，造成带宽瓶颈，导致数据有丢包（5） 电视机顶盒对查询包的响应速率慢，导致上层设备进行了地址老化（6） 链路中各设备之间的配置配合问题导致组地址的反复建立和老化（7） 启用组播Proxy 或Snooping 的设备上
27、，存在查询包数目限制，导致了对某些查询包的丢弃【解决方法】（1） 查看用户线路连接是否正常，如有线路裸漏，提醒用户更换好的视频线（2） 如遇EPON 设备工作环境恶劣，造成光功率不达标或ONU 工作不稳定，进行环境的改善或更换ONU （3） 更改限速配置，消除带宽瓶颈（4） 进行抓包分析，查看是否有配置或设备性能导致的地址频繁老化，然后根据分析结果采取相应措施【现网案例一】某地有用户反应，使用IPTV 业务观看电视节目时有卡的现象，卡的程度分为以下三种： 1）大量用户出现马赛克，花屏现象，但是可以跳过去。2）出现马赛克后频道卡死，通过换台或者是重启机顶盒才能恢复。3）部分用户出现卡和马赛克现象
28、现象一到达现场后发现ONU 工作环境非常恶劣，ONU 和光路被尘土覆盖，测量光功率后发现严重不足，接近ONU 的工作临界值解决方法：对现场进行清理，现象消除现象二原因同现象一，ONU 工作环境极度恶劣，造成了严重的丢包，对现场进行清理后问题得到解决现象三对EPON 设备工作环境进行改善后依然存在此现象，通过在ONU 和机顶盒之间抓包分析发现，在电视节目卡的时候，会抓到大量来自上游设备的查询包，并带有一个5 秒的响应时间，而电视机顶盒的回查询时间不稳定，在4s 到9s 之间，上游设备在等待超时后会将组地址老化掉，下行的组播流不能到达电视机顶盒，随后机顶盒的响应报文到达上游设备， 执行加入组播组操
29、作，流又可以到达电视机顶盒，所以出现了卡的现象。解决方法：建议将上游设备查询包的回复时间由5s 修改为10s，并且将查询次数由一次改为多次，只有多次查询特定组没有收到应答帧，才将地址老化，至此问题解决。并建议机顶盒厂商能查找对查询包回复偏慢的原因，保证在上游设备规定的时间内进行查询包的应答。【现网案例二】某工程中系统组播模式为侦听模式下，在开通04、05A 、05ONU 组播业务时，会出现画面反复中断到恢复的问题，影响用户的正常使用。观察业务中断的时刻，在ONU 本地的组播组地址也同时被删除。结合ONU 处的抓包，并没发现有离开报文或者查询无应答的情况，通过ONU PON 口的性能统计来看，业
30、务中断时， ONU PON 口有很大组播包的计数，在EC2 前面板配置组播VLAN，把机顶盒接入EC2 前面板ETH 口，观察业务正常。确认问题和线卡无关，验证了问题的确出在ONU 处。从EC2 前面板捕获的报文来看，业务中断时刻并无带有异常的报文发往ONU，从正常到中断时刻捕获发到05A GE 口的报文中，可以发现问题原因： 上图中 10.21.128.1 为组播服务器发来的通用组查询，然后机顶盒 10.21.129.248 应答了组播组地址 224.0.54.181 。此时业务正常。接下来到了第63s： 在业务中断前约 10s 的位置，ONU 又收到了 192.168.50.103 发来的
31、通用组查询报文， 最大应答时间限制为10s，而且带的VLAN 为60，而我们 ONU 组播 VLAN 为 102，这样的查询报文透传到05A 的端口，机顶盒根本无法应答，ONU 在 10s 后会把所有组地址从本地删除， 导致业务中断。中断后，又因会继续收到正确的查询报文使业务恢复，直到下次再中断，如此反复。解决方法： 由于系统采用代理模式时，主控盘会忽略组播VLAN 不正确的组播查询，因此配置系统为代理模式也可规避此问题。但建议先解决异常查询的问题，把网络上异常的查询去掉。2.2 切换频道图像黑屏【问题现象】在进行频道切换后出现短暂的黑屏现象，使用户不能正常享用IPTV 业务。【原因分析】导致
32、频道切换后出现黑屏现象的原因很多，但是总结起来无非是由于各种原因电视机短时间内没有收到节目信号导致。有以下几种情况可能会导致切换频道后电视机不能收到节目信号：1、电视机本身问题，切换频道时间间隔较大。2、切换频道操作伴随着离开报文和加入报文的发送，由于网络延时导致加入报文不能及时到达上游的组播路由器，用户不能立即加入相应的组播组，电视机也就不能及时收到IPTV 服务器下行的节目流。3、电视机顶盒的响应速度慢，不能及时响应用户切换频道的操作，或者机顶盒的某些设置导致切换频道间隙大出现短暂黑屏现象。4、 由于网络堵塞，切换频道后组播流下行出现丢包。【解决方法】1、对电视机进行相应设置，或更换电视机
33、。2、查看网络设备中是否启用了限速设置，使网络出现瓶颈导致加入报文的延时。3、联系电视机顶盒厂商，询问机顶盒配置和性能情况，对机顶盒进行升级或更换。4、对网络情况进行检查，是否存在环路、限速、网络高峰期等引起的网络堵塞，根据具体情况进行相应的处理。2.3 观看时突然信号中断【问题现象】用户在使用IPTV 业务观看电视节目时，会每隔一段时间发生电视信号中断，切换频道后才能恢复正常，过一段时间后又会中断【原因分析】问题现象可以反复重现，我们可以确定整个网络的物理通路是好的，从现象的描述我们可以看出，只要切换频道中断现象就可以解决，结合组播机制，说明只要有新的加入报文发向上游设备，组播流就可以继续下
34、发，由此，我们可以猜测是网络通路中某个设备对上游设备的查询包响应超时，导致上游设备的组播地址老化，使节目发生中断，在新的加入报文到达上游设备时，组地址重新建立，节目恢复。【解决方法】采用分段法，在网络链路的各个以太网口处进行抓包分析，确定不能回查询包的原因。【现网案例一】某IPTV 工程中，用户反应在看IPTV 一段时间后，节目中断，切换频道后恢复正常，过一段时间再次中断，用户无法稳定的观看同一个节目。对问题进行抓包分析，分别在如下位置进行抓包：网络交换机的镜像口，我方设备上联口，IPTV 设备以太网口。从我们的抓包结果来看，上联设备发送了大量组播查询报文，使我们DSLAM 回查询的时间很没有
35、规律，甚至出现很长时间不回查询的情况，根据我们的测试，上层设备组播老化时间在170sec 左右（根据最后一次DSLAM 回应的join 时间和业务流中断的时间判断），如果我们的DSLAM 在这段时间间隔内，不能回应查询报文，无疑就会出现组播业务中断的情况。切换频道后，我们的DSLAM 向上游重新发送join 报文， 组播流再次下发，业务恢复。解决方法：对我们的DSLAM 设备进行软件代码修改，加强对大量查询报文的处理能力，问题得到解决【现网案例二】某IPTV 工程上，近期有客户反映在观看直播节目约3 分钟左右，画面定格并随后提示信号中断。通过在 07ONU 的 FE 口和机顶盒之间抓包分析，我
36、们发现 BAS（IP 为 16.16.16.16） 下发了的组播通用组(224.0.0.1) 查询，而机顶盒（IP 为 121.226.10.40）没有给组播通用组查询回IGMP Report 报文，所以直播节目业务中断。07ONU 的 FE 口和机顶盒间抓包截图如下：机顶盒通过发送IGMP Membership reports，申请加入一个组239.252.153.75，BAS 周期性发出 IGMP membership query ，检查是否有组员存在，如果在3 次查询时间间隔里没有收到回复，则BAS 宣布这个子网没有组员。通过在07ONU 的FE 口和机顶盒之间进行抓包分析，我们可以看出
37、IGMP Membership Query 查询间隔约为 1 分钟，3 次就是3 分钟， 由于机顶盒没有回组播通用组查询 224.0.0.1，在3 次组播通用组查询结束后 BAS 自动将组删除，所以用户在观看直播节目约 3 分钟左右，画面定格并随后提示信号中断。通过与客户工程师沟通，我们确认用户宽带 IPTV 接入方式是 PPPOE 方式，采用 PPPoE 方式的情况下，需要对数据包进行 PPPOE 封装。通过 07ONU 的FE 口和机顶盒之间抓包分析，我们可以看出BAS（IP 为 16.16.16.16）下发的组播通用组(224.0.0.1) 查询报文并没有进行 PPPoE 封装。由于机顶
38、盒和服务器的宽带接入方式不同，组播通用组查询报文没有进行 PPPoE 封装，机顶盒IP 为121.226.10.40 没有回组播通用组查询 224.0.0.1，所以用户在观看直播节目约3 分钟左右，画面定格并随后提示信号中断。如下图所示，组播通用组查询报文没有进行PPPOE 封装： 通过以上分析，我们可以定位华为BAS （MA5200 ）没有对IGMP 包进行PPPOE 封装。解决办法：对华为BAS 进行重新配置后，华为BAS 对IGMP 报文进行PPPOE 封装2.4 不能切换频道【问题现象】电视机和机顶盒上电后，机顶盒拨号成功并获得播放列表，选择一个频道进行观看，然后进行频道切换时不成功，
39、即用户只能观看一个频道。【原因分析】机顶盒获得的播放列表中，每一个直播频道对应一个组播地址，当进行频道切换时，对应机顶盒进行离开报文和加入报文的发送，即机顶盒发送离开当前组和加入目标组的报文， 对现象描述进行分析我们可以知道，机顶盒可以加入一个组，就说明加入报文是可以到达上游设备，获得组播流的，也就说明从机顶盒到IPTV 服务器的通路是好的，而之所以不能切换频道，是由于某种原因导致上游设备没有收到机顶盒符合规则的离开报文、新的加入报文或者新的加入报文无效，如下几种情况可能导致该现象： 1、机顶盒自身问题导致，如机顶盒不能响应用户切换频道的操作，可以通过更换机顶盒的方式验证。2、机顶盒获得的节目
40、菜单中，可能会有部分无效的链接，进行频道切换时无法连接到新的节目源。3、机顶盒上游设备不能响应机顶盒的离开报文。4、网络中交换机受到了恶意的MAC 地址欺骗，导致离开和加入报文没有经过正确的途径进行处理，而是发送到了交换机错误的端口，使报文被丢弃。【解决方法】针对上述几个原因，可以采取如下措施： 1、联系机顶盒厂商进行机顶盒的升级，使其得到改善，或者更换新的机顶盒。2、与局方沟通，对节目菜单进行修整。3、采用抓包分析法，确定为何种原因导致的设备不能响应机顶盒的离开报文。4、使用抓包工具确定被受攻击处，然后采取端口绑定、设置端口MAC 地址学习优先级等方式防止MAC 地址欺骗。2.5 无图像【问
41、题现象】机顶盒上电并拨号成功后，获得IPTV 服务器下发的节目菜单，但是不能打开电视节目，即用户不能观看节目。【原因分析】一般情况下，IPTV 的认证平台和媒体提供平台是分开的，如果用户不能正常收看电视节目，说明机顶盒到IPTV 媒体平台的信令和数据通路有问题，导致上下行信令流不能到达媒体平台和终端机顶盒；或信令格式有问题，使得终端机顶盒不能识别平台下发的报文，平台也不能识别终端机顶盒发送的加入离开报文，在此有几种可能会导致以上情况的发生，即物理连接问题导致的通路不通，配置问题导致的信令和组播流的不通，配置问题导致的信令不能正确识别。具体到配置，有可能有以下几种情况： 1、VLAN 配置不正确
42、，导致信令和数据流在平台和终端机顶盒之间不通。2、中间某设备启用了组播抑制功能，组播流不能通过该设备。3、从机顶盒到平台的链路中可能存在不支持组播的设备，如交换机、路由器等。4、可能由于使用的是PPPOE 拨号方式，而因平台没有进行相关配置，不能识别PPPOE 封装的加入报文等。【解决方法】首先采用替换法，更换一个新的机顶盒，如果仍然存在问题，则采用分段抓包法进行分析，查看通路是否完好，或者是哪一段存在问题，并根据抓包结果判断是物理连接问题还是配置问题。如果是物理连接问题，对线路进行重新连接即可；如果是配置问题，则要对抓包结果进一步分析，确定为原因分析中的哪种情况，然后根据具体情况进行相应配置
43、的更改。2.6 无视频播放菜单【问题现象】电视机和机顶盒上电，并用机顶盒成功拨号后不能显示播放菜单【原因分析】机顶盒的工作流程为：机顶盒上电后用客户申请的账号和密码进行拨号，在IPTV 认证服务器上通过认证后会向机顶盒下发节目菜单。由其工作流程可知，如下情况会导致不能显示节目菜单： 1、IPTV 服务器没有下发节目菜单。2、机顶盒自身问题导致，可通过更换电视机顶盒进行确认。3、由于网络配置原因导致下行流不通，电视机顶盒没有收到服务器下发的节目菜单。4、设备配置原因使电视机顶盒不能识别下行流，比如机顶盒接收到的是带有VLAN 标志的流，而机顶盒对此不能识别；上游服务器可能下发了错误封装的数据包，
44、导致机顶盒不能正确识别，等等。在机顶盒和上游设备之间进行抓包分析可以得出具体结论。【解决方法】1、联系客户进行服务器的配置检查，解决不能下发节目菜单的问题。2、联系机顶盒厂商进行机顶盒升级或更换机顶盒。3、采用分段法进行故障定位，确定故障点，根据具体情况进行相应设备配置的更改或设备的更换，解决下行通的问题。4、根据抓包分析结果更改设备相应配置，如改变下行流为untag 方式；改变下行流的封装格式，保证机顶盒收到的为可以识别的数据流。3、基本语音业务故障分类查找3.1 网关未注册上软交换【问题现象】摘机没有拨号音，查看网关状态为未注册上或者正在注册中。【原因分析】EPON 系统中，ONU 同时担
45、任信令网关(MG) 的角色。在进行业务开通时，首先要向软交换平台注册。网关注册失败主要由以下3 种原因导致： 1.VLAN ID 配置不正确：VLAN ID 配置信息不正确使得ONU 和软交换平台之间无法正常的通信，从而导致网关注册失败。2.MG 的IP 配置重复：在软交换系统中，每个MG 都应该有唯一的IP 地址，当两个或者两个以上MG 配置相同的IP 地址的时候，将导致MG 网关注册失败。3.MID 配置错误：在软交换系统之，用MID 来标识网关。MG 上配置的网关MID 必须与平台的配置一致，否则当MG 向软交换平台注册时，软交换平台会认为是非法的网关，从而导网关注册失败。【解决方法】出
46、现网关注册失败的故障按照以下的方法进行排查: 1. 检查ONU 与软交换平台之间网络连接是否正常。从ONU 中ping 软交换的IP，如果ping 不通，请检查VLAN ID 的配置信息和MG 的IP 配置信息是否正确。2. 检查ONU 是否从网管得到H248 配置及相关配置是否正确如果MG 能够正常ping 通软交换平台，而网关注册失败，请检查MG ip 和MID 配置是否正确，是否与软交换平台上配置的MG 信息相匹配。【现网案例】某FTTH 工程AN5116-02 设备在一个PON 口下发现IP 网关名称为10.32.160.2 的ONU 语音不通，在该PON 口下更换为另一个IP 网关名称为10.32.160.252 的IAD 软交换语音用户通话正常。测试中发现软交换平台（10.0.55.2）在审计10.32.160.2 时，IAD 回430 Unknown TerminationID，更换为另一个测试IP 10.32.160.252 后正常，用户通话也正常，通过对包的分析发现在配置原10.32.160.2 IP 时网关名称10.32.160.2 后多敲了字符空格键，删除网关名称10.32.160.2 后的字符空格键后经过验证解决, IP 网关名称
