pon组网及原理17-典型案例培训.ppt

《pon组网及原理17-典型案例培训.ppt》由会员分享，可在线阅读，更多相关《pon组网及原理17-典型案例培训.ppt（93页珍藏版）》请在三一文库上搜索。

1、维护案例培训,FIBERHOME 2011-05,摘 要,一、故障处理流程 二、设备类案例 三、网管类案例 四、其他案例,数据业务故障排查流程,语音业务故障排查流程,CATV业务故障排查流程,摘 要,一、故障处理流程 二、设备类案例 三、网管类案例 四、其他案例,设备类：1、语音业务通信中断后，不能自动注册,一、语音业务通信中断后，不能自动注册 【现象描述】 某FTTX工程AN5116-02型OLT设备下带AN5006-07和09型ONU有语音和数据业务，onu停电，等来电设备重新上电后，语音业务不正常，需要多次重写配置，才能注册成功。语音协议使用MGCP。 【处理过程】 首先，找一个故障点，

2、然后做镜像抓包，如下图所示：,设备类：1、语音业务通信中断后，不能自动注册,从抓包分析来看，onu在通信正常后，就会给软件换平台发注册消息，但此软件换平台给onu回的是一个400的错误码，是一个临时不执行的错误，只有连续多下几次配置，也就是多次向软交换平台发起注册，onu才能注册上，平台才会回200 ok的消息。 为进一步查找故障原因，让软交换平台也做信令跟踪。通过软交换平台的信令跟踪发现，MGC向下发的审计消息，如下图所示：,设备类：1、语音业务通信中断后，不能自动注册,设备类：1、语音业务通信中断后，不能自动注册,与软交换平台工程师联系沟通后，发现信令跟踪的是MGC与SBC间的信令，根据从

3、onu侧抓的包和MGC侧的跟踪信令可以说明SBC没有转发onu向平台发的注册消息。因此，初步可以判断是上层平台的问题导致onu注册不上的。 最后，软交换平台工程师在查找原因时发现，所提供的软交换平台地址为备用地址，将注册地址修改后，故障消失。 【故障分析】 从此次故障来看，通过抓包发现onu在注册时，软交换平台给回的消息为400（临时不执行）的错误，那么就需要平台给出为什么不执行的原因，最后通过平台侧的工程师协助查找，发现是所提供软交换平台地址错误导致的。,设备类：2、 09AONU下联设备ARP攻击导致同一个PON口下所有用户pppoe拨号678的故障案例,二、09AONU下联设备ARP攻击

4、导致同一个PON口下所有用户pppoe拨号678的故障案例 【网络拓扑】,设备类：2、 09AONU下联设备ARP攻击导致同一个PON口下所有用户pppoe拨号678的故障案例,【现象描述】 某处运营商网络使用我司AN5116-02系列EPON设备，下挂09A,07A的ONU，全部为FTTB设备。某日该OLT有一个PON口下带的FTTB用户出现拨号678的故障，但拨号并不是每次都拨不上，有时拨号十次或二十多次偶尔还是能够成功拨到BRAS的，拨通后宽带业务使用正常，无掉包或网速慢等问题。 【处理过程】 首先对该处进行OLT上联、ONU下联进行PING包处理，目的是检查整个通路到BRAS的情况。在

5、某个故障点的07A设备接一部电脑，在OLT上联空的电口接一部电脑，使用同一VLAN PING包，PING包10000个后发现只丢一个包，丢包率近0%，故无物理通路故障。继续检查OLT设备的FDB表，以及投诉点07A设备的ARL表。当我们进行拨号的时候，可以在29槽看到上层8505交换机的MAC地址，也可以在EC2槽位上看到用户拨号电脑的MAC地址，并且业务VLAN ID正确；同时看07A设备ARL表，可以看26口上学到的8505的MAC，也可看到用户端口学到的用户电脑的MAC，且VLAN ID正确。由以上信息可以证明在设备内部的VLAN学习及地址转发情况都是正常的，而且一但拨上后业务一切正常，

6、PING DNS都是良好，说明上层设备也正常，但始终pppoe拨号十分困难。,设备类：2、 09AONU下联设备ARP攻击导致同一个PON口下所有用户pppoe拨号678的故障案例,继续在OLT上联口做拨号测试，挑空电口做测试，发现每次拨号都能成功；再进一步了解情况，做各处的拨号测试，将故障范围缩小在了一个PON口上，即其它几个PON口拨号都正常，仅一个PON口下的共计10台ONU拨号不正常。怀疑存在环回，再检查FDB表，对比29槽和该槽位的地址表，并未发现有EC2板存在上层设备地址的情况，而且此处也设置了ONU ACL，已经杜绝了下联ONU端口环回情况，但不能排除ONU下挂交换机的硬件环回情

