陳 宇,韓久江,劉 建,鮮 明,王會梅,張宇翔
國防科技大學 電子科學學院,長沙 410073
網絡仿真實驗場已經成為網絡安全領域的一項重要科學裝置,能夠在安全可控的環境下為網絡空間行為的觀察、測量與分析提供支撐手段,為網絡攻防行為的測試與評估、網絡安全工具的測試與驗證、專業人員的技戰術訓練演練提供靈活高效的軟硬件基礎設施。目前,主流的網絡仿真實驗場主要依賴數字仿真、虛擬化等技術構建虛擬環境中的仿真實體,然而考慮到真實的網絡空間中設備復雜異構、廠家來源多樣,而且某些設備(如密碼機、專用設備等)不存在虛擬仿真模型或者鏡像、某些復雜終端(如各類涉密目標信息系統、定制化的特殊終端)難以進行虛擬仿真構建等問題,迫切需要將實體終端與虛擬網絡進行靈活集成,共同構建虛實融合的網絡仿真實驗場,為網絡攻防演練提供高逼真的場景環境。
軟件定義網絡是近些年新興的一種網絡技術,其通過控制層面與數據轉發層面的相互分離,為網絡設備提供基于硬件基礎的轉發層面和基于軟件控制的控制平面[1-2],通過SDN控制器實現對全域網絡的控制、管理。鑒于SDN管控分離的特點,網絡便具備了更好的靈活性和可拓展性。
文章提出一種基于SDN的虛實融合網絡仿真實驗場構建方法,其核心思想是實現網絡仿真場景構建中虛擬實例與實體終端的共同組網,使得構建的網絡仿真場景更加得全面、逼真,更好地滿足網絡安全實驗需求。實驗發現,基于SDN的網絡仿真實驗場構建方法能夠快速實現虛實融合場景的構建,相比于傳統的構建方法,能夠滿足大規模復雜網絡場景生成,并有效規避網絡節點鏈路堵塞等現象。通過SDN的方式將實體終端接入虛擬網絡環境中,可以有效降低復雜網絡的構建成本,實現網絡規模靈活擴展、網絡仿真真實有效。
文章的主要貢獻包括三個方面:
(1)基于SDN,提出了一種虛實融合網絡仿真實驗場構建方法,并設計開發了一套用于虛實融合網絡仿真的原型系統。
(2)基于Ryu控制器,提出了一種流表生成算法,實現虛實設備間的互聯互通。
(3)通過實驗證明所述基于SDN的虛實融合網絡仿真實驗場構建方法與流表生成算法的有效可行。
進入新世紀以來,隨著網絡規模逐步增大、網絡結構越發復雜、網絡需求日益劇增,對網絡的靈活性要求也不斷提高,SDN解決了傳統網絡架構復雜、結構分散等問題,突出了網絡靈活性。SDN是斯坦福大學Nick教授在2008年提出的,在傳統的TCP/IP網絡中,數據平面與控制平面具有緊密耦合的特點,針對不同的網絡架構都必須進行定制化的網絡架構構建,導致網絡后期維護復雜、成本巨大、,且對于如今用戶更多功能、更加靈活、更復雜多變的網絡需求明顯顯得力不從心,所面臨的現實問題和業務挑戰持續增大。SDN則更好地適應了網絡發展趨勢,采用分層思想,將網絡的數據平面和控制平面完全解耦分離[3-4],SDN是一種新型網絡體系結構,是網絡功能虛擬化的一種實現方式。如圖1所示,SDN架構從上往下可以分為應用層、控制層、基礎設施層,應用層運行著大量的應用與軟件,控制層是整個SDN架構的核心,基礎設施層由基礎物理設備組成,用于數據處理。在分層結構中,控制層通過提供北向接口和南向接口分別實現與應用層和基礎設施層的通信,通過北向接口對接運營商的業務應用,便于維護人員通過編程的方式實現網絡部署等服務;而通過南向接口可實現對數據平面網絡設備的集中控制。因此SDN架構最突出的特點便體現在直接可編程、集中化管控、開放兼容等方面。

