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

维护案例培训FIBERHOME2011-05摘要

一、故障处理流程二、设备类案例三、网管类案例四、其他案例数据业务故障排查流程语音业务故障排查流程CATV业务故障排查流程摘要

一、故障处理流程

二、设备类案例三、网管类案例四、其他案例

设备类：1、语音业务通信中断后，不能自动注册

一、语音业务通信中断后，不能自动注册【现象描述】某FTTX工程AN5116-02型OLT设备下带AN5006-07和09型ONU有语音和数据业务，onu停电，等来电设备重新上电后，语音业务不正常，需要多次重写配置，才能注册成功。语音协议使用MGCP。【处理过程】首先，找一个故障点，然后做镜像抓包，如下图所示：

设备类：1、语音业务通信中断后，不能自动注册

从抓包分析来看，onu在通信正常后，就会给软件换平台发注册消息，但此软件换平台给onu回的是一个400的错误码，是一个临时不执行的错误，只有连续多下几次配置，也就是多次向软交换平台发起注册，onu才能注册上，平台才会回200ok的消息。为进一步查找故障原因，让软交换平台也做信令跟踪。通过软交换平台的信令跟踪发现，MGC向下发的审计消息，如下图所示：

设备类：1、语音业务通信中断后，不能自动注册

设备类：1、语音业务通信中断后，不能自动注册

与软交换平台工程师联系沟通后，发现信令跟踪的是MGC与SBC间的信令，根据从onu侧抓的包和MGC侧的跟踪信令可以说明SBC没有转发onu向平台发的注册消息。因此，初步可以判断是上层平台的问题导致onu注册不上的。最后，软交换平台工程师在查找原因时发现，所提供的软交换平台地址为备用地址，将注册地址修改后，故障消失。【故障分析】从此次故障来看，通过抓包发现onu在注册时，软交换平台给回的消息为400（临时不执行）的错误，那么就需要平台给出为什么不执行的原因，最后通过平台侧的工程师协助查找，发现是所提供软交换平台地址错误导致的。

设备类：2、

09AONU下联设备ARP攻击导致同一个PON口下所有用户pppoe拨号678的故障案例

二、09AONU下联设备ARP攻击导致同一个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的情况。在某个故障点的07A设备接一部电脑，在OLT上联空的电口接一部电脑，使用同一VLANPING包，PING包10000个后发现只丢一个包，丢包率近0%，故无物理通路故障。继续检查OLT设备的FDB表，以及投诉点07A设备的ARL表。当我们进行拨号的时候，可以在29槽看到上层8505交换机的MAC地址，也可以在EC2槽位上看到用户拨号电脑的MAC地址，并且业务VLANID正确；同时看07A设备ARL表，可以看26口上学到的8505的MAC，也可看到用户端口学到的用户电脑的MAC，且VLANID正确。由以上信息可以证明在设备内部的VLAN学习及地址转发情况都是正常的，而且一但拨上后业务一切正常，PINGDNS都是良好，说明上层设备也正常，但始终pppoe拨号十分困难。

设备类：2、

09AONU下联设备ARP攻击导致同一个PON口下所有用户pppoe拨号678的故障案例

