部分光纤故障类型及其处理方法的实践经验
2019-07-27霍泽
霍 泽
内蒙古广播电视网络集团有限公司乌拉特中分公司 内蒙古 巴彦淖尔市 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 时需要厂家和区公司协助共同排查，确定服务器是否有问题或是在转发过程中出现其他问题。
