APP下载

部分光纤故障类型及其处理方法的实践经验

2019-07-27

数字传媒研究 2019年4期
关键词:用户端上联报文

霍 泽

内蒙古广播电视网络集团有限公司乌拉特中分公司 内蒙古 巴彦淖尔市 015300

1 长发光ONU故障

1.1 故障情况

新安装用户光功率在正常范围,但是PON 灯闪烁,注册失败,OLT 中同时也没有注册信息。初步判断,有长发光ONU 存在。某小区编号为:JFHT-01#主分纤箱下挂的新装用户张三(化名)ONU 无法正常使用,安装队反映,安装后用户ONU PON 灯一直在闪烁,光功率为(-20),链路经过反复排查也没有异常。

1.2 故障处理

1.2.1 确定覆盖设备

从营业厅查找到JFHT-01#下挂的其他的已经注册并且在用的ONU,通过这个ONU 的MAC 地址锁定OLT 设备,由于中分公司城网只有两台OLT,所以排查其他也比较方便,最终,排查到JFHT-01#下的某台ONU 上联PON 口是笔者所在单位 232.162的1号OLT,登录OLT通过已知 MAC 查找对应PON 口。如图1所示。

图1

以:00∶0a∶5a∶27∶fe∶79 这台正常在线的ONU 为例,查找结果为:设备2/1/10,设备2PON板1Pon 口下存在。命令为:config 模式下:show onu mac 00∶0a∶5a∶27∶fe∶79,如图2所示。

图2

1.2.2 查看是否有长发光ONU 存在

例:Config 模式下输入:

gcom-wulatezhongqi-01 (config)#interface po 3/5 gcom-wulatezhongqi-01 (config-if-pon-3/5)#show opm op laser-always-on。通过不停的刷新设备信息,会看到这个PON 口下一直有长发光ONU存在,确定有长发光ONU 存在。如图3、图4所示。

图3

图4

1.2.3 确定端口

下往现场,通过断开分路器纤芯接头,结合OLT 设备刷新查看发光命令来综合确定端口。方法有两种,一种是通过无法上线的ONU 来排查。将用户端的ONU 链接好,ONU PON 灯处于闪烁无法注册的状态,通过拔插PON 口下的第一个分路器到每个单元的光纤,一旦断开长发光的某一路,这台无法注册的ONU 会马上注册上线,从而确定单元分纤箱的位置。用同样的方法,确定单元分纤箱所带的ONU 接口,确定故障ONU。

另一种方法是通过OLT 不停的刷新查看长发光命令来判定。

通过拔插第一个分路器的光纤,查看到这个PON 口下,如果显示没有长发光信息,说明拔插正确,从而确定端口。如图5所示。

图5

同样的方法,查找到单元的分纤箱光纤和到ONU 的光纤。例:断开3//9/11 这台ONU 后,长发光消失,其他ONU 同时可以正常注册在线。如图6所示。

图6

找到这个ONU 将其更换,此PON 口下ONU 恢复正常。如图7所示。

图7

笔者理解的长发光并不是影响所有ONU 都无法注册,只是影响比长发光ONU 接收光功率低的其他ONU 无法注册。例如:长发光这台ONU 的接收光功率为-18,那么这个PON 口下所有低于-18接收的ONU 就会注册失败。长发光故障排查起来有一定的困难,但是一定要按顺序逐一排查。

2 PPPoE拨号691故障

2.1 故障情况

用户端直连电脑拨号一直出现错误代码691,或通过路由器后,路由中设置好PPPoE 拨号,但提示拨号失败。(确定账号密码无误),如图8所示。

图8

2.2 故障处理

首先,从OLT 中通过查看报障用户端的MAC查到了PON 板信息和ONU 配置信息,确定没有问题。如图9所示。

图9