7、况，因为此处有大量FTTB_ONU下挂或级联交换机的情况。再继续从抓包分析入手，分别在镜像ONU上联、EC2前面板、OLT上联口等三处同时安排人员，各挂一台电脑，将每次pppoe拨号包的流程进行抓包。实施后发现PPPOE拨号的PADI广播包不是每次都能到达上联口，直到成功发送出上联口才能收到BRAS的PADO回复，那样才能成功拨号上网。而我们从某次pppoe发包，ONU端抓包发现共发送了两次拨号直到第7个PADI广播才收到PADO回复，对比EC2抓包，只收到了总共3个PADI广播包；而上联口当然只收到了一个PADI的广播包，也就是最后一次拨号成功了。反复进行了多次pppoe抓包，都是随机性的拨

8、号成功，有时候拨号十几次才拨号成功。从上述情况看就是因为PADI广播包在ONU-EC2丢失一次，在EC2-GSWC-GUP7丢失一次。请参考下图，ONU处总共发出7次PADI才成功的流程：,设备类：2、 09AONU下联设备ARP攻击导致同一个PON口下所有用户pppoe拨号678的故障案例,得知故障根源后，要确定是什么缘由导致丢弃PADI包才行。OLT系统内部有广播包的门限限制，AN5116-02系统内部每个PON口的广播包带宽是2048kbit/s。再次抓包，并且不过滤包，终于在包中发现有一个MAC为00:27:19:5d:61:62的设备不停的向上层发送大量ARP广播包，不停的查找192

9、.168.1.1的地址是对应哪台设备，它完全把目的地址为ff:ff:ff:ff:ff:ff的广播类型带宽资源占用耗尽，这很明显这是属于病毒包。找到该包的VLAN Tag值，立即找出了对应的是一台AN5006-09A设备的端口，立即屏蔽掉该端口业务，发现拨号每次都能正常了，故障解决。赴,设备类：2、 09AONU下联设备ARP攻击导致同一个PON口下所有用户pppoe拨号678的故障案例,现场发现该台09A下面下挂一台交换机，这个交换机上没有做任何设置，默认的VLAN 1也没有关闭，导致不停的向上发送ARP包，造成广播类型带宽资源耗尽，致使正常用户拨号受阻。请看下图，大量无用ARP广播包：,设备

10、类：2、 09AONU下联设备ARP攻击导致同一个PON口下所有用户pppoe拨号678的故障案例,【故障分析】 AN5006-07A、AN5006-09B、AN5006-10几款设备中都有一个包抑制功能的设置，在stwich目录下，可以在ONU的switch目录中输入show storm port 1-24查看门限，查看07ONU的包抑制设置方法如下： 其中有广播包、多播包、目的地环回失败包等类型的门限设置，广播包门限默认设置为62kbit/s，也可以用set storm port 1-24 enable 1 bcast 62设置门限（出厂一般都是62kbit/s）。由于组网时，ONU侧的F

11、E口有下挂多个交换机或级联的情况，不可避免的造成了网络复杂化，也很难杜绝一些硬件环回和病毒包的泛滥，而07ONU等设备下有门限设置，即使存在下游设备问题也不会影响PON口,设备类：2、 09AONU下联设备ARP攻击导致同一个PON口下所有用户pppoe拨号678的故障案例,的上行广播包带宽。而AN5006-09A设备早期固件版本不支持上行包的抑制功能，导致09AONU下带交换机产生的大量ARP广播包上行到EC2盘PON口，同时pppoe协议中的PADI包是广播方式通过EC2盘和GSWC盘上行到BRAS，导致用户发出PADI广播包上行到EC2盘后被丢弃，引起PPPOE连接不能成功，因此用户端电

12、脑拨号出现678错误无法上网。 对于5006-09A型ONU可以有两种方法解决此问题：1、查到此大量广播包的端口，屏蔽此端口，然后查清广播包问题来源，进行处理；2、升级5006-09A设备为最新固件版本，可以进行广播包抑制，避免此故障发生。推荐采用第二种方法。 另外关于抓包分析，平时分析故障抓包总是通过过滤等手段逐步细化定位问题，虽然某些问题如语音可以通过此法逐步定位问题，但此次故障仅过滤pppoed报文不能完全定位出问题，相反抓包不过滤看全部的包，才能发现是其它的ARP攻击包占用了广播包带宽。同时抓包需要在OLT的上联口，EC2盘上，09AONU的端口上分别抓包，分析PPPOE协议的报文是否

