基于OMNEST的以太網傳輸丟包問題研究

王建璞+趙亞麗+占凌云

摘 要： 針對實驗過程中以太網傳輸的丟包問題，使用OMNEST進行仿真建模，利用精確的系統描述，復現所出現的問題，進行丟包和端到端時延的研究。通過仿真分析定位問題，發現ARPCache中目的地址的超時或定期清空導致故障發生。基于此問題提出解決方案，為解決問題提供支持。

關鍵詞： OMNEST； 丟包； 以太網； ARP解析

中圖分類號： TN911?34； TP393.11 文獻標識碼： A 文章編號： 1004?373X（2015）10?0016?04

0 引 言

在通信系統建立以及調試過程中，仿真建模實驗作為一種重要的支撐技術發揮著越來越重要的作用。相對于實物調試試驗，使用仿真技術能夠更快、更多的遍歷問題出現的條件，為解決問題提供方案，提高工作效率。

OMNEST是一款面向對象的離散事件網絡模擬器，它的特征體現在分層次嵌入式模塊、各模塊以模塊類型分類、模塊之間通過信號在通道上的傳輸進行通信、靈活的模塊參數和拓撲描述語言。一個可執行仿真程序一般由網絡描述語言NED、.h和.cc文件、配置文件INI及消息文件.msg組成，其中：網絡描述語言NED，描述網絡拓撲結構；.h和.cc文件，用于完成各模塊的代碼編寫、也可以通過代碼生成網絡的拓撲結構，以及實現仿真結果的統計工作；配置文件INI，主要實現對模塊參數的配置，便于對仿真參數的更改；消息文件.msg，可以模擬傳輸過程中的事件、消息、包、幀等。

本文使用OMNEST離散事件仿真工具對以太網進行建模，建立以太網節點模型及其中心節點內各分功能模塊模型，多個節點模型通過NED語言聯合組成最終的網絡模型。節點模型由應用層模塊APP、傳輸層模塊UDP、網絡層模塊NETWORK（包含IP、ICMP、IGMP等子模塊）、鏈路層模塊ETH（包含ARP、ENCAP、MAC等模塊）組成[1?2]。

1 以太網傳輸丟包問題分析

在進行某綜合試驗的過程中，使用千兆以太網通過交換機將主機與終端相連。在實際網絡傳輸過程中，由主機產生消息通過接入設備路由將消息分別傳輸給所有的終端。對系統進行調試中，主機上的綜合監控軟件在向終端上的監控信息模擬軟件發送數據的過程中出現丟包現象。經分析，對出現問題的原因建立故障樹，如圖1所示。

通過對故障進行排查，排除了硬件和應用軟件的問題。在主機和終端上分別安裝CommView抓包軟件，通過多次試驗，查看抓到的數據包發現出錯的現象相同，故障可復現。每次出錯時，數據包信息描述如下：

（1） ARP request方向為：本機→對端；

（2） IP分片方向為：本機→對端；

（3） ARP respond 方向為：本機←對端。

圖1 故障樹分析

查看抓到的數據包內容：

ARP Request方向數據包中源IP為本機IP，源MAC為本機MAC，目的IP為對端IP，目的MAC為全“1”，意為廣播，這種形式的ARP包是在一臺主機的ARP列表中不含有可用項時發出的標準的ARP請求數據包；

IP分片方向通過查看數據包的大小、偏移量和MF標志位，證實它是數據包中一包數據所分成的IP片中的最后一片（每包數據大小為8 960 B，被分成7個IP片）；

ARP Respond方向數據包中的內容顯示它是一個標準的ARP應答包。通過抓包分析猜測問題出現在ARP解析過程中，當發送方主機ARPCache清空或者目的地址超時導致MAC目的地址不可用，就會發起ARP查詢時，故障出現。在故障樹中對應于操作系統引起的故障。在連續試驗過程中，由于故障每隔10 min會出現一次，因此，分析認為是系統定期ARP查詢導致故障的出現。

2 仿真模型的建立