圖1 SDN架構Fig.1 Structure of SDN
隨著SDN技術的發展,SDN控制器也已經較為成熟多樣,呈現出開源與商用SDN控制器并存的現狀,較為常用的SDN控制器有Ryu、NOX、FloodLight、Open-Daylight[5]。其中,Ryu控制器因為具有更佳的輕量級優勢,基于Python實現的代碼更靈活簡潔,同時提供了各種規范定義的API接口、網絡組件等,也可支持多種實體和虛擬交換機,因而得到了廣泛的應用。Ryu控制器主要由app、base、cmd、contrib、controller、lib、ofproto、services、tests、topology等組件構成[5],基于特定需求實現特定功能,只需結合上述組件構建自定義的app即可,因此在實驗過程中便于開發人員進行快速的創建、管理和應用。
OpenFlow協議是SDN眾多南向接口協議中最為出名、應用最廣的協議[6-7],如表1所示,一條OpenFlow流表項包含Match Fields、Priority、Instructions、Counters等基本字段、條件字段和動作字段[8],其中Match Fields的主要作用是在流表項中進行規則匹配,可用于匹配in_port、dl_dst、dl_src、vlan、tun_id等關鍵報文字段;Priority定義了流表的優先級,流表在處理報文時按照流表優先級的高低依次進行報文處理;Instructions則為流表的動作指令集,通過一系列的Instructions定義流表的具體執行行為action,如執行output、drop、push_vlan、pop_vlan、set_field→tun_id等動作,而且在Instructions指令集中可以包含多種指令類型,通過一系列的action后才完成數據報文的處理[9]。