13、正确。,设备类：3、 5006-15设备语音单通故障分析,三、5006-15设备语音单通故障分析 【现象描述】 AN5006-15设备语音出现单通现象。具体现象为该15设备下用户无论做主叫还是做被叫，与外部电话通话时，15ONU设备的用户可以听到外部电话的声音，但是外部电话听不到15ONU设备用户的声音。 【处理过程】 AN5006-15设备配置情况如下： 设备IP地址： 10.14.149.242 MGC IP地址： 10.14.132.36 出现故障时，我们在OLT的上联口做镜像抓包。对所抓的包进行如下分析： 1、查看信令流程，如下图所示 A、远端信息 通话建立的时候平台给设备下发的远端的

14、IP地址是10.14.134.4，远端端口号是27744。,设备类：3、 5006-15设备语音单通故障分析,B本地信息 通话建立的时候设备的本地IP地址是10.14.149.242，本地端口号是20000。,设备类：3、 5006-15设备语音单通故障分析,2、查看媒体流信息，如下图所示 A、远端发给设备的RTP流，编码方式为G.711A RTP流从10.14.134.4发给10.14.149.242，远端端口号是27744，本地端口号是20000 IP地址信息与信令中所指明的一致。远端MAC地址为：00:e0:fc:6e:ba:e2 本地MAC地址为：00:0a:c2:1f:8e:cd B

15、、设备发给远端的RTP流 RTP流从10.14.149.242发给10.14.134.4，本地端口号是20000，远端端口号是27744 IP地址信息与信令中所指明的一致。远端MAC地址为：00:e0:fc:6e:ba:e2 本地MAC地址为：00:0a:c2:1f:8e:cd,设备类：3、 5006-15设备语音单通故障分析,3、将所抓的RTP流还原成声音文件，可以听到两边说话的声音。 设备正常时同样抓了一个包。 对该包的分析如下： 1、查看信令流程，如下图所示 A远端信息 通话建立的时候平台给设备下发的远端的IP地址是10.14.134.4，远端端口号是45916。,设备类：3、 5006

16、-15设备语音单通故障分析,B本地信息 通话建立的时候设备的本地IP地址是10.14.149.242，本地端口号是20000。,设备类：3、 5006-15设备语音单通故障分析,2、查看媒体流信息，如下图所示 A远端发给设备的RTP流 RTP流从10.14.134.4发给10.14.149.242，远端端口号是45916，本地端口号是20000 IP地址信息与信令中所指明的一致。远端MAC地址为：00:18:82:84:e7:ff 本地MAC地址为：00:0a:c2:1f:8e:cd B. 设备发给远端的RTP流 RTP流从10.14.149.242发给10.14.134.4，本地端口号是20

17、000，远端端口号是45916。IP地址信息与信令中所指明的一致。远端MAC地址为：00:18:82:84:e7:ff 本地MAC地址为：00:0a:c2:1f:8e:cd,设备类：3、 5006-15设备语音单通故障分析,3、将所抓的RTP流还原成声音文件，可以听到两边说话的声音。 【故障结论】 单通现象的产生一般是由于没有收到对方的媒体流导致的。而我们发现所抓的单通的包中媒体流是双向的，而且声音还原出来两边都可以听得到，这表明设备是有发媒体流给远端的。由于包是在OLT上联抓的，这说明从AN5006-15设备到OLT端没有问题。对比正常和单通时的抓包，两个包并没有区别，这说明对于EPON设备

18、这端来说没有任何改变，出现单通问题并不是由于EPON设备引起的。,设备类：4、 IPTV业务HTTP页面失败故障,四、IPTV业务HTTP页面失败故障 【现象描述】 用户的IPTV 业务应用中，观看大部分频道节目正常，就是唯独新闻频道无法正常收看。 【处理过程】 现场处理测试把机顶盒放在设备上联口单VLAN测试，结果正常。放在用户处无法正常收看。根据现在捕获的信令消息，分析如下： 用户处异常时信令报文：,设备类：4、 IPTV业务HTTP页面失败故障,如上图：在NO.4报文的位置，用HTTP协议（TCP PSH）GET操作尝试从服务器58.223.251.72获取新闻频道的内容.接着服务器也响