本文使用OMNEST進行仿真，實現由1臺主機向6臺終端通過路由器發送報文，對故障進行編碼設計具有ARPCache清空功能的ARP協議，通過參數設定，與標準以太網模塊進行比較定位問題。圖2所示為使用OMNEST搭建的仿真場景。通過對抓包結果進行分析，定位問題可能出現在ARP解析過程中。在每一次ARP解析時都會出現丟包現象，而且總是丟掉IP分片的前面6片，而發送最后一個分片。

基于以上分析，本文建立如圖3所示的節點模型，使用計算機體系結構5層協議來模擬發送數據端[3]。應用層為myapp，實現消息的產生，接收以及統計；傳輸層使用UDP協議，綁定端口號1 024；網絡層建立IP?ICMP?IGMP結構模型，實現IP分片以及差錯控制等功能；數據鏈路層建立myarp?encap?MAC結構模型，myarp模塊實現地址的ARP解析模型，以及復現上述所定位的問題的編程實現，encap模塊實現仿真中上下層報文的發送控制，MAC模塊實現MAC地址的分配；最后通過1 000 MHz以太網發送。在消息的產生以及傳輸等方面，通過上述方法建立的節點模型都與實際情況一致。

圖2 OMNEST仿真場景

圖3 節點模型

圖4為實現myarp模塊的編碼流程圖。參考計算機網絡ARP標準并結合實驗的實際情況，本文設計具有ARPCache清空功能的ARP協議，在協議中中采用ARP高速緩存存放局域網上各主機和路由器的IP地址到硬件的映射表。本文中規定ARPCache清空時間為t1，而對于每一個目的地址，在協議中有一個生存時間為t2，在t2時間內使用過該目的地址則再延長一個生存時間，如果超過這個生存時間就會把這一地址映射丟棄。

3 仿真結果及分析

OMNEST系統自帶有ARP模塊，此模塊按照計算機網絡ARP標準建立。標準ARP模塊無法準確描述實驗出現的問題，所以本文建立具有ARPCache清空功能的以太網模型。仿真實驗時，將具有ARPCache清空功能的以太網模型與標準的以太網模型進行對比。分別對故障樹羅列情況進行仿真，得到仿真結果，并對仿真結果進行對比分析。

3.1 仿真參數

本文的仿真的參數都使用實物實驗時設定的參數值和實驗過程中實測的數據，以保證對系統的精確描述。

圖4 ARP編碼流程圖

表1 仿真主要參數設定

3.2 仿真結果及分析

使用具有ARPCache清空功能的以太網模型進行仿真，千兆網下各發報時間點所對應的延時見圖5。

圖5 各發報時間點的延時情況

在10 s，20 s，30 s，40 s，70 s，100 s，440 s，530 s，570 s，600 s，620 s，630 s，670 s，730 s，740 s，900 s，940 s，1 200 s，1 210 s，1 230 s，1 280 s，1 380 s，1 510 s發生了丟包，其中10 s，20 s，30 s，40 s，70 s，100 s，600 s，620 s，630 s，670 s，730 s，740 s，1 200 s，1 210 s，1 230 s，1 280 s，1 380 s，1 510 s是由于ARPCache在每隔600 s進行一次清空導致的ARP查詢，而440 s，530 s，570 s，900 s，940 s則是由于超過120 s未使用ARPCache中對應的目的地址過期導致的。其他時刻正常發出6個包，傳輸正常。

圖6為仿真過程中發生ARP查詢時，接收端應用層收到的報文。從圖6中可看到，在ARP查詢時，接受終端收到的報文大小為724 B，正好是IP分片的最后一片。正常傳輸時接收端會收到7個IP分片，而在仿真過程中發現，每進行一次ARP查詢在MAC層都只能收到兩個包，一個是ARP請求包，另外一個是IP分片，而在應用層只能收到一個包，是IP分片的最后一片。

圖6 發出的報文情況

可以看出在ARPCache定時清空或目的地址超時發生的情況下，仿真可以復現實際以太網傳輸所出現的丟包問題。通過參數設定，將帶ARPCache清空的的節點與標準模型下的節點對故障樹對應的各個問題進行仿真對比，結果如表2所示。

表2 仿真結果

