PON网络应用案例分析库

中国移动通信集团目录

1.项目概述..........................................................................................................................................11.1.1.2.1.3.2.背景和意义..............................................................................................................................1研究内容..................................................................................................................................1编制依据..................................................................................................................................1PON网络故障点分析.....................................................................................................................12.1.PON网络结构.........................................................................................................................12.2.PON网络常见故障分析.........................................................................................................22.2.1.光网络层常见故障..........................................................................................................22.2.2.业务应用层常见故障......................................................................................................22.2.3.其他常见故障..................................................................................................................33.PON网络应用问题案例分析.........................................................................................................33.1.光网络层故障案例..................................................................................................................33.1.1.传输距离超过20km........................................................................................................33.1.2.PON链路光功率衰耗过小.............................................................................................43.1.3.PON链路光功率衰耗过大.............................................................................................43.1.4.光纤接头不匹配导致ONT无法注册...........................................................................53.1.5.光纤链路性能恶化引发误码丢包..................................................................................53.1.6.异常发光ONU导致同PON口下所有ONU业务异常..............................................53.1.7.SDH光端机误接入PON网络导致多个ONU业务异常............................................63.1.8.上联光口单纤中断导致业务中断..................................................................................63.1.9.设备与交换机两端光模块配置错误导致链路异..........................................................73.1.10.上行设备光模块问题导致组播节目不流畅..................................................................73.2.业务应用层故障案例..............................................................................................................83.2.1.ONU掉电重启后业务配置下发丢失............................................................................83.2.2.业务配置模板与ONU设备类型不兼容.......................................................................83.2.3.流量模板中设置的业务流下行速率值较小导致机顶盒下载节目列表慢..................93.2.4.PCMAC地址重复导致PPP拨号失败.........................................................................93.2.5.电话打不通但能上网....................................................................................................103.2.6.OLT与BRAS之间双路由引起的宽带拨号业务676故障.......................................103.2.7.SN相同导致ONT无法注册........................................................................................113.2.8.OLT与ONU之间双路由保护出现ONU离线问题..................................................113.2.9.OLT上联接口VLAN配置与BRASVLAN配置不匹配导致业务中断..................123.2.10.网关地址冲突造成上网业务全部中断........................................................................123.2.11.设备网线类型设置为AUTO导致与传输对接不成功...............................................133.2.12.组播流TTL值设置不当导致用户无法收看节目常..................................................133.2.13.用户点播节目一段时间后画面停止............................................................................143.2.14.未配置Hostip导致用户不能点播节目.......................................................................143.2.15.未配置Fastleave导致用户下载速率慢......................................................................153.2.16.QoS配置不合理导致VoIP业务质量较差..................................................................153.2.17.错误配置导致DHCP拨号不成功...............................................................................163.2.18.ACL配置不合理导致专线用户不能上网...................................................................163.2.19.设备没有转发未知多播报文导致下挂路由器建立OSPF路由失败........................173.2.20.上级设备开启广播抑制功能导致级联的设备下用户拨号困难................................173.2.21.BRAS侧数据配置问题导致OLT接入的拨号用户无法正常上网...........................183.2.22.拨号用户提示721错误................................................................................................183.2.23.E1映射到T-CONT中带宽配置不当引起丢包..........................................................193.2.24.远程升级ONU软件版本失败.....................................................................................19i3.2.25.OLT工作在IGMPProxy模式下IGMP协议版本互通故障.....................................203.2.26.VoIP语音质量问题.......................................................................................................213.2.27.VoIP话机摘机忙音故障...............................................................................................213.2.28.ONU上配置了管理地址导致从OLT下发IP失败...................................................213.2.29.ARP映射不匹配导致无法从维护网口登录ONU设备............................................223.2.30.ONU由于H.248接口没有正常注册无法进行数据保存..........................................223.2.31.MA5616开启环路检测导致用户端口自动关闭........................................................233.2.32.OLT与对端设备的链路聚合配置不一致导致用户有时打不开网页.......................233.2.33.ONU上配置的广播域太多导致PC经常无法获取DHCP分配的地址..................243.2.34.ONU设备用户VLAN和组播VLAN不同导致组播不通........................................253.2.35.OLT的PON口有组播带宽导致新加入的节目无法播放.................................263.2.36.承载组播方式工作的私有协议的二层透传业务专线的配置问题............................263.2.37.承载RIP协议的二层透传业务专线的配置问题.......................................................273.2.38.MA5616下挂公话只能接不能打的问题....................................................................283.2.39.MA5620E软交换功能故障..........................................................................................293.2.40.MAC地址老化时间过短导致OLT下挂UA5000的VOD组播用户花屏..............293.2.41.不同组播IP映射到相同的组播MAC导致某组播频道节目卡...............................303.2.42.OLT与交换机LACP配置问题导致对接不成功.......................................................313.2.43.POTS配置冗余导致语音业务闪断.............................................................................313.2.44.IMS未配置号码属性支持T38导致ONT上传真业务故障.....................................323.2.45.ONU拨号后要等4-5s才出现回铃音的情况故障.....................................................323.2.46.ONU体彩、福彩掉线故障.........................................................................................333.2.47.ONU设备开通呼叫转接引起的故障..........................................................................343.2.48.BRAS负载过大导致IPTV节目故障.........................................................................393.2.49.ONU发传真故障..........................................................................................................403.2.50.ONU宽带拨号678故障的分析..................................................................................413.2.51.ONU下挂无线AP电脑无法获取IP问题的故障分析............................................423.2.52.丢失关键包导致语音断话故障....................................................................................433.2.53.MGC链接断开告警频现的故障..................................................................................453.2.54.无回铃音故障处理........................................................................................................463.2.55.拨号数图格式问题导致二次拨号故障........................................................................473.2.56.语音业务通信中断后，不能自动注册........................................................................493.2.57.ONU下联设备ARP攻击导致同一PON口下所有用户pppoe拨号678故障......503.2.58.IPTV业务HTTP页面失败故障..................................................................................533.2.59.三方通话问题处理........................................................................................................553.3.其他故障案例........................................................................................................................573.3.1.单路电源功率不足导致设备频繁重启........................................................................573.3.2.电压不稳定导致ONU反复上下线.............................................................................583.3.3.板卡温度异常引起ONU不能同步.............................................................................583.3.4.OLT机框内单板之间软件版本不匹配导致的故障...................................................593.3.5.备用主控板无法正常启动............................................................................................593.3.6.电磁干扰引起上联口时通时断问题............................................................................604.PON网络运维建议.......................................................................................................................614.1.光网络层故障排查方法........................................................................................................614.1.1.在线测试和诊断............................................................................................................614.1.2.离线测试和诊断............................................................................................................614.1.3.PON光链路自动测试和诊断系统...............................................................................624.2.业务应用层故障排查建议....................................................................................................62ii1.项目概述

1.1.

背景和意义

随着网络演进和业务发展的需要，移动正进入全业务宽带网络的发展阶段，PON设备以其高带宽、长距离传输、全业务接入能力成为实现FTTx的主流技术，因此是今后移动全业务宽带网络发展战略中不可缺少的技术实现手段。为了更好地推进PON宽带光接入网建设，少走弯路，有必要从PON网络自有特性为出发点，分析PON网络在应用中可能存在的问题及故障点，归纳总结PON网络在应用中出现的各种故障案例，为今后移动公司的PON网络建设应用和运行维护提供技术支持。1.2.研究内容

本研究报告从分析PON网络中的可能故障点为出发点，给出了PON网络故障排查的通用方法，并总结归纳了PON网络中可能出现的光网络层、业务应用层及其他故障案例。1.3.编制依据

（1）相关调研资料2.PON网络故障点分析

2.1.PON网络结构

典型的PON网络如图1所示。图1典型的PON网络结构图PON网络主要由用户端设备ONU（光网络单元）、局端设备OLT（光线路终端）、ODN（光分配网）和EMS四部分组成，通过城域汇聚网络上联BRAS（宽带远程接入服务器），下联用户设备如企业局域网交换机、无线基站、PC和电话机等。第1页共62页ODN主要由光配线架、单模光纤/光缆、无源光分路器、光纤适配器和光纤连接器等组成。2.2.PON网络常见故障分析2.2.1.光网络层常见故障

在PON网络中，光网络层故障主要包括光纤/光缆线路故障、OLT/ONU光模块故障以及异常发光ONU故障等。1）光纤/光缆线路故障常见的光纤/光缆线路故障可分为以下三类：光纤故障，如断纤、弯曲等光纤老化引起的光纤衰减异常光纤连接异常，包括连接头脱落、连接头松动/受污、熔接点受损、接头盒进水等2）OLT/ONU光模块故障OLT/ONU光模块故障即OLT/ONU的光收发机故障，OLT/ONU收发机的常见故障可分为四类：发射光功率异常偏置电流异常工作温度异常工作电压异常掉电3）异常发光ONU故障异常发光ONU，即指PON系统中那些在没有被OLT授权时隙内发光的ONU，是PON系统中的一种典型故障。异常发光ONU又可分为两类：发射异常但接收正常，称为可控光源，即OLT可以通过下达特定指令使ONU关闭激光器，停止发光，从而达到一定程度的故障排查；发射接收都异常，此类ONU称为不可控光源，无法通过PON系统中的远程诊断手段排查，一般情况下需要进行人工现场排查。由于PON具有多点接入的拓扑特征，异常发光ONU将导致系统可靠性的大大降低以及网络拥塞，严重时甚至可使整个PON系统瘫痪。因此，异常发光ONU故障的排查对PON系统来说尤为重要。2.2.2.业务应用层常见故障

PON系统具有数据、语音和视频等全业务的接入能力，可向终端用户提供宽带上网、IP电话、高清视频等多种宽窄带业务。在业务开通时，需要在PON系统上配置业务上下行第2页共62页带宽、QoS参数、VLAN参数、组播业务参数等，并且这些参数应与上游的BRAS参数、下联的家庭网关设备或企业交换机设备参数匹配，才能保证业务正常。在PON系统中，业务应用层故障包括但不限于以下几方面：上下行业务带宽参数配置错误QoS参数配置错误VLAN参数配置错误或与BRAS配置不匹配业务参数配置错误ACL配置错误安全策略引发的业务故障上联、下联接口参数配置错误，如全双工/半双工模式、LACP协议参数等2.2.3.其他常见故障

在PON网络中，除了光网络层故障和业务应用层故障外，还可能出现一些由工作环境、供电或软硬件引起的故障，例如：电源引起的故障，包括电源功率不足、电压不稳等环境温度过高或过低引起的故障软硬件版本不匹配引起的故障电磁干扰引起的故障3.PON网络应用问题案例分析

3.1.光网络层故障案例3.1.1.传输距离超过20km

（1）故障表现ONU与OLT之间通过1：N光分路器相连，最大光纤传输距离超过20km，ONU和OLT的PON端口状态都为ON，但ONU设备始终无法注册。（2）故障分析a)使用光功率计分别测量远端ONU与OLT的GPON端口的光功率，衰耗均为-19dB左右，在正常范围内，说明光路正常。b)将该ONU换到光纤传输距离约10km的支路上，ONU可以正常注册，说明ONU与OLT两侧GPON端口正常。第3页共62页c)因为传输距离约10km的ONU可以正常注册而传输距离超过20km的ONU不能注册，怀疑是光纤传输距离过长导致。OLT默认支持的最长光传输距离是20km。d)下发指令修改OLT支持的最大距离为30km，问题解决。（3）解决建议OLT到ONT之间的光传输距离建议不要超过20km。通常情况下，PON系统的最大光传输距离受限于以下几个方面：a)b)PON系统的链路光功率预算，功率预算决定了传输距离和光分支比大小。PON本身的技术特点对传输距离的，比如DBA轮询周期和注册开窗大小的取值都会约束到PON的最大传输距离。3.1.2.PON链路光功率衰耗过小

（1）故障表现ONT能正常注册，但在OLT侧不断上报“GEM信元丢失”、“GEM信道恢复”、“ONU信号退化”告警信息。（2）故障分析a)ONT能正常注册说明光路是通的，通过EMS查询ONT接收光功率值，发现ONT接收光功率过大，超出了光模块的正常工作范围。b)检查光纤连接，发现ONT通过一根光纤直连到OLT。在ONT与OLT之间加一个光分器，ONT注册正常后，告警不再出现。（3）解决建议ONT与OLT间光通路的光衰减如果明显小于15dB，会导致ONT或者OLT的光模块接收功率过载并工作在不稳定状态，进而会影响正常报文的传输。3.1.3.PON链路光功率衰耗过大

（1）故障表现ONT不能正常注册，但ONT各指示灯正常，打开OLT端口的自动发现功能，OLT无法自动发现ONT。（2）故障分析a)b)ONT指示灯亮排除光路不通的可能性，推断光通路衰减过大造成。用光功率逐段检测各个连接点的光功率，发现从机房配线架到分光器的一段光纤的光衰达到了-13db。这导致通过分光器后的光衰达到-30db，低于ONT的最低激活光衰（-27db），从而导致ONT无法自动发现。c)更换光纤后故障解决。（3）解决建议第4页共62页ONT与OLT间光通路的光衰减如果明显大于25dB，会导致ONT或者OLT的光模块的接收光功率低于接收机的灵敏度，从而使光模块无法正常工作。3.1.4.光纤接头不匹配导致ONT无法注册