继续在OLT上联口做拨号测试，挑空电口做测试，发现每次拨号都能成功；再进一步了解情况，做各处的拨号测试，将故障范围缩小在了一个PON口上，即其它几个PON口拨号都正常，仅一个PON口下的共计10台ONU拨号不正常。怀疑存在环回，再检查FDB表，对比29槽和该槽位的地址表，并未发现有EC2板存在上层设备地址的情况，而且此处也设置了ONUACL，已经杜绝了下联ONU端口环回情况，但不能排除ONU下挂交换机的硬件环回情况，因为此处有大量FTTB_ONU下挂或级联交换机的情况。再继续从抓包分析入手，分别在镜像ONU上联、EC2前面板、OLT上联口等三处同时安排人员，各挂一台电脑，将每次pppoe拨号包的流程进行抓包。实施后发现PPPOE拨号的PADI广播包不是每次都能到达上联口，直到成功发送出上联口才能收到BRAS的PADO回复，那样才能成功拨号上网。而我们从某次pppoe发包，ONU端抓包发现共发送了两次拨号直到第7个PADI广播才收到PADO回复，对比EC2抓包，只收到了总共3个PADI广播包；而上联口当然只收到了一个PADI的广播包，也就是最后一次拨号成功了。反复进行了多次pppoe抓包，都是随机性的拨号成功，有时候拨号十几次才拨号成功。从上述情况看就是因为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广播包，不停的查找的地址是对应哪台设备，它完全把目的地址为ff:ff:ff:ff:ff:ff的广播类型带宽资源占用耗尽，这很明显这是属于病毒包。找到该包的VLANTag值，立即找出了对应的是一台AN5006-09A设备的端口，立即屏蔽掉该端口业务，发现拨号每次都能正常了，故障解决。赴

设备类：2、

09AONU下联设备ARP攻击导致同一个PON口下所有用户pppoe拨号678的故障案例

现场发现该台09A下面下挂一台交换机，这个交换机上没有做任何设置，默认的VLAN1也没有关闭，导致不停的向上发送ARP包，造成广播类型带宽资源耗尽，致使正常用户拨号受阻。请看下图，大量无用ARP广播包：

设备类：2、

09AONU下联设备ARP攻击导致同一个PON口下所有用户pppoe拨号678的故障案例

【故障分析】AN5006-07A、AN5006-09B、AN5006-10几款设备中都有一个包抑制功能的设置，在stwich目录下，可以在ONU的switch目录中输入showstormport[1-24]查看门限，查看07ONU的包抑制设置方法如下：其中有广播包、多播包、目的地环回失败包等类型的门限设置，广播包门限默认设置为62kbit/s，也可以用setstormport[1-24]enable1bcast62设置门限（出厂一般都是62kbit/s）。由于组网时，ONU侧的FE口有下挂多个交换机或级联的情况，不可避免的造成了网络复杂化，也很难杜绝一些硬件环回和病毒包的泛滥，而07ONU等设备下有门限设置，即使存在下游设备问题也不会影响PON口

设备类：2、

09AONU下联设备ARP攻击导致同一个PON口下所有用户pppoe拨号678的故障案例

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

设备类：3、

5006-15设备语音单通故障分析三、5006-15设备语音单通故障分析【现象描述】AN5006-15设备语音出现单通现象。具体现象为该15设备下用户无论做主叫还是做被叫，与外部电话通话时，15ONU设备的用户可以听到外部电话的声音，但是外部电话听不到15ONU设备用户的声音。【处理过程】AN5006-15设备配置情况如下：设备IP地址：MGCIP地址：出现故障时，我们在OLT的上联口做镜像抓包。对所抓的包进行如下分析：

1、查看信令流程，如下图所示

A、远端信息通话建立的时候平台给设备下发的远端的IP地址是，远端端口号是27744。

设备类：3、

5006-15设备语音单通故障分析

B．本地信息通话建立的时候设备的本地IP地址是，本地端口号是20000。

设备类：3、

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

B、设备发给远端的RTP流RTP流从发给，本地端口号是20000，远端端口号是27744IP地址信息与信令中所指明的一致。远端MAC地址为：00:e0:fc:6e:ba:e2本地MAC地址为：00:0a:c2:1f:8e:cd

设备类：3、

5006-15设备语音单通故障分析3、将所抓的RTP流还原成声音文件，可以听到两边说话的声音。设备正常时同样抓了一个包。对该包的分析如下：

1、查看信令流程，如下图所示A．远端信息通话建立的时候平台给设备下发的远端的IP地址是，远端端口号是45916。

设备类：3、

5006-15设备语音单通故障分析B．本地信息通话建立的时候设备的本地IP地址是，本地端口号是20000。

设备类：3、