表1 流表項的部分組成情況Table 1 Composition of partial OpenFlow table
OVS(Open vStich)在SDN虛擬交換機中最具影響力、使用最廣泛,已經廣泛應用于商業界和學術界,尤其是隨著近些年云產品規模的高速發展,OVS已經成熟運用于各類云平臺中。在云平臺中,對于多租戶的各類場景,租戶對網絡的需求多種多樣,且隨時都會進行不同的增、刪、改,傳統的網絡管理方式基本上需要管理人員不斷地手動維護和操作,很難滿足云平臺的網絡需求,因此基于SDN實現網絡虛擬化、自動化、靈活化后,能更好地滿足云平臺的網絡需求。基于云平臺的虛擬資源編排能力,實現網絡攻防訓練場景的快速構建,是當前網絡仿真實驗場的主流技術方案。OpenStack作為主流的開源云平臺,已廣泛應用于各行各業,基于OpenStack云平臺定制化構建網絡仿真實驗場,生成各類網絡安全實驗場景也已成為目前網絡仿真實驗研究中最常用的手段。在OpenStack云平臺中,每臺節點的OVS虛擬交換機共有br-tun、br-int、br-ex三個虛擬網橋,其中br-tun是隧道網橋,基于隧道技術的vxlan和GRE網絡則是使用該網橋進行通信[10],br-int是集成網橋,網絡場景生成的所有實例都將通過網卡等虛擬設備與集成網橋進行連接,br-ex則是用于連接外部網絡的網橋。
在進行網絡仿真場景生成的時候,不僅云平臺內部需要構建復雜多樣的拓撲環境,而且還經常需要將某些實體終端集成于虛擬網絡中,共同構建虛實融合的網絡仿真實驗場場景[11]。云平臺自帶的技術方案主要是通過網絡節點的br-ex網橋,搭建vlan或著flat網絡實現云平臺中虛擬實例與外界實體終端的通信互連,但基于上述兩種方式分別存在以下不足:vlan使用12 bit標記的vlan_id,使得該技術最多只能夠支持4 096個vlan號,不利于同時構建大規模網絡場景;而flat網絡又必須滿足每一個flat網絡獨占一個網絡節點的物理網卡,故受限于網絡節點的物理網卡數量,在實際生產測試環境中,局限性和弊端性較大,同時上述兩種方式均需要通過網絡節點實現與外界的通信,會導致大流量數據傳輸時,網絡節點存在阻塞的現象。
針對上述問題,部分學者也進行了虛實融合的研究,如:文獻[12]結合OpenStck研究了多粒度虛擬化技術及虛實網絡一體化融合技術,實物網絡通過Cisco邊界路由器接入OpenStack集群,通過BGP(external BGP,EBGP)協議與虛擬路由器實現有機融合組網,但是在實現過程中需要先在OpenStack數據庫中查詢虛擬實例網絡ID,再結合查找對應的vlan號后,才能進行相應配置與連通,不利于實際應用,且所有實體網絡數據也都是通過OpenStck網絡節點與OpenStck集群中虛擬實例進行連通;文獻[13]通過MPI技術實現了實體終端靈活接入NS3網絡仿真平臺,但其實體終端與仿真實例進行通信時,需要進行真實報文與虛擬報文的重構轉發,結構復雜,不適用于大規模網絡場景的仿真;文獻[14]分別針對單實體終端和多網段實體終端提出了基于FloatingIP和基于路由節點的方式實現虛實融合,基于FloatingIP的方式造成了底層物理資源的大量消耗,基于路由節點的方式同樣未能解決大規模OpenStck集群中網絡節點通信瓶頸的問題;文獻[15]通過將OpenStck中網絡節點作為虛實互聯服務器,由于受限于服務器網卡數量,便通過增加網絡節點的數量和相應的網卡數量來增加實物終端接入的數量,該方法對接了OpenStack中Neutron數據庫和OVS中ovs-db數據庫,通過在Neutron數據庫建立虛實互聯的映射表,借助虛擬路由器實現了通連,但存在邏輯復雜、難以進行大規模自動化快速部署等問題。
上述研究工作雖然都實現了實體終端與虛擬實例的共同組網,但是卻存在不支持大規模網絡場景、結構復雜、不能適用于實際環境、容易出現通信瓶頸造成鏈路阻塞等問題。因此采取一種部署簡便、高效、靈活、安全、適用于大規模網絡場景構建的方式實現網絡仿真實驗場中虛擬實例與實體終端的互聯互通、從任意位置接入后可共同組網構建融合仿真場景已成為一種迫切需求。為滿足大規模網絡場景構建需求,設計采取vxlan網絡而并非flat或者vlan網絡;為實現部署靈活、高效,采取基于SDN的方式,利用控制器實現虛實設備間的靈活組網;為規避由于云平臺網絡節點的通信瓶頸造成鏈路堵塞,采取將實體SDN交換機與各個計算節點的虛擬OVS交換機分別搭建vxlan隧道,實現多條虛實鏈路的互聯互通,從根本上杜絕了由網絡節點造成通信堵塞的可能。
主要介紹基于SDN軟硬件交換機實現虛實融合網絡仿真實驗場構建,該設計依賴overlay網絡,通過搭建vxlan隧道實現實體終端的接入。Vxlan網絡具有和vlan網絡相似的功能,能夠提供二層的以太網服務,但vxlan相較于vlan卻具備更好的靈活性和擴展性,其采取24 bit標記vxlan_id,能夠支持更多的二層網絡,達到1 600多萬個二層網段,因此能夠滿足大規模復雜云平臺中網絡場景構建。
在OVS的云平臺中,虛擬實例的數據包傳輸會經過一系列的虛擬網橋設備,下面以計算節點中虛擬實例數據包走向進行詳細描述。
如圖2所示,云平臺中虛擬實例通過虛擬網卡等設備,將數據包通過OVS的br-int網橋傳送至br-tun網橋,當數據包到達OVS的br-tun網橋時,會根據網橋中多級OpenFlow流表規則進行轉發,其流表轉發規則如圖3所示。

圖2 實例數據走向Fig.2 Instance flow direction