19、应了该请求。（TCP ACK）如下图： 接下来，等待了15s服务器却未应答HTML请求成功（HTTP/1.0 200 OK），也没有发回任何HTML资源，于是在15.57s的时候结束了TCP连接，如下图：,设备类：4、 IPTV业务HTTP页面失败故障,异常时，HTTP协议并未应答成功，于是机顶盒一直去尝试用GET获取HTML资源。在怀疑上层服务器未应答的同时，在捕获下来的正常的过程中，我们发现了问题所在。在机顶盒以同样GET方式请求服务器资源的时候（TCP PUH），服务器也像刚才那样用(TCP ACK)给与响应，但与之前不同的是，这次服务器开始传输HTML资源的内容（第103的报文开始包含

20、了HTML请求的应答200 OK,后续为HTML资源内容）。如下图：,设备类：4、 IPTV业务HTTP页面失败故障,HTTP协议请求服务器端服务成功（HTTP/1.0 200 OK） 再观察上面帧的长度达到了1514，不带VLAN的帧是1514，加上双层VLAN，帧的长度就达到了1522.再去看下主控盘交换芯片的最大帧长度为1518，这样的下行应答报文主控盘不让过也就不足为奇了。,设备类：4、 IPTV业务HTTP页面失败故障,【故障结论】 在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。 第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入

21、SYN_SEND状态，等待服务器确认； SYN： 同步序列编号(Synchronize Sequence Numbers) 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态； 第三次握手：客户端收到服务器的SYNACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。 完成三次握手，客户端与服务器开始传送数据，流程如下: HTTP协议请求服务器端服务成功（HTTP/1.0 200 OK） 上述故障是由于T

22、CP协议在三次握手失败，导致创建TCP连接失败，故障出现。导致TCP握手和建链失败是由于OLT上的MTU值限制了包的大小。通过修改增大GSWC主控盘的最大帧长度解决了故障。,设备类：4、 IPTV业务HTTP页面失败故障,设备类：5、 pos机拨号频繁失败,五、pos机拨号频繁失败 【现象描述】 AN5116-02下挂07B型ONU，出现窄带pos机拨号无法连接，抛开POS机使用而电脑进行模拟拨号正常。 【处理过程】 通过电脑模拟pos机拨号情况。,设备类：5、 pos机拨号频繁失败,设备类：5、 pos机拨号频繁失败,上图是电脑连接POS中心过程，将连接过程中电脑发出的RTP包还原成语音(s

23、end1.au),电脑接收的RTP包还原成语音(recv1.au),上图是将这两个语音信号放到语音处理软件中看到的频域信号连接之初交互过程，红色直线表示时间上的对应关系，下图中红色圆中的信号是POS中心发过来的信号。,设备类：5、 pos机拨号频繁失败,设备类：5、 pos机拨号频繁失败,上图红色圆圈中的是电脑与POS中心连接上过程，从电脑与POS中心交互信号的特征可以判断双方使用的是V90协议。 2 pos机拨号情况。 下图是POS机与POS中心连接过程，将连接过程中POS机发出的RTP包还原成语音(send2.au),POS机接收的RTP包还原成语音(recv2.au),上图是将这两个语音

24、信号放到语音处理软件中看到的频域信号连接之初交互过程，红色直线表示时间上的对应关系，下图中红色圆中的信号是POS中心发过来的信号。通过对比图1与图3中recv1和recv2信号发现这两个在交互之初是一样的，随后就不同了。同时通过对比图1与图3中send1和send2信号可以看到用蓝色箭头标记的就是这两个信号的不同之处，正是由于这两个信号的不同导致了POS中心随后发出来的信号有差异，在图1中POS中心随后用V90协议与电脑进行协商并且最终电脑可以连接上，而在图2中POS中心随后一直发送频率为2100HZ的ansbar信号，而POS机也一直发送频率范围为700hz1400hz信号，最终协商超时，连

25、接失败。,设备类：5、 pos机拨号频繁失败,设备类：5、 pos机拨号频繁失败,【故障结论】 基于以上分析，更改服务器或者客户端的modem协商协议使其匹配后，故障解决。,设备类：6、数图错误导致无法拨号问题,六、数图错误导致无法拨号问题 【现象描述】 开通时注册能够成功，被叫正常，但是主叫时无法拨号。 【处理过程】 1、被叫正常，说明端点用户名、RTP资源设置正确。 2、通过抓包分析，发现在主叫时，收到软交换下放数图后，ONU回复语法错误，如图：,设备类：6、数图错误导致无法拨号问题,3、根据此错误提示，应该是数图中存在语法不支持，导致回错。与软交换配置人员沟通后，确认为软交换数图配置错误

