承載網(wǎng)對接故障處理指南和典型案例分析.ppt

1、2020/8/8,核心網(wǎng)與數(shù)通對接故障處理和典型案例分析,Page 2,WCDMA網(wǎng)絡(luò)總體組網(wǎng)圖,說明：目前在聯(lián)通WCDMA現(xiàn)網(wǎng)網(wǎng)絡(luò)中，IU-PS口、Gn口、Gi口、Mc口等接口采用IP承載，實(shí)際組網(wǎng)需要和相關(guān)數(shù)通設(shè)備進(jìn)行對接。,A,Iu-CS,Iu-PS,Mc,Mc,Gn,Gi,Nb,Nc,Gb,Abis,Iub,Gr,C/D,C/D,HLR,MSC Server,MGW,SGSN,GGSN,RNC,PSTN,Internet,GMSC Server,2G,接入,CS,其它網(wǎng)絡(luò),BSC,MGW,3G,接入,PS,承載通道,信令通道,BTS,Page 3,UMG8900,承載骨干網(wǎng),CE,計(jì)費(fèi)

2、系統(tǒng),LANSwitch,MSoftX3000,FE,iGWB,CE,PE,LANSWITCH,DCN,M2000,核心網(wǎng)CS局端組網(wǎng)詳細(xì)拓?fù)鋱D,PE,LANSwitch,FE,FE,FE,GE,GE,GE,GE,VRRP,說明：1、如果PE路由器下面為CE路由器，而非交換機(jī)，則VRRP一般設(shè)置在CE路由器上，CE與PE之間運(yùn)行OSPF。 2、目前現(xiàn)網(wǎng)Nb口還沒有IP化，上圖主要是描述信令承載的組網(wǎng)結(jié)構(gòu)。后續(xù)IP化，建議UMG出GE口直連CE設(shè)備，承載媒體流業(yè)務(wù)。,OSPF,Page 4,核心網(wǎng)對接相關(guān)協(xié)議應(yīng)用說明,1、ARP：ARP（Address Resolution Protocol,地

3、址解析協(xié)議），工作原理是本端IP接口板對其配置的默認(rèn)網(wǎng)關(guān)發(fā)送ARP包，網(wǎng)關(guān)回送ARP響應(yīng)。如果長時(shí)間無法獲得響應(yīng)，就判斷這條路徑可能存在問題，自動(dòng)倒換相關(guān)接口板。ARP探測主要目的是為了避免某傳輸路徑有問題而物理層檢測不到的情況，導(dǎo)致不能正常切換。主要用于MSC server和LSW交換機(jī)組網(wǎng)情況下，對信令承載通道的安全保護(hù)。 2、VRRP：VRRP（Virtual Router Redundancy Protocol，虛擬路由冗余協(xié)議）是用于解決組網(wǎng)可靠性的問題。它保證當(dāng)主機(jī)的下一跳路由器故障時(shí)，可以及時(shí)由另一臺(tái)路由器來代替，從而保持通訊的連續(xù)性和可靠性。主要用于MSC server/MGW

