pon組網(wǎng)及原理17-典型案例培訓(xùn)

維護(hù)案例培訓(xùn)FIBERHOME2011-05摘要

一、故障處理流程二、設(shè)備類案例三、網(wǎng)管類案例四、其他案例數(shù)據(jù)業(yè)務(wù)故障排查流程語(yǔ)音業(yè)務(wù)故障排查流程CATV業(yè)務(wù)故障排查流程摘要

一、故障處理流程

二、設(shè)備類案例三、網(wǎng)管類案例四、其他案例

設(shè)備類：1、語(yǔ)音業(yè)務(wù)通信中斷后，不能自動(dòng)注冊(cè)

一、語(yǔ)音業(yè)務(wù)通信中斷后，不能自動(dòng)注冊(cè)【現(xiàn)象描述】某FTTX工程AN5116-02型OLT設(shè)備下帶AN5006-07和09型ONU有語(yǔ)音和數(shù)據(jù)業(yè)務(wù)，onu停電，等來(lái)電設(shè)備重新上電后，語(yǔ)音業(yè)務(wù)不正常，需要多次重寫(xiě)配置，才能注冊(cè)成功。語(yǔ)音協(xié)議使用MGCP。【處理過(guò)程】首先，找一個(gè)故障點(diǎn)，然后做鏡像抓包，如下圖所示：

設(shè)備類：1、語(yǔ)音業(yè)務(wù)通信中斷后，不能自動(dòng)注冊(cè)

從抓包分析來(lái)看，onu在通信正常后，就會(huì)給軟件換平臺(tái)發(fā)注冊(cè)消息，但此軟件換平臺(tái)給onu回的是一個(gè)400的錯(cuò)誤碼，是一個(gè)臨時(shí)不執(zhí)行的錯(cuò)誤，只有連續(xù)多下幾次配置，也就是多次向軟交換平臺(tái)發(fā)起注冊(cè)，onu才能注冊(cè)上，平臺(tái)才會(huì)回200ok的消息。為進(jìn)一步查找故障原因，讓軟交換平臺(tái)也做信令跟蹤。通過(guò)軟交換平臺(tái)的信令跟蹤發(fā)現(xiàn)，MGC向下發(fā)的審計(jì)消息，如下圖所示：

設(shè)備類：1、語(yǔ)音業(yè)務(wù)通信中斷后，不能自動(dòng)注冊(cè)

設(shè)備類：1、語(yǔ)音業(yè)務(wù)通信中斷后，不能自動(dòng)注冊(cè)

與軟交換平臺(tái)工程師聯(lián)系溝通后，發(fā)現(xiàn)信令跟蹤的是MGC與SBC間的信令，根據(jù)從onu側(cè)抓的包和MGC側(cè)的跟蹤信令可以說(shuō)明SBC沒(méi)有轉(zhuǎn)發(fā)onu向平臺(tái)發(fā)的注冊(cè)消息。因此，初步可以判斷是上層平臺(tái)的問(wèn)題導(dǎo)致onu注冊(cè)不上的。最后，軟交換平臺(tái)工程師在查找原因時(shí)發(fā)現(xiàn)，所提供的軟交換平臺(tái)地址為備用地址，將注冊(cè)地址修改后，故障消失?！竟收戏治觥繌拇舜喂收蟻?lái)看，通過(guò)抓包發(fā)現(xiàn)onu在注冊(cè)時(shí)，軟交換平臺(tái)給回的消息為400（臨時(shí)不執(zhí)行）的錯(cuò)誤，那么就需要平臺(tái)給出為什么不執(zhí)行的原因，最后通過(guò)平臺(tái)側(cè)的工程師協(xié)助查找，發(fā)現(xiàn)是所提供軟交換平臺(tái)地址錯(cuò)誤導(dǎo)致的。

設(shè)備類：2、

09AONU下聯(lián)設(shè)備ARP攻擊導(dǎo)致同一個(gè)PON口下所有用戶pppoe撥號(hào)678的故障案例

二、09AONU下聯(lián)設(shè)備ARP攻擊導(dǎo)致同一個(gè)PON口下所有用戶pppoe撥號(hào)678的故障案例

【網(wǎng)絡(luò)拓?fù)洹?/p>

設(shè)備類：2、

09AONU下聯(lián)設(shè)備ARP攻擊導(dǎo)致同一個(gè)PON口下所有用戶pppoe撥號(hào)678的故障案例

【現(xiàn)象描述】某處運(yùn)營(yíng)商網(wǎng)絡(luò)使用我司AN5116-02系列EPON設(shè)備，下掛09A,07A的ONU，全部為FTTB設(shè)備。某日該OLT有一個(gè)PON口下帶的FTTB用戶出現(xiàn)撥號(hào)678的故障，但撥號(hào)并不是每次都撥不上，有時(shí)撥號(hào)十次或二十多次偶爾還是能夠成功撥到BRAS的，撥通后寬帶業(yè)務(wù)使用正常，無(wú)掉包或網(wǎng)速慢等問(wèn)題?！咎幚磉^(guò)程】首先對(duì)該處進(jìn)行OLT上聯(lián)、ONU下聯(lián)進(jìn)行PING包處理，目的是檢查整個(gè)通路到BRAS的情況。在某個(gè)故障點(diǎn)的07A設(shè)備接一部電腦，在OLT上聯(lián)空的電口接一部電腦，使用同一VLANPING包，PING包10000個(gè)后發(fā)現(xiàn)只丟一個(gè)包，丟包率近0%，故無(wú)物理通路故障。繼續(xù)檢查OLT設(shè)備的FDB表，以及投訴點(diǎn)07A設(shè)備的ARL表。當(dāng)我們進(jìn)行撥號(hào)的時(shí)候，可以在29槽看到上層8505交換機(jī)的MAC地址，也可以在EC2槽位上看到用戶撥號(hào)電腦的MAC地址，并且業(yè)務(wù)VLANID正確；同時(shí)看07A設(shè)備ARL表，可以看26口上學(xué)到的8505的MAC，也可看到用戶端口學(xué)到的用戶電腦的MAC，且VLANID正確。由以上信息可以證明在設(shè)備內(nèi)部的VLAN學(xué)習(xí)及地址轉(zhuǎn)發(fā)情況都是正常的，而且一但撥上后業(yè)務(wù)一切正常，PINGDNS都是良好，說(shuō)明上層設(shè)備也正常，但始終pppoe撥號(hào)十分困難。

設(shè)備類：2、

09AONU下聯(lián)設(shè)備ARP攻擊導(dǎo)致同一個(gè)PON口下所有用戶pppoe撥號(hào)678的故障案例