圖3 流表間的走向Fig.3 Direction of OpenFlow
圖3中各個OpenFlow流表的功能分別為:
table0:做分流處理,根據報文來源是云平臺內部的br-int網橋或云平臺外部(外部發送過來的數據是指數據由其余節點或設備傳輸至本節點,并非本節點中虛擬實例通過br-int網橋傳輸的數據報文),分別轉發至不同的流表作后續處理,對于內部br-int網橋發送過來的數據報文則轉發至table2處理,對于外部發送過來的數據報文則轉發至table4處理;
table2:對于虛擬實例準備向外發送的數據報文,若是單播包則轉至table20,若是多播包則轉至table22處理;
table3:將滿足該流表匹配條件的數據包直接丟棄;
table4:用于處理外部發送過來的數據報文,具體為剝除vxlan的tun-id,添加vlan tag,實現云平臺內部vxlan與vlan的映射轉換后轉至table10進行處理;
table10:該流表是一條自學習流表,實現數據報文中mac地址表等的學習,并將學習到的內容放到table20中;
table20:根據報文的匹配域(vlan、目的mac等),剝離vlan_id,添加vxlan的tun-id,并從指定的vxlan port轉發出去,若未能實現相應的匹配,則轉至table22進行處理;
table22:同樣是根據報文的匹配域(vlan、目的mac等),剝離vlan_id,添加vxlan的tun-id,然后進行泛洪廣播,將數據報文發送至所有的vxlan隧道中,實現數據報文在云平臺中不同節點間的傳輸。通過上述OpenFlow流表的轉發規則,則實現了云平臺中各個虛擬實例之間的相互通信。
3.2.1 系統架構
通過上節虛擬實例之間數據走向的分析可知,將實體交換機與云平臺中計算節點的br-tun網橋通過vxlan隧道進行連接,便能實現實體終端與虛擬實例融合組網通信。為實現簡便、高效、靈活、安全地將實體終端與云平臺中虛擬實例共同組網構建高逼真的網絡仿真實驗場景,采取基于SDN的方式,實現實體終端的接入,構建虛實融合網絡,其系統架構如圖4所示。系統架構自下而上分別是硬件層、平臺層、中間邏輯層、用戶交互層,硬件層主要通過服務器、實體SDN交換機等為整個系統搭建硬件環境支撐;通過硬件構建出的OpenStack云平臺、SDN控制器、數據庫等組成了平臺層,為中間邏輯層奠定軟件環境基礎;中間邏輯層通過與用戶交互層的交互獲得繪制和配置好的拓撲信息,再通過調用平臺層的軟件資源進行邏輯功能的實現。

圖4 系統架構Fig.4 System architecture
系統各個模塊間的詳細功能如下所述:
用戶交互層通過前端WEB交互界面實現虛實網絡場景的拓撲構建,其中虛擬資源信息注冊模塊主要提供OpenStack云平臺中虛擬實例的構建要素,如鏡像名、實例大小等資源信息,可在生成具體實例時進行選擇;實物設備信息注冊模塊主要是進行實體終端的注冊入庫,如型號、操作系統、功能和在實體SDN交換機上連接情況等;虛實融合網絡拓撲繪制模塊主要用于構建具體的網絡實驗場景,通過與虛擬資源信息注冊模塊和實物設備信息注冊模塊的交互,指定繪制的拓撲場景具體使用的虛擬實例和實體終端信息;虛實融合網絡參數配置模塊主要用于虛擬實例的磁盤、CPU、IP等參數的配置,即將繪制出的場景實例進行具體化配置;虛實網絡場景生成模塊主要通過與用戶交互層中各個模塊的交互,獲取繪制和配置的拓撲場景,根據配置好的網絡拓撲,進行拓撲解析,調用OpenStack后臺資源按照繪制和配置的網絡拓撲生成相應的虛擬實例;虛實融合處理模塊則主要是結合SDN控制器實現相應的功能,其中虛實信息查詢模塊將查詢到的實體終端在拓撲中所屬vxlan信息反饋給流表構造模塊,流表構造模塊和流表下發模塊通過與虛實信息查詢模塊的交互,結合相應的算法實現各級流表的構造下發,流表動作執行模塊則根據下發的流表執行相應的具體操作,如數據包的組播、丟棄、打vxlan_tag標記后再轉發等。
具體生成一次虛實融合網絡場景的流程圖如圖5所示,用戶交互層根據虛擬資源信息注冊模塊和實物設備信息注冊模塊的注冊信息,繪制網絡拓撲場景,主要繪制虛擬實例和實體終端組網情況;拓撲繪制完成后需要對虛擬實例進行詳細參數配置,確定實例的鏡像類型、網段參數等,如對每個實例確定使用Ubuntu或者Windows鏡像,明確虛擬CPU、磁盤等大小。用戶交互層完成上述拓撲繪制和配置后,將所得到的場景信息由中間邏輯層進行具體處理。其中網絡拓撲解析模塊首先處理場景描述中的網絡部分信息,調用OpenStack的Neutron_API逐個生成虛擬網絡、子網、端口等,再根據拓撲解析得到的實例信息,調用Nova_API,通過Nova_scheduler和Nova_compute服務完成虛擬實例創建請求,再通過調用OpenStack中Glance和Neutron等組件,結合解析得到的實例配置信息完成虛擬實例的創建。至此則完成了虛實融合場景構建中虛擬實例和網絡環境的生成,接下來主要介紹通過虛實融合處理模塊完成虛實鏈路的互聯互通,首先通過調用Neutron數據庫獲取場景相應的vxlan_id信息、具體實體終端需要融入的虛擬網段等,將虛擬實例與實體終端間的報文數據上報SDN控制器進行解析處理,結合流表生成算法進行OpenFlow流表的構造并下發至實體SDN交換機,實體SDN交換機則依據流表指令完成相應的處理動作打通鏈路,實現虛實互通、融合組網,后面將詳細介紹完成虛實融合中鏈路打通和流表生成算法的關鍵技術。
3.2.2 系統各模塊交互關系
圖6顯示了基于SDN的虛實融合網絡仿真實驗系統中各模塊之間的控制流信息。