然后在用户端,将PPPoE 改回WEB 动态获取方式后可使用,但会不定时的掉线。再通过相关协助,登录BRAS 后发现,无法查看到故障用户端ONU 的正常上下线认证过程并报错。接着在机房OLT 上联GE 口抓包,结合用户端现场拨号,抓包抓取拨号请求发送过程。发现异常交互报文,在与故障用户同PON 板下,不同PON 口的4/11PON口下,有异常设备MAC 存在。将异常MAC 做黑洞隔离。

错误代码691 是指radius 验证用户名密码不匹配;导致认证失败。通过镜像抓包分析,发现PPPoE 交互报文是用户端和华为brass me60-x16;但实际上,现场组网内没有华为brass;如图10、图11 所示。

图10

图11

发现bras 有异常后;通过查询华为BRAS MAC地址后;在OLT内使用黑洞MAC;故障排除。

反复测试后,确定故障排除,通过营业厅BOSS 查到异常源ONU 的具体地址,到用户家后,发现连接并无异常,下挂设备也正常,怀疑此ONU 隐藏的流氓MAC,更换ONU 后所有问题全部处理。

3 注册故障

3.1 故障情况

2016年3月20日,在日常接到故障保修单后,笔者前往报障地点进行故障的排查与修复,使用2500C 场强仪进行CM 注册过程中发现,CM选择了上行通道,但一直处于等待DHCP 信息,无法获取IP,无法正常连接到网络时间协议(NTP)。而随后,故障自愈。自此,每天都会随机发生此种故障。笔者与技术人员利用NM3000 网管平台和SecureCRT 进行24 小时不间断观察发现,随机CM 出现卡D 状态,部分用户CM 无法上线,半小时内自动恢复。随后笔者与OLT 厂商取得联系,厂商派技术工程师协助配合排查故障。

3.2 故障处理

CM 上线有以下过程:offline、init(r2)、init(d)、init(io)、init(dr)、init(i)、online 这几种,其中init(r2)表示小cm 已经锁定上下行,等待dhcp 过程,dhcp 过程中init(d)是表示CM已经发出discover,但是没有收到offer,导致CM卡D。如图12 所示。

重启了小C,重启OLT,重启上联交换机,故障依然未解决。尝试更换上联交换机端口和OLT上联口并更换光模块后任然出现故障。再更换OLT的主控板,CM还是出现卡D。设备厂家工程师在故障发生时,在交换镜像抓包,发现交换机已经收到DHCP服务器回复的offer。如图13 所示。

图12

图13

厂家在故障时在OLT 上联口镜像抓包发现,OLT 收到多次卡(d)cm 的 offer,厂家在 OLT 的统计信息中发现收到的DHCP 的offer 信息是DISCOVER的几百倍,已经相当于行DHCP 风暴攻击,OLT 无法处理这么多报文,导致CM 卡D。如图14、图15 所示。

图14

图15

经过分析报文发现给一个cpe 的offer 报文峰值就到了180pps,最低的时候已经80pps 了,这还只是其中一个cpe,320 秒内这个TransactionID 的offer报文文件就达16MB,已经超过正常值很多倍。如图16 所示。

图16

厂家将整台OLT 更换后,cm 大量上线时发生一部分CM 卡D,经过十几分钟后正常。更换设备后,厂家技术人员将DHCP 处理能力提升后故障减少很多,但还是有大量offer 报文。

经过以上的工作与排查后得出问题和结论:设备经过更换后,基本上无问题。故障时的大量offer 是如何产生的,以及怎么产生的。由于现在故障减少,如果再次出现大批量卡D 时需要厂家和区公司协助共同排查,确定服务器是否有问题或是在转发过程中出现其他问题。

猜你喜欢

用户端上联报文
基于J1939 协议多包报文的时序研究及应用
Android用户端东北地区秸秆焚烧点监测系统开发与应用
牛年春联集锦
CTCS-2级报文数据管理需求分析和实现
浅析反驳类报文要点
基于三层结构下机房管理系统的实现分析
基于三层结构下机房管理系统的实现分析
一种太阳能户外自动花架电气系统简介
小试身手
ATS与列车通信报文分析