EPON典型故障处理方法汇总12月版zhwfang教学文案.doc

Good is good, but better carries it.精益求精，善益求善。EPON典型故障处理方法汇总12月版zhwfang-目录设备问题3一、呼叫转移故障处理技术案例3二、未知包引起语音断断续续故障处理5三、关于07型ONU出现的误摘挂机的情况说明5四、关于北京清河局OLT2_4003外层VLAN用户拨号676错误报告6五、同一个PON口下15型ONU上联EUP2盘引起其它15ONU传真的问题7六、modem掉线问题的处理10七、07ONU下接MSAN设备上网时延大处理10八、打包间隔不一致导致传真问题的处理方法11九、传真机模式错误导致传真失败问题处理12十、高科iad的payload值影响传真处理案例13十一、5006-07杂音问题处理案例15十二、5116-02的AC16语音代理问题处理16十三、AN5006-03/04/09AONU下挂wlan等设备未知包问题处理案例16十四、07B-ONU传真问题18十五、AN5116-02下挂07ONU催挂音超时处理问题22十六、930OLT版本后ONU下挂AG,DSLAM等设备优先级注意问题26十七、payload为特殊值导致传真故障处理案例28十八、用户拨号有时提示忙音处理案例29十九、IP冲突导致语音不通处理案例30二十、外部电压不稳造成AN5006-16语音中断处理案例31二十一、15ONU设备语音业务被叫自动挂断故障案例32网管技术问题34一、ANM2000在Win2003SP2上运行间歇服务中断问题说明34二、网管配置过大导入不成功处理方法36三、网管内存过大导致数据库服务无法启动案例36四、AC16上联用户信令数据配置无法读取故障处理37五、42SP1网管无法对ONU端口进行业务配置问题处理37六、网管下AC16配置失败故障39七、客户端常报“数据库已修改”问题41八、计划任务不能启动处理案例41-设备问题一、呼叫转移故障处理技术案例【网络拓朴】【现象描述】端点用户名为AG58900,07ONU（R3.07.05.56），需要开通呼叫转接功能，软交换平台数据已做，用户在进行呼叫转接时，拨完*57*后有拨号音，继续输入转接号码时出现忙音。【处理过程】1、 通过命令行查看明确匹配及上报功能，确认没有打开；查看命令：Configprotocol#shdigNotifymatcheddigitwithtypeunambiguous:disableNotifymatcheddigitdelay:255通过抓包分析软交换下发数图，发现数图定义不标准，如下图：在红框表示的数图中规定为EF0-90-9E.EF，表示前三位接受相关拨号后，第四位如果输入“*”（E表示*）或者“#”（F表示#），都表示拨号结束，将立即上报所拨的号码，则IAD收到“*57*”后就把号码上报给软交换平台了，如下图：这样就造成拨号没有结束就上报了号码，导致转接不成功。2、 和软交换平台协商，把数图改为EF0-90-9E.F后问题解决。【故障分析】数图的定义不符合标准。由于某些软交换是这样配置的，故我公司后期软件也将更改可以符合这种不标准的数图。【相关资料】二、未知包引起语音断断续续故障处理【网络拓朴】组网主图【故障分析】在没有上15-onu之前，在网运行AN516-02(OLT)，下挂2台07B型ONU，共开通语音业务29户、数据业务1户，至开通业务以来，没有用户报障情况。但新近加装15-onu后（开通96户语音，15户数据），07B和15-onu下的用户都出现了“外线拨打15-onu下的用户号码，被叫方听语音正常，主叫方听语音出现断断续续的现象，即上行方向有阻断”。通过如上图所示红点处抓包分析的结果来看当15-onu与外线通话时，确实存在RTP流丢包情况。在RTP流建立之前，15-onu与软交换平台的信令流交互过程中，信令包正常而且完整，可以排除线路问题和网络丢包情况。如下图所示：凡是从平台-ip到15-ip的RTP流都没有丢包，即下行方向，15-onu下用户听对方语音是清晰的。而从15-ip（10.33.210.26）到平台-ip的RTP流出现了不同程度的丢包情况，严重时达到43.0%，即上行方向，外线用户听15-onu下业主的声音，就出现了断断续续的情况，故障原因即为：15-onu上行方向RTP流丢包所致。【故障具体原因】经技术人员对抓包数据的进一步分析表明：当15-ip向上发ARP包时（10.33.210.26ping10.33.210.1），目的MAC地址是00:00:5e:00:01:c9。但网关-ip返回的包中（10.33.210.1回复10.33.210.26），源地址是00:1a:f0:67:76:74，与前面的目的MAC地址不一致。通常情况下，我公司15-onu上AC16盘的MAC地址表中是一个IP对应一个MAC地址，但现场实际的情况是同一个IP（10.33.210.1）对应了两个MAC地址，使得AC16盘认为上层回复的包都是未知的包，即unknown的包，同时也认为与MAC地址00:1a:f0:67:76:74对应的上行方向语音包也是unknown包。通过与相关人员沟通，出现一个IP对应两个MAC地址的情况是上层的贝尔7750路由设备出于主备保护的原因，特意作此设置的。由于我公司推出的15-onu属于FTTC型，07B属于FTTB型，前者在设计时，考虑其128户的最大接入能力，通过其FSWB盘实现：广播包抑制功能、多播包抑制功能、unkonwn包抑制功能，避免在内网出现广播风暴、病毒攻击时出现设备端口被冲死的情况。所以在白天业务繁忙时，15-onu下多个用户拨打或接听电话时，其内部会产生大量unknown包，当达到设定门限时，unkonwn包抑制功能启动，丢弃了这些unkonwn包（具体数量根据当时的通话线数而定），而这些包实际上是用户正常通信的语音RTP包，所以上行语音出现断断续续的情况，是因为这些RTP包被当作unkonwn包抑制了。为什么对原07B-onu产生影响？实际上，15-onu在设计上沿用了OLT的方式，可以把它看做一个小型的OLT，都具备广播包抑制功能、多播包抑制功能、unkonwn包抑制功能。07B属于FTTB型，它自身没有unkonwn包抑制功能，而15-onu出厂默认的unkonwn包抑制数量是150个/s，一旦超出，就出现该故障现象，这也是为什么每天17：00之后，业务量减少后，故障现象消失的原因。当两型号都在同一PON口下时02-OLT可以插16块EC2盘，每盘2个PON口，共32个PON口，它们相互隔离，unkonwn包抑制是按照每个PON口来工作的。当新上的15-onu与两台07B-onu共PON口时，如果15-onu上的unknown包数量没有超过15-onu的门限，onu就会放它继续上行，但在该PON口通道内，再加上从07B上来的unknown包（自身不具备抑制功能），两者一叠加，数量就有可能超过02-OLT的unknown包抑制门限值，所以两种型号onu上都出现故障现象。当两型号onu分别在两个PON口下时07B下有29户，15-onu下有96户，所以当15-onu上话务忙时，unknown包越限，15-onu自己就抑制了，控制了未知包的继续上行。这时02-OLT，主要面对的就是07B上来的unknown包，因07B下同时通话超过限制的几率相对15-onu较低，所以分开到2个PON口下，07B就没有被影响。【处理过程】把02-OLT和15-onu的unknown包抑制门限从150改为1500，相当于可同时让50线语音用户通话不受影响，故障现象已排除。三、关于07型ONU出现的误摘挂机的情况说明最近在几个省份陆续出现了07型ONU在下挂智能电话或是较高级的其他类型的电话是出现误摘机的现象。1. 主要现象如下：主叫正常，被叫时振铃一声就自动断掉了。换成别的话机就是正常的。出故障时从抓包来看在振铃0.6s后，出现了al/on的挂机信号如下图在5.3s时ONU上报摘机，但5.9s却自动上报了挂机。之间只有0.6s的时间，明显不是人为挂机。（MGCP协议也有类似的情况）2. 原因分析：出现故障的话机一般为智能话机或功能较多的高级话机。此类话机工作时所需要的电流主要来自两个方面，一是本身自带的电池或电源，二会从电话线上取得一部分电流。这样问题就出现了。正常情况下，在用户没摘机的情况下，电话线上是没有电流的。但出故障的高级电话，由于自身工作的需要会从电话线上取得部分电流，而此时在电话没有摘机的情况下，电话线上却有了电流，于是我们的onu根据线路上有了电流这一点判断认为用户已经摘机，故放了al/of摘机信号，但此时电话实际是没有摘机的，属于误判摘机，所以响一声就断了。3. 解决方法：研发提供了升级包，主要是提高了ONU对摘机的判断门限。目前主要针对故障07onu进行升级解决，正式软件3月20日之前将释放，等待软件正式释放后再大面积升级。四、关于北京清河局OLT2_4003外层VLAN用户拨号676错误报告1、现象描述1月18日清河局第二框AN511602设备出现所有外层vlan为4003的用户，PPPOE拨号均返回676错误的问题。2、分析过程Ø 仅外层vlan为4003的用户受到影响；Ø 经过查看主交换盘的mac地址表发现vid为4003的BRASmac地址学习到了槽位端口上，导致所有外层vlan为4003的，目的mac地址为BRAS的单播数据流发送目的地错误；Ø 怀疑是用户家外接网络发生环路或者用户电脑中毒，通过查看onumac地址表的方式找到了发生问题的用户端口，确定用户；Ø 后发现用户家ONU下挂路由器的两个端口用网线连接形成环路导致下行方向BRAS发出的报文又环回到设备，进一步引起系统mac地址学习发生错误。解决用户外接环路后，业务回复正常。3、 解决办法最终解决方案：建议通过配置远端onu过滤规则的方式解决该问题。操作步骤如下：用户仅需操作第一步。第一步：在网管上配置过滤规则，过滤规则为源mac地址等于BRASmac地址（如果有多个BRAS需要配置多条）；第二步：设备收到配置后会自动对当前所有在线onu进行配置，所有从用户侧端口收到的源mac地址为BRASmac地址的数据包均被丢弃；第三步：对于以后上电的onu或者以后新增的onu，系统会在该onu上电注册后自动将过滤规则下发。临时解决方案：4、 对于FTTHonu可以配置用户端口绑定解决该问题，配置方式为：源mac地址不等于BRASmac地址的数据包允许通过。时间进度解决该问题需要升级主控盘软件和EC2pon业务板卡软件（onu软件不需升级），按照目前正规的工程问题解决，发布流程，初步计划在二季度末正式释放解决该问题的版本。五、同一个PON口下15型ONU上联EUP2盘引起其它15ONU传真的问题【网络拓扑】AN5116-0215ONU115ONUnODN1：8【现象描述】某运营商EPON工程反应有一端OLT的EC2盘同一个PON口下带的四端15ONU，有三端15ONU同时出现传真业务失败，但是语音业务正常，一端15ONU传真业务正常。现场人员检查15ONU的PON光功率正常。同时更换了EC2盘，以及1：8的光分路器，故障仍然无法解决。【处理过程】现场人员在发送传真失败时，同时在EC2盘抓包，发现RTP流中最大有1.8%的丢包。如下：在传真业务正常的15ONU的上联口抓包发现没有丢包，同一个PON口下，一个15ONU传真正常，三个15ONU传真不正常，同时在OLT的上联盘GE3口建一个语音业务VLAN，端口设置为UNTAG，将PC电脑的IP设成与15ONU的AC16IP同一个网段，在上联口用PC去PING15ONU的AC16IP，现场传真正常的15ONU的IP为10.37.111.6，另外三端15ONU的IP分别为10.37.111.2,10.37.111.3,10.37.111.4。将本机电脑IP设置为10.37.111.253,这时电脑去PING10.37.111.2发现有丢包，如下：同时PING10.37.111.3,和10.37.111.4都有丢包。但是PING10.37.111.6的ONU，此时发现没有丢包。通过以上测试说明传真业务失败与丢包有关系，而且丢包就在PON内，从EC2盘PON口到15ONU的PON口之间有丢包，首先定位到是EC2盘问题，于是更换了EC2盘后再测试传真，仍然是传真业务正常的15ONU仍然正常，传真业务不正常的15ONU仍然不正常。于是再更换光分路器继续测试，故障现象依旧，于是在1：8的分路器上将15ONU的光纤分别断开进行测试，当断开传真业务正常的15ONU时（10.37.111.6）,在从PC去PING10.37.111.2,和10.37.111.3,10.37.111.4的15ONU都没有丢包。在10.37.111.3的15ONU上发传真业务测试发现业务正常,在另外两个15ONU上测试传真业务也是正常的。于是定位到10.37.111.6的15ONU上联盘EPU2盘问题,将该EPU2盘更换后,再测试四个15ONU的传真业务都是正常。【故障分析】通过该15ONU传真问题的处理，发现该问题一般与丢包有关系，首先通过抓包分析是否有丢包，可以在上联口抓包，查看是否上联有丢包，如果有丢包需要查看上连通道部分。包括从上联口经过的交换机，或者是上联光纤收发器的工作模式，排除工作模式不对引起语音上联通道丢包。另外在EC2盘或15ONU抓包，查看是否PON内有丢包，如果有丢包再分析是光功率不正常引起，还是其它原因引起。首先排除PON内的丢包才能解决传真问题。本案例中的传真故障就是由于PON内的丢包造成的，由于同一个PON口下某一个15ONU的上联盘故障引起其他15ONU的丢包，该15ONU的EPU2盘光模块为海信模块，分析可能由于光模块器件原因，光反射太强影响其它ONU的链路正常工作，语音业务由于对丢包不敏感，但是传真业务对与丢包是很敏感。六、modem掉线问题的处理对于moden掉线问题的现象描述：即moden的link指示灯处于慢闪烁状态无法进入常亮状态。或者在进入到了常亮状态后不能保持反复出现闪烁状态。在设备端的现象则是在主控的命令行看到端口的link状态为down，或者观察一段时间端口link状态在up和down状态之间来回切换，在网管界面则显示为用户端口变成灰色。需要注意的是，有时候用户moden反复出现掉线重训练状态，设备上的显示的状态来不及更新。诊断方法：检查adsl模版的配置检查的内容包括三个方面：1.编码类型（lineCoding）2.线路类型（channelMode）3.训练速率（dnFastMaxTxRate，dnIntlMaxTxRate，upFastMaxTxRate，upIntlMaxTxRate）推荐的配置为：1编码类型在开通的下行速率低于8Mb/s时采用G.dmt，大于8M时采用adsl2plusauto。2线路类型采用interleaved更为稳定。3对于上下行训练速率不要采用默认模版中的值（默认为最大值），而应根据工程要求作速率限制（目前大多数出现moden常掉线不稳定都是由于模版没有限速原因造成）Adsl模版的配置方法首先登陆到主控命令行，并获取管理员权限，进入到admin提示符：然后进入到dslprofile配置目录，添加xaplus（adsl2+）模版命名为“4M”的模版，同时进入到修改模版的提示符下：开始修改“4M”模版的配置项，修改下行最大速率为4M，修改linecoding线路模式为gdmt（默认为adsl2），还可以修改其他需要修改的配置项，如：channelMode改为“interleavedOnly”，可以用list命令查看有哪些配置项：修改完后用“exit”命令退出。然后将新添加的模版绑定到指定的端口：注意一个端口只能绑定一个模版，去绑定命令：排除线路因素的干扰当moden在线的情况下，在主控命令行dev目录下查看端口状态，观察downstreammargin和upstreammargin值，如果低于6则线路可能状态不稳定，会出现moden频繁重训练的现象。（正常情况下取值范围为831,且值越大稳定性越好）另排除moden自身问题：需要注意的是由于某些品牌ADSLModem的直流变压器的质量不过关，在夏天长时间的使用后会因为过热造成输出电压产生紊乱引起ADSLModem内部的错误。这个时候只能对ADSLModem采取断电重启的办法。实在不行只有叫直流变压器先冷却一下了。注：此文档适用范围仅适用于moden掉线问题。七、07ONU下接MSAN设备上网时延大处理【网络拓扑】公网BAS三层交换机OLT29:429:5trunkODNDNS服务器61.134.1.4华为MSAN语音3407BONU13数据CaptureModemPC【现象描述】升级之前业务正常，升级到930版本后，OLT下挂华为msan设备上网速度非常慢，pppoe拨号非常困难，pingDNS等公网ip时延达1000多ms甚至丢包。从EC2上PING07ONU的私网IP延时也达到1000多ms。同时发现如果MSAN设备下上网用户少时业务正常，随着用户数量增加时延会迅速增大。升级前EC2软件版本：R1.22.05.35升级前07AONU软件版本：R03.07.06.23升级之后EC2软件版本：R1.22.05.36升级之后07AONU软件版本：R3.07.06.26【处理过程】现场抓包确认从EC2到GSWC之间时延正常，07ONU交换芯片收到下行报文时延达到1000ms，确认问题在EC2到ONU之间。后检查发现用户上网业务在LLID2上转发，而LLID2是优先级最高的逻辑链路，软件将该LLID的带宽限制为2M，因此当用户数量多，业务流量大时就出现时延大，甚至丢包的现象。通过抓包查看MSAN设备上行的报文所带的COS值为6，确实是最高优先级。后告知局方将MSAN设备配置的COS值降低后业务恢复正常。【故障分析】EC2软件为进行业务QOS保障，自动将不同优先级的报文通过规则映射到不同的LLID，通过LLID的不同配置来保证不同COS值的优先级。其映射关系及配置如下：COS6,7LLID2minBW=maxBW=2M优先级最高COS4,5LLID1minBW=640K,maxBW=1000M优先级中COS0-3LLID0minBW=0K,maxBW=1000M优先级低其中LLID2为绝对优先级，一般做为语音业务使用，目前软件的处理过程是正确的，做为普通数据业务不需要带这么高的COS值。EC2软件的处理机制一直是按以上方式设计的，在升级之前业务正常的原因为930之前的EC2软件在进行规则映射时不正确，将COS6,7的报文映射到了LLID0上，所以反而未出现该问题。八、打包间隔不一致导致传真问题的处理方法由于北京网通有贝尔和华为两个平台模块，每个模块的打包频率设置不同。其中贝尔平台对语音通话的RTP流采用20ms的打包间隔，后期传真数据的RTP流采用10ms的打包间隔；华为平台对语音通话和传真数据的RTP流均采用20ms的打包间隔。如果仅仅是使用语音通话业务，则无需对AN5006-07设备进行特别的设置。而如果需要使用T30传真业务，为了适应平台不同的打包间隔，需要对AN5006-07设备进行如下配置。以port1口举例：1. 修改port1的模板，将抖动值设为80ms2. Configprotocol#setprofileport1jitter_buffer80（930软件默认就是80，不需要配置）修改port1口的2833pt值，设置优化因子Configdsp#set2833port1payloadtypetx101rx101/设置端口1的2833pt值为101Configdsp#jitterport180optifactor13/设置端口1的jitterbuffer为固定的80，其中optifactor是优化因子，13代表固定，7代表dynamic以下是公共设置3. 设置vbd参数进入dsp目录Configdsp#setvbdenable/设置vbd使能Configdsp#setvbdpacket_intervaltx20rx10/设置收包间隔为10ms，发包间隔为20msConfigdsp#setvbdevent101/设置2833PT为101Config#save/保存配置九、传真机模式错误导致传真失败问题处理现象描述16ONU用户传真故障，16ONU为930版本，AC16盘软件为01.12,软交换协议为MGCP,故障现象为用户在传真机上主叫打电话平台放拨号错误提示音，发不了传真，被叫接收传真正常。但是同样电话端口换成普通电话主叫都是正常。处理过程升级了AC16盘软件到01.14.再到现场测试故障依旧,于是怀疑现场所用的传真机有问题,现场的传真机是日本兄弟公司的,后来从其它地方借了一台传真机也是兄弟公司的,再次在现场发传真测试,发现拿到现场测试的传真机主叫也是同样的故障想象,有用普通电话主叫拨号测试,同时在上联口抓包,从MGCP协议上发现用传真机拨号上的号码总是多了一串数字。原来兄弟公司的传真机拨号变为了脉冲方式，正常情况下应该为音频方式，但是传真机上没有修改的设置，后来在网上查发现，用兄弟公司的传真机在拨号时前面要加#号，此时传真机会自动将拨号方式变成音频，于是按照上面方法测试主叫电话正常。故障分析传真机的拨号方式有音频和脉冲两种方式，而软交换平台下需要采用音频方式，传真机本身的设置需要注意的。十、高科iad的payload值影响传真处理案例【现象描述】5116-02设备下挂5006-04onu，用户打电话正常,但是发不了传真，RTP未丢包. 【处理过程】1、 关闭静音压缩和回声抑制，问题没有解决；2、通过抓包分析软交换在传真过程中采用了payload96，如下图：由于软交换用到96的payload，故iad需要对应的修改payload值，否则将成为unknown包，导致传真失败。高科iad的修改命令如下（表红部分）：MG6002(F2)#setdsp->是否启用回声消除?'yes'or'no'yes:->是否启用静音压缩?'yes'or'no'no:输入增益:->是否屏蔽输入?'yes'or'no'no:->输入增益(-31dB31dB)-1:输出增益:->是否静音?'yes'or'no'no:->输出增益(-31dB31dB)-1:->DTMF增益(-31dB0dB)-4:DTMF传输方式:1-带内传输.2-RFC2833.->请选择传输方式(12)1:最大传真速率(bps):0-2400bps.1-4800bps.2-7200bps.3-9600bps.4-12000bps.5-14400bps.->请输入最大传真速率(05)5:->是否启用传真误码纠错?'yes'or'no'no:->请选择传真模式(0-透传模式,1-T.38模式)0:->透传时发包间隔(0-10ms,1-20ms)1:->中兴T30传真RTP负载值97:96->传真增益(015)9:馈电方式配置:0-高馈电电压(电话线长度>=4000m)1-低馈电电压(电话线长度<4000m)->请选择馈电方式(01)1:话音时延等级:0-时延最小1-时延较小2-时延适中3-时延较大4-时延最大->请选择时延等级(04)2:确定更改配置吗?'yes'or'no'no:更改payload值并且重启iad和传真机后，传真问题解决。【故障分析】中兴软交换在传真过程中采用了特殊的payload值，而iad的相关配置必须与软交换一致，否则会导致RTP流问题，从而造成传真失败。出问题时的iad的payload值为97，而软交换为96，这样不匹配导致传真失败。十一、5006-07杂音问题处理案例【网络拓朴】【现象描述】5116-02设备下挂5006-07onu，5006-07设备原来采用的软件为R3.07.05.28，用户打电话正常,但是升级为R3.07.05.60或者R3.07.05.59后，打电话有较明显的杂音。 【处理过程】1、打开静音压缩和回声抑制功能，问题没有解决；2、修改抖动容限相关参数，命令如下：Configdsp#jitterport135optifactor7/修改端口1的抖动容限为35，7表示自动调整Configprotocol#setprofileport1jitter_buffer35/修改端口1的抖动容限模板参数为35修改抖动容限后没有明显改善3、通过抓包分析软交换在下发信令时，要求抖动容限为0，如下图：软交换信令下发为nt/jit=0，即要求抖动容限为0，这样一旦网络上延时较大、抖动较大或者存在丢包时，都会造成语音质量变差。4、要求软交换改为nt/jit=40后解决此问题。【故障分析】抖动容限的功能是用来处理网络路由质量不好，通过软件算法解决语音上的损耗，而关闭此功能后在网络质量较好的时候没有问题，一旦出现网络路由问题将直接导致语音质量不好。老软件R3.07.05.28在处理抖动容限时是以自身设定为准，不响应软交换下发的信令，这种处理方式是有问题的，故在新软件R3.07.05.59或者R3.07.05.60上改为了响应软交换的信令，这样就导致了老软件没有问题，而新软件出现杂音问题十二、5116-02的AC16语音代理问题处理现象描述：ONU下挂华为和贝尔AG，出现了贝尔AG之间语音不能互通，无法互相PING通，而华为的AG均互通正常的情况。故障分析：通过抓包分析，发现原因为：AC16发给贝尔AG的ARPrequest报文，贝尔AG不会进行处理，因为该ARP报文中的源IP和目标IP不在同一个网段内（设备能否处理这样的ARP报文和不同厂家设备使用的操作系统以及协议栈有关），在这种情况下，AC16无法主动获得贝尔AG的ARP信息，而从抓包看贝尔AGARP刷新周期比较长（应该远大于AC16的老化时间10分钟），所以AC16的ARP表不能实时完整的记录系统下所有贝尔AG的ARP信息，而华为AG主动发送ARP报文的频率相对较快，所以该OLT下华为AG互通正常，贝尔AG互通不正常。解决方法：对于该问题，可以通过设置AC16的代理IP来予以解决，AC16默认的代理IP为192.168.244.222,可以通过主控盘的命令行（可以保存）:Adminservice#setac16ip<A.B.C.D>mask<A.B.C.D>gateway<A.B.C.D>来进行设置，将其设置成与AG在同一网段的IP，例如贝尔AG为10.28.108.10,掩码为255.255.255.192，则可以将AC16的IP设置为10.28.108.31（前提是该IP之前没有被使用，不会引起网络冲突）。十三、AN5006-03/04/09AONU下挂wlan等设备未知包问题处理案例【网络拓扑】上层服务器03/04/09AONUWLAN(或DSLAM)交换机ODNOLT【现象描述】03、04、低成本09A下挂wlan（或DSLAM等设备）管理ip可能ping不通【处理过程】1、 在onu和wlan间接集线器抓包，由于wlan（或其他设备）管理通道不主动上行发包，超过epon系统最大老化时间300s后，必然会在在1到2个老化周期内地址老化，从而下行ping包通过olt到onu侧后找不到具体对应mac的端口，03、04、09A交换芯片处理为直接丢弃；2、 交换芯片一般有洪泛（flood）模式，交换机对于目的地址未知的帧，可以把它泛洪到除收到该帧的接口（上联pon接口）的其他的和收到帧的接口属于同一个VLAN的接口（用户端口）；03、04、低成本09A开启洪泛模式为将任一onuFE端口mac地址限制由64改为0（如果没有dslam等设备，推荐用未开业务的一个端口）；WlanWlanFTTH默认mac限制一般为64任一端口mac地址限制改为0，不学习，flood模式下行未知包到03onu所有下行业务不管单播、广播还是未知包都往同一个vlan的用户端口进行洪泛，缺点会浪费下行带宽。【故障分析】1、 ftthonu默认为端口限制为64，如果下挂wlan，且管理不主动发包，以前需要升级03/04特殊pers来解决未知包下行问题（不是很可靠），目前一是可以利用洪泛模式实现，一是可wlan加上行长ping命令，一是waln和wlan网管间加单方或双方心跳机制，且心跳时间小于我司epon系统老化时间；2、 如果下挂dslam，除管理通道问题可比照wlan外，如果dslam用户mac被我司onu学习超过64，也需要修改该FE端口mac限制为0，不学习模式；Mac限制为0表示该端口mac不学习，且整个onu交换芯片为flood模式，仅针对03、04、低成本09A有效；十四、07B-ONU传真问题【现象描述】某运营商电信辖区内，一OLT上的第1块EC2盘下挂3台的07B-ONU出现宽带和语音电话业务正常，而传真业务不通的故障现象。因在930升级前，OLT和ONU上的各类业务，包括传真业务都正常，所以故障原因可能是930升级后引起。【故障处理】（1）根据以往的工程经验，当ONU上的宽带和语音业务都正常的时候，如果传真业务不通有两种可能：一是传真机的协议类型，它是选用T30协议，还是T38协议；二是ONU上的传真模式与软交换平台不匹配。（2）在没有升级为930系列前，OLT下带的07B型ONU采用的是T38协议，并打开了“静音开关”和“回声抑制”功能，宽带、语音、传真三类业务正常。升级后，惟独传真业务不好，我们首先检查了到达07B型ONU的光功率，结果正常。（3）与中兴软交换平台操作人员沟通，确认近期他并没有升级及更改设置的操作。（4）更换其中一台07B，并且使用未升级930之前的版本（48），发现传真业务不通。（5）更换了OLT上的EC2盘，检测发送光功率正常，宽带和语音正常，而传真业务不通。（6）根据从07B上抓包的结果来看，当它接受到传真信令一秒钟后，就自动挂断了，因此我们也检查了与软交换平台的心跳时间设置，结果正常且一致。（7）从抓包结果看，我们发现RTP流没有出现丢包，只是收包数目和发包数目完全不相对应，说明单方向有问题。（8）从平台获知，中兴软交换平台，对于传真业务同时开启了T30和T38协议，如果我们的ONU只固定一个协议即可，所以关闭了T38协议，传真机可以发出，但收不成功；然后关闭了传真事件检查功能，传真机既可发出，也接收正常。【故障分析】10.69.137.199是中兴软交换平台的语音IP10.69.138.143是烽火07B的IAD语音IP以下（图一）是07B上，拨打“02767840400”（烽火通信客服总部传真）的数据包记录情况，在与软交换平台进行信令交互的过程，双方形成一问一答、“requestreply匹配成对”呈现。图-1如下图二所示，信令建立成功后，开始发送数据，丢包率为0，但收包与发包数量不匹配。以上结果现象说明，在IP对接的设置方面是没有问题的，只是RTP流在发送方向并不完整。为此，我们调整了07B型ONU的传真模式设置，如下：测试结果，07B下挂的传真机可以发传真，但收并不成功。然后，我们又关闭了“传真事件”检测功能。把“NotifyFaxEvent:disable”，这时07B下挂传真机既可发送文件，也可接受传真文件。（1）先把RTP流强制为“单一流”模式；（2）关闭“传真事件检查“功能。传真的RTP流结果如下：收/发流数量基本一致，无丢包。故障问题排除。【经验总结】使用我烽火公司930版本软件的07BONU在使用T38协议时，会自动检测传真上报事件，发现线路质量不好或不匹配等情况，即会关闭通道。因此，为了适应中兴软交换平台的工作模式，建议辖区内，07B型ONU采用传统T30协议，以完成传真发送工作。另外，我们在测试工作中，还发现传真机自身工作状态也会引起传真收发不成功的情况，所以建议：（1）把传真机接入传统的PSTN网，即接纯固定电话线，发出传真和接收传真，确认传真机收/发正常。在测试中，我们就发现个别传真机只能发，不能收，以至于误导了我们的测试方向。（2）近可能给传真机的电话线不要接分机，如传真机上的“EXT”口不要接电话分机，特别是测试阶段。（3）如果传真机以前是可以收发传真，而近一段时间不通，可以重启传真机，其主要目的是清除传真机的内存，因为传真机的传送文件在内存里是排队的，如果前一个异常没有清除，那么后面的任务，不论是否正常它都将长时间等待。当然不同的传真机清楚内存的办法不同，可以联系该传真机的服务商或上网查询。十五、AN5116-02下挂07ONU催挂音超时处理问题【网络拓扑】【现象描述】某运营商辖区内完成4台OLT进行930升级后，只有一台OLT上的第2块EC2盘下挂了8台07B-ONU。只开通了语音端口（数据端口都关闭），而语音电话随机出现：摘机后只有电流音，没有拨号音，压簧动作无效的故障现象，当在网管上重设端口或通过命令行重启端口，可立刻恢复该语音业务端口。【处理过程】（1）07-ONU绑定软交换平台互通参数模板。（2）把软交换平台互通参数模板中的催挂音超时处理选择为“不注册”后正常。【故障分析】在AC16盘的NGN配置中，有“软交换平台互通参数摸板”，除了前面的RTP流设置外，继续向右拉，会出现“催挂音超时处理”设置项。该项默认设置是“空”。（共有三个选项：空、不注册、注册。）“不注册”表示不注销，表示07-ONU下的电话用户打完电话后，一直没有挂机，平台下放了催挂音完毕后，还没有挂机（通常是由于用户没有把话筒挂好），出现了催挂音超时，该端口的电话号不会在软交换中注销。“注册”表示注销，表示07-ONU下的电话用户打完电话后，一