5006-15设备语音单通故障分析2、查看媒体流信息，如下图所示A．远端发给设备的RTP流RTP流从发给，远端端口号是45916，本地端口号是20000IP地址信息与信令中所指明的一致。远端MAC地址为：00:18:82:84:e7:ff本地MAC地址为：00:0a:c2:1f:8e:cdB.设备发给远端的RTP流RTP流从发给，本地端口号是20000，远端端口号是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设备这端来说没有任何改变，出现单通问题并不是由于EPON设备引起的。

设备类：4、

IPTV业务HTTP页面失败故障四、IPTV业务HTTP页面失败故障【现象描述】用户的IPTV业务应用中，观看大部分频道节目正常，就是唯独新闻频道无法正常收看。【处理过程】现场处理测试把机顶盒放在设备上联口单VLAN测试，结果正常。放在用户处无法正常收看。根据现在捕获的信令消息，分析如下：用户处异常时信令报文：

设备类：4、

IPTV业务HTTP页面失败故障如上图：在NO.4报文的位置，用HTTP协议（TCPPSH）GET操作尝试从服务器获取新闻频道的内容.接着服务器也响应了该请求。（TCPACK）如下图：

接下来，等待了15s服务器却未应答HTML请求成功（HTTP/1.0200OK），也没有发回任何HTML资源，于是在15.57s的时候结束了TCP连接，如下图：

设备类：4、

IPTV业务HTTP页面失败故障

异常时，HTTP协议并未应答成功，于是机顶盒一直去尝试用GET获取HTML资源。在怀疑上层服务器未应答的同时，在捕获下来的正常的过程中，我们发现了问题所在。在机顶盒以同样GET方式请求服务器资源的时候（TCPPUH），服务器也像刚才那样用(TCPACK)给与响应，但与之前不同的是，这次服务器开始传输HTML资源的内容（第103的报文开始包含了HTML请求的应答200OK,后续为HTML资源内容）。如下图：

设备类：4、

IPTV业务HTTP页面失败故障

HTTP协议请求服务器端服务成功（HTTP/1.0200OK）再观察上面帧的长度达到了1514，不带VLAN的帧是1514，加上双层VLAN，帧的长度就达到了1522.再去看下主控盘交换芯片的最大帧长度为1518，这样的下行应答报文主控盘不让过也就不足为奇了。

设备类：4、

IPTV业务HTTP页面失败故障

【故障结论】在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。

第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；SYN：同步序列编号(SynchronizeSequenceNumbers)

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

完成三次握手，客户端与服务器开始传送数据，流程如下:

HTTP协议请求服务器端服务成功（HTTP/1.0200OK）上述故障是由于TCP协议在三次握手失败，导致创建TCP连接失败，故障出现。导致TCP握手和建链失败是由于OLT上的MTU值限制了包的大小。通过修改增大GSWC主控盘的最大帧长度解决了故障。

设备类：4、

IPTV业务HTTP页面失败故障

设备类：5、

pos机拨号频繁失败

五、pos机拨号频繁失败

【现象描述】AN5116-02下挂07B型ONU，出现窄带pos机拨号无法连接，抛开POS机使用而电脑进行模拟拨号正常。【处理过程】通过电脑模拟pos机拨号情况。

设备类：5、

pos机拨号频繁失败

设备类：5、

pos机拨号频繁失败

上图是电脑连接POS中心过程，将连接过程中电脑发出的RTP包还原成语音(send1.au),电脑接收的RTP包还原成语音(recv1.au),上图是将这两个语音信号放到语音处理软件中看到的频域信号连接之初交互过程，红色直线表示时间上的对应关系，下图中红色圆中的信号是POS中心发过来的信号。

设备类：5、

pos机拨号频繁失败

设备类：5、

pos机拨号频繁失败

