《EPON典型故障处理方法汇总12月版zhwfang》由会员分享，可在线阅读，更多相关《EPON典型故障处理方法汇总12月版zhwfang（47页珍藏版）》请在金锄头文库上搜索。
1、目录设备问题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
2、-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在Win2003 SP2上运行间歇服务中断问题说明34二、网管配置过大导入不成功处理方法36
3、三、网管内存过大导致数据库服务无法启动案例36四、AC16上联用户信令数据配置无法读取故障处理37五、42SP1网管无法对ONU端口进行业务配置问题处理37六、网管下AC16配置失败故障39七、客户端常报“数据库已修改”问题41八、计划任务不能启动处理案例41 / 文档可自由编辑打印设备问题一、呼叫转移故障处理技术案例【网络拓朴】 【现象描述】端点用户名为AG58900, 07ONU（R3.07.05.56），需要开通呼叫转接功能，软交换平台数据已做，用户在进行呼叫转接时，拨完*57*后有拨号音，继续输入转接号码时出现忙音。【处理过程】1、 通过命令行查看明确匹配及上报功能，确认没有打开；查看
4、命令：Configprotocol# sh digNotify matched digit with type unambiguous :disableNotify matched digit delay :2552、 通过抓包分析软交换下发数图，发现数图定义不标准，如下图：在红框表示的数图中规定为EF0-90-9E.EF，表示前三位接受相关拨号后，第四位如果输入“*”（E表示*）或者“#”（F表示#），都表示拨号结束，将立即上报所拨的号码，则IAD收到“*57*”后就把号码上报给软交换平台了，如下图：这样就造成拨号没有结束就上报了号码，导致转接不成功。3、 和软交换平台协商，把数图改为EF0
5、-90-9E.F后问题解决。【故障分析】 数图的定义不符合标准。由于某些软交换是这样配置的，故我公司后期软件也将更改可以符合这种不标准的数图。【相关资料】 二、未知包引起语音断断续续故障处理【网络拓朴】组网主图【故障分析】在没有上15-onu之前，在网运行AN516-02 (OLT)，下挂2台07B型ONU，共开通语音业务29户、数据业务1户，至开通业务以来，没有用户报障情况。但新近加装15-onu后（开通96户语音，15户数据），07B和15-onu下的用户都出现了“外线拨打15-onu下的用户号码，被叫方听语音正常，主叫方听语音出现断断续续的现象，即上行方向有阻断”。通过如上图所示 红点处
6、抓包分析的结果来看当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-i
7、p向上发ARP包时（10.33.210.26 ping 10.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对应的上行方向语音包
8、也是unknown包。通过与相关人员沟通，出现一个IP对应两个MAC地址的情况是上层的贝尔7750路由设备出于主备保护的原因，特意作此设置的。由于我公司推出的15-onu属于FTTC型，07B属于FTTB型，前者在设计时，考虑其128户的最大接入能力，通过其FSWB盘实现：广播包抑制功能、多播包抑制功能、unkonwn包抑制功能，避免在内网出现广播风暴、病毒攻击时出现设备端口被冲死的情况。所以在白天业务繁忙时，15-onu下多个用户拨打或接听电话时，其内部会产生大量unknown包，当达到设定门限时，unkonwn包抑制功能启动，丢弃了这些unkonwn包（具体数量根据当时的通话线数而定），而
9、这些包实际上是用户正常通信的语音RTP包，所以上行语音出现断断续续的情况，是因为这些RTP包被当作unkonwn包抑制了。为什么对原07B-onu产生影响？实际上，15-onu在设计上沿用了OLT的方式，可以把它看做一个小型的OLT，都具备广播包抑制功能、多播包抑制功能、unkonwn包抑制功能。07B属于FTTB型，它自身没有unkonwn包抑制功能，而15-onu出厂默认的unkonwn包抑制数量是150个/s，一旦超出，就出现该故障现象，这也是为什么每天17：00之后，业务量减少后，故障现象消失的原因。（1） 当两型号都在同一PON口下时02-OLT可以插16块EC2盘，每盘2个PON口
10、，共32个PON口，它们相互隔离，unkonwn包抑制是按照每个PON口来工作的。当新上的15-onu与两台07B-onu共PON口时，如果15-onu上的unknown包数量没有超过15-onu的门限，onu就会放它继续上行，但在该PON口通道内，再加上从07B上来的unknown包（自身不具备抑制功能），两者一叠加，数量就有可能超过02-OLT的unknown包抑制门限值，所以两种型号onu 上都出现故障现象。（2） 当两型号onu分别在两个PON口下时07B下有29户，15-onu下有96户，所以当15-onu上话务忙时，unknown包越限，15-onu自己就抑制了，控制了未知包的继续
11、上行。这时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的挂机信号
12、如下图在5.3s时ONU上报摘机，但5.9s却自动上报了挂机。之间只有0.6s的时间，明显不是人为挂机。（MGCP协议也有类似的情况）2. 原因分析：出现故障的话机一般为智能话机或功能较多的高级话机。此类话机工作时所需要的电流主要来自两个方面，一是本身自带的电池或电源，二会从电话线上取得一部分电流。这样问题就出现了。正常情况下，在用户没摘机的情况下，电话线上是没有电流的。但出故障的高级电话，由于自身工作的需要会从电话线上取得部分电流，而此时在电话没有摘机的情况下，电话线上却有了电流，于是我们的onu根据线路上有了电流这一点判断认为用户已经摘机，故放了al/of摘机信号，但此时电话实际是没有摘机
13、的，属于误判摘机，所以响一声就断了。3. 解决方法：研发提供了升级包，主要是提高了ONU对摘机的判断门限。目前主要针对故障07onu进行升级解决，正式软件3月20日之前将释放，等待软件正式释放后再大面积升级。四、关于北京清河局OLT2_4003外层VLAN用户拨号676错误报告1、现象描述 1月18日清河局第二框AN511602设备出现所有外层vlan为4003的用户，PPPOE拨号均返回676错误的问题。2、分析过程 仅外层vlan为4003的用户受到影响； 经过查看主交换盘的mac地址表发现vid为4003的BRAS mac地址学习到了槽位端口上，导致所有外层vlan为4003的，目的ma
14、c地址为BRAS的单播数据流发送目的地错误； 怀疑是用户家外接网络发生环路或者用户电脑中毒，通过查看onu mac地址表的方式找到了发生问题的用户端口，确定用户； 后发现用户家ONU下挂路由器的两个端口用网线连接形成环路导致下行方向BRAS发出的报文又环回到设备，进一步引起系统mac地址学习发生错误。解决用户外接环路后，业务回复正常。4、 解决办法最终解决方案：建议通过配置远端onu 过滤规则的方式解决该问题。操作步骤如下：用户仅需操作第一步。第一步：在网管上配置过滤规则，过滤规则为源mac地址等于BRAS mac地址（如果有多个BRAS需要配置多条）；第二步：设备收到配置后会自动对当前所有在
15、线onu进行配置，所有从用户侧端口收到的源mac地址为BRAS mac地址的数据包均被丢弃；第三步：对于以后上电的onu或者以后新增的onu，系统会在该onu上电注册后自动将过滤规则下发。临时解决方案：对于FTTH onu可以配置用户端口绑定解决该问题，配置方式为：源mac地址不等于BRAS mac地址的数据包允许通过。5、 时间进度解决该问题需要升级主控盘软件和EC2 pon业务板卡软件（onu软件不需升级），按照目前正规的工程问题解决，发布流程，初步计划在二季度末正式释放解决该问题的版本。五、同一个PON口下15型ONU上联EUP2盘引起其它15ONU传真的问题【网络拓扑】 AN5116-0215ONU115ONUnODN1：8 【现象描述】 某运营商EPON工程反应有一端OLT的EC2盘同一个PON口下带的四端15ONU，有三端
