ICMP回顯的監控應用
我們以前曾經講解過ICMP協議的有關內容。了解了ICMP的基礎知識,那么對已ICMP協議的應用,我們今天來講解一下ICMP回顯的內容。這里面我們,我們主要是根據對監控系統的分析來學習這部分知識。
一、概述
在電信級設備功能日益完善,組網日趨復雜的今天,對設備的管理監控已經成為保障設備穩定、正常運轉的必要手段.其中,對底層通信網絡的監控是整個監控管理系統的核心和基礎.
以前眾多企業級的通信核心網設備因為沒有完善的監控管理,缺乏告警及系統運行狀態的相關日志信息,致使維護人員無法準確掌握設備運行狀態,設備運轉達不到用戶所必須的穩定性及安全性要求.尤其當網絡物理硬件出現故障造成網絡中斷時,如果不能及時發現并定位,不僅會造成用戶長時間通信中斷,而且會讓我們廠商的研發和工程人員無謂浪費時間去逐步查找軟件問題.針對這種現象,我們提出一種網絡狀態監測的解決方案.
這種監測方法主要是基于ICMP協議開發的,基本原理類似Windows自帶的Ping功能.Ping的目的是為了測試網絡中的另一臺主機是否可達.該程序給主機發送一份ICMP回顯請求報文,并等待返回ICMP回顯應答.通常Ping是對兩個TCP/IP系統連通性進行測試的基本工具.它只利用ICMP回顯請求和回顯應答報文,無須經過傳輸層(TCP/UDP),從而將問題定位到IP層以下,避免了傳輸層和應用層的問題干擾.Ping服務一般在內核中實現ICMP的功能.
由于Ping具有上述特點,其統計結果信息可以被利用顯示底層傳輸網絡的狀態.關鍵的統計數據有:
報文抵達序列,由ICMP序列號(ICMP-seq)顯示;
每個報文往返所用時間,單位為ms(毫秒);
報文丟失百分比,它在ping命令輸出的總結行顯示.
其中,序列號用于標識每一個響應包的先后順序,用于檢驗網絡傳輸是否會重復或失序;往返時間RTT可以顯示出網絡傳輸狀態的好壞;而報文丟失百分比則是對網絡傳輸質量的統計評估.
基于上述特性,我們提出一種多方向網絡狀態監測的方法,并簡要說明其實現原理.
二、網絡狀態監測實現原理
TCP/IP三層網絡作為應用層傳輸數據的基礎,尤其是電信級交換數據的傳輸基礎,無論從安全性還是可靠性上都有非常高的要求,因此,網絡狀態監控已經成為目前眾多設備提供商的研究重點之一.
如果僅僅使用Windows或者Linux系統自帶的Ping功能作為狀態監控手段,我們只能實現單一的一臺服務器到另一臺服務器的通信監測.如果該服務器與多個其它服務器同時建立TCP/IP連接,就必須通過多次重復使用ping命令才能達到同時監控每條鏈路方向的目的.對于復雜的電信核心網來說,單一的點對點監控已經無法滿足其發展需求,我們必須找出一種單臺服務器可同時監控多臺(幾十甚至幾百臺)服務器的跨平臺網絡狀態監測方法,以滿足集中監控整個核心網絡的目的.
基于上述原因,利用ping的原理開發出一種用于多點通信狀態監測的系統,具體實現機制如下:
監控系統模塊通過指定接口函數接收待監測的客戶端服務器IP地址,將該客戶端的地址記錄到內部統計結構列表中,并在記錄時判定該地址與已保存地址的重復性(重復的地址將不會被二次記錄),然后,通過定時器周期向所有客戶端地址方向發送ICMP探測包,對其鏈路狀態進行監控.
監測過程中,分別對每一被控鏈路方向的收發ICMP探測消息進行統計:當收到響應的時延小于用戶指定閥值的時候,記錄該消息的接收時間、序列號,以及接收ICMP響應的RTT往返時間,否則做丟包處理.通常情況下,由于電信級設備的高要求性,我們認為響應時間大于1s的網絡是不可用網絡,屬于嚴重堵塞或中斷狀態,必須告警并盡快查明恢復.正常通信時,網內響應時間應小于10ms,網間小于100ms才是具有高可靠性的傳輸網絡.發送ICMP探測包的周期應該由用戶根據安全需要自行設定.
每發送10包ICMP探測消息后,應該對各被控方向的整體網絡狀況進行一次統計,內容包括收到響應的數量、時延及丟包率等.將所有的統計數據全部記錄在指定目錄下的log日志文件中,日志文件的大小在大于一個閥值時應該保存為備份文件,然后重新記錄.通過日志在本機中查看服務器在一個周期時間(例如一周)內的網絡通信狀況,便于維護人員及時發現并提前避免傳輸層的問題.
這里需要設置一個周期上報線程,每隔一個用戶指定的時間周期,通過計算,將網絡狀態統計數據主動上報到操作維護臺.上報內容包括被監控端的IP地址,RTT往返時間和丟包率等.此外,該線程還對每個被監測客戶端的收發消息進行差值統計,一旦發現丟包立即通過接口函數上報告警至維護臺.告警內容包含監控客戶端的IP地址和告警級別.
需要注意的是,由于采用多方向連續ICMP監,所以,對于ICMP響應消息一定要進行合理的區分,以避免各個監控方向的統計混亂.由于傳輸網絡具有不確定性,并不能保證每一包到達的先后順序,此時通過IP地址、序列號和消息pid號區分響應消息就顯得尤為重要.另外,為了使用發送接收超時設置,必須設定socket為SO_RCVTIMEO和SO_SNDTIMEO方式,否則一旦某一監測方向出現網絡超時中斷問題,程序將面臨被懸掛死鎖的危險.
當返回ICMP回顯應答時,要保存消息序列號和TTL生存時間,并計算探測消息往返時間.ICMP消息序列號計數從0開始,每發送一次新的回顯請求,序列號加1.程序記錄返回的每個分組的消息序列號,供查看是否有分組丟失、失序或重復,并通過在ICMP報文數據中存放發送請求的時間值來計算往返時間.當應答返回時,用當前時間減去存放在ICMP報文中的消息發起時間,即往返時間.
基于ICMP的網絡監測方法,優點是具有平臺無關性.無論服務器、普通計算機或者電信交換機,只要是支持TCP/IP協議的操作系統,都可以被列為監控對象.即此監控方式不受被控端所使用的操作系統和操作平臺限制.這樣不僅提供了極強的平臺通用性,還大大減少了開發和維護所需成本.#p#
三、試驗數據分析
選擇在一個相對穩定的局域網(192.168.1.網段)內搭建實驗環境,這樣可以在測定監控系統運行穩定性的同時,通過斷開、連接網線的操作,實時模擬測試各種異常情況的發生.這里只給出基本的測試數據.
其中,以1.171作為監控的服務器,160、208、211三臺主機作為被監控的客戶端.當服務器分別收到三個被控端的IP地址,就會以60秒為周期分別對三臺服務器進行實時監控;每間隔10分鐘做一次統計寫日志操作(該時間周期用戶可調).
正常情況下,日志會每隔10分鐘記錄一次收發總包數和丟包率.為了測試超時中斷情況,拔掉192.168.1.160的網線模擬網絡中斷,再查看日志.
此時,日志文件會記錄下每次響應超時的狀況,并在該次探測失敗時上報告警消息至維護臺,然后,統計數據時算出當前1.160服務器的丟包率.監控系統運行時,其它方向的統計信息并未因該方向丟包而受到影響,各個客戶端的統計信息是相互獨立的.另外,也應該對網內響應時間超過100ms的數據包記錄統計(100ms指代網絡延時過長的閥值),以供查看整個網絡是否處于超負荷工作狀態.
在記錄當前時間、IP地址和序列號的同時,具體響應時間也被詳細列出,以供維護人員定位故障時間和故障的嚴重程度.
該監控系統已經在Windows、Linux、Unix、Vxworks等系統平臺上進行過穩定性測試,可正常使用.筆者針對測試過程中遇到的一些問題做如下總結,以供參考.
在發送端上,往返時間的計算結果有時可能為0 ms.這是因為程序所在的某些服務器CPU時間精度***只能到10ms級,低于10ms的時間精度無法取得,只能以數字0代替.
測試發現,通常第1個響應消息的往返時間值要比其他的大.這是由于目的端的硬件地址不在ARP高速緩存中的緣故.在發送***個回顯請求之前要發送一個ARP請求并接收ARP應答,這需要花費幾毫秒甚至幾十毫秒的時間.
在網絡運行中,正常工作狀態是:響應時間趨近于0,報文丟失很少或沒有,并且報文按序抵達.如果報文丟失較多而響應時間低或報文亂序抵達,說明網絡硬件可能出錯.在以太網中,可能是線纜終端故障,線纜分段故障或中繼器故障.首先檢查線纜終端,它很容易出故障,尤其是終端器放在用戶可碰到的工作區中;然后看中繼器的工作狀態,長時間使用的中繼器出問題的幾率也比較高.
如果在廣域網上進行測試,則上述報文丟失較多而響應時間低的現象可能屬于正常范圍.由于TCP/IP適用于不可靠網絡,某些廣域網的報文丟失率可能較高.但是若對于安全級別要求較高的電信級網絡而言,上述現象一定表明出現網絡故障,需要馬上進行問題排查.
四、應用情況及其缺陷
現階段,該監控方法已經應用于大唐電信SCDMA多組組網中,為核心交換網絡的底層傳輸系統提供監控,在工程應用中獲得了良好的效果.在給已開發的網絡管理系統項目中也使用了該監控方法,對整個網絡的底層通信狀態進行監控.應用前景及可擴展性都較好.
但是,該方法也存在一定的弊端.如果不能Ping到某臺主機,那么,就不能Telnet或FTP到那臺主機,即網絡可能存在問題.隨著Internet安全意識的增強,出現了提供訪問控制清單的路由器和防火墻.一臺主機的可達性可能不只取決于IP層是否可達,還取決于使用何種協議及端口號.監測程序的運行結果可能顯示某臺主機不可達,但可以用Telnet遠程登錄到該臺主機的25號端口(郵件服務器).即此方法不適用于有防火墻和限制IP功能的網絡.要使用該模塊,必須關閉服務器上相應的防火墻功能.
五、結束語
網絡傳輸層是整個現在通信系統的基礎和核心,其好壞直接影響到上層應用程序實現的質量.利用ICMP協議開發的這種監測方法提供了對底層傳輸物理設備(包括網卡、hub、路由器或者網線等物理設備)的實時監測.并能滿足多服務器跨平臺的復雜組網監控需求.
通過使用該監測系統,在網絡出現問題時,能迅速定位故障,以檢修或更換相應的硬件設備,并通過配合其他診斷方法的使用查找詳細故障原因,從而大大減少了網絡故障排查時間,為設備維護減少了人力和物力的投入.
今后,可以通過給該系統擴展類似Windows系統下的tracert功能,使該監控系統應用于不同網段的高等級分級監測,這樣將有助于更詳細地監控整個商業運行網絡的狀態,精確定位網絡故障.這種擴展有待于研究和開發.