上图红色圆圈中的是电脑与POS中心连接上过程，从电脑与POS中心交互信号的特征可以判断双方使用的是V90协议。2pos机拨号情况。下图是POS机与POS中心连接过程，将连接过程中POS机发出的RTP包还原成语音(send2.au),POS机接收的RTP包还原成语音(recv2.au),上图是将这两个语音信号放到语音处理软件中看到的频域信号连接之初交互过程，红色直线表示时间上的对应关系，下图中红色圆中的信号是POS中心发过来的信号。通过对比图1与图3中recv1和recv2信号发现这两个在交互之初是一样的，随后就不同了。同时通过对比图1与图3中send1和send2信号可以看到用蓝色箭头标记的就是这两个信号的不同之处，正是由于这两个信号的不同导致了POS中心随后发出来的信号有差异，在图1中POS中心随后用V90协议与电脑进行协商并且最终电脑可以连接上，而在图2中POS中心随后一直发送频率为2100HZ的ansbar信号，而POS机也一直发送频率范围为700hz—1400hz信号，最终协商超时，连接失败。

设备类：5、

pos机拨号频繁失败

设备类：5、

pos机拨号频繁失败

【故障结论】

基于以上分析，更改服务器或者客户端的modem协商协议使其匹配后，故障解决。

设备类：6、数图错误导致无法拨号问题六、数图错误导致无法拨号问题【现象描述】开通时注册能够成功，被叫正常，但是主叫时无法拨号。【处理过程】

1、被叫正常，说明端点用户名、RTP资源设置正确。

2、通过抓包分析，发现在主叫时，收到软交换下放数图后，ONU回复语法错误，如图：

设备类：6、数图错误导致无法拨号问题

3、根据此错误提示，应该是数图中存在语法不支持，导致回错。与软交换配置人员沟通后，确认为软交换数图配置错误导致，软交换更改配置后正常。【故障分析】

数图截图如下：

设备类：6、数图错误导致无法拨号问题从上面数图截图可以看到，在数图中间连续出现两个“|”，标准中规定“|”表示前后内容为可选项，在每个“|”后必须由具体数图内容，否则就是不符合标准的，故连续两个“|”中间没有任何内容，是不符合标准的，这样将导致信令回错，无法拨号。

设备类：7、

AN5006-20开通IC卡业务处理说明

设备类：7、

AN5006-20开通IC卡业务处理说明

设备类：8、

OLT下挂ONU频繁出现MGC中断告警故障处理八、

OLT下挂ONU频繁出现MGC中断告警故障处理【网络拓朴】

设备类：8、

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

设备类：8、

OLT下挂ONU频繁出现MGC中断告警故障处理【处理过程】

该OLT下挂ONU以前运行一直很稳定，这次故障极有可能是新增的数据引起的，首先检查各项数据，发现VLAN和MGC地址配置均正确，NGN上联用户数据配置也没有错误，不存在下配置导致其他数据丢失的情况。后来分析用户之前ONU所有的宽带数据和语音数据VLAN均走的是上联盘的第一个光口29:4，部分语音VLAN为1160，主备用MGC地址为和，部分语音为1070到1136，主备用MGC地址为和1.

设备类：8、

OLT下挂ONU频繁出现MGC中断告警故障处理

而新增的07B和10B设备用户为了分流将所有宽带和语音所有数据均走的上联盘第二个光口29:5，语音VLAN也为1160，主备用MGC地址为和4.【故障分析】通过观察发现出现故障的ONU语音VLAN全为1160，在1070到1136范围内的ONU无此故障。后来发现上联盘29:4和29:5光口均透传了1160的语音VLAN，而上层对以前开的设备和新扩容的设备分配的MGC地址不一样，造成所有走1160VLAN的语音业务在2个上联口处不断切换，造成MGC的闪断。后来将新扩容设备的语音业务改到走29:4光口业务恢复正常。

设备类：9、丢失关键包导致语音断话故障案例九、丢失关键包导致语音断话故障案例【现象描述】20ONU下挂语音用户上报拨打电话几分钟后电话断掉。主叫被叫都是一样。查看设备注册MGC状态，端点用户名注册状态都正常。【处理过程】