從仿真結果可以看出帶ARPCache清空的以太網模型發送端都發生了丟包，而使用標準ARP模塊的以太網模型的節點則沒有發生丟包。通過參數設定進行仿真分析發現試驗中的以太網丟包問題只和ARP查詢有關，所以可以在實際試驗中把問題準確定位在ARPCache上。

3.3 機理分析

從仿真中可以看出當ARP查詢時會導致丟包，而致使ARP查詢的原因是每隔600 s一次的ARPCache清空或者120 s每ARPCache內的目的地址未使用而導致的地址過期。對于這兩個因素，在實際環境中進行驗證分析。

（1） 操作系統自動發起ARP查詢。在操作系統HKE_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/ TcpIP/Parameters注冊列表下，保存了操作系統自動發起ARP查詢時間的鍵值。鍵值1：ArpCacheLife，類型為Dword，單位為s，默認值為120；鍵值2：ArpCacheMinReferencedLife，類型為Dword，單位為s，默認值為600；默認情況下這些鍵值不存在，如需修改，則需自行創建。在默認情況下，Windows Server 2003和Windows XP的ARP緩存中的ArpCacheLife表項僅存儲2 min，如果一個ARP緩存表項在2 min內被用到，則其再延長2 min，直到最大生命周期10 min為止，超過10 min的最大期限后，ARP緩存表項將被移除，并通過一對ARP請求和ARP應答來獲得新的對應關系。綜上所述，當ArpCacheLife小于ArpCacheMinReferencedLife的值時，ArpCacheLife表示未被使用的表項在ARP緩存中的生存時間，ArpCacheMinReferencedLife表示被重復使用的表項在ARP緩存中的生存時間，當設置ArpCacheLife的值大于或等于ArpCacheMinReferencedLife時，則被使用和未被使用的表項的生存時間均為ArpCacheLife。

（2） 發起ARP查詢時僅發送最后一個IP片。在ARP協議源碼中，獲得與IP地址對應的MAC地址由arpresovle函數完成。該函數的一個工作特點是：如果一個節點沒有一個有效的MAC地址就必須發送一個ARP請求，在發送ARP請求和接收ARP應答之間，如果有多個發往同一目的IP地址的數據包即IP分片要發送，則只把最近一個IP數據包保留，而將其他的IP分片丟棄。

4 解決措施

通過對問題機理的分析，可以看出在發送有IP分片的數據包時，ARPCache清空所帶來的丟包就會發生，所以要解決這一問題就要從數據包大小和ARPCache清空兩個方面入手。本文提出5種解決措施，并指出每種措施的優缺點，為實際應用提供支持，見表1所示[4]。

5 結 語

本文使用OMNEST通信仿真軟件對以太網主機之間通信進行建模，對每個節點采用計算機網絡體系5層結構進行精確仿真，使用C++編程實現每一個功能模塊，使模型與真實模型逼近。針對以太網丟包問題，本文先建立故障樹對故障進行理論分析，然后使用OMNEST建立具有ARPCache清空功能的節點模型，復現丟包現象，精確定位問題，并結合仿真結果提出問題的解決方案。隨著通信仿真技術的發展，通信仿真手段越來越多的被用來解決工程問題。本文使用OMNEST對以太網丟包問題的描述和解決為后續同類工程問題的解決提供借鑒。

參考文獻

[1] 趙永利，張杰.OMNET++與網絡仿真[M].北京：人民郵電出版社，2012.

[2] 單衛龍，馬奎，周武能.基于OMNeT++的“實代碼”仿真模式研究[J].微型機與應用，2010（20）：11?15.

[3] 謝希仁.計算機網絡[M].北京：電子工業出版社，2008.

[4] 王海軍，劉彩霞，程東年.一種基于UDP的可靠傳輸協議分析與研究[J].計算機應用研究，2005（11）：181?185.

[5] 李振，鄭連澤，饒廣然.基于OMNeT++的Link 11網絡建模仿真研究[J].現代電子技術，2012，35（3）：21?25.

[6] 李愛國.SCTP在工業以太網通信技術中的應用研究[J].現代電子技術，2011，34（3）：160?162.