圖6 系統模塊之間的控制流信息Fig.6 Control flow information between system modules
系統各模塊之間的控制流為順序執行的邏輯流程。首先,虛實融合網絡拓撲繪制模塊和虛實融合網絡參數配置模塊作為系統的輸入端,通過繪制和配置拓撲得到構建的網絡場景具體信息。將得到的網絡場景具體信息發送至虛擬網絡場景生成模塊,虛擬網絡場景生成模塊進行場景要素的解析,主要解析得到場景構建的網段、實例的系統配置、端口連接情況等,解析后分別調用OpenStack的API生成對應的虛擬網絡和虛擬實例等。虛實融合處理模塊再根據所生成的網絡信息,結合OpenStack的Neutron組件和SDN控制器完成流表的構造與下發,虛擬實例與實體終端則根據下發流表所對應的指令動作進行相關通信。
圖7顯示了基于SDN的虛實融合網絡仿真實驗系統中各模塊之間的數據流信息。

圖7 系統模塊之間的數據流信息Fig.7 Date flow information between system modules
系統管理員通過虛擬資源信息注冊模塊和實物設備信息注冊模塊,將虛擬資源信息和實物設備信息存入數據庫中。用戶通過虛實融合網絡拓撲繪制模塊,在WEB交互界面繪制虛實融合網絡拓撲場景,然后配置拓撲參數,完成拓撲參數配置后將場景具體信息存入數據庫中,如IP段、虛擬實例數量、端口及實體終端連接情況等。場景生成模塊讀取數據庫中存儲的場景信息后,生成具體的虛擬網絡和虛擬實例,同時將虛擬網絡和虛擬實例的具體生成信息存入數據庫中,如實例IP、實例mac、vxlan_id等。虛實融合處理模塊再通過讀取數據庫中vxlan_id、實體終端連接情況等數據,將其作為關鍵參數反饋至SDN控制器,SDN控制器依據得到的關鍵參數結合流表生成算法完成具體流表的構造與下發。
上節所述系統架構的具體物理連接圖如圖8所示。