1、端点域名，端点用户名注册正常，查看心跳配置正常如下：Config\ngn#SHOWkeepaliveKeepAliveis:Enable.Interval:30(s)maxtimes:3KeepAlivemode:Time.2．通过PINGMGC发现有丢包，在上联口抓包分析为：

设备类：9、丢失关键包导致语音断话故障案例

设备端点域名为54MGCIP为

发现丢包多的时候达到连续丢7个，在网络不稳定的时候如果存在丢包而且丢掉关键的信令包会导致语音问题，延着这一思路接下来通过抓语音信令包来分析3.通过抓语音信令包分析如下：

设备类：9、丢失关键包导致语音断话故障案例通过上图抓包分析为设备向软交换发送心跳包如图包序号为1，2，软交换并没有回应。从图2中我们知道丢包应丢在城域网。在通过图3我们确定了导致通话过程中断话的根本原因。

设备类：9、丢失关键包导致语音断话故障案例通过图3我们发现设备向软交换重新发起了网关注册导致删除了RTP流与关联，导致用户通话中断，而设备向软交换重新发起网关注册的原因为设备向软交换发心跳包软交换没有回应导致设备误以为软交换路故障导致重新发起网关注册。【故障分析】由于网络丢包丢失了关键的心跳回应包导致了设备重新向软交换发起网关注册导致语音中断，通过解决上层网络问题解决丢包问题来最终解决语音断话问题。

设备类：10、IP冲突导致OLT脱管十、IP冲突导致OLT脱管【现象描述】某地市一局端OLT频繁出现脱管现象，网管上每3-5分钟出现该端OLT系统通信终端告警，在告警指示灯显示灰色时，ping该OLT能够正常ping通，下挂业务也正常。【处理过程】登陆OLT，查看该OLT的管理IP，进入OLT查看地址解析，showarp如图1：

设备类：10、IP冲突导致OLT脱管

设备类：10、IP冲突导致OLT脱管

等待状态轮询后，重新做地址解析，如图2：从以上情况看出，两次解析网关所对应的MAC地址不同，但理论上应该是相同的，可以断定问题是由IP冲突导致，在告警显示系统通信中断的情况下，中，发现设备并非OLT，为一端15型ONU，ONU管理地址与OLT管理地址冲突，更改15ONU的管理IP后一切正常。

设备类：10、IP冲突导致OLT脱管【故障分析】图1中解析出的网关所对应的MAC地址为：00:0a:c2:20:24:a4，但是下面又提示：arpinfooverwrittenfor87fes4ffeby00:18:82:3c:61:d8这表示真正地路由地址是00:18:82:3c:61:d8，而不是00:0a:c2:20:24:a4，那么此时做ping动作，实际是在pingIP冲突后的15型ONU；图2中的网关所对应的MAC地址为：00:18:82:3c:61:d8，此时为正常状态，同时网管网元指示灯也为绿色正常。综上所述，故障原因为一端15型ONU与OLT的管理IP冲突，导致OLT脱管情况。

设备类：11、AN5006-04ONU语音频繁中断故障分析十一、AN5006-04ONU语音频繁中断故障分析【现象描述】用户自开通后反映语音业务经常出现中断，一段时间后可恢复，反复如此。【处理过程】接到申告后，首先更换了该ONU，并重新写入SN号，数据都可以正常下发成功，业务测试均正常，但2小时候，用户再次申告故障。通过在EC2盘上进行抓包查看，如下图

设备类：11、AN5006-04ONU语音频繁中断故障分析可以看出，软交换在向ONU发出AUEP审计消息的时候，IAD回复了一个500的错误代码，出现UNKNOWNendpoint的错误，进一步发现，该审计消息是从第一个端口，也就是aaln/1开始，由于该ONU采用的SN自动认证，业务通过自动工单系统来进行自动下发，所下发的业务为自动从资源系统进行获取，导致下发的语音业务中没有配置第一个端口，直接从第二个端口（aaln/2）开始使用，当软交换平台发起审计消息时，IAD无法正常的回应该消息，导致软交换平台认为该MGC链路断开，从而引起语音业务中断。从后面的ntfy消息可以看出，IAD主动发起的心跳没有得到回应，此时软交换平台已断开链路。为进一步确认故障原因，在ONU侧将第一个语音端口虚拟的配置一个端点用户名（aaln/1）,再次抓包查看

