許志成 高婷婷 王兆敏 潘志鵬

摘 要：隨著組網(wǎng)方式的多樣化和規(guī)模的不斷擴(kuò)大，網(wǎng)元數(shù)量的不斷增加，網(wǎng)管的監(jiān)控管理和維護(hù)工作更加重要，告警信息的增加和故障的處理是最直觀的體現(xiàn)。常見告警和對應(yīng)的處理方法對于開展通信設(shè)備的運(yùn)維工作起到了至關(guān)重要的作用。

關(guān)鍵詞：PTN；告警

在日常的維護(hù)工作中，設(shè)備網(wǎng)元的各種告警是我們經(jīng)常遇到的。隨著組網(wǎng)方式的多樣化和規(guī)模的不斷擴(kuò)大，網(wǎng)元數(shù)量的不斷增加，網(wǎng)管的監(jiān)控管理和維護(hù)工作更加重要，告警信息的增加和故障的處理是最直觀的體現(xiàn)。

日常維護(hù)中的網(wǎng)元告警實(shí)際上大部分是比較常見的，那么接下來簡單地分析一下這些常見告警和對應(yīng)的處理方法。

我們常見的告警可以簡單分為：環(huán)境告警、設(shè)備告警、業(yè)務(wù)告警等。

1 環(huán)境告警我們比較常見的主要有

單路輸入電源電壓丟失：需要到站點(diǎn)現(xiàn)場依次檢查是否是多路供電，電源分配箱是否有供電問題，電源線是否壓接牢固，倒換設(shè)備電源板檢查是否是電源模塊問題，依次處理直到告警消除。

電源輸入電壓越限（過壓或欠壓）：需要到站點(diǎn)現(xiàn)場逐段檢查供電電源設(shè)備——電源分配箱——設(shè)備電源模塊的供電電壓，針對檢查出的問題進(jìn)行處理直到告警消除。

外部環(huán)境告警：需要到站點(diǎn)現(xiàn)場檢查對應(yīng)的外部環(huán)境指標(biāo)是否正常，外部傳感器工作是否正常，系統(tǒng)告警門限值配置是否正確，依次檢查找到問題后處理直到告警消除。

2 設(shè)備告警可以簡單分為單板告警、接口告警

單板告警常見的主要有：單板CPU利用率越限：出現(xiàn)該告警可能是因?yàn)闃I(yè)務(wù)或協(xié)議開啟過多，超過設(shè)備實(shí)際可提供的帶寬；某些模塊運(yùn)行異常，導(dǎo)致該模塊長時(shí)間占用CPU；網(wǎng)絡(luò)不穩(wěn)定，導(dǎo)致長時(shí)間處理協(xié)議報(bào)文或頻繁倒換。利用降溫手段降低單板CPU的溫度，參照設(shè)備規(guī)格檢查業(yè)務(wù)數(shù)量是否超過設(shè)備處理能力并配置合理的業(yè)務(wù)數(shù)量，檢查網(wǎng)絡(luò)狀況，逐項(xiàng)排查處理直到告警消失。

單板脫位：出現(xiàn)該告警可能是因?yàn)檫\(yùn)行中的單板被人為拔除；運(yùn)行中的單板與主控板的板間通訊出現(xiàn)異常，導(dǎo)致主控板無法檢測到單板；運(yùn)行中的單板電源模塊故障導(dǎo)致單板掉電。

到現(xiàn)場檢查單板是否被拔出或掉電，用手電筒查看背板插槽插座部分是否有物理損傷，檢查主控板與背板連接的插針是否有損傷，然后進(jìn)行復(fù)位、倒換、更換單板或背板、機(jī)框等操作直到告警消除。

單板類型失配告警：該告警可能是因?yàn)樵谠O(shè)備物理槽位插入錯(cuò)誤的單板類型，應(yīng)安板與實(shí)安板類型不一致；新增的單板啟動(dòng)后上報(bào)的類型與網(wǎng)管上邏輯安裝的類型不一致；運(yùn)行中的單板自身硬件原因。

現(xiàn)場檢查單板類型與應(yīng)安板類型是否一致，在物理槽位上插入與應(yīng)安板類型一致的單板并檢查告警，檢查板卡啟動(dòng)后上報(bào)的板卡類型與邏輯安裝板卡是否一致，在網(wǎng)管上安裝與物理槽位類型一致的板卡并檢查告警，更換物理槽位安裝單板，待單板啟動(dòng)后檢查告警，依次按照以上順序進(jìn)行排查處理直到告警消失。

常見的接口告警主要有：

以太網(wǎng)物理接口ETPI Ethernet端口未連接：端口處于down狀態(tài)，或者從up變到down?？赡軐?dǎo)致業(yè)務(wù)中斷。該告警可能是因?yàn)槲床骞饽K或up狀態(tài)時(shí)拔出光模塊；未連接光纖或up狀態(tài)時(shí)拔出光纖；收光功率過低；端口shutdown；端口震蕩抑制；對接端口碼型不一致；時(shí)鐘子卡異常，無法恢復(fù)10GE頻率。