圖8 基于SDN的虛實融合Fig.8 Virtual-real fusion based on SDN
3.3.1 構造vxlan隧道
Vxlan隧道是整個虛實融合系統的橋梁,控制器對實體SDN交換機進行全權管控,通過vxlan隧道打通實體SDN交換機與云平臺各個計算節點OVS中br-tun隧道網橋之間的鏈路,這也是實現云平臺與實體終端連通交互的前提。具體實現步驟為:
步驟1在云平臺各個計算節點OVS虛擬交換機的br-tun隧道網橋和實體SDN交換機上分別增加相應的vtep_port端口對。
步驟2通過OVS相關命令,利用步驟1中的vtep_port端口對,創建vxlan隧道,實現實體SDN交換機與云平臺各個計算節點OVS中br-tun隧道網橋的連通,進而便實現了云平臺中虛擬實例與實體終端的鏈路連通。
步驟3在云平臺各個計算節點的br-tun隧道網橋中添加守護進程,將新增加的vtep_port信息添加進入br-tun隧道網橋的各級流表中。
3.3.2 流表構造與下發
上述系統架構中最為核心的是虛實融合處理模塊,其中流表的構造與下發是整個模塊中最重要的一個部分,其核心則主要在于虛實網絡信息的查詢和流表構造的相應算法。SDN控制器流表構造和下發的具體過程如算法1所示,首先SDN實體交換機接收到數據報文后先判定是否有可匹配的流表項,如果無可匹配的流表,則觸發Packet-in機制,以Packet-in消息的形式將數據報文上傳至控制器。控制器接收到Packet-in消息形式的報文后,進行相關的關鍵信息提取,建立自學習機制,通過對in_port、eth_src、eth_dst、tunnel_id等關鍵字段的解析學習,將數據報文走向分為從虛擬實例發送至實體終端和從實體終端發送至虛擬實例兩個方向,結合虛實網絡信息查詢模塊的結果,分別向實體SDN交換機構造和下發不同優先級的OpenFlow流表,實現實體SDN交換機基于不同優先級的流表進行數據報文的處理。具體如算法1所示:
算法1SDN控制器流表構造下發算法
輸入:Packet-in消息;
輸出:OpenFlow流表項。
//未匹配到流表且數據為arp報文則上報控制器
1.If not match && protocols==arp:
//報文是實體終端發送的廣播包
2.If in_port from Physical and type=Flood:
//學習報文的輸入端口、mac等信息
3.Learn(in_port,mac)
//通過數據庫獲取vxlan_id信息
4.Request.ge(tvxlan)
//區分交換機端口進行直接轉發和通過隧道轉發組播流表構造
5.SetGroup table[setAction(forward),SetAction(setTun_id,forward)]
//下發優先級為A的流表
6.SetFlowEntry(setGroup table,priority=A)
//若報文是實體終端發送給虛擬實例的非廣播包
7.Else:
8.Request.ge(tvxlan)
//進行隧道轉發流表構造
9.SetAction(setTun_id,forward)]);
//下發優先級為B的流表
10.SetFlowEntry(setAction,priority=B)
//報文由虛擬實例通過隧道發送
11.If in_port from OpenStack && vxlan in pro-tocols:
12.If type!==Flood:
//學習報文中源端口、mac、vxlan_id等信息
13.Learn(in_port,mac,vni)
14.SetAction(forward);
//下發優先級同樣為B的流表
15.SetFlowEntry(setAction,priority=B);
16.Else:
17.SetAction(Flood);
//下發優先級為C的流表
18.SetFlowEntry(setAction,priority=C)
19.Else:
20.Drop
將通過大量的仿真實驗來測試所提出的虛實融合方案性能表現,從連通性、隔離性、發包延遲、吞吐量等方面對方案進行評估。
使用多節點部署的OpenStack云平臺作為本地網絡仿真實驗平臺,使用盛科V530型號的交換機作為實體SDN交換機,使用Ryu控制器作為SDN控制器,用于云平臺和盛科交換機間的網絡管理。通過四臺服務器搭建分布式部署的OpenStack云平臺,其中一臺控制和網絡復合節點的管理網段IP為192.168.36.50,三臺計算節點的管理網段IP為192.168.36.51、192.168.36.52、192.168.36.53。以臺式終端作為實體終端通過盛科交換機實現與OpenStack云平臺的融合組網。
在實驗中,通過虛實融合WEB用戶交互界面進行虛實融合網絡仿真實驗場景的拓撲繪制,通過生成的不同場景進行不同實驗驗證。
4.2.1 虛實節點連通性與真實性測試
面向圖9的虛實網絡拓撲,完成虛實融合網絡仿真實驗場景的構建,將三臺實物終端連接至實體SDN交換機,虛擬實例均設置為192.168.16.0/24網段,實體終端IP分別設置為192.168.16.197、192.168.16.198、192.168.16.199,首先從虛擬實例節點ping實物終端節點,顯示ping成功;然后重新進行上述場景生成,再從實物終端節點ping各個虛擬實例節點,也顯示ping成功,通過Wireshark抓包結果如圖10所示。