（1）故障表现ONT开局安装时，查询光路衰减-23db，插上光纤后，PON端口状态指示灯不停闪烁，同时设备无法正常注册，不停的上下线。（2）故障分析a)光路衰减-23db属于正常范围，但ONT却无法注册，在排除ONT个体问题的基础上推测是由于光接头部分的衰减过大，原因可能由于光接头接触不良或者受污染。b)在清洁光接头后现象依然存在，进而怀疑是光接头类型不匹配，检查尾纤接头发现颜色不匹配。c)更换相匹配光接头的尾纤后，ONT注册上线并能正常工作。（3）解决建议尾纤接头必须匹配。尾纤接头目前常见的有以下几种：SC接头，LC接头和FC接头。其中SC接头又分两种，分别是：SC-APC纤芯对接面为斜面，接头颜色为绿色；SC-UPC纤芯对接面为平面，接头颜色为蓝色。如果把SC-APC和SC-UPC误对接的话，会引入3db~5db的衰减。3.1.5.光纤链路性能恶化引发误码丢包

（1）故障表现PON口接收光功率正常，但E1业务一直出现误码，以太网业务一直存在丢包现象。（2）故障分析EMS无任何故障告警信息，通过CONSOLE口检查报文统计发现PON接口处有CRC错误报文，初步判定为光纤线路问题。将ODF、分路器上的光接口重新插拔后问题现象消失。（3）解决建议a)b)EMS提供CRC错误报文统计信息，并根据预设门限值触发性能劣化告警。EMS提供以太网OAM环回测试功能，通过EMS下发指令命令ONU侧以太网链路远端环回，并自动发包进行链路状态检测。3.1.6.异常发光ONU导致同PON口下所有ONU业务异常

（1）故障表现OLT某PON接口下所有ONU都下线或者通信中断，但OLT仍可接收到光信号，并且第5页共62页EMS未收到ONU掉电通知。（2）故障分析a)OLT能接收到上行光信号，表示仍有ONU在发送上行信号，所有显示下线或者通信中断的ONU都在同一个OLT的PON接口下，且无ONU掉电通知告警，可初步判断有ONU发光异常。b)通过EMS开启PON系统“流氓”ONU检测和控制功能，发现并关闭了异常发光的ONU，正常ONU随即上线，通信恢复。（3）解决建议a)PON系统提供“流氓”ONU检测和控制功能，通过该功能可检测和定位异常发光ONU，并下发命令关闭“流氓”ONU光模块的发射。b)“流氓”ONU检测和控制功能，只适用于由于光模块故障造成的ONU异常发光，不能解决SDH光端机误接入PON网络而造成的光网络异常。3.1.7.SDH光端机误接入PON网络导致多个ONU业务异常

（1）故障表现OLT某PON接口下所有ONU都下线或者通信中断，但OLT仍可接收到光信号，并且EMS未收到ONU掉电通知。（2）故障分析OLT能接收到上行光信号，表示有远端设备在发送上行信号，所有显示下线或者通信中断的ONU都在同一个OLT-PON接口下，且无ONU掉电通知告警，可初步判断有远端设备发光异常。（3）解决建议a)PON系统提供“流氓”ONU检测和控制功能，通过该功能可检测和定位异常发光ONU，并下发命令关闭“流氓”ONU光模块的发射。b)“流氓”ONU检测和控制功能只适用于远端异常发光设备为ONU的情况，若a)中的措施无法定位远端异常发光设备，也无法关闭异常发光。目前只能建议人工逐个远端排查。3.1.8.上联光口单纤中断导致业务中断

（1）故障表现OLT下接所有业务中断，但无任何告警，从OLT上看，上联口UP，光路正常，所有下接的ONU也在线。（2）故障分析a)现场查看发现设备主控板及上联板均正常，数据配置文件也没有丢失。第6页共62页b)查看OLT对端BAS设备，发现BRAS与OLT相连的端口处于down状态，而OLT与BRAS相连的端口却处于UP状态。c)检查整条光纤链路，发现OLT上联口的发送口单纤中断，因为OLT接收光纤正常，但发光光纤中断，所以对端BAS相对应端口down，而OLT相对应的端口是UP。修复后解决。（3）解决建议a)在业务数据配置正确的情况下OLT下所有业务均中断，很大可能是OLT上联接口故障，需检查OLT与上联BRAS之间的光纤链路。3.1.9.设备与交换机两端光模块配置错误导致链路异（1）故障表现MA5680T与三层交换机通过GE口多模光纤相连。交换机的光口能收到光，光端口处于常亮状态；而MA5680T的光口不能收到光，光端口处于常灭状态。（2）故障分析a)检查光纤，没问题。更改MA5680T端口的双工模式为全双工，问题依旧；更改MA5680T端口的协商模式为自协商，问题依旧，说明不是端口协商问题。b)检查两端光模块，发现两端的模块型号不同。交换机为单模（1310nm），而MA5680T为多模（850nm）。c)更换其中一端的光模块与另一端一致，故障排除。（3）解决建议光模块两端收发光异常，除了光纤、端口协商模式的影响外，还要考虑到两端光模块不一致的影响。通常情况下，造成上述问题的原因有：a)b)c)d)光纤有问题。光模块坏。接口模式配置错误。接口模式协商错误。3.1.10.上行设备光模块问题导致组播节目不流畅（1）故障表现组网结构：TV->STB->ONU->OLT->交换机->BRAS->组播源当用户点播组播节目的时候，节目流出现卡的现象。（2）故障分析a)与用户确认组播源节目工作正常，更换另外一台机顶盒依旧出现这种现象，排除机顶盒故障。第7页共62页b)通过以上软件检查和端口检查，OLT到用户电脑检查判断都没有问题，怀疑故障点在上层设备。从OLT设备PINGBAS的网关地址有丢包现象，证明OLT上行端口至BAS段设备出现故障，更换光纤，发现还是存在丢包。c)上层交换机设备光模块以后再PING时，无丢包现象，同时，组播节目卡的现象也随之消失。由此定位组播卡的故障是由于上层交换机设备光模块问题而导致的。（3）解决建议组播节目点播出现不流畅的原因有很多，需要整理尽可能的故障原因，从用户端开始，逐步检查排除。3.2.业务应用层故障案例

3.2.1.ONU掉电重启后业务配置下发丢失

（1）故障表现某居民小区断电，ONU掉电后数据业务中断，待小区重新来电后，ONU重新上电，重新注册激活，局端OLT下发数据配置给ONU，但个别ONU下的用户仍无法上网。（2）故障分析a)ONU重新上电，重新注册激活，局端OLT下发数据配置给ONU，判断故障ONU未接收到OLT下发的数据配置信息，导致用户不能上网。也就是说故障在ONU来电恢复后，完成了正常的注册功能，实现了PON层的连通，推断OLT通过OMCI下发数据配置信息后，ONU没有收到数据配置信息，造成用户业务中断。b)OLT设备重启后，ONU重新注册，OLT通过OMCI通道正常下发业务，数据恢复正常，故障解决。（3）解决建议GPON设备软件应遵循标准规定，在OMCI消息的交互过程中加入重传机制，保证配置信息下发的可靠性。3.2.2.业务配置模板与ONU设备类型不兼容

（1）故障表现PON口下的ONU能正常注册激活，业务配置依然无法下发。（2）故障分析a)通过EMS网管查看光路的插入损耗在正常范围内，在排除了网元故障和线路故障的可能性后，推测是业务配置模板与ONU设备能力不兼容造成。b)通过EMS检查业务配置模版发现与当前ONU设备的能力不对应，修改为与该型号ONU对应业务配置模版后，重新下发配置成功。第8页共62页（3）解决建议a)通过EMS查询ONU的能力信息，诸如ONU设备端口数量、支持T-CONTS数量、支持GEMPort数量。b)查看ONU的业务配置模板是否同ONU的硬件能力相一致，重新修正业务配置模板以适应ONU设备能力，业务配置下发成功。3.2.3.流量模板中设置的业务流下行速率值较小导致机顶盒下载节目列表慢

（1）故障表现机顶盒直连ONU接入，机顶盒启动后IPTV业务正常，但下载节目列表速度慢，要20多秒的时间。（2）故障分析a)IPTV业务正常，说明光通路正常，组播通路的业务正常，组播带宽正常。但下载节目列表走的是用户单播通道，推测该通道的默认配置的带宽较低。b)通过EMS将该用户对应的单播通道带宽提高到1Mbit/s，下载节目列表速度正常。（3）解决建议IPTV的业务虚端口主要用于点播消息上行，需要的带宽较小。但下载节目列表和升级机顶盒也要通过这个业务虚端口，所以建议设置流量模板的速率值为512Kbit/s以上。3.2.4.PCMAC地址重复导致PPP拨号失败

（1）故障表现采用同一台电脑测试两个ONU业务是否正常，发现其中一个ONU拔号错误678，而另一台拔号正常，过一会儿，原来发生678错误的ONU能拔号，而原来拨号正常的ONU发生拨号错误678，即，关闭其中任意一台，另一台上网正常。（2）故障分析a)b)c)查看数据配置，正常。怀疑是两台ONU的MAC地址冲突，检查发现MAC没有冲突。因数据配置一样，怀疑是用户PCMAC地址未老化引起，在OLT上清空MAC地址表，故障解决。（3）解决建议a)OLT为了避免ONU侧出现环路，启用了MAC地址防重复功能。开通测试时使用同一台电脑进行测试，如果间隔时间较短，OLT上MAC地址未老化，OLT会判定在两个ONU上出现了相同的MAC地址，其中一个ONU的业务会被切断。b)同一台电脑在同一个OLT下测试时，需要等待OLT设置的MAC地址老化时间过了后，才能重新测试。第9页共62页3.2.5.电话打不通但能上网

（1）故障表现开通用户的GPON接入业务，个别用户反映电话打不通，但是能上网。（2）故障分析a)b)用户能上网说明光通路及数据通道正常，推测是终端业务配置的问题。将ONUANI侧的业务虚拟端口加入语音VLAN，同时将ONU下联IAD的UNI端口的PVID加入语音VLAN，电话业务恢复。（3）解决建议a)当在用户侧需要使用VLAN来区分业务时，必须正确配置终端以太网端口的NativeVLAN。b)当需要数据不带VLANTag上行时，必须保证上行端口的NativeVLAN与该端口所在的VLAN一致。3.2.6.OLT与BRAS之间双路由引起的宽带拨号业务676故障

（1）故障表现OLT两个上联口分别通过不同的路径和同一个BAS相连，两个上联口对应不同业务。启用QINQ后，PON口下全部用户宽带不定期出现拨号676故障，一段时间后自己恢复。故障具体反映为相应VLAN的用户PPPoE拨号时，在用户发出了PADI包后，一直没有收到BRAS回复的PADO包，用户计算机报676错误。（2）故障分析a)某些厂商的OLT设备在启用灵活QINQ的情况下提供了MAC地址防迁移功能，该功能是为了解决某些实际应用中出现的用户侧或者网络侧出现环路造成的MAC地址反复迁移从而导致业务中断的问题。如果一个MAC地址同时出现在两个上联口，会被认为是出现了网络环路，需要采用创建静态MAC地址表项的方式选择MAC地址先出现的源端口作为转发端口，同时丢弃从另外一个端口出现的相同源MAC地址的数据包。b)在OLT与BRAS之间双路由的组网环境下，在启用灵活QINQ后MAC地址防迁移被使能，而BAS的数据包从C220的两个上联口下发，C220认为上联网络出现了网络环路，从而将所有的上行流量只能一个上联口发出，同时丢弃掉来自另外一个上联口的下行流量，从而导致业务不通。c)关闭OLT的MAC地址防迁移功能后故障解决。（3）解决建议a)关闭MAC地址防迁移功能，可以暂时解决OLT与BRAS之间双路由引起的宽带第10页共62页拨号业务676故障问题，但在网络出现环路时不能进行有效防护可能会导致业务异常。b)建议配置网络时不要采用这样的网络配置：不同上联口对应不同业务但又在同一个BRAS设备上终结处理，这样会导致一个MAC地址同时出现在OLT的多个上联口上，使OLT误判上联网络发生环路从而断开其中一条链路。c)当需要将多个上联口汇聚到一个边缘设备时，建议开启链路聚合功能，可以提高带宽并起到上联口链路保护的效果，比几个上联口配置更加合理。3.2.7.SN相同导致ONT无法注册

（1）故障表现单个ONT可以正常注册，而多个ONT不能同时注册。例如此ONT注册过程中会使已经注册成功的某些ONT掉线。（2）故障分析a)单个ONT可以正常注册，而多个ONT却不能同时注册，首先可以排除局端设备的问题，以及ONT设备的问题，同时光路问题也可以排除。推断是ONT彼此冲突造成。b)c)检查发现有ONT实际的SN与标签所标识的不一致，且彼此相同。修改SN值，使其与标签所标识的保持一致，重新注册ONT，注册成功。（3）解决建议a)检查发现实际的SN是否与标签所标识的不一致。如果不一致，修改SN值，使其与标签所标识的保持一致。重新注册ONT，注册成功，问题解决。b)每个ONT都有唯一的SN，请保证ONT实际配置的SN值与标签所标识的一致。3.2.8.OLT与ONU之间双路由保护出现ONU离线问题

（1）故障表现在OLT—ONU做了双路由保护后，出现ONU不断离线问题。（2）故障分析a)经检查，在某些相关OLT上没有启用双路由保护协议，在启用该协议后，ONU离线的故障消失。b)某些OLT在启用了双路由保护协议后故障依旧存在，因此认为不是数据问题，怀疑该故障是光纤接错导致。c)经过对OLT接的光纤仔细观察，发现工作端口和保护端口光纤插错，OLT侧的保护端口被当成工作端口配置了数据，导致保护纤也成了工作纤，两纤变成了互相，互不相关的两根纤，从而也就在物理链路上引起了环路，使ONU无法判断第11页共62页到底因该从哪一根纤出去，引起ONU不断“在线”-“离线”。（3）解决建议a)大量出现故障，一部分是因光纤跳错引起，一部分是因OLT数据未做引起，不同的原因引起大量相同的故障现象。b)新开局时，线路人员应将所有该OLT的相关资料，如组网方式、数据分配等交接给OLT调试人员，使调测人员明确知道是否需要配置主备路由，哪根光纤是工作口，哪根光纤是保护端口，从而正确配置数据。3.2.9.OLT上联接口VLAN配置与BRASVLAN配置不匹配导致业务中断