繼續(xù)在OLT上聯(lián)口做撥號(hào)測(cè)試，挑空電口做測(cè)試，發(fā)現(xiàn)每次撥號(hào)都能成功；再進(jìn)一步了解情況，做各處的撥號(hào)測(cè)試，將故障范圍縮小在了一個(gè)PON口上，即其它幾個(gè)PON口撥號(hào)都正常，僅一個(gè)PON口下的共計(jì)10臺(tái)ONU撥號(hào)不正常。懷疑存在環(huán)回，再檢查FDB表，對(duì)比29槽和該槽位的地址表，并未發(fā)現(xiàn)有EC2板存在上層設(shè)備地址的情況，而且此處也設(shè)置了ONUACL，已經(jīng)杜絕了下聯(lián)ONU端口環(huán)回情況，但不能排除ONU下掛交換機(jī)的硬件環(huán)回情況，因?yàn)榇颂幱写罅縁TTB_ONU下掛或級(jí)聯(lián)交換機(jī)的情況。再繼續(xù)從抓包分析入手，分別在鏡像ONU上聯(lián)、EC2前面板、OLT上聯(lián)口等三處同時(shí)安排人員，各掛一臺(tái)電腦，將每次pppoe撥號(hào)包的流程進(jìn)行抓包。實(shí)施后發(fā)現(xiàn)PPPOE撥號(hào)的PADI廣播包不是每次都能到達(dá)上聯(lián)口，直到成功發(fā)送出上聯(lián)口才能收到BRAS的PADO回復(fù)，那樣才能成功撥號(hào)上網(wǎng)。而我們從某次pppoe發(fā)包，ONU端抓包發(fā)現(xiàn)共發(fā)送了兩次撥號(hào)直到第7個(gè)PADI廣播才收到PADO回復(fù)，對(duì)比EC2抓包，只收到了總共3個(gè)PADI廣播包；而上聯(lián)口當(dāng)然只收到了一個(gè)PADI的廣播包，也就是最后一次撥號(hào)成功了。反復(fù)進(jìn)行了多次pppoe抓包，都是隨機(jī)性的撥號(hào)成功，有時(shí)候撥號(hào)十幾次才撥號(hào)成功。從上述情況看就是因?yàn)镻ADI廣播包在ONU->EC2丟失一次，在EC2->GSWC->GUP7丟失一次。請(qǐng)參考下圖，ONU處總共發(fā)出7次PADI才成功的流程：

設(shè)備類：2、

09AONU下聯(lián)設(shè)備ARP攻擊導(dǎo)致同一個(gè)PON口下所有用戶pppoe撥號(hào)678的故障案例

得知故障根源后，要確定是什么緣由導(dǎo)致丟棄PADI包才行。OLT系統(tǒng)內(nèi)部有廣播包的門限限制，AN5116-02系統(tǒng)內(nèi)部每個(gè)PON口的廣播包帶寬是2048kbit/s。再次抓包，并且不過(guò)濾包，終于在包中發(fā)現(xiàn)有一個(gè)MAC為00:27:19:5d:61:62的設(shè)備不停的向上層發(fā)送大量ARP廣播包，不停的查找的地址是對(duì)應(yīng)哪臺(tái)設(shè)備，它完全把目的地址為ff:ff:ff:ff:ff:ff的廣播類型帶寬資源占用耗盡，這很明顯這是屬于病毒包。找到該包的VLANTag值，立即找出了對(duì)應(yīng)的是一臺(tái)AN5006-09A設(shè)備的端口，立即屏蔽掉該端口業(yè)務(wù)，發(fā)現(xiàn)撥號(hào)每次都能正常了，故障解決。赴

設(shè)備類：2、

09AONU下聯(lián)設(shè)備ARP攻擊導(dǎo)致同一個(gè)PON口下所有用戶pppoe撥號(hào)678的故障案例

現(xiàn)場(chǎng)發(fā)現(xiàn)該臺(tái)09A下面下掛一臺(tái)交換機(jī)，這個(gè)交換機(jī)上沒(méi)有做任何設(shè)置，默認(rèn)的VLAN1也沒(méi)有關(guān)閉，導(dǎo)致不停的向上發(fā)送ARP包，造成廣播類型帶寬資源耗盡，致使正常用戶撥號(hào)受阻。請(qǐng)看下圖，大量無(wú)用ARP廣播包：

設(shè)備類：2、

09AONU下聯(lián)設(shè)備ARP攻擊導(dǎo)致同一個(gè)PON口下所有用戶pppoe撥號(hào)678的故障案例

【故障分析】AN5006-07A、AN5006-09B、AN5006-10幾款設(shè)備中都有一個(gè)包抑制功能的設(shè)置，在stwich目錄下，可以在ONU的switch目錄中輸入showstormport[1-24]查看門限，查看07ONU的包抑制設(shè)置方法如下：其中有廣播包、多播包、目的地環(huán)回失敗包等類型的門限設(shè)置，廣播包門限默認(rèn)設(shè)置為62kbit/s，也可以用setstormport[1-24]enable1bcast62設(shè)置門限（出廠一般都是62kbit/s）。由于組網(wǎng)時(shí)，ONU側(cè)的FE口有下掛多個(gè)交換機(jī)或級(jí)聯(lián)的情況，不可避免的造成了網(wǎng)絡(luò)復(fù)雜化，也很難杜絕一些硬件環(huán)回和病毒包的泛濫，而07ONU等設(shè)備下有門限設(shè)置，即使存在下游設(shè)備問(wèn)題也不會(huì)影響PON口

設(shè)備類：2、

09AONU下聯(lián)設(shè)備ARP攻擊導(dǎo)致同一個(gè)PON口下所有用戶pppoe撥號(hào)678的故障案例

的上行廣播包帶寬。而AN5006-09A設(shè)備早期固件版本不支持上行包的抑制功能，導(dǎo)致09AONU下帶交換機(jī)產(chǎn)生的大量ARP廣播包上行到EC2盤(pán)PON口，同時(shí)pppoe協(xié)議中的PADI包是廣播方式通過(guò)EC2盤(pán)和GSWC盤(pán)上行到BRAS，導(dǎo)致用戶發(fā)出PADI廣播包上行到EC2盤(pán)后被丟棄，引起PPPOE連接不能成功，因此用戶端電腦撥號(hào)出現(xiàn)678錯(cuò)誤無(wú)法上網(wǎng)。對(duì)于5006-09A型ONU可以有兩種方法解決此問(wèn)題：1、查到此大量廣播包的端口，屏蔽此端口，然后查清廣播包問(wèn)題來(lái)源，進(jìn)行處理；2、升級(jí)5006-09A設(shè)備為最新固件版本，可以進(jìn)行廣播包抑制，避免此故障發(fā)生。推薦采用第二種方法。另外關(guān)于抓包分析，平時(shí)分析故障抓包總是通過(guò)過(guò)濾等手段逐步細(xì)化定位問(wèn)題，雖然某些問(wèn)題如語(yǔ)音可以通過(guò)此法逐步定位問(wèn)題，但此次故障僅過(guò)濾pppoed報(bào)文不能完全定位出問(wèn)題，相反抓包不過(guò)濾看全部的包，才能發(fā)現(xiàn)是其它的ARP攻擊包占用了廣播包帶寬。同時(shí)抓包需要在OLT的上聯(lián)口，EC2盤(pán)上，09AONU的端口上分別抓包，分析PPPOE協(xié)議的報(bào)文是否正確。

設(shè)備類：3、

5006-15設(shè)備語(yǔ)音單通故障分析三、5006-15設(shè)備語(yǔ)音單通故障分析【現(xiàn)象描述】AN5006-15設(shè)備語(yǔ)音出現(xiàn)單通現(xiàn)象。具體現(xiàn)象為該15設(shè)備下用戶無(wú)論做主叫還是做被叫，與外部電話通話時(shí)，15ONU設(shè)備的用戶可以聽(tīng)到外部電話的聲音，但是外部電話聽(tīng)不到15ONU設(shè)備用戶的聲音?！咎幚磉^(guò)程】AN5006-15設(shè)備配置情況如下：設(shè)備IP地址：MGCIP地址：出現(xiàn)故障時(shí)，我們?cè)贠LT的上聯(lián)口做鏡像抓包。對(duì)所抓的包進(jìn)行如下分析：

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