圖9 拓撲繪制Fig.9 Topology drawing

圖10 終端和實例分別采集的報文Fig.10 Packets collected by physic and instances
抓包結果證明了虛實融合網絡鏈路的連通性,其次通過對虛擬實例數據報文和實體終端數據報文的解析對比,可以發現兩種數據報文的大小、內容、類型等完全一致,這說明虛實融合網絡的數據報文在虛擬網絡中的傳輸結果與實體網絡中的傳輸結果完全一致,表明了虛實網絡下數據的真實性。另外,無論是虛擬實例節點向實物終端節點請求建立通信,還是實物終端節點向虛擬實例節點請求建立通信,都可以建立正常通信,證明了本文方案的有效性。同時使用Zenmap探測軟件,在實物終端節點上進行拓撲探測,可以清晰地顯示出云平臺中處于同網段的虛擬實例節點,也證明了虛實網絡數據鏈路層面的連通性。圖11中中心紅色節點為實物終端,周邊環繞的綠色節點為云平臺中的90個同網段的虛擬實例和實體終端。

圖11 Zenmap探測結果Fig.11 Result of Zenmap
表2為實體終端與隨機選取的六個虛擬實例連通測試結果。

表2 部分實例連通性測試結果Table 2 Results of some VMs’connectivity test
4.2.2 流表構造結果正確性測試
根據4.2.1小節所述的虛實融合網絡仿真實驗場景,基于SDN控制器流表生成算法,設計了流表自動化配置代碼,首先從虛擬實例節點ping實物終端節點,Ryu控制器通過該算法會自動構造和下發流表規則,虛實節點ping成功后,登錄實體SDN交換機查看交換機流表信息配置情況如圖12所示;在虛擬實例節點所在的計算節點服務器上,使用命令查看流表規則,結果如圖13所示。

圖12 實體SDN交換機部分流表Fig.12 Some OpenFlows of physical SDN switch

圖13 計算節點部分流表Fig.13 Some OpenFlows of computing node
從上述流表信息可以看出,通過設計的流表構造和下發算法,生成的流表可以使虛擬實例與實體終端實現虛實鏈路的無縫互通。
4.2.3 虛實融合網絡隔離性測試
在實際的網絡實驗中,往往會存在多個相同網絡配置參數的虛實網絡場景,它們分別屬于不同的vxlan網絡,但在這些不同場景中虛擬實例的IP屬于同一個網段,構建了如圖14所示的拓撲來驗證方案的隔離性。其結合4.2.1小節所生成的網絡,再創建一個不同vxlan下的192.168.16.0/24的虛擬網絡,并生成多臺IP段為192.168.16.0/24的虛擬實例。兩個網絡的vxlan_id分別為vxlan100和vxlan200,實體終端1、2的IP設備分別為192.168.16.199、192.168.16.200,實體終端1、2通過流表實現隔離,為實現實體終端1與vxlan100的網絡互聯互通,實體終端2與vxlan200的網絡互聯互通,用戶交互層的前端頁面具體拓撲繪制如圖14所示。實驗隔離性測試結果如表3所示。

圖14 隔離性測試拓撲Fig.14 Topology of isolation test

