FTTx故障案例
--------2011年8月刊
2011年8月
烽火通信科技股份有限公司
客服中心技术服务部
目录
设备类 (3)
一、AN5516-01OLT下挂用户网速慢分析处理报告 (3)
二、AN5516-01OLT GC4B板出现窗口飘移告警故障 (7)
三、IPTV卡故障定位 (9)
四、AN5516OLT重启恢复后20ONU依旧托管故障案例 (12)
五、20ONU业务中断故障案例 (13)
六、AN5006-20型ONU宽带用户频繁出现PPPoE拨号691问题 (14)
七、EPON-OLT下挂中兴AP业务不稳定问题 (17)
八、EPON-AN5006-07-ONU下挂机顶盒使用DHCP方式认证无法成功的案例 (20)
九、华为SBC2200版本缺陷造成H.248协议ONU语音故障 (24)
网管技术类 (26)
一、ANM2000不能通过CMD进行命令行操作故障处理 (26)
设备类
一、AN5516-01OLT下挂用户网速慢分析处理报告
【现象描述】
某FTTX工程AN5516-01OLT下挂宽带用户反应网速比较慢，4M宽带用户的下载速度为350K左右。
【处理过程】
首先核对了数据配置，发现数据配置正常。然后，检查OLT和ONU的版本，发现OLT版本都是最新的，有部分ONU的版本需要更新，将这部分ONU做了升级，升级之后问题未见解决。随后检查设备的光路，发现光路正常。之后只在OLT上联盘上做一个透传的VLAN，在该端口下用网线接到电脑上拨号进行测试，发现测试网速为350k左右，如下图：
该测试初步说明从上层到上联盘的网速就是350k左右，为了进一步确定问题，随后了测试整个EPON系统，在上联盘的3号端口做一个透传的VLAN，在该端口下用网线连到笔记本电脑上，用该台电脑做为OLT上联服务器使用（相当于上层base），之后在ONU下接电脑进行测速，发现速度正常，如下图（分别为ONU限速在100M、4M、2M和8M时候的情况）：
该测试进一步说明整个EPON系统不存在问题；因此针对该情况，从仓库运了一台全新的OLT 安装到机房，并将数据联调通畅，进行测试，测试结果同以前一样，如下图：
随后，重新在原来的OLT下进行测试，发现在下载点测试的下载速度可以达到450K左右，如下图：
该情况进一步说明了该故障与EPON系统没有关系，如果EPON存在问题，那么所有的站点的下载速度肯定都存在问题，而不是现在的有部分站点下载速度正常的情况；之后，直接将电脑连到bas口进行拨号测试，测试发现在bas口的速度就是300多k左右，如下图：
该测试说明网速慢的故障不是EPON系统引起；后经过咨询中兴bas的技术支持，得知bas上需要配qos参数，将该参数配置完毕之后，再在bas口进行测试，发现速度恢复正常，如下图：
之后在EPON的ONU下进行测速，发现速度也恢复了正常，如下图：
至此，该故障已经处理完毕。
【故障分析】
此次故障并不是EPON系统引起的，而是由于bas数据（qos参数）的配置问题引起的，目前，技术人员将bas的数据做了调整之后，该故障已经得到了解决。
二、AN5516-01OLT GC4B板出现窗口飘移告警故障
【网络拓扑】
【现象描述】
某运营商一台AN5516-01OLT下挂多台AN5006-20ONU，网管上反复出现“窗口漂移”告警，如下图：
【处理过程】
由于此告警从来都没有见过，初步怀疑是GC4B盘CPLD固件太低造成，通过命令行Config\gpon# show link0config进行查看PON板CPLD版本，如下图：
从图中可以看出，第36行值为1，表明CPLD版本已升级为最新版本。
通过查询设备告警库，有此告警的定义，但无此告警的详细说明和解决方法，如下图：
经过排查，此告警应该是光路小误码引起，对业务应该没有影响，怀疑是光功率不正常，需要对光路进行检查。
到现场进行光路检查后，发现光功率正常，对PON口和光纤头进行清洁后，故障消失。
【故障分析】
此告警的产生主要是由于光路光功率引起光路上有误码，短时间不会对业务造成影响，但长时间不处理的话会对PON口造成损伤，对业务的稳定产生隐患，一般通过调整光路和清洁PON口及光纤头可以解决。
三、IPTV卡故障定位
【网络拓朴】
【现象描述】
某局将一个酒店IPTV与数据业务割接到AN5516-01型OLT上后，IPTV业务在晚上总是出现卡屏等故障。
【处理过程】
首先检查主控盘包抑制，将多播包改为不抑制，将广播包与未知包改为3000，在更改EC4B每个PON 口的包抑制。
更改后，故障有明显改善，但是还是存在卡画面的情况。
通过抓包工具对故障位置进行定位，在上联口与ONU端口分别做好镜像，在晚上用户出现卡屏故障时同时进行抓包。使用机顶盒MAC地址进行过滤后，
如下图进行分析：
在抓的UDP包右键选择Decode as
如图选择RTP点OK，将UDP包转换为RTP包。
如图，分别查看上联口与ONU端口丢包率是否一致，经查看上联口与ONU端口丢包率一致，确定到达OLT上联口包已经存在丢包，汇报当地局方进行处理。
后将用户IPTV带宽有3M增加到6M后，基本没有出现IPTV卡故障。
【处理结果】
前期由于OLT设备默认包抑制导致用户IPTV很卡，通过抓包分析上联BAS也存在丢包。
四、AN5516OLT重启恢复后20ONU依旧托管故障案例
【现象描述】
工程上出现重启OLT后，AN5006-20ONU设备脱管，脱管10几分钟到32分钟后又自动恢复。【处理过程】
查看20脱管时的现象，从网管计算机一直ping20设备，发现如下几个现象：
1、不通时，EC4B线卡的上联口（线卡switch目录下show56302_mac_portbase10）学习不到针对20管理vlan的网关mac地址；但是OLT主控盘的上联口19:2可以学习到，由于OLT主控盘和20采用相同的管理vlan并且是同一个网关，因此不能确定OLT上联口学习到的源地址对应的包是发给OLT 主控盘的还是发给20设备的。
2、不通时，通过私网网段telnet到20设备，再从20设备发起ping网关的操作，现象立即消失，下行从网管计算机也能ping通了，网管也可以正常管理20设备了。
3、不通时，取消OLT上联端口19:2~19:5的广播包和未知包抑制，仍然不通。
4、因此，需要抓包确定下行本应到达20设备的报文是丢在了OLT主控盘上还是丢在OLT之上（即上游设备），如果没有抓到20设备的包，则说明此时下行的报文丢在了上游设备上，否则丢在OLT的主控盘上。
5、通过抓包分析如下：
其中，
网管计算机的IP地址为135.255.153.2，
20设备的IP地址为135.255.165.4，
OLT主控盘的IP地址为135.255.165.2，
网关地址为135.255.165.1
从抓包来看，在正常情况下，网管计算机与20设备之间可以ping通，因此上游路由器设备（华为NE80E）应该缓存有20设备的arp表项，路由器不必向20设备发送arp请求。
OLT重启后，下行方向上一直没有从网关到20设备的报文下来，无论是ping包还是arp包，一直等待20向上发送了请求网关的arp网关（950#包）并且网关应答后，网管计算机相应的包才下发到OLT 上联口，至此，20设备才恢复正常。
6、修改华为网关设备，让其主动发起ARP请求，20ONU管理业务恢复正常
【故障分析】
华为网关设备与OLT 相连的接口在down 下去时清空了arp 表项，并且华为的网关设备也不主动发起arp 请求，只等待被动响应arp 请求。
目前20设备通常有主动向上发起的报文，这些报文主要是校时请求报文和告警trap 报文，校时请求默认是1个小时发一次，告警等trap 报文则根据实际情况发送，这些报文能够发送的前提条件是需要配置或者学习到正确的trap 接收地址。当需要发起这些报文时还应确认20设备相应的arp 表项是否存在，如果存在则向网关请求arp，网关响应该请求后网管计算机就可以通了，因此这个时间可能比较长，arp 老化的时间是20分钟，而20设备发包的时间并不确定。
另外，OLT 重启后为什么不会管理不通？
由于OLT 设备存在主备倒换的功能，OLT 重启后会主动周期性的向网关发送arp 请求报文，网关很快学习到OLT 的arp 表项，所以OLT 不存在这个问题。
五、20ONU 业务中断故障案例
【网络拓朴
】
S O D r o 10未知设备1
未知【现象描述】
据工程现场反映，烽火OLT 下挂20ONU 业务无故中断，ONU 无法获取到EC2分配的私有IP 地址，且EC2命令行不停打印3721busy 消息。
一般情况下，有以下几种情况会导致EC2打印3721busy ，且下挂业务全部中断：
1）3721芯片挂死
中断现象特点：同PON 下所有ONU 无法正常注册，不停上报link loss 告警或者ONU 收无光。排查方法：该类故障，需要在ONU 端测试收光功率是否正常，以及通过EC2命令行读取相关PON 芯片信息，例如版本、芯片CRC 统计等信息。
依次在ONU 端测试收光为-9dBm 左右，属于正常值范围。后续通过EC2命令行查看PON 芯片的工作状态，响应做了读取PON 芯片版本信息，以及统计光路中CRC 误码信息，发现版本读取正常，但
光路中有大量的CRC错误产生，从上述现象基本可判断PON芯片并为挂死，而是由于大量信息无法处理而处于繁忙状态；
2）ONU长发光，占用其他ONU的时隙通道，导致PON下所有ONU掉注册，无法获取私有IP 地址，且PON芯片工作出现异常。
中断现象特点：PON下所有ONU掉注册，业务中断。
排查方法：将PON口下挂所有ONU光纤断开，再逐一测试ONU上行光功率是存在长发光。
故障出现在ONU入网运行3个月左右，且在所在PON口仅有这一个ONU，通过上述的排查，排除了PON芯片挂死问题。遂后对光路展开了排查，在排查中发现该ONU所在PON口下挂1:8分光器，分路下接3条光路，但实际只有一条光路处于使用中，其他两条光路不知其作用。遂将3条链路均断开，并同步将串口接至OLT的EC2盘，发现断开光纤后，3721busy打印消失，至此基本可定位为光路原因引起PON芯片工作异常，随后逐一对3条上行光路进行测试，发现有一条链路处于长发光状态，光功率值为-14.5dBm，通过此现象基本可以确定是长发光导致ONU业务中断，随将该路光纤断开，并将接ONU的链路恢复，ONU注册恢复正常，随即下挂业务也恢复正常，在随后10分钟的观察中未出现异常。
【故障分析】
后进一步了解得知，存在长发光的设备是在跳纤时误跳到我方设备下，致使我方设备工作异常，但该设备的具体型号未知。所以应避免将未知的设备挂到我方设备下，以免引起重大工程故障。
六、AN5006-20型ONU宽带用户频繁出现PPPoE拨号691问题
【现象描述】
某地市前期使用的都是AN5006-16型ONU，当使用AN5006-20型ONU后，用户反映频繁出现拨号691等错误，经验证，宽带账号及密码正确，需重复拨几次号才能拨号成功，而AN5006-16型ONU下的用户则不会出现拨号691错误，客户怀疑我司AN5006-20型ONU设备问题导致频繁出现该故障。
【处理过程】
一．在选取的几台AN5006-20型ONU的端口上拨号，故障现象确实存在，通过多次拨号并且在多台AN5006-20型ONU的多个端口上拨号上网，并且抓包分析。
从抓包信息查看发现，使用的电脑mac地址为00:13:77:af:de:c2，vlan使用1055，账号采用的是：JYDSL1045090788@16900.gd，密码采用的是：3861000.电脑在使用pppoe拨号软件进行拨号时，先是上报PADI广播报文，然后有两台BAS服务器同时回复PADO报文，其中每台BAS服务器有两个mac 地址在同时发送PADO，也即是我们设备端共收到了四条PADO报文，如下图所示：
根据先到先响应的原则，用户主机收到BAS服务器回应的PADO报文后,会单播（目的地址为此用户选定的那个PPPoE主机的MAC）发起的请求报文.
1、如果mac地址为00:25:9e:17:0b:37的BAS服务器回复的PADO报文先到达我端设备，则流程如下：
BAS服务器会为在这个会话分配一个唯一的会话进程ID,并在发送给主机的PADS报文中携带上这个会话ID：
此时BAS服务器会发起询问握手认证协议（CHAP）的校验方式，
此时BAS服务器会返回验证失败的错误返回：
所以建链失败。
2、如果mac地址为00:e0:fc:c6:49:a5的BAS服务器回复的PADO报文先到达我端设备，则流程如下：
BAS服务器会为在这个会话分配一个唯一的会话进程ID,并在发送给主机的PADS报文中携带上这个会话ID：
而此时BAS服务器会发起密码认证协议（PAP）的校验方式
此时BAS服务器会返回验证成功：
所以建链成功。
通过分析大量的pppoe包，发现一个普遍的规律：如果mac地址为00:25:9e:17:0b:37的BAS服务器回复的PADO报文先到达我端设备，BAS服务器会发起询问握手认证协议（CHAP）的校验方式，会出现建链失败，用户端拨号会出现691故障；如果mac地址为00:e0:fc:c6:49:a5的BAS服务器回复的PADO报文先到达我端设备，pppoe服务器会发起密码认证协议（PAP）的校验方式，服务器会返回验证成功，用户拨号正常，不会出现691故障。
初步分析，问题很可能出现在mac地址为00:25:9e:17:0b:37的BAS服务器发起询问握手认证协议（CHAP）的校验方式上。
二．为了进一步验证上一步的判断，彻底打消客户对AN5006-20设备的怀疑，找出具体原因。我们在多台AN5006-16型ONU上的多个端口多次进行拨号上网，均不会出现691问题，并且抓包分析后发现，当电脑拨号后上报PADI广播报文，每次只有mac地址为00:25:9e:17:0b:37的BAS服务器回复PADO 报文到达我端设备，并且每次都能拨号成功。
三．最后，将问题定位到mac地址为00:25:9e:17:0b:37的服务器发起询问握手认证协议（CHAP）的校验方式上。向负责OLT上层交换机及BAS的客户那里了解情况得知，mac地址为00:25:9e:17:0b:37的服务器为近期新添加的服务器，并且近期新开通的AN5006-20型ONU均做了两条路由分别到达mac 地址为00:25:9e:17:0b:37的服务器及mac地址为00:e0:fc:c6:49:a5的服务器，当通过mac地址为00:25:9e:17:0b:37的服务器认证时才会出现拨号691问题。而前期开通的AN5006-16型ONU只做了一条到mac地址为00:e0:fc:c6:49:a5的服务器路由，只通过该服务进行认证。尝试将AN5006-16型ONU 做一条到mac地址为00:25:9e:17:0b:37的服务器的路由，同样会出现拨号691问题。进一步排除了AN5006-20型ONU的原因导致拨号691故障，判断问题出现在mac地址为00:25:9e:17:0b:37的BAS服务器发起询问握手认证协议（CHAP）的校验方式上。
【故障分析】
1、查RADIUS服务器的状态、地址、端口、密钥，均正确无误。
2、mac地址为00:25:9e:17:0b:37的BAS服务器为华为ME60设备，通过debugging radius packet 命令打开RADIUS报文的调试开关，通过抓包测试，发现一直未收到响应报文，只收到拒绝认证报文。在RADIUS服务器侧进行分析，定位故障原因为RADIUS服务器不支持CHAP认证。
将BAS服务器上的认证方式更改为PAP认证方式后，经过多次测试没有出现拨号691问题，故障排除。
七、EPON-OLT下挂中兴AP业务不稳定问题
【网络拓扑】
【现象描述】
AN5506-04B型号ONU下挂中兴厂家AP设备,wlan业务不稳定。
【处理过程】
1、为了更加明确故障现象,便于故障定位,我们前往现场进行测试。发现有的时候可以正常连接上CMCC的wlan信号并且认证上网,但是很多情况下都无法打开移动wlan登录的portal界面。于是在ONU 的FE端口将wlan对应的业务vlan改为UNTAG模式,通过网线连接笔记本进行多次测试,发现此时业务正常,基本排除自ONU向上的数据配置问题。
2、笔记本通过AP的无线信号连接wlan业务,在业务不通的情况下,发现无线网卡也能够正常获得上层DHCP设备分配的111.14.X.X的地址,如下图:
但是无法ping通网关111.14.40.1。能够获得上层DHCP服务器分配的IP地址，表明DHCP的流程也正确完成了，那么笔记本ping网关的报文会不会是在哪里被弄丢了呢?
在ONU和AP之间进行抓包测试,分别对业务正常和不正常两种情况进行抓包测试。发现在能获得IP无法ping通网关的情况下,AP设备也向ONU侧发送了ARP的报文,源MAC地址也是笔记本的无线网卡MAC没错。可是之前的测试,在ONU侧通过网线连接笔记本,业务也是好的,但是换成从AP上来的ping 包就不通了,怀疑会不会是AP和GPON中间的互联问题。
将同在AP下测试，业务成功与失败的包文件仔细进行比较，发现了新的问题。业务正常的情况下,在笔记本成功获得111.14.X.X的IP地址之后,会广播一个ARP包,告知自己获得的DHCP服务器分配的IP地址,如下图:
上图的ARP包,是笔记本在广播自己获得的IP地址为111.14.129.245,带有vlan2386(业务vlan)标签,同样它找寻网关的时候,发送的ARP包也必然也是带有vlan2386标签的,如下图:
以上是正常情况下的包文件截图,那么对比业务失败情况下的包文件就会发现,从AP发送到ONU侧的ARP包中,并没有带vlan2386的标签信息,包文件截图如下:
所以此时ARP报文就无法被正确识别并送往上层设备,那么ping网关也就不会成功了,更别说portal登陆界面认证上网了。将此问题反馈给中兴厂家工程师,在他们做相关配置调整之后问题解决。
【故障分析】
在GPON这一侧,AP的管理vlan是13,在ONU端口进行封装打上tag标签,用于AC管理AP;业务vlan2386则在AP侧进行打标签封装。所以如果是业务的数据包,从AP出来送达ONU端口的时候,就应该是有2386的vlan标签的，GPON侧仅仅需要进行透传即可。该问题中，因为AP送达ONU时的报文并没有业务vlan2386的tag标签,在GPON侧无法被正确识别,无法正确送达上层设备,那么网络连接也就
无法正常建立,从而使得业务不正常。
八、EPON-AN5006-07-ONU 下挂机顶盒使用DHCP 方式认证无法成功的案例
【网络拓扑】
IPTV 平台（直播、组播源）—IP 承载网—SR 交换机—接入交换机—OLT—ODN—ONU—用户型交换机—iTV
机顶盒AN5006-07B AN5006-07B 7609
NE40（二平面
新增的SR IP 承载网DHCP BAS 互联网
8505
【现象描述】
某局开通IPTV 业务，接入层使用AN5116-02型OLT，入户为FTTB 方式。该处下挂一端AN5006-07型的ONU，CPU 软件版本号为R3.07.09.03，固件为3108，IPTV 业务以点播+组播的方式开通，用户机