（1）故障表现OLT上联接口启用QinQ后，所有宽带用户无法上网。（2）故障分析a)b)c)怀疑OLT的PON口有问题，更换后故障依旧，排除了OLT硬件问题。检查OLT数据配置，没有发现问题。将OLT上联接口业务去掉QINQ，配置为单层VLAN，故障解决，因此定位于QINQ数据配置有问题。d)通过OLT与上层设备BRAS双方检查数据配置，发现OLT与BRAS设备的内层VLAN不同，导致所有业务不通。（3）解决建议配置数据时，OLT与BRAS双方维护人员应协商好数据配置，包括VLAN设置，端口模式等。3.2.10.网关地址冲突造成上网业务全部中断（1）故障表现某局MA5680T上行口通过二层交换机连接到路由器上，用户上网采用固定分配公网IP地址方式。故障现象为上网业务中断，用户能Ping通网关，但Ping不通DNS。（2）故障分析a)b)c)将计算机直接连到二层交换机的端口上，可以上网，证明交换机端口正常。检查配置数据，没有问题；Ping网关，严重丢包。检查路由配置，发现有地址冲突告警，网关IP地址绑定的MAC地址为一错误值，由此可以定位问题在于网关地址冲突。d)经过检查发现有一台计算机的IP地址和网关地址相同。将这台计算机隔离，修改路由器上网关绑定的MAC地址后，业务恢复。（3）解决建议第12页共62页当用户IP为静态获取的固定IP时，需要确保此IP地址在同一子网段内的唯一性。3.2.11.设备网线类型设置为AUTO导致与传输对接不成功（1）故障表现MA5680T上联以太网口与对端设备的以太网口对接，MA5680T的上联以太网口配置为100Mbit/s全双工，以太网口的网线MDI类型配置为auto；对端设备的以太口的网线MDI类型配置为across。对端设备的传输网口配置为100Mbit/s全双工，正常连接后，以太网口不能UP。（2）故障分析a)传输设备以太网口与PC对接可以UP，说明传输的端口硬件正常；MA5680T以太网口与PC对接可以UP，说明MA5680T的端口硬件正常。b)用两台PC测网线正常，用此网线将两个设备连接起来端口不能UP，说明端口之间的协商有问题。c)检查MA5680T上联以太网口为百兆全双工，上联网口的网线MDI类型为自动识别AUTO。修改其类型为“across”，故障排除。（3）解决建议LSW（LANSwitch）芯片的MDIAUTO和自协商AUTO是绑定在一起，也就是说当自协商是禁止的情况下，MDI即使配置成AUTO也是没有作用的，MDI只能固定为某一值，或者是“normal”或者“across”。如果使用直连线，可以设置MDInormal；如果使用交叉线，可以设置MDIacross。3.2.12.组播流TTL值设置不当导致用户无法收看节目常（1）故障表现用VLC视频软件收看节目，无法看到视频。在PC终端捕获数据包，发现已经发出IGMPreport报文，但没有收到组播流。查看MA5680T上行端口流量统计，发现已经接收到大量组播媒体报文。（2）故障分析a)b)在组播服务器侧的交换机上捕获数据包，发现组播流已经发到骨干网。将MA5680T直接连接在组播服务器上，点播正常，表明报文没有被MA5680T丢弃。导致此问题的原因可能是组播源设置TTL值不合理，没有考虑到网络对TTL值的影响。c)在骨干网与MA5680T之间捕获数据包，与直接从组播服务器发出的组播报文对比。发现到达MA5680T上行端口的组播报文TTL值已经为0，而MA5680T将组播报文转发到用户侧时，还需要减一跳。由此可见，组播源设置TTL值不合理。第13页共62页d)在组播服务器上把组播流的TTL值增加1，用户能正常点播节目，问题解决。（3）解决建议IP报文中TTL域值表示该IP报文的生存时间，每经过一跳路由，则TTL值-1。当TTL值为0时，三层设备会丢弃该IP报文。所以在假设组播服务器时，要考虑组播服务器到用户的路由跳数对组播流TTL值设置的影响。3.2.13.用户点播节目一段时间后画面停止（1）故障表现用户点播正常，但观看一段时间后画面停止，过一段时间再次点播节目又可继续观看，后又停止。（2）故障分析a)通过EMS查看检查用户对该组播节目的观看权限，发现用户观看该节目的权限为预览。b)将用户观看该节目的权限改为观看，问题解决。（3）解决建议通常情况下，支持可控组播的节点设备可为每个用户配置组播访问权限，组播节目的访问权限有禁止、观看和预览三种权限，需要根据实际情况具体配置。3.2.14.未配置Hostip导致用户不能点播节目（1）故障表现组网：PC—>ONU终端—>MA5680T—>BRAS—>组播路由器—>组播服务器，MA5680T开启IGMPProxy功能，组播用户无法点播节目。（2）故障分析a)b)用户单播业务正常，说明问题在组播业务相关的数据配置上。通过EMS检查发现组播用户的状态为在线，说明MA5680T收到了PC发上来的IGMPReport报文，怀疑是BRAS未向上转发此报文。c)在BRAS上抓包分析后发现，BRAS丢弃了从MA5680T发出的IGMPReport报文。分析IGMPReport报文发现源地址和BRAS地址不在同一网段。d)配置MA5680T的组播Hostip与BRAS在同一网段。MA5680T以此Hostip地址代理转发IGMP报文，问题解决，用户点播节目正常。（3）解决建议当OLT工作在IGMPProxy的模式，会将收到的IGMPReport报文的源IP地址修改为第14页共62页OLT的组播Hostip再向上转发，所以需要保证这个IP地址和BRAS在同一网段，否则BRAS会丢弃这个IP包。3.2.15.未配置Fastleave导致用户下载速率慢（1）故障表现组网：PC—>机顶盒—>家庭网关—>MA5680T—>L3Switch—>组播路由器—>Multicastserver。端口的速率为16Mbit/s，观看视频的同时持续下载，下载速率约为10Mbit/s。关闭机顶盒后，发现下载速率一直是10Mbit/s，几分钟后才能恢复到16Mbit/s。。（2）故障分析a)查看端口速率配置为16Mbit/s，且端口激活速率为16Mbit/s，排除端口速率设置问题。b)查看FTP软件配置，没有设定软件下载速率，并且在其他端口下载都没有问题，排除下载软件问题。c)将机顶盒关闭后，查看IGMP在线用户，发现用户仍然在线，则可能是没有将端口的IGMP属性配置为fastleave。d)查看端口配置，fastleave属性为disable状态，修改端口属性为fastleave。用户下载速率同时上升，达到16Mbit/s，问题解决。（3）解决建议如果端口不配置fastleave，将机顶盒关闭后，用户不能立即下线。从Multicastserver过来的视频流仍旧会发送到ONU端口，占用相应的带宽，下载速率也不会立即上升。即在收到IGMPLeave报文时，若端口在该组播组内则直接将端口从组内删除，不再下发特定组查询报文，使频道切换时间小于1秒钟。因此在配置组播业务时，最好使能fastleave功能，使组播业务占用的带宽能够被快速释放。3.2.16.QoS配置不合理导致VoIP业务质量较差（1）故障表现组网：业务终端—>家庭网关—>MA5680T—>L2Switch—>BRAS—>路由器—>骨干网—>语音网关—>PSTN网络。采用多通道多业务方案，VoIP业务质量不稳定，有时甚至出现不能成功拔号，但IPTV业务和上网业务质量良好。（2）故障分析a)将另一套IAD直接连接MA5680T上的L2Switch上，并修改相应配置，测试后发现VoIP质量良好，说明上层设备无问题。b)检查发现流量模板的优先级策略为Tag-In-Package，系统将根据报文自身所携带的802.1p信息进行调度。对上行口进行镜像并连接PC抓包，VoIP报文所携带的802.1p第15页共62页设定值为0，IPTV业务报文和上网业务报文所携带的802.1p设定值分别为3和1。当用户端口下行发生拥塞时，VoIP将有可能被丢弃（报文优先级最低）。c)修改流量模板，将Priority设定为7。进行测试，VoIP业务质量良好。（3）解决建议设计Tripleplay实现方案时一定要仔细分析何处会发生拥塞以及拥塞时采用何种调度策略，保证优先级较高的业务优先得到调度。对实时性要求较高的VoIP和视频业务标记较高的优先级。3.2.17.错误配置导致DHCP拨号不成功（1）故障表现用户拨号不成功。查看报文统计信息，只收到用户的DHCPDISCOVER报文，没有收到DHCP服务器的DHCPOFFER报文，并且在BRAS上没有收到任何报文。（2）故障分析a)b)c)d)检查用户到MA5680T的链路，链路正常。检查MA5680T到BRAS的链路，链路正常。检查系统配置，发现用户业务VLAN没有绑定DHCP服务器。将DHCP服务器绑定后，拨号成功。（3）解决建议用户发出了DISCOVER报文，上层BRAS设备却没有收到，可在如下三段链路逐段分析定位故障：用户到MA5680T的链路MA5680T到BRAS的链路MA5680T上3.2.18.ACL配置不合理导致专线用户不能上网（1）故障表现组网：PC—>Modem—>MA5680T—>BRAS。PPPoE拨号用户上网没有问题，新添加的专线用户（不需要拨号的静态用户）却不能上网。（2）故障分析a)断开MA5680T与PC的连接，在三层交换机与MA5680T上配置相同的VLAN信息（将三层交换机代替MA5680T进行组网）。PC配置静态IP地址时测试业务正常，说明BRAS上用户的数据是正确的。b)重新将MA5680T接上，采用静态IP地址Ping网关（BRAS），无法Ping通。在BRAS跟踪数据包，发现没有数据包上报，判断MA5680T有问题。第16页共62页c)检查MA5680T的配置，上行口0/19/0只允许源IP地址为1.1.1.1和2.2.2.2的IP报文通过，其他IP报文一律丢弃。所以静态用户的上网报文都被丢弃了。因为基本ACL（2000～2999）是针对IP报文的，只能匹配标准的IPoE封装格式的报文，对PPPoE这种封装的报文就不能匹配。所以对PPPoE拨号用户不起作用。d)从运营商那里了解到MA5680T设备上有一个三层接口作为带内网管以及telnet接口。为了防止非法用户登录设备，做了上述配置。只允许固定的几个IP（1.1.1.1和2.2.2.2）访问设备。但是由于ACL配置不合理，将正常上网用户的报文也过滤掉了。所以处理措施就是修改ACL，使其过滤条件更精确。此外，要防止非法用户telnet或者网管登录MA5680T，那么要过滤的报文的目的IP就是MA5680T上三层接口的IP地址（3.3.3.3）。因此，可以将目的IP作为过滤的一个条件加入到ACL规则中。（3）解决建议配置QoS&ACL时，应仔细分析各种报文的特征，精确地配置ACL规则，以免造成ACL配置不合理而导致专线用户不能上网。3.2.19.设备没有转发未知多播报文导致下挂路由器建立OSPF路由失败（1）故障表现组网：路由器—>MA5680T—>BRAS—>路由器。BRAS上开通了VPLS业务，路由器之间建立OSPF失败。（2）故障分析a)依据前期测试情况，2端路由器都可以发出协议报文却收不到报文，而OSPF是基于组播报文传送。BRAS的VPLS业务对组播报文是不做任何的，所以重点怀疑MA5680T没有转发组播报文。b)将MA5680T的IGMP模式设置为OFF，未知组播报文正常转发。两端路由器OSPF通道建立成功。（3）解决建议MA5680T对上行组播报文默认操作是丢弃，对下行的组播报文则工作在受控组播状态。3.2.20.上级设备开启广播抑制功能导致级联的设备下用户拨号困难（1）故障表现上级MA5680T的用户拨号正常，级联的两台MA5680T在上网高峰期用户拨号困难。用户拨号错误提示678，在线用户上网正常。（2）故障分析a)更换上行板，故障依然存在。更换尾纤，故障依然存在。第17页共62页b)在BRAS上抓包分析，如果用户拨号成功，在BRAS上可以抓到PPPoE的报文。如果用户拨号失败，在BRAS上抓不到用户的PPPoE的报文，说明用户的PPPoE的报文没有送到BRAS设备上，在传输过程中被丢弃。c)在被级联的MA5680T设备上行口做镜像抓包，可以抓到用户的PPPoE的报文，说明用户的PPPoE的报文已经传送上去，由此说明报文是在上级MA5680T设备上被丢弃。d)查看上级MA5680T设备配置发现，该设备在级联的子槽位上启用了广播抑制功能，使用命令取消广播抑制功能后测试，用户拨号正常。（3）解决建议由于上级MA5680T启用了广播抑制功能，上网高峰期来至用户端的广播过大，PPPoE报文得不到及时处理而被丢弃，所以用户拨号困难。建议根据PON接入的用户规模，对广播报文限速在合理范围。3.2.21.BRAS侧数据配置问题导致OLT接入的拨号用户无法正常上网（1）故障表现F820上的一个用户拨号成功后马上就会断线，提示如下：到“宽带”的链接没有成功，重新连接被挂起。（2）故障分析在拨号认证前打开抓包工具ethereal开始抓包，确实出现了认证完立即断线的故障，抓包情况如下：NOTimeSourceDestinationProtocolInfo