A、遠(yuǎn)端信息通話建立的時(shí)候平臺(tái)給設(shè)備下發(fā)的遠(yuǎn)端的IP地址是，遠(yuǎn)端端口號(hào)是27744。

設(shè)備類：3、

5006-15設(shè)備語(yǔ)音單通故障分析

B．本地信息通話建立的時(shí)候設(shè)備的本地IP地址是，本地端口號(hào)是20000。

設(shè)備類：3、

5006-15設(shè)備語(yǔ)音單通故障分析2、查看媒體流信息，如下圖所示A、遠(yuǎn)端發(fā)給設(shè)備的RTP流，編碼方式為G.711ARTP流從發(fā)給，遠(yuǎn)端端口號(hào)是27744，本地端口號(hào)是20000IP地址信息與信令中所指明的一致。遠(yuǎn)端MAC地址為：00:e0:fc:6e:ba:e2本地MAC地址為：00:0a:c2:1f:8e:cd

B、設(shè)備發(fā)給遠(yuǎn)端的RTP流RTP流從發(fā)給，本地端口號(hào)是20000，遠(yuǎn)端端口號(hào)是27744IP地址信息與信令中所指明的一致。遠(yuǎn)端MAC地址為：00:e0:fc:6e:ba:e2本地MAC地址為：00:0a:c2:1f:8e:cd

設(shè)備類：3、

5006-15設(shè)備語(yǔ)音單通故障分析3、將所抓的RTP流還原成聲音文件，可以聽(tīng)到兩邊說(shuō)話的聲音。設(shè)備正常時(shí)同樣抓了一個(gè)包。對(duì)該包的分析如下：

1、查看信令流程，如下圖所示A．遠(yuǎn)端信息通話建立的時(shí)候平臺(tái)給設(shè)備下發(fā)的遠(yuǎn)端的IP地址是，遠(yuǎn)端端口號(hào)是45916。

設(shè)備類：3、

5006-15設(shè)備語(yǔ)音單通故障分析B．本地信息通話建立的時(shí)候設(shè)備的本地IP地址是，本地端口號(hào)是20000。

設(shè)備類：3、

5006-15設(shè)備語(yǔ)音單通故障分析2、查看媒體流信息，如下圖所示A．遠(yuǎn)端發(fā)給設(shè)備的RTP流RTP流從發(fā)給，遠(yuǎn)端端口號(hào)是45916，本地端口號(hào)是20000IP地址信息與信令中所指明的一致。遠(yuǎn)端MAC地址為：00:18:82:84:e7:ff本地MAC地址為：00:0a:c2:1f:8e:cdB.設(shè)備發(fā)給遠(yuǎn)端的RTP流RTP流從發(fā)給，本地端口號(hào)是20000，遠(yuǎn)端端口號(hào)是45916。IP地址信息與信令中所指明的一致。遠(yuǎn)端MAC地址為：00:18:82:84:e7:ff本地MAC地址為：00:0a:c2:1f:8e:cd

設(shè)備類：3、

5006-15設(shè)備語(yǔ)音單通故障分析

3、將所抓的RTP流還原成聲音文件，可以聽(tīng)到兩邊說(shuō)話的聲音。【故障結(jié)論】單通現(xiàn)象的產(chǎn)生一般是由于沒(méi)有收到對(duì)方的媒體流導(dǎo)致的。而我們發(fā)現(xiàn)所抓的單通的包中媒體流是雙向的，而且聲音還原出來(lái)兩邊都可以聽(tīng)得到，這表明設(shè)備是有發(fā)媒體流給遠(yuǎn)端的。由于包是在OLT上聯(lián)抓的，這說(shuō)明從AN5006-15設(shè)備到OLT端沒(méi)有問(wèn)題。對(duì)比正常和單通時(shí)的抓包，兩個(gè)包并沒(méi)有區(qū)別，這說(shuō)明對(duì)于EPON設(shè)備這端來(lái)說(shuō)沒(méi)有任何改變，出現(xiàn)單通問(wèn)題并不是由于EPON設(shè)備引起的。

設(shè)備類：4、

IPTV業(yè)務(wù)HTTP頁(yè)面失敗故障四、IPTV業(yè)務(wù)HTTP頁(yè)面失敗故障【現(xiàn)象描述】用戶的IPTV業(yè)務(wù)應(yīng)用中，觀看大部分頻道節(jié)目正常，就是唯獨(dú)新聞?lì)l道無(wú)法正常收看?！咎幚磉^(guò)程】現(xiàn)場(chǎng)處理測(cè)試把機(jī)頂盒放在設(shè)備上聯(lián)口單VLAN測(cè)試，結(jié)果正常。放在用戶處無(wú)法正常收看。根據(jù)現(xiàn)在捕獲的信令消息，分析如下：用戶處異常時(shí)信令報(bào)文：

設(shè)備類：4、

IPTV業(yè)務(wù)HTTP頁(yè)面失敗故障如上圖：在NO.4報(bào)文的位置，用HTTP協(xié)議（TCPPSH）GET操作嘗試從服務(wù)器獲取新聞?lì)l道的內(nèi)容.接著服務(wù)器也響應(yīng)了該請(qǐng)求。（TCPACK）如下圖：

接下來(lái)，等待了15s服務(wù)器卻未應(yīng)答HTML請(qǐng)求成功（HTTP/1.0200OK），也沒(méi)有發(fā)回任何HTML資源，于是在15.57s的時(shí)候結(jié)束了TCP連接，如下圖：

設(shè)備類：4、

IPTV業(yè)務(wù)HTTP頁(yè)面失敗故障

異常時(shí)，HTTP協(xié)議并未應(yīng)答成功，于是機(jī)頂盒一直去嘗試用GET獲取HTML資源。在懷疑上層服務(wù)器未應(yīng)答的同時(shí)，在捕獲下來(lái)的正常的過(guò)程中，我們發(fā)現(xiàn)了問(wèn)題所在。在機(jī)頂盒以同樣GET方式請(qǐng)求服務(wù)器資源的時(shí)候（TCPPUH），服務(wù)器也像剛才那樣用(TCPACK)給與響應(yīng)，但與之前不同的是，這次服務(wù)器開(kāi)始傳輸HTML資源的內(nèi)容（第103的報(bào)文開(kāi)始包含了HTML請(qǐng)求的應(yīng)答200OK,后續(xù)為HTML資源內(nèi)容）。如下圖：

設(shè)備類：4、

IPTV業(yè)務(wù)HTTP頁(yè)面失敗故障

HTTP協(xié)議請(qǐng)求服務(wù)器端服務(wù)成功（HTTP/1.0200OK）再觀察上面幀的長(zhǎng)度達(dá)到了1514，不帶VLAN的幀是1514，加上雙層VLAN，幀的長(zhǎng)度就達(dá)到了1522.再去看下主控盤(pán)交換芯片的最大幀長(zhǎng)度為1518，這樣的下行應(yīng)答報(bào)文主控盤(pán)不讓過(guò)也就不足為奇了。

設(shè)備類：4、

IPTV業(yè)務(wù)HTTP頁(yè)面失敗故障

【故障結(jié)論】在TCP/IP協(xié)議中，TCP協(xié)議提供可靠的連接服務(wù)，采用三次握手建立一個(gè)連接。

第一次握手：建立連接時(shí)，客戶端發(fā)送syn包(syn=j)到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)；SYN：同步序列編號(hào)(SynchronizeSequenceNumbers)

第二次握手：服務(wù)器收到syn包，必須確認(rèn)客戶的SYN（ack=j+1），同時(shí)自己也發(fā)送一個(gè)SYN包（syn=k），即SYN+ACK包，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)；