26、导致，软交换更改配置后正常。 【故障分析】 数图截图如下：,设备类：6、数图错误导致无法拨号问题,从上面数图截图可以看到，在数图中间连续出现两个“|”，标准中规定“|”表示前后内容为可选项，在每个“|”后必须由具体数图内容，否则就是不符合标准的，故连续两个“|”中间没有任何内容，是不符合标准的，这样将导致信令回错，无法拨号。,设备类：7、 AN5006-20开通IC卡业务处理说明,七、 AN5006-20开通IC卡业务处理说明 【现象描述】 烽火AN5006-20下挂IC卡话机, 首先需要ONU侧端口电流能够达到35MA左右,才能激活话机内的芯片运行，并且每天凌晨1点，话机的存储芯片会将每天的

27、通话记录自动上报到IC卡平台，设备也无法自动上报. 【处理过程】 1、下图为IC卡电话机，通过电话线连接到一个芯片,当端口电流达到35MA时，可激活该芯片，使话机自动运行. 2、现场测试，当采用默认电流时，摘机后屏幕会显示请等待，听筒里首先会听到连嘟3声，然后接下来就是每隔4秒左右哒一声，一直到最后听忙音，这个就是电话芯片没有启动起来.由于芯片没有启动，因此无法抓到任何语音信令. 3、从MCU盘telnet登录到pots盘的, 在device目录下输入config port 1 register c6 len 2 value 0b 91 0 0 0 0 1 - 该pots盘的端口（范围164）

28、 91 - 电流值，可以逐步增加 其它值固定不变,设备类：7、 AN5006-20开通IC卡业务处理说明,4. 命令保存后，摘机后也是听到连嘟3声，然后听忙音，但是不会听到每隔4秒左右哒一声，这说明电话芯片已经启动，于是让平台加载业务，通过测试后业务正常使用. 5. IC卡话机可正常使用，但却没有定时上报存储芯片的通话信息，于是该20上对应IC卡业务的单个端口的回声抑制关闭掉后正常,每天可定时上报存储芯片的内容 . 【故障分析】 普通IC卡公话是一种离线式终端，其话机信息（如工作参数、费率资料、卡资料、话单等）是通过每日定时汇报与IC卡管理系统通信进行更新，其通信协议为标准的MODEM通信协议

29、（V.23或V.22），该协议属于模拟通信，而现在的EPON采用光通信协议，属于数字通信。通信协议的不匹配在一定程度上造成EPON在还原模拟通信的波形时出现失真，从而使IC卡系统接收到不正确上传命令而中断通信过程, EPON设备端口馈电电流一般在16mA24mA. 而现行IC卡使用的是1998年信息产业部发布的第二版标准“YDN-109-1998 集成电路（IC）卡公用付费电话系统总技术要求”，该标准规定应保证不少于18mA的工作电流，这就造成部分话机因工作电流不足而掉电，无法正常使用.特别是部分使用时间长的IC卡话机，其内部原件（电容等）有一定损耗的情况下，对电流要求会更高,设备类：8、 O

30、LT下挂ONU频繁出现MGC中断告警故障处理,八、 OLT下挂ONU频繁出现MGC中断告警故障处理 【网络拓朴】,设备类：8、 OLT下挂ONU频繁出现MGC中断告警故障处理,【现象描述】 某地区5116-02 OLT的下挂10几端5006-20，40几端5006-07B，语音采用H.248协议，一直以来运行稳定。最近新增部分5006-07B和5006-10B，做完数据发现很多ONU出现MGC链接断开告警，过段时间可以自行恢复，过会又出现该告警，语音业务一直闪断。,设备类：8、 OLT下挂ONU频繁出现MGC中断告警故障处理,【处理过程】 该OLT下挂ONU以前运行一直很稳定，这次故障极有可能

31、是新增的数据引起的， 首先检查各项数据，发现VLAN和MGC地址配置均正确，NGN上联用户数据配置也没有错误，不存在下配置导致其他数据丢失的情况。后来分析用户之前ONU 所有的宽带数据和语音数据VLAN均走的是上联盘的第一个光口29:4，部分语音VLAN为1160， 主备用MGC地址为10.9.39.45和10.9.33.45，部分语音为1070到1136，主备用MGC地址为10.9.39.41和10.9.33.41 .,设备类：8、 OLT下挂ONU频繁出现MGC中断告警故障处理,而新增的07B和10B设备用户为了分流将所有宽带和语音所有数据均走的上联盘第二个光口29:5，语音VLAN也为1