表3 隔離性測試結果Table 3 Result of isolation test
如圖14所示,在之前的流表算法自動構造與下發的基礎上,場景中新增了一組除vxlan不同外,其余網段均相同的虛實融合網絡。表3的測試結果顯示,實體終端1只能與vxlan100的虛擬網絡相互連通,實體終端2只能與vxlan200的虛擬網絡相互連通,這是因為流表構造與下發算法是依據vxlan_id作為關鍵字段進行處理的,通過構造與下發的流表實現了不同虛擬網絡的相互隔離,證明了方案具有網絡隔離性,且具有實際可行性。
4.2.4 虛實融合網絡性能測試
為了驗證所述方案在虛實網絡中的實際網絡性能,在同一虛實網絡中生成不同數量的虛擬實例進行實驗測試。實驗的三臺計算節點服務器,配置均為16核256 GB,本次實驗構建了一個虛擬網絡,在該網絡中仿真不同數量規模的虛擬實例節點,考慮到虛擬實例的配置參數對虛擬網絡仿真規模的影響,本次實驗時,將OpenStack中虛擬實例的Flavor配置參數分成三個等級,分別是小(RAM=512 MB,Root Disk=5 GB)、中(RAM=2 GB,Root Disk=10 GB)、大(RAM=4 GB,Root Disk=20 GB),對小、中、大三種虛擬實例的數量規模比例選取為5∶3∶2,針對生成的不同數量規模的虛實網絡場景,分別從通信時延、吞吐量、丟包率等方面進行網絡性能測試,測試結果如圖15~17所示。
圖15是本文方法虛實網絡的通信時延與虛擬實例節點數量的關系曲線圖,針對每一種虛擬實例數量,均測試10次然后取平均值。從圖中可以看出隨著虛擬節點數量規模增大,本文方法的通信時延也略微增加,但總體上時延依然保持在極低的水平。圖16是虛實網絡的吞吐量與虛擬實例節點數量的關系曲線圖,針對每一種方法,同樣測試10次然后取平均值。由于實驗環境中服務器以及實物終端均為千兆網,所以在虛實網絡中,吞吐量最大應接近1 000 Mb/s。本文所述方法是基于vxlan的網絡模型,虛擬實例的數據報文直接從所在的計算節點網卡發出,通過實體SDN交換機直接與實體終端通信,由于實驗中計算節點有三個,從圖中可以看出,吞吐量受虛擬實例規模影響較小。圖17是虛實網絡的丟包率與虛擬實例節點數量的關系曲線圖,在丟包率的測試中,通過在虛擬實例和實物終端之間不斷發送UDP報文并且不斷調整源主機的發送帶寬,從而確定網絡帶寬的瓶頸。當調整發送帶寬為940 Mb/s時,隨著虛擬實例節點規模增大,本文方法的丟包率略微增加,但是依然在較低的水平。

圖15 網絡時延與虛擬實例數量關系曲線Fig.15 Relationship between network delay and number of virtual instances

圖16 吞吐量與虛擬實例數量關系曲線Fig.16 Relationship between throughput and number of virtual instances

圖17 丟包率與虛擬實例數量關系曲線Fig.17 Relationship between packet loss rate and number of virtual instances
從通信時延、吞吐量、丟包率的測試結果來看,基于SDN的虛實融合網絡仿真具有很好的網絡性能,并且在虛擬實例節點數量增大的情況下,網絡性能優勢依然保持在較好的水平。
提出了一種基于SDN的虛實融合網絡仿真構建方法,通過實體SDN交換機,利用Ryu控制器將實物終端與OpenStack云平臺構建的虛擬實例進行融合組網,實驗證明基于SDN的方式能夠有效適用于大規模虛實網絡場景構建,在網絡連通、時延、吞吐量、丟包率等方面較傳統的方式均有較好的表現,該方法未將所有虛實流量全部通過云平臺中網絡節點進行傳輸,規避了網絡節點堵塞的可能,同時該方法基于vxlan實現網絡隔離,在確保虛實場景高可靠的同時也解決了規模受限的問題,且基于SDN的連接方式可以兼容除OpenStack之外的各類云平臺,具有較好的實際應用前景。
當實體終端與云平臺存在地域隔離時,在實現虛實網絡仿真場景構建中,還需要將異地實體終端或者通信系統與本地云平臺進行共同融合組網,下一步工作將主要解決以下兩個方面。
(1)實現異地設備的跨域融合組網,構建多地兼容的虛實融合網絡仿真實驗場。
(2)實現不同云平臺之間的多云組網,完成更大規模或者不同功能云平臺之間的融合組網,為網絡攻防演練提供更加復雜、更加逼真的仿真環境。