第三次握手：客戶端收到服務(wù)器的SYN＋ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1)，此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)，完成三次握手。

完成三次握手，客戶端與服務(wù)器開(kāi)始傳送數(shù)據(jù)，流程如下:

HTTP協(xié)議請(qǐng)求服務(wù)器端服務(wù)成功（HTTP/1.0200OK）上述故障是由于TCP協(xié)議在三次握手失敗，導(dǎo)致創(chuàng)建TCP連接失敗，故障出現(xiàn)。導(dǎo)致TCP握手和建鏈?zhǔn)∈怯捎贠LT上的MTU值限制了包的大小。通過(guò)修改增大GSWC主控盤(pán)的最大幀長(zhǎng)度解決了故障。

設(shè)備類：4、

IPTV業(yè)務(wù)HTTP頁(yè)面失敗故障

設(shè)備類：5、

pos機(jī)撥號(hào)頻繁失敗

五、pos機(jī)撥號(hào)頻繁失敗

【現(xiàn)象描述】AN5116-02下掛07B型ONU，出現(xiàn)窄帶pos機(jī)撥號(hào)無(wú)法連接，拋開(kāi)POS機(jī)使用而電腦進(jìn)行模擬撥號(hào)正常?！咎幚磉^(guò)程】通過(guò)電腦模擬pos機(jī)撥號(hào)情況。

設(shè)備類：5、

pos機(jī)撥號(hào)頻繁失敗

設(shè)備類：5、

pos機(jī)撥號(hào)頻繁失敗

上圖是電腦連接POS中心過(guò)程，將連接過(guò)程中電腦發(fā)出的RTP包還原成語(yǔ)音(send1.au),電腦接收的RTP包還原成語(yǔ)音(recv1.au),上圖是將這兩個(gè)語(yǔ)音信號(hào)放到語(yǔ)音處理軟件中看到的頻域信號(hào)連接之初交互過(guò)程，紅色直線表示時(shí)間上的對(duì)應(yīng)關(guān)系，下圖中紅色圓中的信號(hào)是POS中心發(fā)過(guò)來(lái)的信號(hào)。

設(shè)備類：5、

pos機(jī)撥號(hào)頻繁失敗

設(shè)備類：5、

pos機(jī)撥號(hào)頻繁失敗

上圖紅色圓圈中的是電腦與POS中心連接上過(guò)程，從電腦與POS中心交互信號(hào)的特征可以判斷雙方使用的是V90協(xié)議。2pos機(jī)撥號(hào)情況。下圖是POS機(jī)與POS中心連接過(guò)程，將連接過(guò)程中POS機(jī)發(fā)出的RTP包還原成語(yǔ)音(send2.au),POS機(jī)接收的RTP包還原成語(yǔ)音(recv2.au),上圖是將這兩個(gè)語(yǔ)音信號(hào)放到語(yǔ)音處理軟件中看到的頻域信號(hào)連接之初交互過(guò)程，紅色直線表示時(shí)間上的對(duì)應(yīng)關(guān)系，下圖中紅色圓中的信號(hào)是POS中心發(fā)過(guò)來(lái)的信號(hào)。通過(guò)對(duì)比圖1與圖3中recv1和recv2信號(hào)發(fā)現(xiàn)這兩個(gè)在交互之初是一樣的，隨后就不同了。同時(shí)通過(guò)對(duì)比圖1與圖3中send1和send2信號(hào)可以看到用藍(lán)色箭頭標(biāo)記的就是這兩個(gè)信號(hào)的不同之處，正是由于這兩個(gè)信號(hào)的不同導(dǎo)致了POS中心隨后發(fā)出來(lái)的信號(hào)有差異，在圖1中POS中心隨后用V90協(xié)議與電腦進(jìn)行協(xié)商并且最終電腦可以連接上，而在圖2中POS中心隨后一直發(fā)送頻率為2100HZ的ansbar信號(hào)，而POS機(jī)也一直發(fā)送頻率范圍為700hz—1400hz信號(hào)，最終協(xié)商超時(shí)，連接失敗。

設(shè)備類：5、

pos機(jī)撥號(hào)頻繁失敗

設(shè)備類：5、

pos機(jī)撥號(hào)頻繁失敗

【故障結(jié)論】

基于以上分析，更改服務(wù)器或者客戶端的modem協(xié)商協(xié)議使其匹配后，故障解決。

設(shè)備類：6、數(shù)圖錯(cuò)誤導(dǎo)致無(wú)法撥號(hào)問(wèn)題六、數(shù)圖錯(cuò)誤導(dǎo)致無(wú)法撥號(hào)問(wèn)題【現(xiàn)象描述】開(kāi)通時(shí)注冊(cè)能夠成功，被叫正常，但是主叫時(shí)無(wú)法撥號(hào)?！咎幚磉^(guò)程】

1、被叫正常，說(shuō)明端點(diǎn)用戶名、RTP資源設(shè)置正確。

2、通過(guò)抓包分析，發(fā)現(xiàn)在主叫時(shí)，收到軟交換下放數(shù)圖后，ONU回復(fù)語(yǔ)法錯(cuò)誤，如圖：

設(shè)備類：6、數(shù)圖錯(cuò)誤導(dǎo)致無(wú)法撥號(hào)問(wèn)題

3、根據(jù)此錯(cuò)誤提示，應(yīng)該是數(shù)圖中存在語(yǔ)法不支持，導(dǎo)致回錯(cuò)。與軟交換配置人員溝通后，確認(rèn)為軟交換數(shù)圖配置錯(cuò)誤導(dǎo)致，軟交換更改配置后正常?！竟收戏治觥?/p>

數(shù)圖截圖如下：

設(shè)備類：6、數(shù)圖錯(cuò)誤導(dǎo)致無(wú)法撥號(hào)問(wèn)題從上面數(shù)圖截圖可以看到，在數(shù)圖中間連續(xù)出現(xiàn)兩個(gè)“|”，標(biāo)準(zhǔn)中規(guī)定“|”表示前后內(nèi)容為可選項(xiàng)，在每個(gè)“|”后必須由具體數(shù)圖內(nèi)容，否則就是不符合標(biāo)準(zhǔn)的，故連續(xù)兩個(gè)“|”中間沒(méi)有任何內(nèi)容，是不符合標(biāo)準(zhǔn)的，這樣將導(dǎo)致信令回錯(cuò)，無(wú)法撥號(hào)。

設(shè)備類：7、

AN5006-20開(kāi)通IC卡業(yè)務(wù)處理說(shuō)明

設(shè)備類：7、

AN5006-20開(kāi)通IC卡業(yè)務(wù)處理說(shuō)明

設(shè)備類：8、

OLT下掛ONU頻繁出現(xiàn)MGC中斷告警故障處理八、

OLT下掛ONU頻繁出現(xiàn)MGC中斷告警故障處理【網(wǎng)絡(luò)拓樸】

設(shè)備類：8、

OLT下掛ONU頻繁出現(xiàn)MGC中斷告警故障處理【現(xiàn)象描述】某地區(qū)5116-02OLT的下掛10幾端5006-20，40幾端5006-07B，語(yǔ)音采用H.248協(xié)議，一直以來(lái)運(yùn)行穩(wěn)定。最近新增部分5006-07B和5006-10B，做完數(shù)據(jù)發(fā)現(xiàn)很多ONU出現(xiàn)MGC鏈接斷開(kāi)告警，過(guò)段時(shí)間可以自行恢復(fù)，過(guò)會(huì)又出現(xiàn)該告警，語(yǔ)音業(yè)務(wù)一直閃斷。