3 業(yè)務(wù)告警可以簡單分為

協(xié)議告警、隧道/偽線告警：

3.1 協(xié)議告警常見的主要

有OSPF告警、BGP告警等。

OSPF HELLO包超時(shí)：本端接口超時(shí)未收到鄰居發(fā)送的hello報(bào)文，導(dǎo)致鄰居斷鏈。OSPF鄰居DOWN，學(xué)習(xí)不到路由，造成業(yè)務(wù)中斷。該告警可能是因?yàn)閳?bào)文收發(fā)問題，對端設(shè)備CPU越限導(dǎo)致OSPF報(bào)文無法發(fā)送，本端設(shè)備CPU越限導(dǎo)致OSPF報(bào)文上送CPU通道堵塞，報(bào)文被丟棄。

管理設(shè)備，檢查接口是否有收發(fā)報(bào)文，重啟OSPF進(jìn)程并檢查鄰居是否能夠重建。

BGP鄰居HOLDTIME定時(shí)器超時(shí)：BGP鄰居在HOLDTIME時(shí)間內(nèi)沒有從鄰居接收到任務(wù)的協(xié)議報(bào)文。HOLDTIME超時(shí)后，引起鄰居down，BGP嘗試重新建立鄰居關(guān)系，導(dǎo)致從該鄰居學(xué)習(xí)到的全路路由被刪除。該告警可能因?yàn)锽GP的對端鄰居沒有發(fā)送協(xié)議報(bào)文，網(wǎng)絡(luò)通信異常，導(dǎo)致BGP會話使用的TCP鏈接出現(xiàn)異常斷鏈。

管理設(shè)備，檢查BGP鄰居是否發(fā)送協(xié)議報(bào)文給對端，檢查對端設(shè)備是否接收到BGP協(xié)議報(bào)文，檢查兩端設(shè)備之間的通信狀況，逐項(xiàng)排查處理直到告警消失。

3.2 隧道/偽線告警

隧道維護(hù)點(diǎn) 連通性丟失：這是比較常見的影響通道業(yè)務(wù)的告警之一，在3.5倍幀周期內(nèi)，本端沒有收到對端隧道MEG的MEP發(fā)送過來的CV幀，本端上報(bào)隧道維護(hù)點(diǎn)LOC告警。影響業(yè)務(wù)，存在誤碼。該告警可能是因?yàn)榕渲糜姓`，NNI側(cè)性能異常，OAM參數(shù)配置有誤，P節(jié)點(diǎn)單板轉(zhuǎn)發(fā)故障，單板硬件故障。

分析該隧道業(yè)務(wù)處于哪種階段（開通階段或維護(hù)階段），由網(wǎng)管檢查網(wǎng)元和該業(yè)務(wù)的各項(xiàng)配置是否正確，檢查NNI側(cè)路徑性能是否異常，檢查PE節(jié)點(diǎn)OAM參數(shù)配置是否正確，檢查P節(jié)點(diǎn)單板是否出現(xiàn)故障，逐項(xiàng)排查處理直到告警消失。

偽線維護(hù)點(diǎn) 連通性丟失：在3.5倍幀周期內(nèi)，本端沒有收到對端隧道MEG的MEP發(fā)送過來的CV幀，本端上報(bào)隧道維護(hù)點(diǎn)LOC告警。影響業(yè)務(wù)，存在誤碼。該告警可能是因?yàn)榕渲糜姓`，NNI側(cè)性能異常，OAM參數(shù)配置有誤，P節(jié)點(diǎn)單板轉(zhuǎn)發(fā)故障，單板硬件故障。

檢查網(wǎng)管上業(yè)務(wù)配置是否有誤，檢查是否出現(xiàn)隧道維護(hù)點(diǎn)OAM告警，檢查隧道保護(hù)組狀態(tài)是否異常，檢查PE/UPE/SPE節(jié)點(diǎn)配置、轉(zhuǎn)發(fā)情況是否異常，逐項(xiàng)排查處理直到告警消失。

以上是我們?nèi)粘＞S護(hù)工作中比較常見的告警及其相關(guān)的告警原因和處理辦法。而在工作中還有很多我們很少或者沒有遇到過的問題，因此，不斷地學(xué)習(xí)并充實(shí)自己是非常重要的。通信技術(shù)在不斷進(jìn)步，只有隨之更新自己的技術(shù)知識，才能夠更好地做好通信維護(hù)工作，為通信網(wǎng)絡(luò)的暢通做好保障。

參考文獻(xiàn)

[1]魯衛(wèi).PTN網(wǎng)管系統(tǒng)中告警模塊的設(shè)計(jì)與實(shí)現(xiàn)[D].華中科技大學(xué)，2013.

[2]PTN：IP分組化傳送[M].北京郵電大學(xué)出版社，2009.