民航中南地區(qū)寬帶數(shù)據(jù)網(wǎng)監(jiān)控程序設計與實現(xiàn)

黃河

（中國民用航空珠海進近管制中心，廣東珠海 519015）

1.VPN技術在民航通信網(wǎng)中的應用

在現(xiàn)代內部網(wǎng)絡的發(fā)展過程中，對網(wǎng)絡有著各種各樣的需求。而僅僅采用傳統(tǒng)的路由交換和廣域網(wǎng)連接技術構建內部網(wǎng)絡，將面對路由設計、地址規(guī)劃、安全保護、業(yè)務隔離、成本和靈活性等各個方面的挑戰(zhàn)。針對這一情況，使用VPN技術（虛擬專用網(wǎng)/虛擬私人網(wǎng)）是比較理想的選擇。傳統(tǒng)的VPN技術包括IPSec、GRE、L2TP等，隨著用戶需求和網(wǎng)絡發(fā)展，傳統(tǒng)的VPN技術的一些缺點已無法適配，比如靜態(tài)隧道擴展性問題，維護VPN的ISP（運營商）不能有效區(qū)分不同用戶等。

在VPN技術中，VPN的實現(xiàn)依賴于隧道技術，通過隧道，用戶私網(wǎng)在公網(wǎng)中架起了一個邏輯通路，在MPLS VPN技術中，MPLS協(xié)議就是實現(xiàn)隧道的方式。它依據(jù)路由器（或3層交換機）的路由表來生成標簽轉發(fā)表，在承載IP報文時加上MPLS標簽，路由器根據(jù)標簽進行快速轉發(fā)，MPLS VPN共有2層標簽嵌套，一層為公網(wǎng)標簽，另一層為私網(wǎng)標簽，它們分別標識了公網(wǎng)和私網(wǎng)傳輸隧道，并最終將不同的私網(wǎng)在同一公網(wǎng)中進行了區(qū)分，能夠互不干擾的傳輸多個不同的私網(wǎng)業(yè)務，示意圖如圖1所示。

圖1 私網(wǎng)數(shù)據(jù)在公網(wǎng)內傳輸示意圖

2.監(jiān)控功能設計

筆者計劃從5個方面實現(xiàn)對民航中南地區(qū)寬帶數(shù)據(jù)網(wǎng)的全面監(jiān)控。

（1）硬件狀態(tài)監(jiān)控：包括內存、CPU、業(yè)務板卡、電源、風扇等，如圖2所示。

圖2 硬件監(jiān)控參數(shù)（關鍵字標紅，下同）

（2）協(xié)議監(jiān)控：包括MPLS、BGP協(xié)議，組網(wǎng)路由協(xié)議OSPF等。

（3）干線監(jiān)控：包括4個方面：1）物理狀態(tài)；2）OSPF鄰居狀態(tài)；3）ping檢測狀態(tài)；4）路由表和標簽轉發(fā)表狀態(tài)。

（4）業(yè)務狀態(tài)：包括4個方面：1）物理狀態(tài)；2）端口協(xié)議狀態(tài)；3）ping同一私網(wǎng)內的某終端；4）私網(wǎng)相關協(xié)議狀態(tài)，如圖3所示。

圖3 ping對端私網(wǎng)示意圖

（5）實時獲取log信息，進行綜合判斷。

3.故障判斷機制

3.1 硬件故障判斷

硬件故障的判斷需輸入相應命令，再結合交換機log信息，在回顯中提取狀態(tài)信息關鍵字，下圖為顯示設備溫度示意，如圖4所示。

圖4 獲取設備內溫度狀態(tài)示意圖

當溫度超過閾值時告警。此外，其他硬件狀態(tài)信息的獲取與之類似（包括CPU占用率、CPU歷史占用率、內存占用率、板卡軟硬件狀態(tài)、風扇模塊狀態(tài)、電源模塊狀態(tài)等）。

3.2 中繼干線故障判斷

中繼干線故障的判斷主要從3個方面進行，首先是干線端口狀態(tài)，如圖5所示。

圖5 干線端口狀態(tài)檢查

干線端口狀態(tài)可以通過指令“display interface xxx（端口號）”查詢，從回復信息中可得：（1）端口物理狀態(tài)；（2）端口協(xié)議狀態(tài)；（3）出入峰值是否超限；（4）對比前后2次輪詢出入流量有無增長，如果長時間無增長說明該干線存在異常；（5）對比前后2次輪詢出入錯誤報文有無增長，如果一段時間內錯誤大量增長說明該條干線雖未中斷，但質量不佳，應引起重視。

干線故障判斷的第二個條件，可以結合OSPF鄰居狀態(tài)。在一切正常的情況下，每條干線對應一個直連的OSPF鄰居，如果某個OSPF鄰居狀態(tài)異常，也可以從側面判斷干線狀態(tài)異常，圖6是2條對外干線均正常時OSPF鄰居狀態(tài)，圖7是某1條干線異常時狀態(tài)。