设备类：11、AN5006-04ONU语音频繁中断故障分析可以看出，软交换平台发起的AUEP审计消息已经得到正常的恢复（200代码），经过2天的业务观察，用户没有再出现该问题。

设备类：11、AN5006-04ONU语音频繁中断故障分析【故障分析】此问题是由于ONU的端口配置无法与软交换平台审计对应而导致，软交换平台无法取消发送审计消息，而自动工单系统为自动获取数据，很难确保获取到的数据一定会从第一个端口开始，目前只能通过营业厅前台受理业务时采用端口顺序使用这一方法来规避此问题。

设备类：12、FTTN设备不上网管案例十二、FTTN设备不上网管案例【现象描述】某处运营商反映FTTN设备不能上网管，具体现象是ANM2000网管上显示网元工作指示灯灰色、校时检测物理配置不成功、不能Telnet到设备上。【处理过程】通过登录OLT，进入EC2的PON目录，发现此台15ONU授权正常、在线状态正常、逻辑链路工作正常、业务正常。由上述现象证明该台15ONU问题出在管理VLAN或者管理IP或路由上。再回到网管上，对15ONU进行PING操作，，结果发现返回TTLexpiredtransit，此语句意义为TTL在传输中过期，如下图：

设备类：12、FTTN设备不上网管案例发现问题后，就要用TRACERT命令查看所经过的路由，通过，探查路由，发现报文不停的在和之间反复跳跃，如下图：

通过监测，得出结论为路由在和两处有路由环路，所以造成TTLexpiredintransit，最终造成该15ONU的snmp报文不能顺利到达我这台网管。所以该问题出在的IP承载网上，将以上截图和情况反馈给数据部门后，数据部门经过调整，最终找到错误的路由，更正后该15ONU顺利上网管，Telnet正常。

设备类：12、FTTN设备不上网管案例【故障分析】此15ONU不上网管为路由环路造成，以致于snmp报文不能在15ONU和网管之间相互传递。TTL为PING包的生命周期，TTLexpiredintransit代表包在传输过程中过期，导致这个问题出现的原因有两个：1）TTL值太小，TTL值小于你和对方主机之间经过的路由器数目；2）路由器数量太多，经过路由器的数量大于TTL值。出现该类问题，使用TRACERT这个命令工具可以很容易找到问题根源（Windows里都自带了这个）。这里的测试结果如下：

设备类：12、FTTN设备不上网管案例C:\>tracert93Tracingrouteto[93]overamaximumof30hops:117ms9ms10ms49ms9ms9ms051ms<1ms<1ms967ms9ms14ms071ms1ms1ms983ms9ms9ms092ms<1ms2ms9通过监测，可以清楚的发现，路由产生环路，在，，这两个路由之间转不出来，从而造成TTLexpiredintransit

设备类：13、IPTV业务在收看节目时约3分钟画面中断故障十三、IPTV业务在收看节目时大约3分钟画面中断故障案例【现象描述】EPON设备（AN5116-02、AN5006-07B）为IPTV提供二层传输通道，近期工程中反映在观看直播节目约3分钟左右，画面定格并随后提示信号中断。【处理过程】1.接到上述故障后首先检查了EPON系统为ITV提供的传输通道，确定正常（通过测试拨号测试手段发现并未出现掉线或者闪断）。为尽快定位故障点先后在ONU与家庭网管及OLT上联口进行抓包分析，如下：正常协议流程：IGMPV2协议定义的组播查询机制如下：

