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 在 Win2003 SP2 上运行间歇服务中断问题说明 .34 二、网管配置过大导入不成功处理方法 .36 三、网管内存过大导致数据库服务无法启动案例 .36 四、AC16 上联用户信令数据配置无法读取故障处理 37 五、42SP1 网管无法对 ONU 端口进行业务配置问题处理 .37 六、网管下 AC16 配置失败故障 39 七、客户端常报“数据库已修改”问题 .41 八、计划任务不能启动处理案例 .41 设备问题 一、呼叫转移故障处理技术案例 【网络拓朴】 【现象描述】 端点用户名为 AG58900, 07ONU（R3.07.05.56） ，需要开通呼叫转接功能， 软交换平台数据已做，用户在进行呼叫转接时，拨完*57*后有拨号音，继续输入转接号码 时出现忙音。 【处理过程】 1、 通过命令行查看明确匹配及上报功能，确认没有打开； 查看命令：Configprotocol# sh dig Notify matched digit with type unambiguous :disable Notify matched digit delay :255 2、 通过抓包分析软交换下发数图，发现数图定义不标准，如下图： 在红框表示的数图中规定为EF0-90-9E.EF，表示前三位接受相关拨号后，第 四位如果输入“*” （E 表示*）或者“#” （F 表示#） ，都表示拨号结束，将立即上报所 拨的号码，则 IAD 收到“*57*”后就把号码上报给软交换平台了，如下图： 这样就造成拨号没有结束就上报了号码，导致转接不成功。 3、 和软交换平台协商，把数图改为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.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 对应的上行方向语音包也是 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 之后， 业务量减少后，故障现象消失的原因。 （1） 当两型号都在同一 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 上都出现故障现象。 （2） 当两型号 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 的 BRAS mac 地址学习到了 槽位端口上，导致所有外层 vlan 为 4003 的，目的 mac 地址为 BRAS 的单播数 据流发送目的地错误； 怀疑是用户家外接网络发生环路或者用户电脑中毒，通过查看 onu mac 地址 表的方式找到了发生问题的用户端口，确定用户； 后发现用户家 ONU 下挂路由器的两个端口用网线连接形成环路导致下行方向 BRAS 发出的报文又环回到设备，进一步引起系统 mac 地址学习发生错误。解 决用户外接环路后，业务回复正常。 4、 解决办法 最终解决方案： 建议通过配置远端 onu 过滤规则的方式解决该问题。操作步骤如下： 用户仅需操作第一步。 第一步：在网管上配置过滤规则，过滤规则为源 mac 地址等于 BRAS mac 地址（如 果有多个 BRAS 需要配置多条） ； 第二步：设备收到配置后会自动对当前所有在线 onu 进行配置，所有从用户侧端 口收到的源 mac 地址为 BRAS mac 地址的数据包均被丢弃； 第三步：对于以后上电的 onu 或者以后新增的 onu，系统会在该 onu 上电注册后 自动将过滤规则下发。 临时解决方案： 对于 FTTH onu 可以配置用户端口绑定解决该问题，配置方式为：源 mac 地址不等 于 BRAS mac 地址的数据包允许通过。 5、 时间进度 解决该问题需要升级主控盘软件和 EC2 pon 业务板卡软件（onu 软件不需升级） ， 按照目前正规的工程问题解决，发布流程，初步计划在二季度末正式释放解决该问 题的版本。 五、同一个 PON 口下 15 型 ONU 上联 EUP2 盘引起其它 15ONU 传真的问题 【网络拓扑】 AN5116-02 15ONU 1 15ONU n ODN 1：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 的 AC16 IP 同一个网段，在上联口用 PC 去 PING 15ONU 的 AC16 IP，现场传真正常的 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, 这时电脑去 PING 10.37.111.2 发现有丢包， 如下： 同时 PING10.37.111.3, 和 10.37.111.4 都有丢包。但是 PING 10.37.111.6 的 ONU ，此时发现没有丢包。通过以上测试说明传真业务失败与丢包有关系，而且丢包就在 PON 内，从 EC2 盘 PON 口到 15ONU 的 PON 口之间有丢包，首先定位到是 EC2 盘问题，于是更换 了 EC2 盘后再测试传真，仍然是传真业务正常的 15ONU 仍然正常，传真业务不正常的 15ONU 仍然不正常。于是再更换光分路器继续测试，故障现象依旧，于是在 1：8 的分路器 上将 15ONU 的光纤分别断开进行测试，当断开传真业务正常的 15ONU 时（10.37.111.6）, 在从 PC 去 PING 10.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 提示符： 然后进入到 dsl profile 配置目录，添加 xaplus（adsl2+ ）模版命名为“4M”的模版，同时 进入到修改模版的提示符下： 开始修改“4M”模版的配置项，修改下行最大速率为 4M，修改 linecoding 线路模式为 gdmt（默认为 adsl2） ，还可以修改其他需要修改的配置项，如：channelMode 改为 “interleavedOnly”，可以用 list 命令查看有哪些配置项： 修改完后用“exit”命令退出。 然后将新添加的模版绑定到指定的端口： 注意一个端口只能绑定一个模版，去绑定命令： 排除线路因素的干扰 当 moden 在线的情况下，在主控命令行 dev 目录下查看端口状态，观察 downstream margin 和 upstream margin 值，如果低于 6 则线路可能状态不稳定，会出现 moden 频繁重训练的现 象。 （正常情况下取值范围为 831, 且值越大稳定性越好） 另排除 moden 自身问题： 需要注意的是由于某些品牌 ADSL Modem 的直流变压器的质量不过关，在夏天长时间的使 用后会因为过热造成输出电压产生紊乱引起 ADSL Modem 内部的错误。这个时候只能对 ADSL Modem 采取断电重启的办法。实在不行只有叫直流变压器先冷却一下了。 注：此文档适用范围 仅适用于 moden 掉线问题。 七、07ONU 下接 MSAN 设备上网时延大处理 【网络拓扑】 公网 BAS 三层交换机 OLT 29:4 29:5 trunk ODN DNS 服务 器 61.134.1.4 华为 MSAN 语音 3 4 07B ON U 13 数据 Capture Modem PC 【现象描述】 升级之前业务正常，升级到 930 版本后，OLT 下挂华为 msan 设备上网速度非常慢， pppoe 拨号非常困难，ping DNS 等公网 ip 时延达 1000 多 ms 甚至丢包。从 EC2 上 PING 07ONU 的私网 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 值的优先级。其映射关系及配置如下： COS 6,7 LLID2 minBW=maxBW=2M 优先级最高 COS 4,5 LLID1 minBW=640K,maxBW=1000M 优先级中 COS 0-3 LLID0 minBW=0K,maxBW=1000M 优先级低 其中 LLID2 为绝对优先级，一般做为语音业务使用，目前软件的处理过程是正确的， 做为普通数据业务不需要带这么高的 COS 值。 EC2 软件的处理机制一直是按以上方式设计的，在升级之前业务正常的原因为 930 之 前的 EC2 软件在进行规则映射时不正确，将 COS6,7 的报文映射到了 LLID0 上，所以反而未 出现该问题。 八、打包间隔不一致导致传真问题的处理方法 由于北京网通有贝尔和华为两个平台模块，每个模块的打包频率设置不同。其中贝尔 平台对语音通话的 RTP 流采用 20ms 的打包间隔，后期传真数据的 RTP 流采用 10ms 的打包 间隔；华为平台对语音通话和传真数据的 RTP 流均采用 20ms 的打包间隔。如果仅仅是使用 语音通话业务，则无需对 AN5006-07 设备进行特别的设置。而如果需要使用 T30 传真业务， 为了适应平台不同的打包间隔，需要对 AN5006-07 设备进行如下配置。 以 port 1 口举例： 1. 修改 port1 的模板，将抖动值设为 80ms Configprotocol#set profile port1 jitter_buffer 80（930 软件默认就是 80，不需要 配置） 2. 修改 port1 口的 2833 pt 值，设置优化因子 Configdsp# set 2833 port 1 payloadtype tx 101 rx 101 /设置端口 1 的 2833 pt 值为 101 Configdsp# jitter port 1 80 optifactor 13 /设置端口 1 的 jitter buffer 为固定 的 80，其中 optifactor 是优化因子，13 代表固定，7 代表 dynamic 以下是公共设置 3. 设置 vbd 参数 进入 dsp 目录 Configdsp# set vbd enable /设置 vbd 使能 Configdsp# set vbd packet_interval tx 20 rx 10 /设置收包间隔为 10ms，发包间 隔为 20ms Configdsp# set vbd event 101 /设置 2833 PT 为 101 Config# save /保存配置 九、传真机模式错误导致传真失败问题处理 现象描述 16ONU 用户传真故障，16ONU 为 930 版本，AC16 盘软件为 01.12 ,软交换协议为 MGCP, 故障现象为用户在传真机上主叫打电话平台放拨号错误提示音，发不了传真，被叫接收传 真正常。但是同样电话端口换成普通电话主叫都是正常。 处理过程 升级了 AC16 盘软件到 01.14 . 再到现场测试故障依旧, 于是怀疑现场所用的传真机 有问题, 现场的传真机是日本兄弟公司的, 后来从其它地方借了一台传真机也是兄弟公司 的, 再次在现场发传真测试, 发现拿到现场测试的传真机主叫也是同样的故障想象, 有用普 通电话主叫拨号测试, 同时在上联口抓包, 从 MGCP 协议上发现用传真机拨号上的号码总 是多了一串数字。 原来兄弟公司的传真机拨号变为了脉冲方式，正常情况下应该为音频方式，但是传真 机上没有修改的设置，后来在网上查发现，用兄弟公司的传真机在拨号时前面要加#号，此 时传真机会自动将拨号方式变成音频， 于是按照上面方法测试主叫电话正常。 故障分析 传真机的拨号方式有音频和脉冲两种方式，而软交换平台下需要采用音频方式，传真 机本身的设置需要注意的。 十、高科 iad 的 payload 值影响传真处理案例 【现象描述】 5116-02 设备下挂 5006-04onu，用户打电话正常,但是发不了传真，RTP 未丢包. 【处理过程】 1、 关闭静音压缩和回声抑制，问题没有解决； 2、通过抓包分析软交换在传真过程中采用了 payload 96，如下图： 由于软交换用到 96 的 payload，故 iad 需要对应的修改 payload 值，否则将成为 unknown 包，导致传真失败。 高科 iad 的修改命令如下（表红部分）： MG6002(F2)#set dsp -是否启用回声消除? yes or noyes: -是否启用静音压缩? yes or nono: 输入增益: -是否屏蔽输入? yes or nono: -输入增益(-31dB31dB)-1: 输出增益: -是否静音? yes or nono: -输出增益(-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 nono: -请选择传真模式(0-透传模式, 1-T.38 模式)0: -透传时发包间隔(0-10ms, 1-20ms)1: -中兴 T30 传真 RTP 负载值97: 96 -传真增益(015)9: 馈电方式配置: 0-高馈电电压(电话线长度 = 4000m) 1-低馈电电压(电话线长度 请选择馈电方式(01)1: 话音时延等级: 0-时延最小 1-时延较小 2-时延适中 3-时延较大 4-时延最大 -请选择时延等级(04)2: 确定更改配置吗? yes or nono: 更改 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#jitter port 1 35 optifactor 7 /修改端口 1 的抖动容限为 35，7 表示自 动调整 Configprotocol#set profile port1 jitter_buffer 35 /修改端口 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的ARP request报文，贝尔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# set ac16 ip mask gateway 来进行设置，将其设置成与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、低成本 09A 下挂 wlan（或 DSLAM 等设备）管理 ip 可能 ping 不通 【处理过程】 1、 在 onu 和 wlan 间接集线器抓包，由于 wlan（或其他设备）管理通道不主动上行发包， 超过 epon 系统最大老化时间 300s 后，必然会在在 1 到 2 个老化周期内地址老化，从 而下行 ping 包通过 olt 到 onu 侧后找不到具体对应 mac 的端口，03、04、09A 交换芯 片处理为直接丢弃； 2、 交换芯片一般有洪泛（flood）模式，交换机对于目的地址未知的帧，可以把它泛洪到 上 层 服 务 器 交 换 机 OLT ODN 03/04/ 09A ONU WLAN (或 DSLAM) 除收到该帧的接口（上联 pon 接口）的其他的和收到帧的接口属于同一个 VLAN 的接口 （用户端口） ； 03、04、低成本 09A 开启洪泛模式为将任一 onu FE 端口 mac 地址限制由 64 改为 0（如 果没有 dslam 等设备，推荐用未开业务的一个端口） ； Wlan Wlan FTTH 默认 mac 限制一 般为 64 任一端口 mac 地 址限制改为 0，不 学习，flood 模式 下行未知包到 03onu 3、 所有下行业务不管单播、广播还是未知包都往同一个 vlan 的用户端口进行洪泛，缺点 会浪费下行带宽。 【故障分析】 1、 ftth onu 默认为端口限制为 64，如果下挂 wlan，且管理不主动发包，以前需要升级 03/04 特殊 pers 来解决未知包下行问题（不是很可靠） ，目前一是可以利用洪泛模式实 现，一是可 wlan 加上行长 ping 命令，一是 waln 和 wlan 网管间加单方或双方心跳机 制，且心跳时间小于我司 epon 系统老化时间； 2、 如果下挂 dslam，除管理通道问题可比照 wlan 外，如果 dslam 用户 mac 被我司 onu 学 习超过 64，也需要修改该 FE 端口 mac 限制为 0，不学习模式； 3、 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 是中兴软交换平台的语音 IP 10.69.138.143 是烽火 07B 的 IAD 语音 IP 以下（图一）是 07B 上，拨打“02767840400” （烽火通信客服总部传真）的数据 包记录情况，在与软交换平台进行信令交互的过程，双方形成一问一答、 “requestreply 匹配成对”呈现。 图-1 如下图二所示，信令建立成功后，开始发送数据，丢包率为 0，但收包与发包数量不匹配。 以上结果现象说明，在 IP 对接的设置方面是没有问题的，只是 RTP 流在发送方向并不完整。 为此，我们调整了 07B 型 ONU 的传真模式设置，如下： 测试结果，07B 下挂的传真机可以发传真，但收并不成功。然后，我们又关闭了“传真事 件”检测功能。 把“Notify Fax Event: disable”，这时 07B 下挂传真机既可发送文件，也可接受传真文 件。 （1）先把 RTP 流强制为“单一流”模式； （2）关闭“传真事件检查“功能。 传真的 RTP 流结果如下：收/发流数量基本一致，无丢包。 故障问题排除。 【经验总结】 使用我烽火公司 930 版本软件的 07B ONU 在使用 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 下的电话用户打完电话后，一直没有挂机，平台下放了 催挂音完毕后，还没有挂机（通常是由于用户没有把话筒挂好） ，出现了催挂音超时，该端 口的电话号会从平台中剔除，如果剔除后，下次摘机准备拨号就没有拨号的声音了。 当 07-ONU 绑定了该摸板后， “催挂音超时处理”对应到 07-ONU 就是： Configprotocol# show roh auto play roh :enable release user when roh timeout :enable （对应模板中设置项，已设置为“注册”即注 销） set user out of service when roh timeout :disable 所以当 07-ONU 绑定了该摸板后，如果“催挂音超时处理”没有选择，是空的。 那么你在 07-ONU 内 show 到的显示结果就是： Configprotocol# show roh auto play roh :enable release user when roh timeout :disable （由于“空”对应的值是 255（全 1 码），非 0） set user out of service when roh timeout :disable 由于“空”对应的值是 255（非 0） ，所以 show 出来的结果是 disable ，但 ONU 内部“不 注销”的动作只认“0” 。 所以即使看到 release user when roh timeout :disable ，如果模板里“催挂音超时 处理”是“空”对应的值是 255，超时后一样注销。 网管 NGN 摸板中设 置 催挂音超时处理 对应 07 的 timeout_release 对应 DEBUG 中的值 实际动作 不注册 Disable （0） 0 不注销 注册 Enable （非 0） 1 注销 空（默认） Disable 255 注销 十六、930OLT 版本后 ONU 下挂 AG,DSLAM 等设备优先级注意 问题 【网络拓扑】 【现象描述】 4.37 升级至 930 或以后版本后 07onu 下挂华为 AG 语音业务时延大，丢包，AG 下电话与外 部电话通话，外部电话听音断续。 【处理过程】 1、 现场抓包确认从 EC2 到 GSWC 之间时延正常，07ONU 交换芯片收到下行报文时延 达到 1000ms，确认问题在 EC2 到 ONU 之间。后检查发现用户上网业务在 LLID2 上转发，而 LLID2 是优先级最高的逻辑链路，软件将该 LLID 的带宽限制为 上 层 服 务 器 交 换 机 OLT ODN 07 型 ONU 电话机 华 为 A G 2M，因此当用户数量多，业务流量大时就出现时延大，甚至丢包的现象。通过 抓包查看 AG 设备上行的报文所带的 COS 值为 6，确实是最高优先级。后告知局 方将 AG 设备配置的 COS 值降低后业务恢复正常。 2、 也可通过 EC2 逻辑链路上查看学习地址来确定上行业务优先级大概是哪个范围 来定位： Configpon# show status 2 6 1.onu address:544b70045358 ( 6) auth id:80 AN5006_07B version: 140 chip product type :3715 support catv :NO support switch :NO product code: :0B max distance :20km supply :48V specific flag :0 report iad macaddress :YES iad mac address :000ac210ef76 optical_check :disable hard version :wke2.119.254R2A port link up : port attached to gateway: max links :8 active links : 0 1 2 3 ONU6 CPU COMM :YES TDM INPLACE :NO cpu request configuration:0 onu cpu hardware version:WKE2.119.195R1B onu cpu software version: R3.07.06.26 Configlink#