4、和LSW交換機(jī)/CE設(shè)備組網(wǎng)情況下，對信令承載通道的安全保護(hù)。 3、BFD：BFD（Bidirectional Forwarding Detection，雙向轉(zhuǎn)發(fā)檢測）用于快速檢測、監(jiān)控網(wǎng)絡(luò)中鏈路或者IP路由的轉(zhuǎn)發(fā)連通狀況。主要用于MGW、SGSN、GGSN和承載網(wǎng)路由器連接組網(wǎng)情況下，快速進(jìn)行媒體流/用戶面業(yè)務(wù)的倒換保護(hù)。 4、OSPF: OSPF(OPEN SHORTEST PATH FIRST，開放最短路徑優(yōu)先）協(xié)議，主要運(yùn)行于LSW三層交換機(jī)和AR路由器之間，在設(shè)備或鏈路故障情況下進(jìn)行IP路由自動(dòng)收斂。,Page 5,IP承載網(wǎng)對接問題總體定位思路及方法,1、及時(shí)監(jiān)控檢測故障 通過M2

5、000網(wǎng)管查看相關(guān)事件、故障告警（鏈路故障、TG脫網(wǎng)、丟包率高等）； 通過相關(guān)的承載網(wǎng)性能測試軟件（如安捷倫的Application Analyzer 簡稱AA）對承載網(wǎng)系列QOS指標(biāo)（如時(shí)延、抖動(dòng)、丟包等）進(jìn)行綜合測試和監(jiān)控。 2、判斷故障是否與承載網(wǎng)相關(guān) Msoftx3000維護(hù)臺(tái)的PING 跟蹤、Trace route功能; Msoftx3000以太網(wǎng)端口狀態(tài)信息查詢（如DSP FESTATUS、DSP IPSTAT等）; UMG8900維護(hù)臺(tái)的PING 跟蹤、Trace route功能； UMG8900以太網(wǎng)端口狀態(tài)信息查詢（如DSP IPIF、DSP IPFWD、DSP ROUTE、

6、DSP BFD等）; 3、進(jìn)一步分析判斷故障原因 業(yè)務(wù)完全中斷（信令層面承載故障）， 檢查單板及相連的LSW或CE設(shè)備狀態(tài)、FE/GE端口狀態(tài)、端口工作模式配置、丟錯(cuò)包統(tǒng)計(jì)等； 業(yè)務(wù)質(zhì)量差（媒體流層面承載故障），檢查相關(guān)單板及相連的AR路由器、分析業(yè)務(wù)流量模型、設(shè)備轉(zhuǎn)發(fā)性能、UMG上語音質(zhì)量告警等； 業(yè)務(wù)單通或雙不通，UMG ping功能、查看語音編解碼/EC配置，端口環(huán)回、錄音等。,Page 6,對接案例一,案例1：MGW與MGC連接中斷問題定位分析 【現(xiàn)象描述】MGW與MGC連接中斷 ，網(wǎng)關(guān)無法正常注冊到MGC。 【告警信息】H248鏈路/M3UA鏈路中斷；MGW退出服務(wù) 【原因分析】 H

7、248&UA鏈路故障的可能原因以下幾種情況： MSC Server故障、鏈路參數(shù)配置錯(cuò)誤； 防火墻配置問題、IP承載網(wǎng)網(wǎng)絡(luò)故障； 端口丟包/錯(cuò)包、端口down、端口協(xié)商模式問題 UMG網(wǎng)關(guān)解析失敗、集中轉(zhuǎn)發(fā)故障； IP承載網(wǎng)網(wǎng)絡(luò)故障；,Page 7,對接案例一（續(xù)）,【處理過程】： 對Server故障。檢查對接server的運(yùn)行狀態(tài) 。 防火墻配置：重點(diǎn)檢查ACL的配置及過濾規(guī)則，根據(jù)LST FIREWALL和LST ACL的結(jié)果，確認(rèn)是否是防火墻將UMG和Server過濾導(dǎo)致不通。 端口down：對于主備配置端口down將導(dǎo)致單板倒換，對于單配或者備用異常的情況下，端口down將直接導(dǎo)致鏈路

8、中斷。端口丟包或錯(cuò)包可能造成鏈路檢測超時(shí)，從而導(dǎo)致中斷。 網(wǎng)關(guān)解析失?。涸诟婢_(tái)檢查確認(rèn)告警日志是否存在3266號(hào)（The gateway resolving failed ）告警，網(wǎng)關(guān)解析失敗可能造成鏈路檢測超時(shí)，從而導(dǎo)致中斷。 網(wǎng)絡(luò)故障解決網(wǎng)路故障可以按照分段分析的原則：步驟 1：鏈路本端IP地址PING下一跳地址，看是否能夠PING通。PING不通說明UMG和下一跳之間出現(xiàn)問題，需要分析UMG內(nèi)部問題。步驟 2：使用本端IP地址PING對段IP地址（MGC上的地址），如果PING不通，說明和承載網(wǎng)相關(guān)，需要聯(lián)合承載網(wǎng)專家一起處理。,Page 8,對接案例二,案例2：由于數(shù)通設(shè)備丟包問題導(dǎo)

9、致UMG上出現(xiàn)信令鏈路故障 【現(xiàn)象描述】：某局UMG和MSOFTX3000按照分離式組網(wǎng)，通過IP承載網(wǎng)連接，兩端都是通過3528交換機(jī)連接NE40路由器并接入IP承載網(wǎng)。UMG于凌晨割接入網(wǎng)后，觀察運(yùn)行情況一切正常，但到早晨7點(diǎn)左右話務(wù)量逐漸升高時(shí)，出現(xiàn)大量PPU信令鏈路故障告警。 【告警信息】：信令鏈路故障告警重要告警 【原因分析】：1、IP承載網(wǎng)的抖動(dòng)造成偶然的鏈路故障，出現(xiàn)告警到自動(dòng)恢復(fù)間隔時(shí)間為6秒；2、UMG上連到交換機(jī)3528的端口模式和對方設(shè)置不一致；3、IP承載網(wǎng)的某一段存在問題。,Page 9,對接案例二（續(xù)）,【處理過程】：1、因?yàn)橹霸谄渌贮c(diǎn)出現(xiàn)過類似的問題，將最大允