设备类：13、IPTV业务在收看节目时约3分钟画面中断故障1.路由器周期性的向主机侧发出查询报文（QUERY)2.组的其他成员监听到报告后抑制报告发送3.主机发送单个组的报告(REPORT)IP地址分析：为机顶盒获取到的IP地址；为组播服务器地址；

为子网的所有系统；

设备类：13、IPTV业务在收看节目时约3分钟画面中断故障现场抓包分析如:是机顶盒发的加入包,该包是封装在PPP中的。是服务器地址,该服务器下发的组播通用组查询是普通的以太网包,没有封装到PPP中。

设备类：13、IPTV业务在收看节目时约3分钟画面中断故障3.主机通过发送IGMPMembershipreports，申请加入一个组。路由器周期性发出IGMPmembershipquery，检查是否有组员存在，如果在3次查询时间间隔里没有收到回复，则路由器宣布这个子网没有组员。从"ONU-家庭网关直播过滤.pcap"中可以看出,IGMPMembershipQuery查询间隔为1分钟,3次就是3分钟,由于机顶盒没有回组播通用组查询,3次查询过后路由器自动将组删除。

设备类：13、IPTV业务在收看节目时约3分钟画面中断故障【故障分析】服务器地址的宽带接入方式是固定IP,该服务器下发的组播通用组查询没有封装到PPP中。由于用户和服务器的宽带接入方式不同，机顶盒IP为没有回组播通用组查询,所以业务中断。

摘要

目录一、设备类二、网管类三、其余摘要

一、故障处理流程二、设备类案例三、网管类案例四、其他案例

网管类：1、网管服务器informix，anm2000的密码修改步骤一、网管服务器informix，anm2000的密码修改步骤【现象描述】某FTTX工程网管服务器用户名和密码家喻户晓，某局为了保证服务器的安全性，建议我司修改登录服务器的用户名或者密码。【处理过程】1确认网管为930版本及其后续版本均可以修改用户名或者密码，现把修改密码方法整理出来，用户名类似。2暂停所有网管数据库相关服务。3在我们电脑---管理---本地用户和组，点击相关用户修改其密码。4启动数据库服务。点击实例----属性---登录，选择用户并且修改其密码，如下图：

网管类：1、网管服务器informix，anm2000的密码修改步骤5进入aems\md\ini目录下，修改md.ini密码，如下图。

网管类：1、网管服务器informix，anm2000的密码修改步骤6进入aems\fhaems\ini目录下，修改aems.ini密码，如下图。7重启服务或者电脑。

网管类：2、网管与设备间存在NAT转换时的升级方法二．网管与设备间存在NAT转换时的升级方法【网络拓扑】【现象描述】

当网管与设备间存在NAT转换时，按照标准方式升级很有可能无法成功，FTP的log日志与正常时不一样，没有显示设备获取的软件具体名称，如下图：

网管类：2、网管与设备间存在NAT转换时的升级方法同时，网管会显示“从ftpserver下载文件出错”，如下图：【故障分析】按照标准升级方式，在网管升级窗口中需要填写本网卡的IP地址（），但由于存在NAT转换，设备向网管获取软件时，会向转换后的IP获取软件（），但升级时填写的却是未转换的IP（），这样就导致设备从转换后的IP无法获取到具体软件，从而无法升级成功。

网管类：2、网管与设备间存在NAT转换时的升级方法解决方法

1、打开网管的升级窗口，首先填写网管网卡的IP（），同时把“手动输入文件名”前的复选框的勾取消，这时网管将自动找到ftp所指向的文件夹，然后选择需要升级的文件，如下图：

网管类：2、网管与设备间存在NAT转换时的升级方法此步骤让ftp软件指向本机对应的软件文件夹。

2、当选择完毕需要升级的软件后，再更改FTP服务器的IP为NAT转换后的IP（），然后点击“升级软件”，如下图：

网管类：2、网管与设备间存在NAT转换时的升级方法此时可以看到FTP软件的log日志中显示了设备获取具体软件的过程，这样升级可以成功。