371.125594Siara_10:f0:1200:1e:ec:eb:d5:8aPPPLCPTerminationRequest381.13992000:1e:ec:eb:d5:8aSiara_10:f0:12PPPLCPTerminationAck

412.3181Siara_10:f0:1200:1e:ec:eb:d5:8aPPPOEDActiveDiscoveryTerminate(PADT)422.319200:1e:ec:eb:d5:8aSiara_10:f0:12PPPOEDActiveDiscoveryTerminate(PADT)

分析抓包情况，发现PPPOE认证完成后，BRAS侧会向用户发送一个TerminatationRequest包，等用户主机返回TerminationAck后，BRAS侧会向用户发送一个ActiveDiscoveryTer-minate(PADT)包终止PPPOE会话，所以就出现了认证后就掉线的情况。（3）解决建议这种情况是BRAS侧用户数据配置出现了问题，将情况反馈给局方，局方调整BRAS侧用户数据后问题得到解决。3.2.22.拨号用户提示721错误（1）故障表现OLT下所有ONU用户拨号均提示721错误。第18页共62页（2）故障分析a)在用户侧拨号抓包结果如下：b)从上面的抓包可以看到，终端没有收到BRAS发送的下行PPPLCP协议包，因为之前业务都是正常的，让局方也检查了BRAS设备，上层设备出问题的可能性不大，怀疑是OLT没有正确处理PPPLCP协议包。c)登陆到网元上进行查看，发现4号槽位和5号槽位的用户板软件版本和主控板里面对应的软件版本不一致，从而导致下面所有的ONU拨号失败。（3）解决建议把4、5号槽位的用户板软件版本，全部更新为和主控板相统一的软件版本，用户可以成功拨号。3.2.23.E1映射到T-CONT中带宽配置不当引起丢包（1）故障表现在F621A上配置4路E1业务，都使用T-CONT1。在T-CONT1上配置固定带宽30M。在CL1A上打环，使用2M误码仪接在ONU的一个E1接口上测试，发现有误码。（2）故障分析a)b)在OLT侧查询CES计数器，DwLostPkts计数器一直在增长，说明上行有丢包。将4路E1业务配置在TCONT2上，配置带宽为20M时有误码，配置为24M时没有误码。c)将4路E1业务配置在TCONT2上，带宽设置为24M时，故障消失。（3）解决建议按照理论计算，每路E1业务需要5-6M的带宽。F621ATCONT1的buffer太小，每个E1业务需要配置为8M的时候，上行才不会有丢包。使用其他T-CONT，每个E1业务只需要配置为6M带宽就可以了。3.2.24.远程升级ONU软件版本失败（1）故障表现对F621A进行远程版本下载，下载完成后，ONU没有切换到新下载的版本上。同时第19页共62页F621A的版本信息不对，在OLT侧show出来的版本信息为F621v1.0700101，不是真正的版本号。（2）故障分析a)再次更新了一个比较新的版本，在OLT侧显示问题依旧，然后登陆到ONU显示也是一样，确认ONU的版本有问题。b)通过咨询开发人员，最后确定版本文件更新的不完整。需要更新F621_blfs_kernel和F621_fs_kernel。c)同时更新F621_blfs_kernel和F621_fs_kernel，故障解决。（3）解决建议对版本比较新的F621A（如v1.0090204），只需要更新F621_blfs_kernel就行了。对运行版本比较旧的F621A，升级版本时，除了更新F621_blfs_kernel之外，还需要更新F621_fs_kernel。对于特别旧的版本（4.1以前）需要先更新到一个较新的版本，再更新到最终版本。3.2.25.OLT工作在IGMPProxy模式下IGMP协议版本互通故障（1）故障表现OLT上IGMP使用snooping模式时，通过机顶盒能够正常播放节目。OLT上IGMP使用proxy模式时，通过机顶盒无法正常播放节目。（2）故障分析a)检查确认OLT三层接口的HostIP和网关在同一网段，排除IP地址原因引起的故障。b)用PC抓取OLT同机顶盒之间的IGMP协议报文，通过对协议分析发现，机顶盒先发送了IGMPv2的Report报文，组播流没有点下来，机顶盒认为自己之前发送的IGMP协议版本无响应，于是又发送了一次IGMPv3的Report报文。由于OLT工作在Proxy模式的时候，下行发送的Query报文会自适应上行Report报文的版本，之后OLT下行发送的是v3协议的Query包，而机顶盒没有应答该Query包。c)通过禁用OLT上的IGMPv3协议，强制OLT发送的V2版本的Query报文，问题得到解决。（3）解决建议OLT工作在IGMPProxy模式下，下行组播Query包使用何种协议类型，是根据上行的IGMP协议包的协议类型来定的。当Query报文没有获得响应，OLT为判断当前无活动组播用户。第20页共62页3.2.26.VoIP语音质量问题（1）故障表现用户反映通话能够正常连接，但是语音有断续现象。（2）故障分析a)通话能正常连接，可排除物理线路故障和业务数据配置故障，怀疑是网络数据配置的问题。b)通过网管对集成IAD功能的ONU下发诊断测试命令，通过语音地址Ping网关发现有丢包。c)d)通过在OLT侧和ONU侧的对RTP流抓包对比分析发现，丢包产生在OLT。更换OLT业务板卡，问题解决。（3）解决建议丢包还有可能因为设备内部丢包引起，这类故障的解决主要依靠升级终端版本，或者更换设备硬件。3.2.27.VoIP话机摘机忙音故障（1）故障表现用户摘机后即听到忙音。（2）故障分析a)b)c)首先检查相关的数据配置，同时软交换侧也需要检查数据配置。检查ONU侧数据配置正确性，同时和软交换侧确认数据配置是否正确。确认双方数据配置没有问题时，再提供抓包进行分析，包括MGCP或者H.248和SIP协议的交互。（3）解决建议用户摘机忙音故障可能的原因：a)b)c)ONU未注册。SS下发忙音信令。数据配置错误。3.2.28.ONU上配置了管理地址导致从OLT下发IP失败（1）故障表现OLT(MA5680T)下新添加ONU(MA5620E)，配置“ipconfig”命令对ONU下发IP时提示“ONT执行资源不足”，配置不成功。（2）故障分析a)检查OLT的数据，数据配置没有问题。查看MxU状态显示ONU已经正常注第21页共62页册。b)检查ONU的数据，发现ONU已经配置了管理VLAN和IP地址。删除管理VLAN和IP地址后，在OLT上重新下发“ipconfig”命令，配置成功，也可以telnet到ONU。（3）解决建议对于ONU设备，尽量采用从网管下发管理VLAN和IP地址的方式，这样节约了时间，又避免产生故障。3.2.29.ARP映射不匹配导致无法从维护网口登录ONU设备（1）故障表现ONU（MA5620E）下接计算机上配IP地址10.11.104.1/24，无法从ONU（MA5620E）默认的维护网口0/1/1登陆到系统，且ping不通ONU（MA5620E）地址10.11.104.2/24，从串口可正常登陆。（2）故障分析a)b)c)d)通过串口登陆设备，查看单板情况为正常。查看ONU(MA5620E)维护网口配置为正常。查看维护网口状态为正常。在PC的DOS中输入arp—a命令查询PC的ARP表项，发现10.11.104.2对应的MAC地址为00-18-82-77-1c-c0，与PC所连接的ONU的MAC地址（00-18-82-77-1d-02）不一致。e)输入arp-d，清除此前保留的ARP映射，即可登陆到当前连接的ONU，问题解决。（3）解决建议PON开局时有多台ONU要升级，每台ONU的管理以太网口默认IP地址都是10.11.104.2，导致计算机的ARP表未及时更新，IP地址10.11.104.2对应MAC地址一直是之前登陆过的ONU的MAC地址，而不是当前ONU的MAC地址。一般计算机ARP表中的映射要在停止使用5到10分钟后才会自动失效，导致计算机无法登陆到当前连接的ONU。3.2.30.ONU由于H.248接口没有正常注册无法进行数据保存（1）故障表现ONU(MA5620E)开局过程中进行数据保存，发现保存进度到90%时总是提示保存失败。（2）故障分析a)执行保存命令前查看系统CPU利用率，发现CPU利用率正常，排除因为系统CPU利用率高而导致保存失败的原因。第22页共62页b)通过多次验证，发现保存失败的时候H.248接口状态都是DOWN，在H.248接口状态为UP的时候可以正常保存。c)查看H.248接口配置发现传输模式为alf/udp，修改为udp后测试，接口在UP和DOWN的状态下都可以正常保存。（3）解决建议当配置H248接口的传输模式为alf/udp时，因为alf/udp具有事务可靠性功能，会检测H248接口状态。当H248接口未正常注册时候，系统会认为H248接口状态不正常，不允许做配置保存。所以配置ONU设备时，在开局建议将MG接口配置为udp传输模式。设备运行正常后，可以选择配置为alf/udp传输模式。3.2.31.MA5616开启环路检测导致用户端口自动关闭（1）故障表现某局MA5616下经常有用户端口突然关闭。（2）故障分析a)b)c)检查log记录。没有关闭端口操作的记录，也没有SNMP下发关闭的记录。根据历史事件记录，怀疑用户端口下存在环网。检查环路检测功能，发现处于enable状态。关闭环路检测后，端口不再自动关闭。由此确定端口关闭是由用户端环路导致。d)排查用户端，发现用户端电脑中病毒造成环路检测报文传回上行口。将用户端电脑杀毒后问题解决。（3）解决建议在每用户每VLAN组网环境下，用户端环路不会影响其他用户，建议设置环路检测为默认关闭状态。3.2.32.OLT与对端设备的链路聚合配置不一致导致用户有时打不开网页（1）故障表现OLT下的用户打开网页有时很慢，有时正常，语音业务及网管正常。（2）故障分析a)b)检查ONU设备流量模板索引，配置没有问题。PING网站域名有不稳定，有时通有时不通。具体表现为：当能PING通的时候，如果一直长PING则不会丢包，如果此时中断PING包，然后再PING就很有可能无法PING通，但过一会又能PING通，没有明显规律。c)查看OLT配置，发现MAC地址老化时间为10秒，怀疑MAC地址老化过快导致，修改为300秒后问题依旧。第23页共62页d)从PCPINGOLT上层设备的网关地址一直正常，初步判断是OLT上层设备的问题。e)检查发现OLT是双上行，但1端口没有配置数据，只是ONLINE。后确认对接的上层设备上做了链路聚合，但OLT上没有相应的配置，拔掉1端口的光纤后问题解决。（3）解决建议PING上层设备的网关地址一直正常，而PING网站域名时通时不通的原因与上层设备上的负荷分担机制有关，由于PING上层设备的网关地址时，源MAC地址与目地MAC地址都是固定的，所以只会出现通或不通的情况。而PING网站域名时，由于网站可以有多台服务器，所以目的MAC地址不是固定的，这样返回的ICMP报文就有可能从1端口的链路回来，于是出现概率性不通的情况。所以建议在OLT上配置链路聚合后可以彻底解决问题，同时提高网络可靠性。3.2.33.ONU上配置的广播域太多导致PC经常无法获取DHCP分配的地址（1）故障表现业务组网：PC->ONU->OLT（MA5680T）->DHCPServer->汇聚交换机故障描述：OLT下挂多台ONU设备，OLT上接一台防火墙。开启DHCPServer，并做NAT，再接入城域网汇聚交换机。ONU下的PC经常无法获取到IP地址，但当PC配置DHCP地址池中的固定IP地址时，就可以ping通网关，也可以正常上网。（2）故障分析a)客户为了做到端口隔离，为ONU的每个用户端口都分别配置了一个VLAN。为了节省VLAN资源，在ONU到OLT上进行VLAN切换。这样就使得OLT下的广播域过多，导致DHCPoffer报文丢失。b)在防火墙上开启debuggingdhcpserverparket，通过抓包工具发现防火墙上面已经发送了DHCPoffer报文，但PC没有收到DHCPoffer报文。。c)在OLT上行端口镜像抓包，发现DHCPoffer报文已经送到OLT，但没有到达PC。d)重新配置数据，在每个ONU上配置一个SmartVLAN，减少OLT下的广播域。再次测试，所有PC都可以正常获取IP地址。（3）解决建议同一个SmartVLAN内端口相互隔离，因此在每个ONU上配置一个SmartVLAN就可以实现ONU上用户端口隔离功能。第24页共62页3.2.34.ONU设备用户VLAN和组播VLAN不同导致组播不通（1）故障表现组网为PC（安装VLC软件模拟组播服务器）->OLT（MA5680T）->ONU（OT928）->PC（安装VLC软件模拟组播客户端）。现场测试发现用户VLAN和组播VLAN相同时，组播业务正常，修改为不同VLAN则组播业务不通，此时发现组播用户是在线的。（2）故障分析a)首先VLAN相同时组播业务正常，说明设备实现组播没有问题。此时查看组播用户状态都是在线，没有问题。b)修改用户VLAN，并相应修改组播配置数据，发现组播用户上线，但是客户端PC却不能正常播放组播节目。修改配置为VLAN相同，播放恢复正常，说明VLC软件设置没有问题。c)在客户端PC上抓包发现，没有组播报文下发，返回组播服务器侧抓包发现已经将组播报文下发。d)由这两种抓包情况可以判断，组播媒体报文是在OLT到ONU中间被丢弃的，这时我们可以镜像PON端口抓包，看媒体报文是否下发，确认已下发，这时可以定位为媒体包在ONU侧被丢弃。e)我们知道组播的协议报文和媒体报文是走不同的通道，即通过不同的gemport传输，而我们的ONU目前未能实现VLAN转换功能，导致到达用户端口的组播媒体报文仍然携带组播VLAN的标签，而我们ONU的用户端口对和自己native-vlan不同的数据报文做丢弃处理。这样我们客户端就收不到组播的媒体报文，自然组播业务不正常。f)使用命令修改ONU的组播转发模式为“translation”，即开启组播跨VLAN转发功能，组播即恢复正常。（3）解决建议在使用ONU实现组播业务的时候，我们目前可以实现的方式只有三种：所有用户的VLAN和组播VLAN相同（如果用户多的话，广播域大，不推荐这样设计）。所有用户VLAN相同，但和组播VLAN不同，通过组播转发模式设置也能实现组播功能。ONU下接交换机实现TAG标签的剥离或者转换，依据交换机能力可以实现多用户多VLAN同时实现组播，此时ONU的UNI口应设置为trunk模式。第25页共62页3.2.35.OLT的PON口有组播带宽导致新加入的节目无法播放（1）故障表现业务组网：PC->ONU（MA5616）->OLT（MA5680T）->组播路由器->组播服务器。故障描述：PC上运行VLC播放软件，部分节目能够播放，而部分节目却显示黑屏，无法播放。（2）故障分析a)在MA5680T上使用命令查询到组播带宽最大约为716.8Mbit/s，当前已使用约为715Mbit/s。。b)在MA5680T上使用命令查询到组播级联端口有143个节目在线。从查询到的参数可以看出，当前有143个节目上线，使用了715Mbit/s左右的带宽，说明每个节目占用的带宽在5Mbit/s左右。由此联想到在MA5616配置静态组播节目时均使能了预加入功能（prejoin），即允许节目向上层设备的预加入。预加入功能是指在增加节目时就向上发report报文，无论有无用户点播组播节目，组播视频流都已经被提前引到MA5616的上行口。这样MA5680T为每个组播节目默认分配5Mbit/s的保证带宽。由于预加入节目极大地占用了MA5680T到MA5616之间有限的组播带宽，导致剩余的组播带宽不足5Mbit/s，所以后续加入的节目就无法播放。c)重新配置所有节目，去使能预加入功能。所有节目正常播放，问题解决。（3）解决建议OLT对PON口是有组播带宽的，默认每个PON口最大组播带宽约为716.8Mbit/s。ONU配置大量静态组播节目时，一般不将所有的节目均使能prejoin，以免造成带宽的负荷。3.2.36.承载组播方式工作的私有协议的二层透传业务专线的配置问题（1）故障表现GPON设备MA5680T下挂HG863来承载ATM机到银行总行的专线业务时，用户提到要承载组播业务，工程人员按设备承载组播业务进行了数据配置，在进行验证时业务不通。现象为思科路由器EIGRP协议无法正常建立连接。组网图如下：第26页共62页xx总行CISCO路由器MSTP传送网OLT设备MA5680T分光器A接入点ATM取款机A接入点CISCO路由器A接入点ONUHG863（2）故障分析与用户沟通，发现实际需求不是承载组播业务，而是承载思科路由器EIGRP协议的二层透传业务。按二层透传进行数据配置后，业务依然不通。数据进一步做如下调整后业务通了：a)b)c)d)在上行口处取消多播抑制。将GPONONT的对应业务模板X中的MAC地址学习功能关闭。在BTV模式下配置ID为X的相关业务流未知多播为透传。业务流上行VLAN配置为QINQ的。（3）解决建议因为把组播方式工作的思科私有协议EIGRP理解为组播业务是前期业务不通的主要原因之一。而GPON在承载此类二层透传业务时，配置方式与普通二层透传业务有差异，需做如上四个方面的调整。3.2.37.承载RIP协议的二层透传业务专线的配置问题（1）故障表现GPON设备MA5680T下挂HG863来承载ATM机到银行总行的二层专线业务，工程人员按二层专线业务进行了数据配置，在进行验证时业务不通。现象为思科路由器无法正常建立连接。组网图如下：第27页共62页xx总行CISCO路由器MSTP传送网OLT设备MA5680T分光器A接入点ATM取款机A接入点CISCO路由器A接入点ONUHG863（2）故障分析与用户沟通，发现用户专线上承载了RIP协议。数据做如下调整后业务就通了：a)b)c)d)在上行口处取消多播抑制。将GPONONT的对应业务模板X中的MAC地址学习功能关闭。在BTV模式下配置ID为X的相关业务流未知多播为透传。业务流上行VLAN配置为QINQ的。（3）解决建议不了解用户专线上承载了RIP协议是造成业务不通的主要原因。GPON在承载此类二层透传业务时，配置方式与普通二层透传业务有差异，需做如上四个方面的调整。3.2.38.MA5616下挂公话只能接不能打的问题（1）故障表现做主叫摘机信号无法上报，并且无拨号音，做被叫可以正常接听。（2）故障分析a)可以正常接听，首先说明光通道和数据通道正常，其次信令能正常交互，说明语音业务配置正常，怀疑是语音端口的底层配置或者话机出的问题。b)更换话机，问题依然存在。内线测试B线对地电压（tip-ring）绝对值远低于48V。检查发现POTS用户端口的反极模式为“软反极”。将POTS用户端口反极模式配置成“软反极”模式后，会对国内某些话机会产生兼容问题，导致语音套片工作在异常状态。导致用户摘机概率性无拨号音，影响正常电话接续。c)复位语音业务板，故障解除。（3）解决建议对于无需反极性功能的局点，无需做反极性配置；对于需要反极性功能的局点，将POTS第28页共62页端口配置成“硬反极”模式；对于已经配置了软反极功能的局点，要求必须修改为“硬反极”模式。3.2.39.MA5620E软交换功能故障（1）故障表现复位MA5620E上的H.248接口失败，提示：“ResetMGinterface0fail!”。（2）故障分析a)首先检查IP通路是否正常，通过用户数据通道Ping网关能Ping通，MGCPing网关也能Ping通，说明MG与MGC间的数据通道正常。怀疑是MA5620E上的配置与MGC不一致导致故障。b)核对MA5620E上的软交换配置发现其配置的H.248协议为v2版本，MGC上使用的H.248协议为v1版本。c)通过EMS更改MA5620E的H.248协议为v1版本，故障解除。（3）解决建议语音业务的故障，建议首先检查端到端的数据通路是否正常，要注意保证MG与MGC间IP路由的双向通达。在此基础上，再检查MG侧设备的业务和协议配置。3.2.40.MAC地址老化时间过短导致OLT下挂UA5000的VOD组播用户花屏（1）故障表现业务组网：MSAN（UA5000）->OLT（MA5680T）->ME60故障描述：OLT下挂UA5000的VOD组播用户偶尔出现花屏。（2）故障分析a)首先排查MA5680T和UA5000的数据配置，发现数据配置没有问题。UA5000在MA5680T上绑定的DBA模版保证带宽为60Mbit/s。查看UA5000的IPMD端口（与MA5680T的EP1A相连的端口）流量不足20Mbit/s。在BRAS上查看发现用户帐号限速3Mbit/s，能够满足组播节目需求。b)检查OLT的上行链路。从BRAS侧pingUA5000的管理地址没有丢包，时延稳定在33ms左右。c)在IPTV的现场进行抓包，做RTP流分析发现有丢包。在OLT上行口抓包，抓包方法是根据用户的MAC地址做流镜像，没有丢包。将UA5000连接到MA5680T另外一个PON口上，仍然存在丢包。d)在MA5680T上使用命令查询MA5680T上行口流量抑制信息，发现设备做了未知单播抑制。当流量较大时设备会对未知单播做抑制，即出问题的时候IPTV的报文变成了未知单播。第29页共62页e)在MA5680T上使用命令查询到MA5680T的MAC地址老化时间为10s。经过分析，认为MAC地址老化时间设置过短是导致组播丢包的原因。如果MA5680T在10s内未收到IPTV机顶盒的上行报文，则机顶盒的MAC地址就会被老化。老化以后下行IPTV报文就会被认为是未知单播。由于设备默认配置了未知单播抑制，当流量较大时IPTV报文就被当成未知单播被抑制而造成丢包。当MA5680T重新学习到机顶盒的MAC地址以后，又会对流量进行转发。f)使用命令将MA5680T的MAC地址老化时间修改为300s之后，问题解决。（3）解决建议合理设置PON设备交换功能模块的MAC地址老化时间，建议同意设置经验值300s。3.2.41.不同组播IP映射到相同的组播MAC导致某组播频道节目卡（1）故障表现业务组网：ONU（MA5620E）->OLT（MA5680T）->组播源故障描述：ONU下组播用户收看节目239.0.0.1时经常卡，但是收看其他频道没有问题。（2）故障分析a)检查OLT配置没有问题。用户使用其他组播源播放该节目，故障依旧，排除组播源问题。b)发现当ONU下有用户收看239.128.0.1频道时，该ONU下其他用户收看239.0.0.1频道时就会卡。c)根据协议中组播IP和组播MAC映射的关系来计算，239.0.0.1和239.128.0.1对应相同的组播MAC。由于该ONU是根据组播MAC来转发组播数据的，也就是对于ONU的转发，239.0.0.1和239.128.0.1是同一个频道。当ONU下有2个用户同时收看频道239.0.0.1和239.128.0.1时，ONU会把这两个频道的数据都发送给用户的端口，导致用户的STB同时收到2个组播节目的流量。用户的STB是根据组播IP来判断需要哪些组播流，对于不需要的流会丢弃。但STB的缓存是一定的，如果缓存较小就会导致2个节目流量有部分会被丢弃，用户收看节目卡。d)修改其中一个组播MAC和IP地址，问题解决。（3）解决建议根据组播协议中组播IP和组播MAC映射的关系，组播地址中有5bit没有参加映射，32个组播地址对应同一个组播MAC。通常跨度很大的2个组播IP才有相同的组播MAC，也就是说冲突的几率很小。但是当确实发生冲突时，一个STB可能会收到自己不需要的组播流。STB根据组播IP对自己不需要的流量进行丢弃，如果缓存不够的话，会导致正常组第30页共62页播流的丢弃，业务受到影响。针对这种情况，建议在规划组播地址时，避免映射重叠组播MAC的组播IP出现。3.2.42.OLT与交换机LACP配置问题导致对接不成功（1）故障表现OLT上行使用lacp-static聚合模式连接到交换机。正常配置lacp-static后，有告警，业务不通。（2）故障分析a)检查OLT上行板和交换机两端配置，两端连接的端口均是强制1000M、全双工，光口也正常UP，排除光路问题。b)去掉聚合后，单链路上行业务正常，排除OLT上行口数据配置问题。配置手动聚合，不运行LACP协议。此时业务正常，判断问题出在LACP协议对接。c)交换机支持PAgP和LACP两种协议，默认是采用PAgP。开始怀疑配置的是默认PAgP协议，导致对接不成功，检查后发现配置的协议为LACP。d)将交换机的LACP配置成主动模式，再次检查，问题解决。（3）解决建议LACP分为两种模式：被动LACP模式（默认模式）：端口为被动状态，不主动LACP协商。主动LACP模式，端口成为积极状态，在该端口启动协商。用户在交换机上只配置了LACP模式，但是未启动主动谈判，因此导致与OLT对接不成功。建议OLT聚合上行到交换机时，仅配置LACP还不够，还必须配置成主动模式，以启动双方的LACP协商。3.2.43.POTS配置冗余导致语音业务闪断（1）故障表现ONT（HG850e）上配置基于SIP的语音业务，配置完成后发现语音业务会每隔3分种闪断，重拨仍然重复此现象。（2）故障分析a)检查OLT语音业务配置，配置正常，同时不产生相关告警。更换电话发现问题仍然存在。b)了解到上层软交换是友方设备，怀疑配置可能不兼容，联系局方，检查发现软交换配置没有问题。c)d)检查ONT状态，始终在线，所有指示灯均正常，且更换ONT问题仍然存在。检查ONT配置，发现两个POTS口都配置了号码、用户名和密码，但只有1第31页共62页个POTS口接话机，SIP的重复注册时间设置为180秒，初步怀疑是另外一个POTS口在重复注册时，上层软交换因其未接话机认为信令交互异常导致软交换切断话。e)删除未使用的POTS口配置，问题解决。（3）解决建议ONT(HG850e)有两个POTS口，如果只使用其中的一个，确定使用的POTS口进行配置，未使用的POTS口不要配置号码、用户名等信息。3.2.44.IMS未配置号码属性支持T38导致ONT上传真业务故障（1）故障表现业务组网：传真->ONT（HG850a）->OLT（MA5680T）->IMS故障描述：OLT下挂两个HG850a，分别接一传真机。两台传真机互相传真失败，使用其中一台传真机和现网其他传真机传真正常。（2）故障分析a)在IMS上抓包分析。ONT发起传真时，传真能力协商INVITE消息里携带了T38协议。IMS返回的OK消息里同样携带了T38协议。IMS随即发起的INVITE消息里面使用的G.711，这个时候我们回复了OK里面也选择了使用G.711。b)检查2个ONT的传真业务相关配置，发现在ONT上配置完全一样。但在IMS上其中一个ONT未配置支持T38，导致传真协商的时候选择备选协议G.711。c)在IMS上对两台ONT接入的线路都配置对T38的支持，故障解除。（3）解决建议HG850a对G711和T38两种传真方式都支持。虽然在HG850a上选择T38模式，但如果IMS未配置支持T38，那么最终传真协议还是会选择G.711。SIP语音业务主要由IMS来控制，所以当基本电话接通后如果发现有其他业务故障时，不仅要检查ONT配置，更要关注IMS配置。3.2.45.ONU拨号后要等4-5s才出现回铃音的情况故障（1）故障表现ONU下接电话拨号后要等4-5s才出现回铃音的情况。（2）故障分析a)以上联口作为分水岭。如果在上联口听到回铃音正常，在ONU设备下回铃音不正常，则初步可以判断是ONU设备的问题。b)如果在上联口回铃音已经出现了延时，则基本可以确认是OLT以上出现了问第32页共62页题。基于以上分析，在上联口对语音数据进行抓包。将之还原成语音后，发现在OLT上联口已经出现了回铃音延时的情况，为进一步分析，将包中的RTP流还原成波形如下图：c)分析上图可以发现。收到的RTP流前4－5秒是没有任何声音的，后面才有彩铃。所以RTP流前面是没有任何波的。d)由此更进一步的确认是媒体平台在放RTP流的前4-5S没有放任何声音。是平台设置问题。在与媒体平台工作人员沟通后。平台做了修改。故障排除。（3）解决建议一般来说平台会在接通后直接下发彩铃。但此处平台设置较为特殊，接通后，平台虽然下发了RTP流，但在RTP流中没有加载语音信号，导致前4-5秒没有声音。3.2.46.ONU体彩、福彩掉线故障（1）故障表现某工程ONU下体彩机有时拨号连接不成功、连接上体彩中心后有时掉线，福彩也有偶尔掉线的情况发生，影响客户的正常使用。（2）故障分析a)通过检查用户线路发现用户体彩机处有一个modem避雷器，该器件存在于电话线路上会对modem信号造成损伤；使用用户的账号登陆上体彩中心，ping体彩服务器有400ms-500ms的平均延时，在体彩服务器繁忙时ping有时还有丢包，因modem信号对时延及丢包非常敏感，在400-500ms平均时延及有丢包的线路上存在偶尔掉线的可能；通过查看用户modem的配置发现modem使用的上行速率为14400bps，下行速率为57600bps，在线路上存在信号损伤、线路平均时延为400-500ms、偶尔有丢包发生的线路上使用窄带拨号进行modem连接是不稳定的。b)所以针对上述体彩线路的特点，做了以下改善：c)去掉避雷器，07ONU与体彩机直连将modem下行速率改为38400bps,上行速率仍为14400bps将07ONU体彩端口的jitbuffer设置为60ms在近半个月的观察中，福彩仅掉线2次，因福彩使用V32协议与POS中心交第33页共62页互，最高上行速率为14400，因其掉线率较低，所以不需要对modem速率进行调整，仅将福彩端口的jitbuffer设置为60ms即可。（3）解决建议影响NGN网络上窄带拨号成功率及掉线率有以下因素：1：线路长短查看ONU设备引到用户处设备电话线路的长度，线路越长表示信号在线路上的损耗越大，这时需要通过调整增益来弥补；2：外线状况检查用户线路上否有分机、转接器、防雷器等电子设备，这些设备的存在会对线路上的信号造成损伤，应尽量避免这些电子设备存在于线路上；3：网络状况通过抓包分析网络延时、丢包、抖动等情况，使用用户设备pingPOS中心，当网络延时大于500ms时表示网络情况较糟糕，这时可以联系交换协助排查；当网络抖动较大时，可以通过调整jitterbuffer来弥补，但过大的jitterbuffer会延迟设备对信号的处理，一般只需大于等于对端deltatime即可；丢包因素是最致命的，当网络存在丢包时，请立即排查。4：modem速率在基本排除了以上3个因素后，若用户偶尔掉线，这时就可以考虑下设备modem的速率是不是有点快了。一般窄带拨号的网络状况都不是很好，平均延时大概有300-400ms，且存在某一时间段POS中心异常繁忙（比如体彩、福彩每晚7-8点），POS中心的繁忙会导致POS中心发包间隔不均，会引起网络抖动及延时的增大，所以在这种网络状况下使用高速率modem与POS中心通信会引起速率重协商，协商不过导致掉线，在这种情况下就需要对modem降速了。3.2.47.ONU设备开通呼叫转接引起的故障（1）故障表现该公司共有3部总机22631685，22631686，22631687。用任何电话拨打分机长号28272220后，ＭＧＣ会自动呼转到总机22631687，然后再通过总机拍插簧拨打分机号码5618，将电话转给分机，在分机接通后一段时间后(不到一分钟)，通话自动中断.用任何电话直接拨打3部总机，总机接通后拍插簧转分机短号5618(对应分机长号28272220)，分机接通后不会中断。第34页共62页（2）故障分析a)通过对现场故障包分析，其过程如下：拨打分机长号28272220，Mgc自动转给总机22631687（此端口的端点用户名为AG557）。其中172.31.8.12为MGCip，172.22.68.36为我司设备语音ip。A.总机拍插簧后，拨分机号码5618，将电话转给分机,如下图:第35页共62页B.MGC给分机端口AG529发送ADD消息，将此端口添加到关联中，如下图:MGC给分机AG529放振铃音,如下图:第36页共62页D.分机AG529摘机,如下图:E.分机AG529摘机接通后大约40秒后，MGC给我司onu下发忙音,如下图:第37页共62页F.分机AG529接到MGC下发的忙音后，上报挂机,如下图:b)到此，通话结束，从此过程来看，主要是由于MGC给我司ONU下发忙音后，导致通话中断，MGC没有在主叫方未挂机的情况下给被叫下发忙音。平台修改配置后，问题排除。（3）解决建议该问题是被叫号码经过了2次呼叫转接，第一次是虚拟的呼叫转移，第二次是拍插簧后转接，在接通后被叫方没有挂机的情况下，mgc平台直接下发了忙音.后续通过确认，软交换平台并不能支持这种类型的业务，通过2次转接之后，平台会自动挂断与被叫方的呼第38页共62页叫,导致通话中断。3.2.48.BRAS负载过大导致IPTV节目故障（1）故障表现某地市IPTV业务，该业务在当地多个酒店和住宅都有应用，某酒店也下挂此业务，最后一公里都是由GPON承载业务，用户端都从ONU的FE口出业务到IPTV机顶盒上，该业务通过pppoe拨号和业务拨号认证两次拨号到异地的内容运营服务中获得，故所有的点播和直播业务全部被pppoe封装，我司设备仅作透传，不进行任何组播代理。业务开通以来，该酒店的IPTV业务就会不定期卡画面，每次现象很随机，但比较频繁，同时伴有马赛克，特别是在晚上18:00—21:00的高峰期阶段。（2）故障分析a)通过初期的ONU和OLT上联接笔记本对PING的排查，发现在OLT上联的交换机有重大嫌疑，上面48个端口满载，业务负担过重，协调更换了一部交换机，上面业务较少，更换后发现马赛克现象消失，并且卡画面的现象比前期大有改观，但仍然在晚间高峰期卡，只是没有以前那么频繁。b)进行进一步检查，通过抓包，看到包的拨号流程并没有什么变化，但每次出现卡住画面的时候，就突然性的完全收不到一个UDP的包，而pppoe线程是完好的，没有断开pppoe封装，说明问题并不在OLT，请见下图抓包IOGraphs对比:c)通过这样一个现象，请来了上层BRAS设备和刀片服务器的督导工程师一起协同检查问题。从该地市的不同物理地点，到其它地域测试IPTV，发现都没有这样卡画面的现象，而该地市的IPTV业务都是点播都是来源于同一个刀片第39页共62页服务器，直播则是走不同的出口到IP城域网直至平台。既然别的点不卡，那么说明不同的VLAN到IPTV点播和直播的路由是不一样的，就调查得知此地有三个BRAS设备，每次该酒店STB拨号都是必经BRAS1设备，就锁定瓶颈在此BRAS1设备上。平台工作人员将测试帐号和VLAN做到BRAS3的数据库中，再测了一个晚上的IPTV直播节目，发现再也没有卡过画面，问题解决。之后晚间割接此处用户帐号到其它的BRAS服务器上，以减轻BRAS负担，保障业务质量。（3）解决建议此次故障通过分析发现在故障问题的时候，不能单独只观察本业务的UDP报文来发现问题，通过观察PPPLCP的报文，发现线程仍然连接，问题在上层设备。因为后面有不断的PPPLCP链路维护包在机顶盒和服务器之间来回请求和响应。通过和正常地域的抓包对比，发现故障是就是收不到UDP报文，但pppoe链路正常，通过检查发现是BRAS的CPU负荷超过90%，BRAS上的账号线程被挂死掉，通过割接到其它各个BRAS分担解决该问题。3.2.49.ONU发传真故障（1）故障表现某工程ONU用户发传真传一半后停止，收正常。（2）故障分析在发生传真不成功时，在ONU侧实时抓包：1、通过对第一次测试的抓包发现，在传第一张纸传到一半时，就发出了该页结束的声音，接着发出了传真结束的声音，图示如下：前面第一段黑粗线即是在传第1张纸时的波形图，接着第二段黑粗线即是传真机认为该页传送完毕的波形图，最后第三段黑粗线就是传真机认为传真已经结束的波形图。2、通过对第二次传真测试的抓包分析发现，第9张纸传到一半时，传真机就发出了该页结束的声音（传真机认为这一页已经传送完毕），接着又发出了传真结束的声音，图示如下：前面第一段黑粗线即是在传第9张纸时的波形图，接着第二段黑粗线即是传真机认为该页传送完毕的波形图，最后第三段黑粗线就是传真机认为传真已经结束的波形图。并且在第二次传真测试的抓包分析发现，在传送第五张纸时，出现断了一下，然后又继续传送的现象，图示如下：第40页共62页3、通过以上测试，确认因传真机信号不稳定，更换传真机后业务正常。（3）解决建议传真不成功的原因为传真机自身信号不稳定性引起的，在传真纸还未传送完毕时，发送传真结束信号，从而导致传真不能完全送出故障。3.2.50.ONU宽带拨号678故障的分析（1）故障表现某地的ONU下挂的小区宽带用户，普遍出现PPPOE拨号678错误。（2）故障分析a)用户反映拨号故障的ONU大多集中在其中一个槽位的EC2线卡上，此线卡两个PON分别挂有14个和16个ONU，每个ONU的下挂4到5端用户百兆交换机（24端口），共计有百兆交换机约135台。在高峰期，此槽位接入PC数量达到了700台左右。b)c)根据用户的使用习惯，下午六点至八点，家庭用户会大量的进行PPPOE拨号。根据PPPOE协议的工作流程的发现（Discovery）阶段中，用户PC以广播方式发包以寻找所连接的接入交换机。以获取局端ADSL设备的以太网MAC地址。该广播包为主机广播发起分组（PADI）报文。分组的目的地址为以太网的广播地址0×ffffffffffff，CODE（代码）字段值为0×09，SESSION-ID（会话ID）字段值为0×0000。PADI分组必须至少包含一个服务名称类型的标签（标签类型字段值为0×0101），提出所要求提供的服务。BAS在收到用户主机发送的PADI报文后，会立即发送PPPOE有效发现提供包（PADO）分组报文，以第41页共62页响应请求。d)考虑到该槽位PPPOE用户使用习惯，同一时刻大量的用户主机发送PADI报文的情况经常会发生。后期在OLT上联口的镜像口抓包也证实了这一点。因此对OLT的广播包抑制参数进行了修改，由默认的150包/秒修改为1500包/秒。用户的PPPOE拨号成功率有明显上升。e)在上联口捕获抓包的同时，我们对BAS的回复PADO报文进行了观察，发现BAS的处理回复机制有异常现象。用户发生拨号678错误时，OLT设备正确的转33次PADI报文，而BAS设备在第33次PADI报文发送后才回复了PADO报文给用户主机。以上现象频繁发生在大量用户主机拨号之后，用户随之对BAS平台进行了调整，以上现象消失后，用户的PPPOE拨号成功率恢复到正常水平。（3）解决建议由此类PPPOE拨号678错误的分析中，对PPPOE协议中的发现和会话两个阶段的工作流程要有所了解。用户发送PADI报文后，BAS回复PADO报文，在用户主机在指定的时间内未收到PADO报文的情况下，会重新发送PADI报文，直至BAS回复PADO报文为止。因此造成以上抓包中出现了多次发送PADI报文后，才有一次PADO报文的回复！后续主机用户在收到PADO报文后，会发送PADR报文以确认。BAS在收到用户主机的PADR报文后，立即准备开始会话阶段，在BAS发送PADS报文给用户主机，当软件捕获到PADS报文时，就说明双方进入到PPP会话阶段。3.2.51.ONU下挂无线AP电脑无法获取IP问题的故障分析（1）故障表现某地在使用我司GPON设备,下挂其它厂家AP，我司在WLAN业务中为其提供二层VLAN通道。现场使用PC经常性获取不到IP地址，但可以进行正常的PPPoE拨号。第42页共62页（2）故障分析a)在ONUFE端口上直接连接PC发现仍无法获取IP地址。可以排除AP造成的故障。b)在ONU侧进行抓包，发现ONU侧未能收到DHCP请求报文的回复报文。排除ONU问题。c)在EC2侧进行抓包，发现EC2盘上也未能首到DHCP请求报文的回复报文。排除了EC2盘向下造成的故障。d)在OLT上联口上镜像抓包分析，现场发现PC正常上报了Discover广播包，但未能发现平台下发的Offer包。故障定位在OLT上层控制层设备未下发offer报文导致了故障。e)为进一步验证上述现象，在OLT上联口开通一个untagged端口，此端口VLAN与AP使用VLAN相同，这样就抛弃了GPON系统，有PC与上层设备直接对接，获取到的现象验证了上述的分析结果：用户PC无法获取IP地址是由于上层设备未能正常回复Offer包引起。通过上层设备修改相关参数，用户PC能正常获取IP地址，问题解决（3）解决建议现场我们在OLT上联口、ONU侧、AP侧分别进行了抓包，从报文中发现OLT已经将DHCP协议关键信令（Discover广播包）从OLT上联口转发出PON系统，但是上联口未接收到上层返回的Offer包，从而排除了GPON和AP的造成故障。3.2.52.丢失关键包导致语音断话故障（1）故障表现20ONU下挂语音用户上报拨打电话几分钟后电话断掉。主叫被叫都是一样。查看设备第43页共62页注册MGC状态，端点用户名注册状态都正常。（2）故障分析a)端点域名，端点用户名注册正常，查看心跳配置正常如下：Config\\ngn#SHOWkeepaliveKeepAliveis:Enable.Intervalmaxtimesb):30(s):3KeepAlivemode:Time.通过PINGMGC发现有丢包，在上联口抓包分析为：设备端点域名为10.51.51.254MGCIP为10.2.161.3发现丢包多的时候达到连续丢7个，在网络不稳定的时候如果存在丢包而且丢掉关键的信令包会导致语音问题，延着这一思路接下来通过抓语音信令包来分析。c)通过抓语音信令包分析如下：通过上图抓包分析为设备向软交换发送心跳包如图包序号为1，2，软交换并没有回应。从上图中我们知道丢包应丢在城域网。在通过下图我们确定了导致通话过程中断话的根本原因。通过上图我们发现设备向软交换重新发起了网关注册导致删除了RTP流与关联，导致用户通话中断，而设备向软交换重新发起网关注册的原因为设备向软交换发心跳包软交换没有第44页共62页回应导致设备误以为软交换路故障导致重新发起网关注册。（3）解决建议由于网络丢包丢失了关键的心跳回应包导致了设备重新向软交换发起网关注册导致语音中断，通过解决上层网络问题解决丢包问题来最终解决语音断话问题。3.2.53.MGC链接断开告警频现的故障（1）故障表现某地GPON工程现场，上联为某厂商的AG。与AG对接之际，开通的两部带有语音业务的ONU设备，均报出“MGC链接断开”告警。（2）故障分析a)在此故障发生之前，没有语音开通的成功先例，并且本次开通的2端设备均出现相同的问题，遂怀疑OLT上联的问题。经访查，上联设备为某公司的AG设备，采用的是IP注册机制。b)查看AC16配置中相应配置，发现心跳开关设为1500s，与平常默认30s差别很大，初步判断心跳开关设置有问题，与平台工程师沟通后，调整开关时间900s,问题仍然存在。遂现场抓包，故障数据包进行分析。c)归纳分析结果为以下几点：PON设备采用ntfyH/co2进行心跳控制，但这方面平台并不支持。平台通过其它的事件来实现类似心跳的功能：x-keepaliveorL/x-keepalive平台设备上目前只加了:aaln/0@[222.168.219.61]，aaln/3@[222.168.219.61]，aaln/4@[222.168.219.61]由于aaln/1@[222.168.219.61]注册包没得到回应，其网管认为链路断。通过以上分析，做出相应调整：关闭心跳开关，将未“放号”的预设置全部关掉，经观察，再无告警报出。（3）解决建议该故障产生原因为，初期开通ONU时为方便用户开通业务，做了大量的预配置，即GPON上配置了所有ONU端口的语音业务，但是软交换上面没有配置那么多号码。这样造成预配置的语音业务不停的向软交换平台注册，大量的注册信息造成MGC链路上的拥堵，导致有第45页共62页号码的注册等待时间过长，未得到注册，遂报出MGC链接断开（此问题升级软件至语音V1.2版本可彻底解决）。另外，双方的心跳机制不同，应关闭心跳开关设置。3.2.54.无回铃音故障处理（1）故障表现某住宅小区OLT下的ONU下一用户拨打87128063电话无回铃音，但是对方有正常振铃并且摘机后双方正常通话。（2）故障分析a)经现场证实，该ONU其它端口用户拨打该号码均为拨通后听不到回铃音，但对方正常振铃且摘机后双方通话正常，拨打其它任何号码均正常。由此定位为平台业务号码问题，经过在ONU处抓包，提取了RTP流，保存为au文件后用电脑里的MediaPlayer播放，确实回放出了回铃音，此情况又与现实相冲突。b)采取抓包获取拨打其它号码正常回铃音的情况，从包中看到了果然有出入，即正常回铃音的号码仅仅就是远端媒体服务器播放了回铃音，而拨打故障号码的是不仅有远端媒体服务器播放的回铃音，还有平台下发的cg/rt要求ONU本地放回铃音。第46页共62页c)要求平台去掉该号码的远端媒体服务器下发回铃音，仅由平台下发cg/rt信令由ONU本地播放，用户正常听到了回铃音，故障解决。（3）解决建议平台对该号码数据进行修改，放回铃音由平台下发cg/rt的信令放本地回铃音，而不通过媒体服务器放远端回铃音，就可以解决。3.2.55.拨号数图格式问题导致二次拨号故障（1）故障表现某处开通FTTB业务，使用普通语音业务均正常，但某用户投诉该处一商务领航业务有故障，故障为企业内部呼叫转接业务不能正常转接。商务领航二次拨号业务流程如下：FTTB_ONU的语音端口被叫，被叫后总机摘机，通话后总机按照主叫方要求转接其它被叫部门的分机上（即该处同一ONU上的其它语音端口或不同ONU上的其它端口），具体操作时通话时拨“*#”，然后平台放二次拨号音，之后主叫听到回铃等待音，其它被叫部门的分机振铃，分部门摘机后正常通话。该处现象为被叫后总机摘机，通话后总机按“*#”，此时平台放正常拨号音，总机再拨短号，拨完短号后平台放忙音。第47页共62页（2）故障分析a)通过现场重复波侧，发现每次问题现象相同，再通过抓包，我们发现信令流程从被叫、通话、拨“*#”、放二次拨号音的信令都正常，只是拨号上报则无法正常匹配，之后平台放忙音。但仔细观察被叫的二次拨号，每次拨号后都是上报为ds=“”，Meth=PM，此时怀疑平台拨号计划有出入。b)我们再次仔细核对平台下发的拨号计划，我们确实发现拨号计划数图有问题。在其中找到拨号计划最后两个拨号方案中，多设置了一个反括号，造成用户端拨号上报不正常，内容如下图：c)错误：|911x)|EF)}而H.248语法中正确的应当是：|911x|EF)}将该情况向平台方面作了阐述，并且发送了截图及邮件，平台后期进行了升级调整。在平台升级调整之后，我们再次在该处拨测，发现拨“*#”后二次拨号音正常得到，拨短后听到正常回铃音，分部门被叫端正常振铃，提机后正常通话，故障解决。（3）解决建议数拨号数图中，每一个号码表中间应用“|”分隔符，而包中拨号方案“911x”和“EF”第48页共62页中则使用成“)|”来分隔，即整个数图被表示成了“DM=dmap1{())}”，而此处正确的应当为“DM=dmap1{()}”，故多设置了一个反括号，不匹配，造成语法错误。由于数图为平台方发送，我方无法作修改，平台作升级调整后才使问题解决。同样的拨号计划在其它地点也出现过，也为“|911x)|EF)}”，故障现象也一样，故两处都是用的平台同一个拨号计划模板，并且包中还有Megaco的协议报错内容，内容为“ERRORDescriptor:ER=401{\"SyntaxError:Line1,Column718\”，表示语法错误，在第一行第718列，指的正是该拨号计划的结尾部分。3.2.56.语音业务通信中断后，不能自动注册（1）故障表现某FTTX工程OLT设备下带两个型号的ONU开有语音和数据业务，onu停电，等来电设备重新上电后，语音业务不正常，需要多次重写配置，才能注册成功。语音协议使用MGCP。（2）故障分析a)首先，找一个故障点，然后做镜像抓包，如下图所示：b)从抓包分析来看，onu在通信正常后，就会给软件换平台发注册消息，但此软件换平台给onu回的是一个400的错误码，是一个临时不执行的错误，只有连续多下几次配置，也就是多次向软交换平台发起注册，onu才能注册上，平台才会回200ok的消息。c)为进一步查找故障原因，让软交换平台也做信令跟踪。通过软交换平台的信令跟踪发现，MGC向下发的审计消息，如下图所示：第49页共62页d)和软交换平台工程师联系沟通后，发现信令跟踪的是MGC与SBC间的信令，根据从onu侧抓的包和MGC侧的跟踪信令可以说明SBC没有转发onu向平台发的注册消息。因此，初步可以判断是上层平台的问题导致onu注册不上的。e)最后，软交换平台工程师在查找原因时发现，所提供的软交换平台地址为备用地址，将注册地址修改后，故障消失。（3）解决建议从此次故障来看，通过抓包发现onu在注册时，软交换平台给回的消息为400（临时不执行）的错误，那么就需要平台给出为什么不执行的原因，最后通过平台侧的工程师协助查找，发现是所提供软交换平台地址错误导致的。3.2.57.ONU下联设备ARP攻击导致同一PON口下所有用户pppoe拨号678故障（1）故障表现某处运营商网络使用GPON设备，下挂的ONU全部为FTTB设备。某日该OLT有一个PON口下带的FTTB用户出现拨号678的故障，但拨号并不是每次都拨不上，有时拨号十次或二十多次偶尔还是能够成功拨到BRAS的，拨通后宽带业务使用正常，无掉包或网速慢等问题。第50页共62页（2）故障分析a)首先对该处进行OLT上联、ONU下联进行PING包处理，目的是检查整个通路到BRAS的情况。在某个故障点的07A设备接一部电脑，在OLT上联空的电口接一部电脑，使用同一VLANPING包，PING包10000个后发现只丢一个包，丢包率近0%，故无物理通路故障。b)继续检查OLT设备的FDB表，以及投诉点07A设备的ARL表。当我们进行拨号的时候，可以在29槽看到上层8505交换机的MAC地址，也可以在EC2槽位上看到用户拨号电脑的MAC地址，并且业务VLANID正确；同时看07A设备ARL表，可以看26口上学到的8505的MAC，也可看到用户端口学到的用户电脑的MAC，且VLANID正确。由以上信息可以证明在设备内部的VLAN学习及地址转发情况都是正常的，而且一但拨上后业务一切正常，PINGDNS都是良好，说明上层设备也正常，但始终pppoe拨号十分困难。c)继续在OLT上联口做拨号测试，挑空电口做测试，发现每次拨号都能成功；再进一步了解情况，做各处的拨号测试，将故障范围缩小在了一个PON口上，即其它几个PON口拨号都正常，仅一个PON口下的共计10台ONU拨号不正常。怀疑存在环回，再检查FDB表，对比29槽和该槽位的地址表，并未发现有EC2板存在上层设备地址的情况，而且此处也设置了ONUACL，已经杜绝了下联ONU端口环回情况，但不能排除ONU下挂交换机的硬件环回情况，因为此处有大量FTTB_ONU下挂或级联交换机的情况。d)再继续从抓包分析入手，分别在镜像ONU上联、EC2前面板、OLT上联口等三处同时安排人员，各挂一台电脑，将每次pppoe拨号包的流程进行抓包。实施后发现PPPOE拨号的PADI广播包不是每次都能到达上联口，直到成功发送出上联口才能收到BRAS的PADO回复，那样才能成功拨号上网。而我们从某次pppoe发包，ONU端抓包发现共发送了两次拨号直到第7个PADI广播才收到PADO回复，对比EC2抓包，只收到了总共3个PADI广播包；而上联口当然只收到了一个PADI的广播包，也就是最后一次拨号成功了。反复进行了多次pppoe抓包，都是随机第51页共62页性的拨号成功，有时候拨号十几次才拨号成功。从上述情况看就是因为PADI广播包在ONU->EC2丢失一次，在EC2->GSWC->GUP7丢失一次。请参考下图，ONU处总共发出7次PADI才成功的流程：e)得知故障根源后，要确定是什么缘由导致丢弃PADI包才行。OLT系统内部有广播包的门限，AN5116-02系统内部每个PON口的广播包带宽是2048kbit/s。再次抓包，并且不过滤包，终于在包中发现有一个MAC为00:27:19:5d:61:62的设备不停的向上层发送大量ARP广播包，不停的查找192.168.1.1的地址是对应哪台设备，它完全把目的地址为ff:ff:ff:ff:ff:ff的广播类型带宽资源占用耗尽，这很明显这是属于病毒包。找到该包的VLANTag值，立即找出了对应的是一台AN5006-09A设备的端口，立即屏蔽掉该端口业务，发现拨号每次都能正常了，故障解决。赴现场发现该台09A下面下挂一台交换机，这个交换机上没有做任何设置，默认的VLAN1也没有关闭，导致不停的向上发送ARP包，造成广播类型带宽资源耗尽，致使正常用户拨号受阻。请看下图，大量无用ARP广播包：（3）解决建议GPON设备中都有一个包抑制功能的设置，其中有广播包、多播包、目的地环回失败第52页共62页包等类型的门限设置，广播包门限默认设置为62kbit/s，也可以用setstormport[1-24]enable1bcast62设置门限（出厂一般都是62kbit/s）。由于组网时，ONU侧的FE口有下挂多个交换机或级联的情况，不可避免的造成了网络复杂化，也很难杜绝一些硬件环回和病毒包的泛滥，而07ONU等设备下有门限设置，即使存在下游设备问题也不会影响PON口的上行广播包带宽。而AN5006-09A设备早期固件版本不支持上行包的抑制功能，导致09AONU下带交换机产生的大量ARP广播包上行到EC2盘PON口，同时pppoe协议中的PADI包是广播方式通过EC2盘和GSWC盘上行到BRAS，导致用户发出PADI广播包上行到EC2盘后被丢弃，引起PPPOE连接不能成功，因此用户端电脑拨号出现678错误无法上网。对于5006-09A型ONU可以有两种方法解决此问题：1、查到此大量广播包的端口，屏蔽此端口，然后查清广播包问题来源，进行处理；2、升级5006-09A设备为最新固件版本，可以进行广播包抑制，避免此故障发生。推荐采用第二种方法。另外关于抓包分析，平时分析故障抓包总是通过过滤等手段逐步细化定位问题，虽然某些问题如语音可以通过此法逐步定位问题，但此次故障仅过滤pppoed报文不能完全定位出问题，相反抓包不过滤看全部的包，才能发现是其它的ARP攻击包占用了广播包带宽。同时抓包需要在OLT的上联口，EC2盘上，09AONU的端口上分别抓包，分析PPPOE协议的报文是否正确。3.2.58.IPTV业务HTTP页面失败故障（1）故障表现用户的IPTV业务应用中，观看大部分频道节目正常，就是唯独新闻频道无法正常收看。（2）故障分析a)现场处理测试把机顶盒放在设备上联口单VLAN测试，结果正常。放在用户处无法正常收看。根据现在捕获的信令消息，分析如下：如上图：在NO.4报文的位置，用HTTP协议（TCPPSH）GET操作尝试从服务器58.223.251.72获取新闻频道的内容.接着服务器也响应了该请求。（TCPACK）如下图：第53页共62页接下来，等待了15s服务器却未应答HTML请求成功（HTTP/1.0200OK），也没有发回任何HTML资源，于是在15.57s的时候结束了TCP连接，如下图：异常时，HTTP协议并未应答成功，于是机顶盒一直去尝试用GET获取HTML资源。b)在怀疑上层服务器未应答的同时，在捕获下来的正常的过程中，我们发现了问题所在。在机顶盒以同样GET方式请求服务器资源的时候（TCPPUH），服务器也像刚才那样用(TCPACK)给与响应，但与之前不同的是，这次服务器开始传输HTML资源的内容（第103的报文开始包含了HTML请求的应答200OK,后续为HTML资源内容）。如下图：HTTP协议请求服务器端服务成功（HTTP/1.0200OK）c)再观察上面帧的长度达到了1514，不带VLAN的帧是1514，加上双层VLAN，帧的长度就达到了1522.再去看下主控盘交换芯片的最大帧长度为1518，这样的下行应答报文主控盘不让过也就不足为奇了。第54页共62页（3）解决建议在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；SYN：同步序列编号(SynchronizeSequenceNumbers)第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。完成三次握手，客户端与服务器开始传送数据，流程如下:上述故障是由于TCP协议在三次握手失败，导致创建TCP连接失败，故障出现。导致TCP握手和建链失败是由于OLT上的MTU值了包的大小。通过修改增大GSWC主控盘的最大帧长度解决了故障3.2.59.三方通话问题处理（1）故障表现测试三方通话时拍叉簧之后中断。（2）故障分析a)b)检查拍叉簧之前通话情况正常。察看抓包，检查拍叉簧事件是否上报，确认已经上报，如下图：第55页共62页c)察看拍叉簧之后抓包，发现收到数图之后，ONU回复了错误，如下图：第56页共62页d)根据此错误提示，应该是数图中存在语法不支持，导致回错。与软交换配置人员沟通后，确认为软交换数图配置错误导致，软交换更改配置后正常。（3）解决建议从上面数图截图可以看到，在数图的最开始有一个正括号，开头具体为([2-8]……..，但是在数图的结尾处却没有看到对应的反括号，结尾具体为13xxxxx，故导致语法错误，从而不通。3.3.其他故障案例