32、160，主备用MGC地址为10.9.33.44和10.9.39.44. 【故障分析】 通过观察发现出现故障的ONU语音VLAN全为1160，在1070到1136范围内的ONU无此故障。后来发现上联盘29:4和29:5光口均透传了1160的语音VLAN，而上层对以前开的设备和新扩容的设备分配的MGC地址不一样，造成所有走1160 VLAN的语音业务在2个上联口处不断切换，造成MGC的闪断。后来将新扩容设备的语音业务改到走29:4光口业务恢复正常。,设备类：9、丢失关键包导致语音断话故障案例,九、丢失关键包导致语音断话故障案例 【现象描述】 20ONU下挂语音用户上报拨打电话几分钟后电话断掉。主叫

33、被叫都是一样。查看设备注册MGC状态，端点用户名注册状态都正常。 【处理过程】 1、端点域名，端点用户名注册正常，查看心跳配置正常如下： Configngn# SHOW keepalive KeepAlive is: Enable. Interval : 30(s) max times : 3 KeepAlive mode: Time. 2 通过PING MGC发现有丢包，在上联口抓包分析为：,设备类：9、丢失关键包导致语音断话故障案例,设备端点域名为10.51.51.254 MGC IP为10.2.161.3 发现丢包多的时候达到连续丢7个，在网络不稳定的时候如果存在丢包而且丢掉关键的信令包

34、会导致语音问题，延着这一思路接下来通过抓语音信令包来分析 3.通过抓语音信令包分析如下：,设备类：9、丢失关键包导致语音断话故障案例,通过上图抓包分析为设备向软交换发送心跳包如图包序号为1，2 ，软交换并没有回应。从图2中我们知道丢包应丢在城域网。在通过图3我们确定了导致通话过程中断话的根本原因 。,设备类：9、丢失关键包导致语音断话故障案例,通过图3我们发现设备向软交换重新发起了网关注册导致删除了RTP流与关联，导致用户通话中断，而设备向软交换重新发起网关注册的原因为设备向软交换发心跳包软交换没有回应导致设备误以为软交换路故障导致重新发起网关注册。 【故障分析】 由于网络丢包丢失了关键的心跳

35、回应包导致了设备重新向软交换发起网关注册导致语音中断，通过解决上层网络问题解决丢包问题来最终解决语音断话问题。,设备类：10、 IP冲突导致OLT脱管,十、IP冲突导致OLT脱管 【现象描述】 某地市一局端OLT频繁出现脱管现象，网管上每3-5分钟出现该端OLT系统通信终端告警，在告警指示灯显示灰色时，ping该OLT能够正常ping通，下挂业务也正常。 【处理过程】 登陆OLT，查看该OLT的管理IP，进入OLT查看地址解析， show arp如图1：,设备类：10、 IP冲突导致OLT脱管,设备类：10、 IP冲突导致OLT脱管,等待状态轮询后，重新做地址解析，如图2： 从以上情况看出，两

36、次解析网关所对应的MAC地址不同，但理论上应该是相同的，可以断定问题是由IP冲突导致，在告警显示系统通信中断的情况下，telnet 135.254.164.253中，发现设备并非OLT，为一端15型ONU，ONU管理地址与OLT管理地址冲突，更改15ONU的管理IP后一切正常。,设备类：10、 IP冲突导致OLT脱管,【故障分析】 图1中解析出的网关所对应的MAC地址为：00:0a:c2:20:24:a4，但是下面又提示：arp info overwritten for 87fes4ffe by 00:18:82:3c:61:d8这表示真正地路由地址是00:18:82:3c:61:d8，而不是

37、00:0a:c2:20:24:a4，那么此时做ping动作，实际是在ping IP冲突后的15型ONU；图2中的网关所对应的MAC地址为：00:18:82:3c:61:d8，此时为正常状态，同时网管网元指示灯也为绿色正常。综上所述，故障原因为一端15型ONU与OLT的管理IP冲突，导致OLT脱管情况。,设备类：11、 AN5006-04 ONU语音频繁中断故障分析,十一、AN5006-04 ONU语音频繁中断故障分析 【现象描述】 用户自开通后反映语音业务经常出现中断，一段时间后可恢复，反复如此。 【处理过程】 接到申告后，首先更换了该ONU，并重新写入SN号，数据都可以正常下发成功，业务测试