网管类：3、客户端和网管告警时间不一致处理案例三、客户端和网管告警时间不一致处理案例【现象描述】网管升级到0508版本，客户端也升级了，但是客户端上查看的告警时间和网管上的不同步.【处理过程】1、核对服务器和客户端上的时间，同步。2、怀疑打补丁时候有错误，在另外一台客户端重新打上补丁进行升级，登录进去后发现告警时间还是不一致。3、找出服务器上和客户端上的单条命令进行对比，发现告警时间提前了15个小时但是分钟和秒钟时同步的。4、因为有多台服务器，在客户端抓包确认与那个服务器相连，确认正确。5、再次对比服务器和客户端上的一批命令，发现客户端上的告警与服务器上的告警每一条命令都是相差15个小时，例如网管告警上报时间2011年3月18号，客户端上对应的告警时间是2011年3月19号，然而服务器和客户端上的时间都是2011年3月18号。6、每条告警相差15个小时，怀疑是服务器时区设置不对。

网管类：3、客户端和网管告警时间不一致处理案例7、检查核对，服务器是windows2008系统，是正版全英文系统，时区是美国时区。经修改重启服务器网管和客户端网，告警时间同步。【故障分析】服务器上的装的是正版英文系统，系统默认是美国时区，但是系统显示时间人为的修改与北京时间同步，服务器上装的是XP系统，系统默认是北京时区，系统显示时间也是北京时间。客户端告警是从服务器上读取的，读取告警时间的时候，客户端会自动的把美国时区转换成北京时区，因此客户端和服务器上的上报时间不一致，提前了15个小时。

网管类：4、TL1下发命令无返回问题处理案例四、TL1下发命令无返回问题处理案例【现象描述】对5516-01下发TL1命令时，无论什么命令，都没有收到设备返回信息，无法下发成功，但是通过手工同步后可以下发成功。【处理过程】

1、由于无法收到设备返回信息，怀疑TRAPIP配置错误，检查后确认没有问题。2、怀疑个性问题，新加几端ONU进行测试，发现现象一样。3、检查操作系统服务，发现安装了一个系统trap服务，如下图，禁用此服务后TL1下发命令恢复正常。

网管类：4、TL1下发命令无返回问题处理案例【故障分析】由于TL1下发配置是否成功完全依赖TRAP信息接收正确与否，一旦没有收到应有的TRAP信息，将导致下配置超时、不全等问题，而5516-01是具备TRAP重传功能的，所以首先检查TRAPIP配置是否正确，如果TRAPIP配置正确，则网管应该肯定能够收到设备TRAPIP。而操作系统如果安装了自带的TRAP服务，将会与网管、设备之间的TRAP冲突，导致网管服务无法接收到应有的TRAP，从而下配置始终收不到设备返回信息，禁用后即可恢复正常。

网管类：5、某地EPON网管分布式服务器ONU自动同步到网管功能引起的网管挂死问题五、某地EPON网管分布式服务器ONU自动同步到网管功能引起的网管挂死问题【现象描述】网管客户端无法登录，提示“Anserver数据库连接失败”【处理过程】1、检查客户端所在电脑网络连接。

2、检查网管客户端配置文件。检查D:\AEMS_Client\fhanms\ini目录下的aems.ini文件里的IP设置是否正确。3、检查应用服务器上的AEMS-DBserver服务是否正常启动，检查ANserver进程内存使用情况(300M以内为正常，但有时进程挂死的时候内存也不超过300M)，在任务管理器->进程里查看。发现Anserver.exe进程内存使用大小为1.2G，需要重启服务。

4、将userdump.exe放在任意本地磁盘根目录下，进入运行->cmd，进入userdump.exe所在的目录下输入userdump<进程名称>回车。例：在相应的目录下会生成一个ANserver.dmp的文件，这个操作是将ANserver的内存数据捕获下来，以便后续在网管功能恢复后查障。

网管类：5、某地EPON网管分布式服务器ONU自动同步到网管功能引起的网管挂死问题