3.3.1.单路电源功率不足导致设备频繁重启（1）故障表现GPON主控板GCSD主备同时在位时，出现不断重启的现象，且很长时间无法启动。（2）故障分析a)因为之前有出现过类似的情况，所以首先判断是CPU过热引起的，此次是初次加电，应该不是CPU过热引起。b)怀疑备用主控板有问题或是主备通信异常引起的，于是将备用拔出来，此时主用启动正常，再将备用插进去以后，整框立即重启。c)为了进一步判定是否是备用主控板的问题，将备用主控板插入到主用的7槽位，此时能够正常启动，再将原主用主控板插入8槽位后，整框立即重启。由于单个板件都能正常启动，所以排除板件和槽位的硬件因素。d)分别查看主备主控板的版本情况，发现版本不一致。将版本升到一致后，现象依第57页共62页旧，也就是版本的不一致只是有可能引起业务的某些故障，但是不会导致这个故障现象。e)仔细查看现场环境，发现只外接了一路电源，将另外一路电源接上后，现象消失，故障排除。（3）解决建议GPON局端设备工作时，须要保证同时接通主用电源和备用电源，尤其当局端设备做主控板卡或线路板卡热备份的时候会增加设备功耗。3.3.2.电压不稳定导致ONU反复上下线（1）故障表现某局OLT下接的一台ONU无规律的反复上下线。（2）故障分析a)b)c)由于此PON端口下接其他ONU都正常，因此排除OLT的PON单板故障。使用光功率计在ONU侧测试光纤衰减为正常(-20dB)，排除线路原因。因为出现故障的ONU在较为偏远的山区，怀疑是周围环境因素导致。通过EMS查看ONU告警信息，发现连续四天都是在早上7点到晚上8点用电高峰期ONU发生重启，初步判断为电压问题。d)在现场使用万用表测试电压，发现电压不稳定，导致ONU反复重启。将此ONU更换为带有直流电模块的ONU后问题解决。（3）解决建议华为的ONU设备有交流供电和直流供电两种供电方式。如果设备采用的是交流供电，在电压不稳定的时候会导致设备反复重启。如果电压不正常且不能保证正常电压，建议用户选择使用带直流模块的ONU设备。3.3.3.板卡温度异常引起ONU不能同步（1）故障表现某个GPON端口有时能同步，但是同步时间不长，重启设备或者复位单板后故障依旧。（2）故障分析a)在OLT上showonu状态，提示ONU正在同步。重启设备或者复位单板后可以同步，但是不久ONU又显示出在同步中。b)拔出单板检查硬件，此时发现单板温度很高。关掉设备电源，单板冷却后加电，能同步一会，然后有进入正在同步状态。c)仔细检查硬件，发现风扇没有安装，导致单板温度过高。由于PON口速率很高，发热量大，没有风扇导致PON口光模块发光功率不正常，ONU不能同步。第58页共62页d)安装风扇，故障解决。（3）解决建议要注意设备的运行状态，尤其是对温度的监控。3.3.4.OLT机框内单板之间软件版本不匹配导致的故障（1）故障表现C220EIG上联板ACT指示灯不亮有如下两种故障现象：a)将EIG上联端口和局方的路由器连接，发现该端口对应的ACT灯不亮，使用“showinterfacegei_..”命令，发现该端口的状态是UP的。b)将EIG上联端口和局方的路由器连接，发现该端口对应的ACT灯不亮，使用“showinterfacegei_..”命令，发现该端口的状态是DOWN的。使用光纤，对上联端口进行环回，现象依旧。（2）故障分析经过检查，发现EIG板上的版本，和主控板使用的版本不一致。升级EIG板的版本以后，ACT灯能够正常工作。（3）解决建议网元各个单板之间的版本一定要统一。3.3.5.备用主控板无法正常启动（1）故障表现备用主控板一直处于“HWONLINE”状态，无法进入“INSERVICE”状态。重启备用主控板也无法解决，查看结果如下：ZXAN#shocardRackShelfSlotCfgTypeRealTypePortHardVerSoftVerStatus-------------------------------------------------------------------------------005GPFAGPFAB4V0V1.1.3T10INSERVICE006EIGEIG4V1V1.1.3T10INSERVICE007GCSDGCSD0V1V1.1.3T10INSERVICE008GCSD0HWONLINE009EIGEIG4V1V1.1.3T10INSERVICE（2）故障分析a)通过串口登陆备用主控板，手工重启备用主控板（或者是插拔备用主控板），在串口消息中看到提示\"PressENTERkeytostopauto-boot…\"信息后，敲回车键停止系统版本的自动加载，进入boot状态。如下：Boardname:GCSD第59页共62页Bootversion:V1.1.3T5Creationdate:2009-05-1005:03:25Copyright(C)2009ZTECorporationAttachedTCP/IPinterfacetomottsec0.Attachingnetworkinterfacelo0...done.Mountingfilesystem...done.maincardparametersectioninited!checkingversionfileDirsuccess!b)c)使用\"format\"命令，将flash进行格式化。格式化以后，系统会提示是否需要重启，此时输入“y”重启备用主控板，让备用主控板重新下载一次版本。d)如果使用上面的方法，备用板依然无法从主用板获取版本，则可能是备用板的boot版本太低，和主用板的通讯有问题。此时，可以将网线接到备用板的Q口上，直接从计算机上更新备用板的版本。（3）解决建议备用主控板在启动过程中，从主用的主控板下载版本失败，导致一直无法正常启动。将备用主控板的版本清空，重新进行启动。3.3.6.电磁干扰引起上联口时通时断问题（1）故障表现某地市OLT所有下挂ONU用户业务同时中断几分钟后又自动同时恢复并持续出现，频率每天20次左右，使用的是电口上联。（2）故障分析a)在网管上检查配置，无问题。检查这些故障用户的拨号中继，发现未发生带宽拥塞的情况。b)在OLTPING网管IP，发现有时断时续的丢包现象，在上联口镜像并同时在上联交换机镜像抓包，经过分析数据包，PING包已从上联口处发出，但上联交换机处未收到，断定丢包发生在OLT上联口与交换机对应端口间。c)检查上联线路，由于机房环境简陋，没有标准的走线架，上联网线经过一端第60页共62页电源列头柜并与其他设备电源线混合走线。d)将上联网线重新走线，该故障现象消失。（3）解决建议电源柜周围存在电磁波干扰，而影响上联网线的通信质量，建议以后的施工中注意走线路由，不能与电源线混合走线。4.PON网络故障排查建议