38、均正常，但2小时候，用户再次申告故障。通过在EC2盘上进行抓包查看，如下图,设备类：11、 AN5006-04 ONU语音频繁中断故障分析,可以看出，软交换在向ONU发出AUEP审计消息的时候，IAD回复了一个500的错误代码，出现UNKNOWN endpoint 的错误，进一步发现，该审计消息是从第一个端口，也就是aaln/1开始，由于该ONU采用的SN自动认证，业务通过自动工单系统来进行自动下发，所下发的业务为自动从资源系统进行获取，导致下发的语音业务中没有配置第一个端口，直接从第二个端口（aaln/2）开始使用，当软交换平台发起审计消息时，IAD无法正常的回应该消息，导致软交换平台认为该

39、MGC链路断开，从而引起语音业务中断。从后面的ntfy消息可以看出，IAD主动发起的心跳没有得到回应，此时软交换平台已断开链路。 为进一步确认故障原因，在ONU侧将第一个语音端口虚拟的配置一个端点用户名（aaln/1）,再次抓包查看,设备类：11、 AN5006-04 ONU语音频繁中断故障分析,可以看出，软交换平台发起的AUEP审计消息已经得到正常的恢复（200 代码），经过2天的业务观察，用户没有再出现该问题。,设备类：11、 AN5006-04 ONU语音频繁中断故障分析,【故障分析】 此问题是由于ONU的端口配置无法与软交换平台审计对应而导致，软交换平台无法取消发送审计消息，而自动工单

40、系统为自动获取数据，很难确保获取到的数据一定会从第一个端口开始，目前只能通过营业厅前台受理业务时采用端口顺序使用这一方法来规避此问题。,设备类：12、 FTTN设备不上网管案例,十二、FTTN设备不上网管案例 【现象描述】 某处运营商反映FTTN设备不能上网管，具体现象是ANM2000网管上显示网元工作指示灯灰色、校时检测物理配置不成功、不能Telnet到设备上。 【处理过程】 通过登录OLT，进入EC2的PON目录，发现此台15ONU授权正常、在线状态正常、逻辑链路工作正常、业务正常。由上述现象证明该台15ONU问题出在管理VLAN或者管理IP或路由上。再回到网管上，对15ONU进行PING

41、操作，PING 172.25.15.193，结果发现返回TTL expired transit，此语句意义为TTL在传输中过期，如下图：,设备类：12、 FTTN设备不上网管案例,发现问题后，就要用 TRACERT命令查看所经过的路由，通过Tracert 172.25.15.193，探查路由，发现报文不停的在59.175.252.89和59.175.252.90之间反复跳跃，如下图： 通过监测，得出结论为路由在59.175.252.89和59.175.252.90两处有路由环路，所以造成TTL expired in transit，最终造成该15ONU的snmp报文不能顺利到达我这台网管。所以

42、该问题出在的IP承载网上，将以上截图和情况反馈给数据部门后，数据部门经过调整，最终找到错误的路由，更正后该15ONU顺利上网管，Telnet正常。,设备类：12、 FTTN设备不上网管案例,【故障分析】 此15ONU不上网管为路由环路造成，以致于snmp报文不能在15ONU和网管之间相互传递。TTL为PING包的生命周期，TTL expired in transit 代表包在传输过程中过期，导致这个问题出现的原因有两个： 1）TTL值太小，TTL值小于你和对方主机之间经过的路由器数目； 2）路由器数量太多，经过路由器的数量大于TTL值。 出现该类问题，使用 TRACERT这个命令工具可以很容易

43、找到问题根源（Windows里都自带了这个）。这里的测试结果如下：,设备类：12、 FTTN设备不上网管案例,C: tracert 172.25.15.193 Tracing route to 172.25.15.193 over a maximum of 30 hops: 1 17 ms 9 ms 10 ms 172.26.255.1 2 1ms 1ms 1ms 221.232.253.141 3 1ms 1ms 1ms 59.175.252.181 4 9ms 9 ms 9ms 59.175.252.90 5 1ms 1 ms 1ms 59.175.252.89 6 7ms 9 ms 14