設(shè)備類：8、

OLT下掛ONU頻繁出現(xiàn)MGC中斷告警故障處理【處理過(guò)程】

該OLT下掛ONU以前運(yùn)行一直很穩(wěn)定，這次故障極有可能是新增的數(shù)據(jù)引起的，首先檢查各項(xiàng)數(shù)據(jù)，發(fā)現(xiàn)VLAN和MGC地址配置均正確，NGN上聯(lián)用戶數(shù)據(jù)配置也沒(méi)有錯(cuò)誤，不存在下配置導(dǎo)致其他數(shù)據(jù)丟失的情況。后來(lái)分析用戶之前ONU所有的寬帶數(shù)據(jù)和語(yǔ)音數(shù)據(jù)VLAN均走的是上聯(lián)盤(pán)的第一個(gè)光口29:4，部分語(yǔ)音VLAN為1160，主備用MGC地址為和，部分語(yǔ)音為1070到1136，主備用MGC地址為和1.

設(shè)備類：8、

OLT下掛ONU頻繁出現(xiàn)MGC中斷告警故障處理

而新增的07B和10B設(shè)備用戶為了分流將所有寬帶和語(yǔ)音所有數(shù)據(jù)均走的上聯(lián)盤(pán)第二個(gè)光口29:5，語(yǔ)音VLAN也為1160，主備用MGC地址為和4.【故障分析】通過(guò)觀察發(fā)現(xiàn)出現(xiàn)故障的ONU語(yǔ)音VLAN全為1160，在1070到1136范圍內(nèi)的ONU無(wú)此故障。后來(lái)發(fā)現(xiàn)上聯(lián)盤(pán)29:4和29:5光口均透?jìng)髁?160的語(yǔ)音VLAN，而上層對(duì)以前開(kāi)的設(shè)備和新擴(kuò)容的設(shè)備分配的MGC地址不一樣，造成所有走1160VLAN的語(yǔ)音業(yè)務(wù)在2個(gè)上聯(lián)口處不斷切換，造成MGC的閃斷。后來(lái)將新擴(kuò)容設(shè)備的語(yǔ)音業(yè)務(wù)改到走29:4光口業(yè)務(wù)恢復(fù)正常。

設(shè)備類：9、丟失關(guān)鍵包導(dǎo)致語(yǔ)音斷話故障案例九、丟失關(guān)鍵包導(dǎo)致語(yǔ)音斷話故障案例【現(xiàn)象描述】20ONU下掛語(yǔ)音用戶上報(bào)撥打電話幾分鐘后電話斷掉。主叫被叫都是一樣。查看設(shè)備注冊(cè)MGC狀態(tài)，端點(diǎn)用戶名注冊(cè)狀態(tài)都正常?！咎幚磉^(guò)程】

1、端點(diǎn)域名，端點(diǎn)用戶名注冊(cè)正常，查看心跳配置正常如下：Config\ngn#SHOWkeepaliveKeepAliveis:Enable.Interval:30(s)maxtimes:3KeepAlivemode:Time.2．通過(guò)PINGMGC發(fā)現(xiàn)有丟包，在上聯(lián)口抓包分析為：

設(shè)備類：9、丟失關(guān)鍵包導(dǎo)致語(yǔ)音斷話故障案例

設(shè)備端點(diǎn)域名為54MGCIP為

發(fā)現(xiàn)丟包多的時(shí)候達(dá)到連續(xù)丟7個(gè)，在網(wǎng)絡(luò)不穩(wěn)定的時(shí)候如果存在丟包而且丟掉關(guān)鍵的信令包會(huì)導(dǎo)致語(yǔ)音問(wèn)題，延著這一思路接下來(lái)通過(guò)抓語(yǔ)音信令包來(lái)分析3.通過(guò)抓語(yǔ)音信令包分析如下：

設(shè)備類：9、丟失關(guān)鍵包導(dǎo)致語(yǔ)音斷話故障案例通過(guò)上圖抓包分析為設(shè)備向軟交換發(fā)送心跳包如圖包序號(hào)為1，2，軟交換并沒(méi)有回應(yīng)。從圖2中我們知道丟包應(yīng)丟在城域網(wǎng)。在通過(guò)圖3我們確定了導(dǎo)致通話過(guò)程中斷話的根本原因。

設(shè)備類：9、丟失關(guān)鍵包導(dǎo)致語(yǔ)音斷話故障案例通過(guò)圖3我們發(fā)現(xiàn)設(shè)備向軟交換重新發(fā)起了網(wǎng)關(guān)注冊(cè)導(dǎo)致刪除了RTP流與關(guān)聯(lián)，導(dǎo)致用戶通話中斷，而設(shè)備向軟交換重新發(fā)起網(wǎng)關(guān)注冊(cè)的原因?yàn)樵O(shè)備向軟交換發(fā)心跳包軟交換沒(méi)有回應(yīng)導(dǎo)致設(shè)備誤以為軟交換路故障導(dǎo)致重新發(fā)起網(wǎng)關(guān)注冊(cè)?！竟收戏治觥坑捎诰W(wǎng)絡(luò)丟包丟失了關(guān)鍵的心跳回應(yīng)包導(dǎo)致了設(shè)備重新向軟交換發(fā)起網(wǎng)關(guān)注冊(cè)導(dǎo)致語(yǔ)音中斷，通過(guò)解決上層網(wǎng)絡(luò)問(wèn)題解決丟包問(wèn)題來(lái)最終解決語(yǔ)音斷話問(wèn)題。

設(shè)備類：10、IP沖突導(dǎo)致OLT脫管十、IP沖突導(dǎo)致OLT脫管【現(xiàn)象描述】某地市一局端OLT頻繁出現(xiàn)脫管現(xiàn)象，網(wǎng)管上每3-5分鐘出現(xiàn)該端OLT系統(tǒng)通信終端告警，在告警指示燈顯示灰色時(shí)，ping該OLT能夠正常ping通，下掛業(yè)務(wù)也正常?！咎幚磉^(guò)程】登陸OLT，查看該OLT的管理IP，進(jìn)入OLT查看地址解析，showarp如圖1：

設(shè)備類：10、IP沖突導(dǎo)致OLT脫管

設(shè)備類：10、IP沖突導(dǎo)致OLT脫管

等待狀態(tài)輪詢后，重新做地址解析，如圖2：從以上情況看出，兩次解析網(wǎng)關(guān)所對(duì)應(yīng)的MAC地址不同，但理論上應(yīng)該是相同的，可以斷定問(wèn)題是由IP沖突導(dǎo)致，在告警顯示系統(tǒng)通信中斷的情況下，中，發(fā)現(xiàn)設(shè)備并非OLT，為一端15型ONU，ONU管理地址與OLT管理地址沖突，更改15ONU的管理IP后一切正常。

設(shè)備類：10、IP沖突導(dǎo)致OLT脫管【故障分析】圖1中解析出的網(wǎng)關(guān)所對(duì)應(yīng)的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，那么此時(shí)做ping動(dòng)作，實(shí)際是在pingIP沖突后的15型ONU；圖2中的網(wǎng)關(guān)所對(duì)應(yīng)的MAC地址為：00:18:82:3c:61:d8，此時(shí)為正常狀態(tài)，同時(shí)網(wǎng)管網(wǎng)元指示燈也為綠色正常。綜上所述，故障原因?yàn)橐欢?5型ONU與OLT的管理IP沖突，導(dǎo)致OLT脫管情況。