10、許心跳丟失數(shù)調(diào)整為5次，延長H.248鏈路的心跳允許的響應(yīng)時(shí)間，但操作后告警未恢復(fù)；2、通過信令跟蹤及查看UMG系統(tǒng)日志，發(fā)現(xiàn)是H.248心跳連接長時(shí)間沒有得到響應(yīng)而被置為DOWN狀態(tài)所致，因此懷疑和IP承載網(wǎng)通道相關(guān)。 3、比對UMG和3528之間的端口速率及雙工方式等設(shè)置，發(fā)現(xiàn)兩端一致，沒有問題；4、通過MSOFTX3000對本端NE40進(jìn)行PING操作，無丟包現(xiàn)象：PING對端UMG的NE40，無丟包；PING對端UMG有丟包，確定問題出現(xiàn)在UMG和NE40之間； 5、從NE40側(cè)PING對端的3528有丟包，確定問題出現(xiàn)在對端NE40和3528之間；5、協(xié)同數(shù)通工程師查看3528和NE

11、40的設(shè)置，發(fā)現(xiàn)3528上連到NE40的端口的雙工方式設(shè)成了自協(xié)商，而NE40上對應(yīng)的端口設(shè)成了強(qiáng)制全雙工；6、修改3528上的端口為強(qiáng)制全雙工，問題解決！ 【建議與總結(jié)】： 1、在處理類似故障時(shí)，要首先詳細(xì)了解具體的局端設(shè)備組網(wǎng)及物理連線情況，然后逐段排查。 2、端口協(xié)商模式不一致是核心網(wǎng)和承載網(wǎng)數(shù)通設(shè)備對接中的比較常見一個(gè)問題，在日常的工程維護(hù)期間需要重點(diǎn)檢查和關(guān)注。,Page 10,對接案例三,案例4：因VRRP地址沖突導(dǎo)致BICC鏈路中斷問題 【現(xiàn)象描述】：某大區(qū)SS1 BICC鏈路中斷，導(dǎo)致落地話務(wù)中斷 【告警信息】：BICC鏈路故障告警 【原因分析】：1、SS自身信令模塊問題，導(dǎo)致

12、BICC鏈路中斷； 2、SS本端IFM接口問題，導(dǎo)致IP承載及BICC鏈路中斷； 3、IP承載網(wǎng)的某一段存在問題。 【處理過程】： 1、檢查SS1相關(guān)單板模塊的狀態(tài)，結(jié)果正常； 2、檢查SS1的IFM單板及后插板FE口，狀態(tài)正常； 3、登錄到和SS1相連的3526E檢查，發(fā)現(xiàn)有IP沖突的異常打印信息（ IP ADDRESS 10.0.38.1 COLLISION WITH VRRP VIRTUAL IPADDRESS ON VLAN20,SOURCED BY 00D0-5938-50EA）,Page 11,對接案例三（續(xù)）,4、進(jìn)一步分析沖突的IP地址，根據(jù)SS1的配置，10.0.38.1是與

