维护案例培训维护案例培训FIBERHOME2011-05 摘 要一、故障处理流程二、设备类案例三、网管类案例四、其他案例数据业务故障排查流程语音业务故障排查流程CATV业务故障排查流程 摘 要一、故障处理流程二、设备类案例三、网管类案例四、其他案例 设备类：1 1、语音业务通信中断后，不能自动注册语音业务通信中断后，不能自动注册一、语音业务通信中断后，不能自动注册一、语音业务通信中断后，不能自动注册【现象描述】某FTTX工程AN5116-02型OLT设备下带AN5006-07和09型ONU有语音和数据业务，onu停电，等来电设备重新上电后，语音业务不正常，需要多次重写配置，才能注册成功。语音协议使用MGCP。【处理过程】首先，找一个故障点，然后做镜像抓包，如下图所示： 设备类：1 1、语音业务通信中断后，不能自动注册语音业务通信中断后，不能自动注册从抓包分析来看，onu在通信正常后，就会给软件换平台发注册消息，但此软件换平台给onu回的是一个400的错误码，是一个临时不执行的错误，只有连续多下几次配置，也就是多次向软交换平台发起注册，onu才能注册上，平台才会回200ok的消息。为进一步查找故障原因，让软交换平台也做信令跟踪。通过软交换平台的信令跟踪发现，MGC向下发的审计消息，如下图所示： 设备类：1 1、语音业务通信中断后，不能自动注册语音业务通信中断后，不能自动注册 设备类：1 1、语音业务通信中断后，不能自动注册语音业务通信中断后，不能自动注册与软交换平台工程师联系沟通后，发现信令跟踪的是MGC与SBC间的信令，根据从onu侧抓的包和MGC侧的跟踪信令可以说明SBC没有转发onu向平台发的注册消息。因此，初步可以判断是上层平台的问题导致onu注册不上的。最后，软交换平台工程师在查找原因时发现，所提供的软交换平台地址为备用地址，将注册地址修改后，故障消失。【故障分析】从此次故障来看，通过抓包发现onu在注册时，软交换平台给回的消息为400（临时不执行）的错误，那么就需要平台给出为什么不执行的原因，最后通过平台侧的工程师协助查找，发现是所提供软交换平台地址错误导致的。 设备类：2 2、09AONU09AONU下联设备下联设备ARPARP攻击导致同一个攻击导致同一个PONPON口下口下所有用户所有用户pppoepppoe拨号拨号678678的故障案例的故障案例二、二、09AONU下联设备下联设备ARP攻击导致同一个攻击导致同一个PON口下所有用户口下所有用户pppoe拨号拨号678的故障的故障案例案例【网络拓扑】 设备类：2 2、09AONU09AONU下联设备下联设备ARPARP攻击导致同一个攻击导致同一个PONPON口下口下所有用户所有用户pppoepppoe拨号拨号678678的故障案例的故障案例【现象描述】某处运营商网络使用我司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 2、09AONU09AONU下联设备下联设备ARPARP攻击导致同一个攻击导致同一个PONPON口下口下所有用户所有用户pppoepppoe拨号拨号678678的故障案例的故障案例继续在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 2、09AONU09AONU下联设备下联设备ARPARP攻击导致同一个攻击导致同一个PONPON口下口下所有用户所有用户pppoepppoe拨号拨号678678的故障案例的故障案例得知故障根源后，要确定是什么缘由导致丢弃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 2、09AONU09AONU下联设备下联设备ARPARP攻击导致同一个攻击导致同一个PONPON口下口下所有用户所有用户pppoepppoe拨号拨号678678的故障案例的故障案例现场发现该台09A下面下挂一台交换机，这个交换机上没有做任何设置，默认的VLAN1也没有关闭，导致不停的向上发送ARP包，造成广播类型带宽资源耗尽，致使正常用户拨号受阻。请看下图，大量无用ARP广播包： 设备类：2 2、09AONU09AONU下联设备下联设备ARPARP攻击导致同一个攻击导致同一个PONPON口下口下所有用户所有用户pppoepppoe拨号拨号678678的故障案例的故障案例【故障分析故障分析】AN5006-07A、AN5006-09B、AN5006-10几款设备中都有一个包抑制功能的设置，在stwich目录下，可以在ONU的switch目录中输入showstormport1-24查看门限，查看07ONU的包抑制设置方法如下：其中有广播包、多播包、目的地环回失败包等类型的门限设置，广播包门限默认设置为62kbit/s，也可以用setstormport1-24enable1bcast62设置门限（出厂一般都是62kbit/s）。由于组网时，ONU侧的FE口有下挂多个交换机或级联的情况，不可避免的造成了网络复杂化，也很难杜绝一些硬件环回和病毒包的泛滥，而07ONU等设备下有门限设置，即使存在下游设备问题也不会影响PON口 设备类：2 2、09AONU09AONU下联设备下联设备ARPARP攻击导致同一个攻击导致同一个PONPON口下口下所有用户所有用户pppoepppoe拨号拨号678678的故障案例的故障案例的上行广播包带宽。而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 3、5006-15设备语音单通故障分析设备语音单通故障分析三、三、5006-15设备语音单通故障分析设备语音单通故障分析【现象描述】AN5006-15设备语音出现单通现象。具体现象为该15设备下用户无论做主叫还是做被叫，与外部电话通话时，15ONU设备的用户可以听到外部电话的声音，但是外部电话听不到15ONU设备用户的声音。【处理过程】AN5006-15设备配置情况如下：设备IP地址：MGCIP地址：出现故障时，我们在OLT的上联口做镜像抓包。对所抓的包进行如下分析：1、查看信令流程，如下图所示A、远端信息通话建立的时候平台给设备下发的远端的IP地址是，远端端口号是27744。 设备类：3 3、5006-15设备语音单通故障分析设备语音单通故障分析B本地信息通话建立的时候设备的本地IP地址是，本地端口号是20000。 设备类：3 3、5006-15设备语音单通故障分析设备语音单通故障分析2、查看媒体流信息，如下图所示A、远端发给设备的RTP流，编码方式为RTP流从发给，远端端口号是27744，本地端口号是20000IP地址信息与信令中所指明的一致。远端MAC地址为：00:e0:fc:6e:ba:e2本地MAC地址为：00:0a:c2:1f:8e:cdB、设备发给远端的RTP流RTP流从发给，本地端口号是20000，远端端口号是27744IP地址信息与信令中所指明的一致。远端MAC地址为：00:e0:fc:6e:ba:e2本地MAC地址为：00:0a:c2:1f:8e:cd 设备类：3 3、5006-15设备语音单通故障分析设备语音单通故障分析3、将所抓的RTP流还原成声音文件，可以听到两边说话的声音。设备正常时同样抓了一个包。对该包的分析如下：1、查看信令流程，如下图所示A远端信息通话建立的时候平台给设备下发的远端的IP地址是，远端端口号是45916。 设备类：3 3、5006-15设备语音单通故障分析设备语音单通故障分析B本地信息通话建立的时候设备的本地IP地址是，本地端口号是20000。 设备类：3 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 3、5006-15设备语音单通故障分析设备语音单通故障分析 3、将所抓的RTP流还原成声音文件，可以听到两边说话的声音。【故障结论】单通现象的产生一般是由于没有收到对方的媒体流导致的。而我们发现所抓的单通的包中媒体流是双向的，而且声音还原出来两边都可以听得到，这表明设备是有发媒体流给远端的。由于包是在OLT上联抓的，这说明从AN5006-15设备到OLT端没有问题。对比正常和单通时的抓包，两个包并没有区别，这说明对于EPON设备这端来说没有任何改变，出现单通问题并不是由于EPON设备引起的。 设备类：4 4、IPTV业务HTTP页面失败故障四、四、IPTV业务业务HTTP页面失败故障页面失败故障【现象描述】用户的IPTV业务应用中，观看大部分频道节目正常，就是唯独新闻频道无法正常收看。【处理过程】现场处理测试把机顶盒放在设备上联口单VLAN测试，结果正常。放在用户处无法正常收看。根据现在捕获的信令消息，分析如下：用户处异常时信令报文： 设备类：4 4、IPTV业务HTTP页面失败故障如上图：在报文的位置，用HTTP协议（TCPPSH）GET操作尝试从服务器获取新闻频道的内容.接着服务器也响应了该请求。（TCPACK）如下图： 接下来，等待了15s服务器却未应答HTML请求成功（HTTP/1.0200OK），也没有发回任何HTML资源，于是在的时候结束了TCP连接，如下图： 设备类：4 4、IPTV业务HTTP页面失败故障异常时，HTTP协议并未应答成功，于是机顶盒一直去尝试用GET获取HTML资源。在怀疑上层服务器未应答的同时，在捕获下来的正常的过程中，我们发现了问题所在。在机顶盒以同样GET方式请求服务器资源的时候（TCPPUH），服务器也像刚才那样用(TCPACK)给与响应，但与之前不同的是，这次服务器开始传输HTML资源的内容（第103的报文开始包含了HTML请求的应答200OK,后续为HTML资源内容）。如下图： 设备类：4 4、IPTV业务HTTP页面失败故障HTTP协议请求服务器端服务成功（HTTP/1.0200OK）再观察上面帧的长度达到了1514，不带VLAN的帧是1514，加上双层VLAN，帧的长度就达到了1522.再去看下主控盘交换芯片的最大帧长度为1518，这样的下行应答报文主控盘不让过也就不足为奇了。 设备类：4 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状态；第三次握手：客户端收到服务器的SYNACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。完成三次握手，客户端与服务器开始传送数据，流程如下:HTTP协议请求服务器端服务成功（HTTP/1.0200OK）上述故障是由于TCP协议在三次握手失败，导致创建TCP连接失败，故障出现。导致TCP握手和建链失败是由于OLT上的MTU值限制了包的大小。通过修改增大GSWC主控盘的最大帧长度解决了故障。 设备类：4 4、IPTV业务HTTP页面失败故障 设备类：5 5、pos机拨号频繁失败机拨号频繁失败五、五、pos机拨号频繁失败机拨号频繁失败【现象描述】AN5116-02下挂07B型ONU，出现窄带pos机拨号无法连接，抛开POS机使用而电脑进行模拟拨号正常。【处理过程】通过电脑模拟pos机拨号情况。 设备类：5 5、pos机拨号频繁失败机拨号频繁失败 设备类：5 5、pos机拨号频繁失败机拨号频繁失败上图是电脑连接POS中心过程，将连接过程中电脑发出的RTP包还原成语音(send1.au),电脑接收的RTP包还原成语音(recv1.au),上图是将这两个语音信号放到语音处理软件中看到的频域信号连接之初交互过程，红色直线表示时间上的对应关系，下图中红色圆中的信号是POS中心发过来的信号。 设备类：5 5、pos机拨号频繁失败机拨号频繁失败 设备类：5 5、pos机拨号频繁失败机拨号频繁失败上图红色圆圈中的是电脑与POS中心连接上过程，从电脑与POS中心交互信号的特征可以判断双方使用的是V90协议。 2 pos机拨号情况。机拨号情况。下图是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机也一直发送频率范围为700hz1400hz信号，最终协商超时，连接失败。 设备类：5 5、pos机拨号频繁失败机拨号频繁失败 设备类：5 5、pos机拨号频繁失败机拨号频繁失败【故障结论故障结论】 基于以上分析，更改服务器或者客户端的modem协商协议使其匹配后，故障解决。 设备类：6 6、数图错误导致无法拨号问题数图错误导致无法拨号问题六六、数图错误导致无法拨号问题、数图错误导致无法拨号问题【现象描述】开通时注册能够成功，被叫正常，但是主叫时无法拨号。【处理过程】1、被叫正常，说明端点用户名、RTP资源设置正确。2、通过抓包分析，发现在主叫时，收到软交换下放数图后，ONU回复语法错误，如图： 设备类：6 6、数图错误导致无法拨号问题数图错误导致无法拨号问题3、根据此错误提示，应该是数图中存在语法不支持，导致回错。与软交换配置人员沟通后，确认为软交换数图配置错误导致，软交换更改配置后正常。【故障分析】数图截图如下： 设备类：6 6、数图错误导致无法拨号问题数图错误导致无法拨号问题从上面数图截图可以看到，在数图中间连续出现两个“|”，标准中规定“|”表示前后内容为可选项，在每个“|”后必须由具体数图内容，否则就是不符合标准的，故连续两个“|”中间没有任何内容，是不符合标准的，这样将导致信令回错，无法拨号。 设备类：7 7、AN5006-20开通开通IC卡业务处理说明卡业务处理说明七、七、 AN5006-20开通开通IC卡业务处理说明卡业务处理说明【现象描述】烽火AN5006-20下挂IC卡话机,首先需要ONU侧端口电流能够达到35MA左右,才能激活话机内的芯片运行，并且每天凌晨1点，话机的存储芯片会将每天的通话记录自动上报到IC卡平台，设备也无法自动上报.【处理过程】1、下图为IC卡电话机，通过电话线连接到一个芯片,当端口电流达到35MA时，可激活该芯片，使话机自动运行.2、现场测试，当采用默认电流时，摘机后屏幕会显示请等待，听筒里首先会听到连嘟3声，然后接下来就是每隔4秒左右哒一声，一直到最后听忙音，这个就是电话芯片没有启动起来.由于芯片没有启动，因此无法抓到任何语音信令.3、从MCU盘telnet登录到pots盘的,在device目录下输入configport1registerc6len2value0b9100001-该pots盘的端口（范围164）91-电流值，可以逐步增加其它值固定不变 设备类：7 7、AN5006-20开通开通IC卡业务处理说明卡业务处理说明4.命令保存后，摘机后也是听到连嘟3声，然后听忙音，但是不会听到每隔4秒左右哒一声，这说明电话芯片已经启动，于是让平台加载业务，通过测试后业务正常使用.5.IC卡话机可正常使用，但却没有定时上报存储芯片的通话信息，于是该20上对应IC卡业务的单个端口的回声抑制关闭掉后正常,每天可定时上报存储芯片的内容.【故障分析】普通IC卡公话是一种离线式终端，其话机信息（如工作参数、费率资料、卡资料、话单等）是通过每日定时汇报与IC卡管理系统通信进行更新，其通信协议为标准的MODEM通信协议（或），该协议属于模拟通信，而现在的EPON采用光通信协议，属于数字通信。通信协议的不匹配在一定程度上造成EPON在还原模拟通信的波形时出现失真，从而使IC卡系统接收到不正确上传命令而中断通信过程,EPON设备端口馈电电流一般在16mA24mA.而现行IC卡使用的是1998年信息产业部发布的第二版标准“YDN-109-1998集成电路（IC）卡公用付费电话系统总技术要求”，该标准规定应保证不少于18mA的工作电流，这就造成部分话机因工作电流不足而掉电，无法正常使用.特别是部分使用时间长的IC卡话机，其内部原件（电容等）有一定损耗的情况下，对电流要求会更高 设备类：8 8、OLT下挂下挂ONU频繁出现频繁出现MGC中断告警故障处理中断告警故障处理八、八、OLT下挂下挂ONU频繁出现频繁出现MGC中断告警故障处理中断告警故障处理【网络拓朴网络拓朴】 设备类：8 8、OLT下挂下挂ONU频繁出现频繁出现MGC中断告警故障处理中断告警故障处理【现象描述现象描述】某地区5116-02OLT的下挂10几端5006-20，40几端5006-07B，语音采用协议，一直以来运行稳定。最近新增部分5006-07B和5006-10B，做完数据发现很多ONU出现MGC链接断开告警，过段时间可以自行恢复，过会又出现该告警，语音业务一直闪断。 设备类：8 8、OLT下挂下挂ONU频繁出现频繁出现MGC中断告警故障处理中断告警故障处理【处理过程处理过程】 该OLT下挂ONU以前运行一直很稳定，这次故障极有可能是新增的数据引起的，首先检查各项数据，发现VLAN和MGC地址配置均正确，NGN上联用户数据配置也没有错误，不存在下配置导致其他数据丢失的情况。后来分析用户之前ONU所有的宽带数据和语音数据VLAN均走的是上联盘的第一个光口29:4，部分语音VLAN为1160，主备用MGC地址为和，部分语音为1070到1136，主备用MGC地址为和10.9.33.41. 设备类：8 8、OLT下挂下挂ONU频繁出现频繁出现MGC中断告警故障处理中断告警故障处理 而新增的07B和10B设备用户为了分流将所有宽带和语音所有数据均走的上联盘第二个光口29:5，语音VLAN也为1160，主备用MGC地址为和10.9.39.44.【故障分析故障分析】通过观察发现出现故障的ONU语音VLAN全为1160，在1070到1136范围内的ONU无此故障。后来发现上联盘29:4和29:5光口均透传了1160的语音VLAN，而上层对以前开的设备和新扩容的设备分配的MGC地址不一样，造成所有走1160VLAN的语音业务在2个上联口处不断切换，造成MGC的闪断。后来将新扩容设备的语音业务改到走29:4光口业务恢复正常。 设备类：9 9、丢失关键包导致语音断话故障案例丢失关键包导致语音断话故障案例九、丢失关键包导致语音断话故障案例九、丢失关键包导致语音断话故障案例【现象描述】20ONU下挂语音用户上报拨打电话几分钟后电话断掉。主叫被叫都是一样。查看设备注册MGC状态，端点用户名注册状态都正常。【处理过程】1、端点域名，端点用户名注册正常，查看心跳配置正常如下：Configngn#SHOWkeepaliveKeepAliveis:Enable.Interval:30(s)maxtimes:3KeepAlivemode:Time.2通过PINGMGC发现有丢包，在上联口抓包分析为： 设备类：9 9、丢失关键包导致语音断话故障案例丢失关键包导致语音断话故障案例 设备端点域名为10.51.51.254MGCIP为10.2.161.3发现丢包多的时候达到连续丢7个，在网络不稳定的时候如果存在丢包而且丢掉关键的信令包会导致语音问题，延着这一思路接下来通过抓语音信令包来分析3.通过抓语音信令包分析如下： 设备类：9 9、丢失关键包导致语音断话故障案例丢失关键包导致语音断话故障案例通过上图抓包分析为设备向软交换发送心跳包如图包序号为1，2，软交换并没有回应。从图2中我们知道丢包应丢在城域网。在通过图3我们确定了导致通话过程中断话的根本原因。 设备类：9 9、丢失关键包导致语音断话故障案例丢失关键包导致语音断话故障案例通过图3我们发现设备向软交换重新发起了网关注册导致删除了RTP流与关联，导致用户通话中断，而设备向软交换重新发起网关注册的原因为设备向软交换发心跳包软交换没有回应导致设备误以为软交换路故障导致重新发起网关注册。【故障分析故障分析】由于网络丢包丢失了关键的心跳回应包导致了设备重新向软交换发起网关注册导致语音中断，通过解决上层网络问题解决丢包问题来最终解决语音断话问题。 设备类：1010、 IP冲突导致冲突导致OLT脱管脱管十、十、IP冲突导致冲突导致OLT脱管脱管【现象描述】某地市一局端OLT频繁出现脱管现象，网管上每3-5分钟出现该端OLT系统通信终端告警，在告警指示灯显示灰色时，ping该OLT能够正常ping通，下挂业务也正常。【处理过程】登陆OLT，查看该OLT的管理IP，进入OLT查看地址解析，showarp如图1： 设备类：1010、 IP冲突导致冲突导致OLT脱管脱管 设备类：1010、 IP冲突导致冲突导致OLT脱管脱管 等待状态轮询后，重新做地址解析，如图2：从以上情况看出，两次解析网关所对应的MAC地址不同，但理论上应该是相同的，可以断定问题是由IP冲突导致，在告警显示系统通信中断的情况下，中，发现设备并非OLT，为一端15型ONU，ONU管理地址与OLT管理地址冲突，更改15ONU的管理IP后一切正常。 设备类：1010、 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脱管情况。 设备类：1111、 AN5006-04 ONU语音频繁中断故障分析语音频繁中断故障分析十一、十一、AN5006-04 ONU语音频繁中断故障分析语音频繁中断故障分析【现象描述现象描述】用户自开通后反映语音业务经常出现中断，一段时间后可恢复，反复如此。【处理过程处理过程】接到申告后，首先更换了该ONU，并重新写入SN号，数据都可以正常下发成功，业务测试均正常，但2小时候，用户再次申告故障。通过在EC2盘上进行抓包查看，如下图 设备类：1111、 AN5006-04 ONU语音频繁中断故障分析语音频繁中断故障分析可以看出，软交换在向ONU发出AUEP审计消息的时候，IAD回复了一个500的错误代码，出现UNKNOWNendpoint的错误，进一步发现，该审计消息是从第一个端口，也就是aaln/1开始，由于该ONU采用的SN自动认证，业务通过自动工单系统来进行自动下发，所下发的业务为自动从资源系统进行获取，导致下发的语音业务中没有配置第一个端口，直接从第二个端口（aaln/2）开始使用，当软交换平台发起审计消息时，IAD无法正常的回应该消息，导致软交换平台认为该MGC链路断开，从而引起语音业务中断。从后面的ntfy消息可以看出，IAD主动发起的心跳没有得到回应，此时软交换平台已断开链路。为进一步确认故障原因，在ONU侧将第一个语音端口虚拟的配置一个端点用户名（aaln/1）,再次抓包查看 设备类：1111、 AN5006-04 ONU语音频繁中断故障分析语音频繁中断故障分析可以看出，软交换平台发起的AUEP审计消息已经得到正常的恢复（200代码），经过2天的业务观察，用户没有再出现该问题。 设备类：1111、 AN5006-04 ONU语音频繁中断故障分析语音频繁中断故障分析【故障分析故障分析】此问题是由于ONU的端口配置无法与软交换平台审计对应而导致，软交换平台无法取消发送审计消息，而自动工单系统为自动获取数据，很难确保获取到的数据一定会从第一个端口开始，目前只能通过营业厅前台受理业务时采用端口顺序使用这一方法来规避此问题。 设备类：1212、 FTTN设备不上网管案例设备不上网管案例十二、十二、FTTN设备不上网管案例设备不上网管案例【现象描述】某处运营商反映FTTN设备不能上网管，具体现象是ANM2000网管上显示网元工作指示灯灰色、校时检测物理配置不成功、不能Telnet到设备上。【处理过程】通过登录OLT，进入EC2的PON目录，发现此台15ONU授权正常、在线状态正常、逻辑链路工作正常、业务正常。由上述现象证明该台15ONU问题出在管理VLAN或者管理IP或路由上。再回到网管上，对15ONU进行PING操作，结果发现返回TTLexpiredtransit，此语句意义为TTL在传输中过期，如下图： 设备类：1212、 FTTN设备不上网管案例设备不上网管案例发现问题后，就要用TRACERT命令查看所经过的路由，通过，探查路由，发现报文不停的在和之间反复跳跃，如下图：通过监测，得出结论为路由在和两处有路由环路，所以造成TTLexpiredintransit，最终造成该15ONU的snmp报文不能顺利到达我这台网管。所以该问题出在的IP承载网上，将以上截图和情况反馈给数据部门后，数据部门经过调整，最终找到错误的路由，更正后该15ONU顺利上网管，Telnet正常。 设备类：1212、 FTTN设备不上网管案例设备不上网管案例【故障分析故障分析】此15ONU不上网管为路由环路造成，以致于snmp报文不能在15ONU和网管之间相互传递。TTL为PING包的生命周期，TTLexpiredintransit代表包在传输过程中过期，导致这个问题出现的原因有两个：1）TTL值太小，TTL值小于你和对方主机之间经过的路由器数目；2）路由器数量太多，经过路由器的数量大于TTL值。出现该类问题，使用TRACERT这个命令工具可以很容易找到问题根源（Windows里都自带了这个）。这里的测试结果如下： 设备类：1212、 FTTN设备不上网管案例设备不上网管案例C:tracert172.25.15.193Tracingrouteto172.25.15.193overamaximumof30hops:117ms9ms10ms172.26.255.149ms9ms9ms59.175.252.9051ms1ms1ms59.175.252.8967ms9ms14ms59.175.252.9071ms1ms1ms59.175.252.8983ms9ms9ms59.175.252.9092ms进程里查看。发现进程内存使用大小为，需要重启服务。4、将放在任意本地磁盘根目录下，进入运行-cmd，进入所在的目录下输入userdump回车。例：在相应的目录下会生成一个的文件，这个操作是将ANserver的内存数据捕获下来，以便后续在网管功能恢复后查障。 网管类：5 5、某地某地EPON网管分布式服务器网管分布式服务器ONU自动同步到网自动同步到网管功能引起的网管挂死问题管功能引起的网管挂死问题5、重启网管服务，重启服务时采用先Anm2000DaemonService，然后关闭除AEMS-DBserver外的其他服务（这里没有先后顺序），最后关闭AEMS-DBserver。如果在关闭AEMS-DBserver时进度条读到一半开始卡住，可以等待4-5分钟等系统报错将服务光比，也可以在任务管理器的进程里找到直接结束进程，进程结束后等待2分钟左右再一次将服务启动起来，顺序与关闭服务顺序相反。AEMS-DBserver启动后1分钟左右再继续启动其他服务。6、服务完全启动后，网管功能恢复。7、启动Anm2000DaemonService服务。【故障分析】确认故障原因如下：由于现有网管采集机制为网管间隔5分钟去轮询所有设备的ONU授权信息，后台程序根据轮询的信息与数据库中已有信息进行比对来进行onu网管自动授权操作。onu被设备自动授权后，olt会有trap主动上报增量的onu授权信息至网管，在trap没有丢失的情况下，网管是能够保证onu授权信息与olt设备上同步的。但是，现在轮询的信息为全量的，并且间隔时间过短（5分钟），这个任务会堆积在后台进行处理，由于onu数目众多，导致后台处理延迟。建议，增加网管轮询间隔时间，来提高后台程序的运行效率，暂时通过此方法来减小后台应用程序进行无效数据比对造成的系统资源浪费。 网管类：5 5、某地某地EPON网管分布式服务器网管分布式服务器ONU自动同步到网自动同步到网管功能引起的网管挂死问题管功能引起的网管挂死问题修正方式：修改采集服务器文件中的如下参数轮询epon系统已授权sn列表，单位:msPOLLINGAUTHORONULIST=300000将其值由300000改为7200000，即轮询时间修正为2小时。再重启manger服务即可。 摘 要一、故障处理流程二、设备类案例三、网管类案例四、其他案例 其余类：1 1、无线上网提示无线上网提示“windows找不到证书来让您登陆到找不到证书来让您登陆到网络网络”问题问题一、无线上网提示一、无线上网提示“windows找不到证书来让您登陆到网络找不到证书来让您登陆到网络”问题问题【现象描述】一用户反映其电脑通过无线网卡连接我司的HG110设备上网时提示“windows找不到证书来让您登陆到网络”，如下图所示【处理过程处理过程】让用户检查电脑无线网卡的设置：1、右键点击“网上邻居网上邻居”，选择“属性属性”。 其余类：1 1、无线上网提示无线上网提示“windows找不到证书来让您登陆到找不到证书来让您登陆到网络网络”问题问题 2.右键点击“无线网络连接”，选择“属性”。 其余类：1 1、无线上网提示无线上网提示“windows找不到证书来让您登陆到找不到证书来让您登陆到网络网络”问题问题 3.在“无线网络配置无线网络配置”中选择所要连接的网络，点击“属性属性”。 其余类：1 1、无线上网提示无线上网提示“windows找不到证书来让您登陆到找不到证书来让您登陆到网络网络”问题问题 4.点击“验证验证”，将“启用此网络的验证启用此网络的验证”前的勾取消。 其余类：1 1、无线上网提示无线上网提示“windows找不到证书来让您登陆到找不到证书来让您登陆到网络网络”问题问题如果该提示还没能消除，则调整电脑无线网卡的“网络验证网络验证”设置： 其余类：1 1、无线上网提示无线上网提示“windows找不到证书来让您登陆到找不到证书来让您登陆到网络网络”问题问题该用户设置成“共享式”后，“windows找不到证书来让您登陆到网络”消除，无线上网正常。【故障分析故障分析】该问题是由于电脑无线网卡与HG110设备（或是别的无线路由器）的验证、加密设置不匹配导致的，可通过调整电脑无线网卡或HG110设备（或是别的无线路由器）的相关设置解决。 附：附：如果有的电脑的“无线网络连接属性”中找不到“无线网络配置无线网络配置”选项，如下图所示： 其余类：1 1、无线上网提示无线上网提示“windows找不到证书来让您登陆到找不到证书来让您登陆到网络网络”问题问题这是无线网络的相关服务没有开启而导致的。单击“开始/运行”，输入“services.msc”并回车，在打开的服务列表中找到“WirelessZeroConfiguration”项服务，鼠标右键点击选择启动该服务。之后再次打开无线网络连接的属性窗口时就会显示“无线网络配置无线网络配置”选项了。谢谢大家！宽带接入已经成为中国电信业务增长的第一驱动力。中国电信总工程师韦乐平