設(shè)備類：11、AN5006-04ONU語(yǔ)音頻繁中斷故障分析十一、AN5006-04ONU語(yǔ)音頻繁中斷故障分析【現(xiàn)象描述】用戶自開(kāi)通后反映語(yǔ)音業(yè)務(wù)經(jīng)常出現(xiàn)中斷，一段時(shí)間后可恢復(fù)，反復(fù)如此?！咎幚磉^(guò)程】接到申告后，首先更換了該ONU，并重新寫(xiě)入SN號(hào)，數(shù)據(jù)都可以正常下發(fā)成功，業(yè)務(wù)測(cè)試均正常，但2小時(shí)候，用戶再次申告故障。通過(guò)在EC2盤(pán)上進(jìn)行抓包查看，如下圖

設(shè)備類：11、AN5006-04ONU語(yǔ)音頻繁中斷故障分析可以看出，軟交換在向ONU發(fā)出AUEP審計(jì)消息的時(shí)候，IAD回復(fù)了一個(gè)500的錯(cuò)誤代碼，出現(xiàn)UNKNOWNendpoint的錯(cuò)誤，進(jìn)一步發(fā)現(xiàn)，該審計(jì)消息是從第一個(gè)端口，也就是aaln/1開(kāi)始，由于該ONU采用的SN自動(dòng)認(rèn)證，業(yè)務(wù)通過(guò)自動(dòng)工單系統(tǒng)來(lái)進(jìn)行自動(dòng)下發(fā)，所下發(fā)的業(yè)務(wù)為自動(dòng)從資源系統(tǒng)進(jìn)行獲取，導(dǎo)致下發(fā)的語(yǔ)音業(yè)務(wù)中沒(méi)有配置第一個(gè)端口，直接從第二個(gè)端口（aaln/2）開(kāi)始使用，當(dāng)軟交換平臺(tái)發(fā)起審計(jì)消息時(shí)，IAD無(wú)法正常的回應(yīng)該消息，導(dǎo)致軟交換平臺(tái)認(rèn)為該MGC鏈路斷開(kāi)，從而引起語(yǔ)音業(yè)務(wù)中斷。從后面的ntfy消息可以看出，IAD主動(dòng)發(fā)起的心跳沒(méi)有得到回應(yīng)，此時(shí)軟交換平臺(tái)已斷開(kāi)鏈路。為進(jìn)一步確認(rèn)故障原因，在ONU側(cè)將第一個(gè)語(yǔ)音端口虛擬的配置一個(gè)端點(diǎn)用戶名（aaln/1）,再次抓包查看

設(shè)備類：11、AN5006-04ONU語(yǔ)音頻繁中斷故障分析可以看出，軟交換平臺(tái)發(fā)起的AUEP審計(jì)消息已經(jīng)得到正常的恢復(fù)（200代碼），經(jīng)過(guò)2天的業(yè)務(wù)觀察，用戶沒(méi)有再出現(xiàn)該問(wèn)題。

設(shè)備類：11、AN5006-04ONU語(yǔ)音頻繁中斷故障分析【故障分析】此問(wèn)題是由于ONU的端口配置無(wú)法與軟交換平臺(tái)審計(jì)對(duì)應(yīng)而導(dǎo)致，軟交換平臺(tái)無(wú)法取消發(fā)送審計(jì)消息，而自動(dòng)工單系統(tǒng)為自動(dòng)獲取數(shù)據(jù)，很難確保獲取到的數(shù)據(jù)一定會(huì)從第一個(gè)端口開(kāi)始，目前只能通過(guò)營(yíng)業(yè)廳前臺(tái)受理業(yè)務(wù)時(shí)采用端口順序使用這一方法來(lái)規(guī)避此問(wèn)題。

設(shè)備類：12、FTTN設(shè)備不上網(wǎng)管案例十二、FTTN設(shè)備不上網(wǎng)管案例【現(xiàn)象描述】某處運(yùn)營(yíng)商反映FTTN設(shè)備不能上網(wǎng)管，具體現(xiàn)象是ANM2000網(wǎng)管上顯示網(wǎng)元工作指示燈灰色、校時(shí)檢測(cè)物理配置不成功、不能Telnet到設(shè)備上?！咎幚磉^(guò)程】通過(guò)登錄OLT，進(jìn)入EC2的PON目錄，發(fā)現(xiàn)此臺(tái)15ONU授權(quán)正常、在線狀態(tài)正常、邏輯鏈路工作正常、業(yè)務(wù)正常。由上述現(xiàn)象證明該臺(tái)15ONU問(wèn)題出在管理VLAN或者管理IP或路由上。再回到網(wǎng)管上，對(duì)15ONU進(jìn)行PING操作，，結(jié)果發(fā)現(xiàn)返回TTLexpiredtransit，此語(yǔ)句意義為TTL在傳輸中過(guò)期，如下圖：

設(shè)備類：12、FTTN設(shè)備不上網(wǎng)管案例發(fā)現(xiàn)問(wèn)題后，就要用TRACERT命令查看所經(jīng)過(guò)的路由，通過(guò)，探查路由，發(fā)現(xiàn)報(bào)文不停的在和之間反復(fù)跳躍，如下圖：

通過(guò)監(jiān)測(cè)，得出結(jié)論為路由在和兩處有路由環(huán)路，所以造成TTLexpiredintransit，最終造成該15ONU的snmp報(bào)文不能順利到達(dá)我這臺(tái)網(wǎng)管。所以該問(wèn)題出在的IP承載網(wǎng)上，將以上截圖和情況反饋給數(shù)據(jù)部門后，數(shù)據(jù)部門經(jīng)過(guò)調(diào)整，最終找到錯(cuò)誤的路由，更正后該15ONU順利上網(wǎng)管，Telnet正常。

設(shè)備類：12、FTTN設(shè)備不上網(wǎng)管案例【故障分析】此15ONU不上網(wǎng)管為路由環(huán)路造成，以致于snmp報(bào)文不能在15ONU和網(wǎng)管之間相互傳遞。TTL為PING包的生命周期，TTLexpiredintransit代表包在傳輸過(guò)程中過(guò)期，導(dǎo)致這個(gè)問(wèn)題出現(xiàn)的原因有兩個(gè)：1）TTL值太小，TTL值小于你和對(duì)方主機(jī)之間經(jīng)過(guò)的路由器數(shù)目；2）路由器數(shù)量太多，經(jīng)過(guò)路由器的數(shù)量大于TTL值。出現(xiàn)該類問(wèn)題，使用TRACERT這個(gè)命令工具可以很容易找到問(wèn)題根源（Windows里都自帶了這個(gè)）。這里的測(cè)試結(jié)果如下：

設(shè)備類：12、FTTN設(shè)備不上網(wǎng)管案例C:\>tracert93Tracingrouteto[93]overamaximumof30hops:117ms9ms10ms49ms9ms9ms051ms<1ms<1ms967ms9ms14ms071ms1ms1ms983ms9ms9ms092ms<1ms2ms9通過(guò)監(jiān)測(cè)，可以清楚的發(fā)現(xiàn)，路由產(chǎn)生環(huán)路，在，，這兩個(gè)路由之間轉(zhuǎn)不出來(lái)，從而造成TTLexpiredintransit