13、SS1相連的兩臺(tái)3536E的虛擬VRRP地址，為MSX3000和UMG8900的缺省路由地址。3526E出現(xiàn)的打印異常信息表示收到異常的VRRP包，VRRP包是別的路由器發(fā)來的，用于廣播自己的狀態(tài)，實(shí)現(xiàn)主、備路由器的功能。從打印信息看這個(gè)路由器的物理地址是00D0-5938-50EA。 5、由此，確認(rèn)是一臺(tái)未知設(shè)備的IP地址與3526E交換機(jī)上的VRRP IP相同，引起IP地址沖突導(dǎo)致BICC鏈路中斷。檢查相關(guān)的物理連線，發(fā)現(xiàn)機(jī)房內(nèi)存在一個(gè)未知的網(wǎng)線錯(cuò)誤的接到了3526E設(shè)備上，將該網(wǎng)線斷開后，地址沖突現(xiàn)象消失，BICC鏈路恢復(fù)正常，故障解決。 【建議與總結(jié)】： 1、將3526E上不用的物理端

14、口全部禁止，這樣別的路由器即使接入也無法干擾我們設(shè)備的運(yùn)行，在真正需要使用這些端口時(shí)才將其打開； 2、與設(shè)備維護(hù)人員強(qiáng)調(diào)說明，軟交換網(wǎng)配套的CE/交換機(jī)等為核心網(wǎng)業(yè)務(wù)專用，嚴(yán)禁其他設(shè)備接入，同時(shí)采用在這些設(shè)備上貼上醒目的標(biāo)簽等方法警示，以防止誤接入。,Page 12,對接案例四,案例5：某局UMG8900上行承載網(wǎng)兩根發(fā)光纖故障導(dǎo)致網(wǎng)關(guān)失去注冊 【現(xiàn)象描述】某運(yùn)營商N(yùn)GN長途匯接局UMG8900網(wǎng)關(guān)，采用GE口上行至兩個(gè)NE80路由器平面（承載網(wǎng)）注冊到SOFTX3000，UMG8900通過兩組光纖兩條信令路由上行至NE80路由器。故障現(xiàn)象為兩組光纖中的兩根發(fā)光纖同時(shí)損壞，導(dǎo)致至承載網(wǎng)兩個(gè)平面

15、均不通，網(wǎng)關(guān)注冊失去注冊，整個(gè)TG網(wǎng)關(guān)下的業(yè)務(wù)全部中斷。 【告警信息】UMG退出服務(wù)緊急告警、H248鏈路故障告警、UMG與軟交換SS失去連接。 【原因分析】：1、目前，網(wǎng)關(guān)設(shè)備對GE口物理狀態(tài)故障的檢測機(jī)制是只檢測收光告警，不檢測發(fā)光告警。因此，如果一條光路上如果發(fā)光光纖故障，網(wǎng)關(guān)本端是感知不到的，需要對端數(shù)通設(shè)備配合檢查確認(rèn)； 2、G10單板至數(shù)通設(shè)備NE80路由器之間的兩根發(fā)光纖故障，導(dǎo)致UMG中繼網(wǎng)關(guān)失去注冊脫網(wǎng)離線。,Page 13,對接案例四（續(xù)）,【處理過程】： 1、檢查UMG網(wǎng)關(guān)至NE80路由器之間是否連通：登錄故障的UMG8900設(shè)備維護(hù)臺(tái)，利用Ping命令，檢查UMG8900的下一跳網(wǎng)關(guān)是否能夠連通，檢查結(jié)果是不能夠連通。 2、排查UMG網(wǎng)關(guān)至NE80路由器之間的光纖接點(diǎn)：找到TG網(wǎng)關(guān)至NE80之間的ODF架，以O(shè)DF架為界，用光纖測試儀分別對NE80側(cè)做環(huán)回測試和對TG網(wǎng)關(guān)側(cè)做環(huán)回測試。測試結(jié)果發(fā)現(xiàn)TG網(wǎng)關(guān)側(cè)沒有發(fā)光。 3、用同樣的方法，對另外一塊G10單板的光口上進(jìn)