圖6 干線端口正常時OSPF鄰居狀態(tài)

圖7 干線端口異常時OSPF鄰居狀態(tài)

干線故障判斷的第3個條件是查詢路由表和MPLS標簽轉發(fā)表。假設A局和B局之間有2條干線，在網(wǎng)絡配置時一般會指定某條為主用，另一條為備用，正常情況下網(wǎng)絡中大部分流量由主用干線承載，備用干線只傳輸少量心跳包（例如OSPF協(xié)議的Hello包）。我們希望，當主用干線因故中斷時，備用干線能夠及時啟用，所以程序在檢測到主用干線中斷時，會自動查詢路由表，檢測備用干線是否正常啟用。此外，當程序檢測到路由表發(fā)生變化時，必然是檢測到了網(wǎng)絡拓撲改變事件，觸發(fā)了路由協(xié)議重新計算，這也從側面反映出某條干線發(fā)生了異常，應引起注意。

在程序試用過程中發(fā)現(xiàn)，當中繼干線的中斷是由租用的運營商線路中間段異常引發(fā)時，主用干線會中斷40s，然后才切換至備用干線，而業(yè)務需經(jīng)過2min40s左右才能恢復。當中繼干線的中斷是由物理端口down引發(fā)時（比如端口網(wǎng)線被拔出或人為shutdown端口），中繼干線的切換是瞬時完成的，但業(yè)務仍需經(jīng)過2min左右才能恢復，如圖8和圖9所示。

圖8 中繼干線中斷前路由表

圖9 中繼干線中斷后路由表

通過監(jiān)控程序返回的結果分析，其原因就在于OSPF協(xié)議的判斷機制和MPLS標簽轉發(fā)表的生成原理。當OSPF協(xié)議檢測到物理端口down時，會迅速切換路由，生成新的路由表。當運營商中間線路異常引發(fā)中繼干線中斷時，物理端口仍是正常up狀態(tài)，OSPF協(xié)議無法通過檢測端口的方式發(fā)現(xiàn)異常。此時，OSPF協(xié)議會通過Hello包的方式進行檢測，由于無法通過原路由傳輸OSPF Hello包，當4個周期未檢測到Hello包時（Hello包默認發(fā)送周期為10s，4個周期約為40s），協(xié)議認為該路由失效，此時再重新計算路由，生成新的路由表，所以2種中斷情況的恢復時間相差40s左右。至于業(yè)務為什么需要經(jīng)過2min才能恢復，是由于MPLS標簽轉發(fā)表是根據(jù)路由表生成的，當路由表更新后，需經(jīng)過約2min才能重新生成新的標簽轉發(fā)表。

3.3 業(yè)務中斷故障判斷

MPLS VPN支持2種類型私網(wǎng)：L3VPN和L2VPN。類似于虛擬一個路由器（L3VPN）或交換機（L2VPN）。

對于業(yè)務監(jiān)控，應從3個方面進行判斷，分別是端口物理狀態(tài)、私網(wǎng)協(xié)議狀態(tài)和ping對端私網(wǎng)終端狀態(tài)。

（1）三層VPN?？梢允褂弥噶睢癲isplay mpls interface Vlan-interface vlanID”查詢，如圖10所示。

圖10 三層VPN狀態(tài)檢測

（2）二層VPN?？梢允褂妹睢癲isplay vsi vsi名稱”查詢，如圖11所示。

圖11 二層VPN狀態(tài)檢測

（3）BGP協(xié)議和MP-BGP協(xié)議狀態(tài)。使用命令“display bgp peer”和“display bgp vpnv4 all peer”來查詢，如果BGP協(xié)議或MP-BGP協(xié)議故障，將導致私網(wǎng)路由無法傳遞，私網(wǎng)業(yè)務會中斷。

3.4 根據(jù)Log信息判斷故障

Log信息對于故障分析排查以及輔助判斷有所幫助。從下圖可以看出，系統(tǒng)檢測到MPLS標簽轉發(fā)表和BGP協(xié)議的狀態(tài)發(fā)生了異常，如圖12所示。

圖12 故障發(fā)生時交換機Log

4.軟件實現(xiàn)

（1）程序主界面（1.0版），如圖13所示。

圖13 程序主界面（1.0版）示意圖

（2）初始化配置。各空管部門可以根據(jù)自身的運行實際，對監(jiān)控項目進行靈活的配置，如圖14所示。

圖14 配置邏輯示意圖

（3）數(shù)據(jù)庫模塊和告警模塊。主要包括配置文件、告警日志和操作日志。所有異常告警都會存入數(shù)據(jù)庫，并在故障當時發(fā)出聲音提示。

5.結語

依據(jù)MPLS VPN的特點，筆者研發(fā)成功了寬帶數(shù)據(jù)網(wǎng)監(jiān)控程序，該程序可廣泛服務于中南地區(qū)各運行現(xiàn)場，對提升安全保障水平有所裨益。