設(shè)備類：13、IPTV業(yè)務(wù)在收看節(jié)目時(shí)約3分鐘畫(huà)面中斷故障十三、IPTV業(yè)務(wù)在收看節(jié)目時(shí)大約3分鐘畫(huà)面中斷故障案例【現(xiàn)象描述】EPON設(shè)備（AN5116-02、AN5006-07B）為IPTV提供二層傳輸通道，近期工程中反映在觀看直播節(jié)目約3分鐘左右，畫(huà)面定格并隨后提示信號(hào)中斷?！咎幚磉^(guò)程】1.接到上述故障后首先檢查了EPON系統(tǒng)為ITV提供的傳輸通道，確定正常（通過(guò)測(cè)試撥號(hào)測(cè)試手段發(fā)現(xiàn)并未出現(xiàn)掉線或者閃斷）。為盡快定位故障點(diǎn)先后在ONU與家庭網(wǎng)管及OLT上聯(lián)口進(jìn)行抓包分析，如下：正常協(xié)議流程：IGMPV2協(xié)議定義的組播查詢機(jī)制如下：

設(shè)備類：13、IPTV業(yè)務(wù)在收看節(jié)目時(shí)約3分鐘畫(huà)面中斷故障1.路由器周期性的向主機(jī)側(cè)發(fā)出查詢報(bào)文（QUERY)2.組的其他成員監(jiān)聽(tīng)到報(bào)告后抑制報(bào)告發(fā)送3.主機(jī)發(fā)送單個(gè)組的報(bào)告(REPORT)IP地址分析：為機(jī)頂盒獲取到的IP地址；為組播服務(wù)器地址；

為子網(wǎng)的所有系統(tǒng)；

設(shè)備類：13、IPTV業(yè)務(wù)在收看節(jié)目時(shí)約3分鐘畫(huà)面中斷故障現(xiàn)場(chǎng)抓包分析如:是機(jī)頂盒發(fā)的加入包,該包是封裝在PPP中的。是服務(wù)器地址,該服務(wù)器下發(fā)的組播通用組查詢是普通的以太網(wǎng)包,沒(méi)有封裝到PPP中。

設(shè)備類：13、IPTV業(yè)務(wù)在收看節(jié)目時(shí)約3分鐘畫(huà)面中斷故障3.主機(jī)通過(guò)發(fā)送IGMPMembershipreports，申請(qǐng)加入一個(gè)組。路由器周期性發(fā)出IGMPmembershipquery，檢查是否有組員存在，如果在3次查詢時(shí)間間隔里沒(méi)有收到回復(fù)，則路由器宣布這個(gè)子網(wǎng)沒(méi)有組員。從"ONU-家庭網(wǎng)關(guān)直播過(guò)濾.pcap"中可以看出,IGMPMembershipQuery查詢間隔為1分鐘,3次就是3分鐘,由于機(jī)頂盒沒(méi)有回組播通用組查詢,3次查詢過(guò)后路由器自動(dòng)將組刪除。

設(shè)備類：13、IPTV業(yè)務(wù)在收看節(jié)目時(shí)約3分鐘畫(huà)面中斷故障【故障分析】服務(wù)器地址的寬帶接入方式是固定IP,該服務(wù)器下發(fā)的組播通用組查詢沒(méi)有封裝到PPP中。由于用戶和服務(wù)器的寬帶接入方式不同，機(jī)頂盒IP為沒(méi)有回組播通用組查詢,所以業(yè)務(wù)中斷。

摘要

目錄一、設(shè)備類二、網(wǎng)管類三、其余摘要

一、故障處理流程二、設(shè)備類案例三、網(wǎng)管類案例四、其他案例

網(wǎng)管類：1、網(wǎng)管服務(wù)器informix，anm2000的密碼修改步驟一、網(wǎng)管服務(wù)器informix，anm2000的密碼修改步驟【現(xiàn)象描述】某FTTX工程網(wǎng)管服務(wù)器用戶名和密碼家喻戶曉，某局為了保證服務(wù)器的安全性，建議我司修改登錄服務(wù)器的用戶名或者密碼?！咎幚磉^(guò)程】1確認(rèn)網(wǎng)管為930版本及其后續(xù)版本均可以修改用戶名或者密碼，現(xiàn)把修改密碼方法整理出來(lái)，用戶名類似。2暫停所有網(wǎng)管數(shù)據(jù)庫(kù)相關(guān)服務(wù)。3在我們電腦---管理---本地用戶和組，點(diǎn)擊相關(guān)用戶修改其密碼。4啟動(dòng)數(shù)據(jù)庫(kù)服務(wù)。點(diǎn)擊實(shí)例----屬性---登錄，選擇用戶并且修改其密碼，如下圖：

網(wǎng)管類：1、網(wǎng)管服務(wù)器informix，anm2000的密碼修改步驟5進(jìn)入aems\md\ini目錄下，修改md.ini密碼，如下圖。

網(wǎng)管類：1、網(wǎng)管服務(wù)器informix，anm2000的密碼修改步驟6進(jìn)入aems\fhaems\ini目錄下，修改aems.ini密碼，如下圖。7重啟服務(wù)或者電腦。

網(wǎng)管類：2、網(wǎng)管與設(shè)備間存在NAT轉(zhuǎn)換時(shí)的升級(jí)方法二．網(wǎng)管與設(shè)備間存在NAT轉(zhuǎn)換時(shí)的升級(jí)方法【網(wǎng)絡(luò)拓?fù)洹俊粳F(xiàn)象描述】

當(dāng)網(wǎng)管與設(shè)備間存在NAT轉(zhuǎn)換時(shí)，按照標(biāo)準(zhǔn)方式升級(jí)很有可能無(wú)法成功，F(xiàn)TP的log日志與正常時(shí)不一樣，沒(méi)有顯示設(shè)備獲取的軟件具體名稱，如下圖：

網(wǎng)管類：2、網(wǎng)管與設(shè)備間存在NAT轉(zhuǎn)換時(shí)的升級(jí)方法同時(shí)，網(wǎng)管會(huì)顯示“從ftpserver下載文件出錯(cuò)”，如下圖：【故障分析】按照標(biāo)準(zhǔn)升級(jí)方式，在網(wǎng)管升級(jí)窗口中需要填寫(xiě)本網(wǎng)卡的IP地址（），但由于存在NAT轉(zhuǎn)換，設(shè)備向網(wǎng)管獲取軟件時(shí)，會(huì)向轉(zhuǎn)換后的IP獲取軟件（），但升級(jí)時(shí)填寫(xiě)的卻是未轉(zhuǎn)換的IP（），這樣就導(dǎo)致設(shè)備從轉(zhuǎn)換后的IP無(wú)法獲取到具體軟件，從而無(wú)法升級(jí)成功。

網(wǎng)管類：2、網(wǎng)管與設(shè)備間存在NAT轉(zhuǎn)換時(shí)的升級(jí)方法解決方法

1、打開(kāi)網(wǎng)管的升級(jí)窗口，首先填寫(xiě)網(wǎng)管網(wǎng)卡的IP（），同時(shí)把“手動(dòng)輸入文件名”前的復(fù)選框的勾取消，這時(shí)網(wǎng)管將自動(dòng)找到ftp所指向的文件夾，然后選擇需要升級(jí)的文件，如下圖：

網(wǎng)管類：2、網(wǎng)管與設(shè)備間存在NAT轉(zhuǎn)換時(shí)的升級(jí)方法此步驟讓ftp軟件指向本機(jī)對(duì)應(yīng)的軟件文件夾。