从目前已经发现的PON网络应用问题看，PON网络在组网应用中的故障主要来自光网络层（即光链路）和业务应用层。4.1.光网络层故障排查方法

光网络层故障的通用排查方法主要有两种：在线测试和诊断；离线测试和诊断。两者的主要区别在于是否会由于测试和诊断的执行而导致正常通信质量的明显下降甚至业务中断。4.1.1.在线测试和诊断对PON光网络层执行的在线测试，包括三个基本内容：1）性能监测与预警通过定期测量光链路的物理层参数（接收光功率，发送光功率，光模块工作温度、偏置电压、偏置电流、OTDR发射脉冲强度和位置等工作状态参数）并对历史数据进行关联分析，实现对光链路性能的监测，并提供预测和预警功能。2）实时测试可根据实际需求，对PON光链路执行不同类型的实时测试，如对光链路各部分的测试，设备自动发起测试等。3）故障诊断基于对测试结果的分析，实现对要求排查的故障进行判断和定位。PON光网络层的在线测试可通过下面三种手段来实现：OLT/ONU光模块集成测试功能外接测试设备通过复接设备接入PON系统不仅在OLT/ONU光模块集成测试功能，同时ODN网络上也接入外接测试设备4.1.2.离线测试和诊断对PON网络光链路执行离线测试，主要包括两种情况：一是PON网络竣工后，终端设备和局端设备尚未部署时，利用外接测试设备对ODN可靠性进行测试；二是网络出现故第61页共62页障且业务由于网络原因已完全中断，此时不得不在ODN上接入外置设备进行测试。当有外接测试设备时接入PON系统的ODN时，为确保PON系统工作波长的正确接收，ONU设备必须具备有将外接测试设备测试信号波长阻塞或反射掉的功能模块。该波长阻塞/反射模块可以外置于ONU设备之前，也可以集成在ONU设备中。4.1.3.PON光链路自动测试和诊断系统由于PON网络由大量的主干光纤和分支光纤组成，因此在规模部署PON网络后，接入层的光纤网络密度和长度将大量增长，如果仍采用人工维护方式，日常的运行维护工作量将会急剧增加，因此，开发一套光链路自动测试和诊断系统，通过动态监测光信号的质量，并通过专家系统预测系统的寿命和定位故障位置，从而实现光纤网络维护自动化，将是PON光网络层故障排查的理想方式。一个典型的PON光链路自动测试和诊断系统功能模型如图2所示。图2PON光链路自动测试和诊断系统功能模型图2所示的PON光链路自动测试和诊断系统可完成下列主要功能：系统开通前用户链路检测系统日常修障维护支撑系统性能监测在实际运维时，根据运营商的不同组网和差异化的业务需求，对测试诊断系统可进行合理化的扩展配置，藉此获得更全面的测试和诊断效果。4.2.日常业务数据配置建议

分析各种故障案例可以发现，业务应用层故障主要是由业务的各项参数配置错误或参数不匹配引起，故障排查主要依靠人工检查数据来实现。为了尽量避免此类故障的发生，有如下建议：（1）新开局时，线路人员应将所有相关资料，如组网方式、数据分配等交接给调试人员，使调测人员明确知道诸如主备PON口位置等线路信息，从而正确配置数据。（2）配置数据时，OLT与BRAS双方维护人员应协商好数据配置，包括VLAN设置，第62页共62页端口模式等。第63页共62页