44、ms 59.175.252.90 7 1ms 1 ms 1ms 59.175.252.89 8 3ms 9 ms 9ms 59.175.252.90 9 2ms 1 ms 2ms 59.175.252.89 通过监测，可以清楚的发现，路由产生环路，在59.175.252.90，59.175.252.89，这两个路由之间转不出来，从而造成TTL expired in transit,设备类：13、 IPTV业务在收看节目时约3分钟画面中断故障,十三、IPTV业务在收看节目时大约3分钟画面中断故障案例 【现象描述】 EPON设备（AN5116-02、AN5006-07B）为IPTV提供二层传输通道

45、，近期工程中反映在观看直播节目约3分钟左右，画面定格并随后提示信号中断。 【处理过程】 1. 接到上述故障后首先检查了EPON系统为ITV提供的传输通道，确定正常（通过测试拨号测试手段发现并未出现掉线或者闪断）。为尽快定位故障点先后在ONU与家庭网管及OLT上联口进行抓包分析，如下： 正常协议流程： IGMP V2协议定义的组播查询机制如下：,设备类：13、 IPTV业务在收看节目时约3分钟画面中断故障,1.路由器周期性的向主机侧发出查询报文（QUERY) 2.组的其他成员监听到报告后抑制报告发送 3.主机发送单个组的报告(REPORT) IP地址分析： 121.226.10.40为机顶盒获取

46、到的IP地址； 16.16.16.16为组播服务器地址； 224.0.0.1 为子网的所有系统；,设备类：13、 IPTV业务在收看节目时约3分钟画面中断故障,现场抓包分析如: 1. 121.226.10.40是机顶盒发的加入包,该包是封装在PPP中的。 2. 16.16.16.16是服务器地址,该服务器下发的组播通用组查询是普通的以太网包,没有封装到PPP中。,设备类：13、 IPTV业务在收看节目时约3分钟画面中断故障,3. 主机通过发送IGMP Membership reports，申请加入一个组239.252.153.15。路由器周期性发出IGMP membership query ，

47、检查是否有组员存在，如果在3次查询时间间隔里没有收到回复，则路由器宣布这个子网没有组员。从“ ONU-家庭网关直播过滤.pcap “中可以看出,IGMP Membership Query 查询间隔为1分钟,3次就是3分钟,由于机顶盒IP 121.226.10.40没有回组播通用组查询224.0.0.1,3次查询过后路由器自动将组删除。,设备类：13、 IPTV业务在收看节目时约3分钟画面中断故障,【故障分析】 服务器地址16.16.16.16的宽带接入方式是固定IP,该服务器下发的组播通用组查询224.0.0.1没有封装到PPP中。由于用户和服务器的宽带接入方式不同，机顶盒IP为121.226

48、.10.15没有回组播通用组查询224.0.0.1,所以业务中断。,摘 要,目 录 一、设备类 二、网管类 三、其余,摘 要,一、故障处理流程 二、设备类案例 三、网管类案例 四、其他案例,网管类：1、网管服务器informix，anm2000的密码修改步骤,一、网管服务器informix，anm2000的密码修改步骤 【现象描述】 某FTTX工程网管服务器用户名和密码家喻户晓，某局为了保证服务器的安全性，建议我司修改登录服务器的用户名或者密码。 【处理过程】 1 确认网管为930版本及其后续版本均可以修改用户名或者密码，现把修改密码方法整理出来，用户名类似。 2 暂停所有网管数据库相关服务。

49、 3 在我们电脑-管理-本地用户和组，点击相关用户修改其密码。 4启动数据库服务。点击实例-属性-登录，选择用户并且修改其密码，如下图：,网管类：1、网管服务器informix，anm2000的密码修改步骤,5 进入aemsmdini目录下，修改md.ini密码，如下图。,网管类：1、网管服务器informix，anm2000的密码修改步骤,6 进入aemsfhaemsini目录下，修改aems.ini密码，如下图。 7 重启服务或者电脑。,网管类：2、网管与设备间存在NAT转换时的升级方法,二网管与设备间存在NAT转换时的升级方法 【网络拓扑】 【现象描述】 当网管与设备间存在NAT转换时 ，按照标准方式升级很有可能无法成功，FTP的log日志与正常时不一样，没有显示设备获取的软件具体名称，如下图：,网管类：2、网管与设备间存在NAT转换时的升级方法,同时，网管会显示“从ftp server下载文件出错”，如下图： 【故障分析】 按照标准升级方式，在网管升级窗口中需要填写本网卡的IP地址（134.73.9.179），但由于存在NAT转换，设备向网管获取软件时，会向转换后的IP获取软件（218.23.156.68），但升级时填写的却是未转