2、當(dāng)選擇完畢需要升級(jí)的軟件后，再更改FTP服務(wù)器的IP為NAT轉(zhuǎn)換后的IP（），然后點(diǎn)擊“升級(jí)軟件”，如下圖：

網(wǎng)管類：2、網(wǎng)管與設(shè)備間存在NAT轉(zhuǎn)換時(shí)的升級(jí)方法此時(shí)可以看到FTP軟件的log日志中顯示了設(shè)備獲取具體軟件的過(guò)程，這樣升級(jí)可以成功。

網(wǎng)管類：3、客戶端和網(wǎng)管告警時(shí)間不一致處理案例三、客戶端和網(wǎng)管告警時(shí)間不一致處理案例【現(xiàn)象描述】網(wǎng)管升級(jí)到0508版本，客戶端也升級(jí)了，但是客戶端上查看的告警時(shí)間和網(wǎng)管上的不同步.【處理過(guò)程】1、核對(duì)服務(wù)器和客戶端上的時(shí)間，同步。2、懷疑打補(bǔ)丁時(shí)候有錯(cuò)誤，在另外一臺(tái)客戶端重新打上補(bǔ)丁進(jìn)行升級(jí)，登錄進(jìn)去后發(fā)現(xiàn)告警時(shí)間還是不一致。3、找出服務(wù)器上和客戶端上的單條命令進(jìn)行對(duì)比，發(fā)現(xiàn)告警時(shí)間提前了15個(gè)小時(shí)但是分鐘和秒鐘時(shí)同步的。4、因?yàn)橛卸嗯_(tái)服務(wù)器，在客戶端抓包確認(rèn)與那個(gè)服務(wù)器相連，確認(rèn)正確。5、再次對(duì)比服務(wù)器和客戶端上的一批命令，發(fā)現(xiàn)客戶端上的告警與服務(wù)器上的告警每一條命令都是相差15個(gè)小時(shí)，例如網(wǎng)管告警上報(bào)時(shí)間2011年3月18號(hào)，客戶端上對(duì)應(yīng)的告警時(shí)間是2011年3月19號(hào)，然而服務(wù)器和客戶端上的時(shí)間都是2011年3月18號(hào)。6、每條告警相差15個(gè)小時(shí)，懷疑是服務(wù)器時(shí)區(qū)設(shè)置不對(duì)。

網(wǎng)管類：3、客戶端和網(wǎng)管告警時(shí)間不一致處理案例7、檢查核對(duì)，服務(wù)器是windows2008系統(tǒng)，是正版全英文系統(tǒng)，時(shí)區(qū)是美國(guó)時(shí)區(qū)。經(jīng)修改重啟服務(wù)器網(wǎng)管和客戶端網(wǎng)，告警時(shí)間同步?！竟收戏治觥糠?wù)器上的裝的是正版英文系統(tǒng)，系統(tǒng)默認(rèn)是美國(guó)時(shí)區(qū)，但是系統(tǒng)顯示時(shí)間人為的修改與北京時(shí)間同步，服務(wù)器上裝的是XP系統(tǒng)，系統(tǒng)默認(rèn)是北京時(shí)區(qū)，系統(tǒng)顯示時(shí)間也是北京時(shí)間?？蛻舳烁婢菑姆?wù)器上讀取的，讀取告警時(shí)間的時(shí)候，客戶端會(huì)自動(dòng)的把美國(guó)時(shí)區(qū)轉(zhuǎn)換成北京時(shí)區(qū)，因此客戶端和服務(wù)器上的上報(bào)時(shí)間不一致，提前了15個(gè)小時(shí)。

網(wǎng)管類：4、TL1下發(fā)命令無(wú)返回問(wèn)題處理案例四、TL1下發(fā)命令無(wú)返回問(wèn)題處理案例【現(xiàn)象描述】對(duì)5516-01下發(fā)TL1命令時(shí)，無(wú)論什么命令，都沒(méi)有收到設(shè)備返回信息，無(wú)法下發(fā)成功，但是通過(guò)手工同步后可以下發(fā)成功?！咎幚磉^(guò)程】

1、由于無(wú)法收到設(shè)備返回信息，懷疑TRAPIP配置錯(cuò)誤，檢查后確認(rèn)沒(méi)有問(wèn)題。2、懷疑個(gè)性問(wèn)題，新加幾端ONU進(jìn)行測(cè)試，發(fā)現(xiàn)現(xiàn)象一樣。3、檢查操作系統(tǒng)服務(wù)，發(fā)現(xiàn)安裝了一個(gè)系統(tǒng)trap服務(wù)，如下圖，禁用此服務(wù)后TL1下發(fā)命令恢復(fù)正常。

網(wǎng)管類：4、TL1下發(fā)命令無(wú)返回問(wèn)題處理案例【故障分析】由于TL1下發(fā)配置是否成功完全依賴TRAP信息接收正確與否，一旦沒(méi)有收到應(yīng)有的TRAP信息，將導(dǎo)致下配置超時(shí)、不全等問(wèn)題，而5516-01是具備TRAP重傳功能的，所以首先檢查TRAPIP配置是否正確，如果TRAPIP配置正確，則網(wǎng)管應(yīng)該肯定能夠收到設(shè)備TRAPIP。而操作系統(tǒng)如果安裝了自帶的TRAP服務(wù)，將會(huì)與網(wǎng)管、設(shè)備之間的TRAP沖突，導(dǎo)致網(wǎng)管服務(wù)無(wú)法接收到應(yīng)有的TRAP，從而下配置始終收不到設(shè)備返回信息，禁用后即可恢復(fù)正常。

網(wǎng)管類：5、某地EPON網(wǎng)管分布式服務(wù)器ONU自動(dòng)同步到網(wǎng)管功能引起的網(wǎng)管掛死問(wèn)題五、某地EPON網(wǎng)管分布式服務(wù)器ONU自動(dòng)同步到網(wǎng)管功能引起的網(wǎng)管掛死問(wèn)題【現(xiàn)象描述】網(wǎng)管客戶端無(wú)法登錄，提示“Anserver數(shù)據(jù)庫(kù)連接失敗”【處理過(guò)程】1、檢查客戶端所在電腦網(wǎng)絡(luò)連接。

2、檢查網(wǎng)管客戶端配置文件。檢查D:\AEMS_Client\fhanms\ini目錄下的aems.ini文件里的IP設(shè)置是否正確。3、檢查應(yīng)用服務(wù)器上的AEMS-DBserver服務(wù)是否正常啟動(dòng)，檢查ANserver進(jìn)程內(nèi)存使用情況(300M以內(nèi)為正常，但有時(shí)進(jìn)程掛死的時(shí)候內(nèi)存也不超過(guò)300M)，在任務(wù)管理器->進(jìn)程里查看。發(fā)現(xiàn)Anserver.exe進(jìn)程內(nèi)存使用大小為1.2G，需要重啟服務(wù)。

4、將userdump.exe放在任意本地磁盤(pán)根目錄下，進(jìn)入運(yùn)行->cmd，進(jìn)入userdump.exe所在的目錄下輸入userdump<進(jìn)程名稱>回車。例：在相應(yīng)的目錄下會(huì)生成一個(gè)ANserver.dmp的文件，這個(gè)操作是將ANserver的內(nèi)存數(shù)據(jù)捕獲下來(lái)，以便后續(xù)在網(wǎng)管功能恢復(fù)后查障。

網(wǎng)管類：5、某地EPON網(wǎng)管分布式服務(wù)器ONU自動(dòng)同步到網(wǎng)管功能引起的網(wǎng)管掛死問(wèn)題