陳 宇，韓久江，劉 建，鮮 明，王會梅，張宇翔

國防科技大學(xué) 電子科學(xué)學(xué)院，長沙 410073

網(wǎng)絡(luò)仿真實驗場已經(jīng)成為網(wǎng)絡(luò)安全領(lǐng)域的一項重要科學(xué)裝置，能夠在安全可控的環(huán)境下為網(wǎng)絡(luò)空間行為的觀察、測量與分析提供支撐手段，為網(wǎng)絡(luò)攻防行為的測試與評估、網(wǎng)絡(luò)安全工具的測試與驗證、專業(yè)人員的技戰(zhàn)術(shù)訓(xùn)練演練提供靈活高效的軟硬件基礎(chǔ)設(shè)施。目前，主流的網(wǎng)絡(luò)仿真實驗場主要依賴數(shù)字仿真、虛擬化等技術(shù)構(gòu)建虛擬環(huán)境中的仿真實體，然而考慮到真實的網(wǎng)絡(luò)空間中設(shè)備復(fù)雜異構(gòu)、廠家來源多樣，而且某些設(shè)備（如密碼機、專用設(shè)備等）不存在虛擬仿真模型或者鏡像、某些復(fù)雜終端（如各類涉密目標(biāo)信息系統(tǒng)、定制化的特殊終端）難以進行虛擬仿真構(gòu)建等問題，迫切需要將實體終端與虛擬網(wǎng)絡(luò)進行靈活集成，共同構(gòu)建虛實融合的網(wǎng)絡(luò)仿真實驗場，為網(wǎng)絡(luò)攻防演練提供高逼真的場景環(huán)境。

軟件定義網(wǎng)絡(luò)是近些年新興的一種網(wǎng)絡(luò)技術(shù)，其通過控制層面與數(shù)據(jù)轉(zhuǎn)發(fā)層面的相互分離，為網(wǎng)絡(luò)設(shè)備提供基于硬件基礎(chǔ)的轉(zhuǎn)發(fā)層面和基于軟件控制的控制平面[1-2]，通過SDN控制器實現(xiàn)對全域網(wǎng)絡(luò)的控制、管理。鑒于SDN管控分離的特點，網(wǎng)絡(luò)便具備了更好的靈活性和可拓展性。

文章提出一種基于SDN的虛實融合網(wǎng)絡(luò)仿真實驗場構(gòu)建方法，其核心思想是實現(xiàn)網(wǎng)絡(luò)仿真場景構(gòu)建中虛擬實例與實體終端的共同組網(wǎng)，使得構(gòu)建的網(wǎng)絡(luò)仿真場景更加得全面、逼真，更好地滿足網(wǎng)絡(luò)安全實驗需求。實驗發(fā)現(xiàn)，基于SDN的網(wǎng)絡(luò)仿真實驗場構(gòu)建方法能夠快速實現(xiàn)虛實融合場景的構(gòu)建，相比于傳統(tǒng)的構(gòu)建方法，能夠滿足大規(guī)模復(fù)雜網(wǎng)絡(luò)場景生成，并有效規(guī)避網(wǎng)絡(luò)節(jié)點鏈路堵塞等現(xiàn)象。通過SDN的方式將實體終端接入虛擬網(wǎng)絡(luò)環(huán)境中，可以有效降低復(fù)雜網(wǎng)絡(luò)的構(gòu)建成本，實現(xiàn)網(wǎng)絡(luò)規(guī)模靈活擴展、網(wǎng)絡(luò)仿真真實有效。

文章的主要貢獻包括三個方面：

（1）基于SDN，提出了一種虛實融合網(wǎng)絡(luò)仿真實驗場構(gòu)建方法，并設(shè)計開發(fā)了一套用于虛實融合網(wǎng)絡(luò)仿真的原型系統(tǒng)。

（2）基于Ryu控制器，提出了一種流表生成算法，實現(xiàn)虛實設(shè)備間的互聯(lián)互通。

（3）通過實驗證明所述基于SDN的虛實融合網(wǎng)絡(luò)仿真實驗場構(gòu)建方法與流表生成算法的有效可行。

1 相關(guān)介紹

進入新世紀(jì)以來，隨著網(wǎng)絡(luò)規(guī)模逐步增大、網(wǎng)絡(luò)結(jié)構(gòu)越發(fā)復(fù)雜、網(wǎng)絡(luò)需求日益劇增，對網(wǎng)絡(luò)的靈活性要求也不斷提高，SDN解決了傳統(tǒng)網(wǎng)絡(luò)架構(gòu)復(fù)雜、結(jié)構(gòu)分散等問題，突出了網(wǎng)絡(luò)靈活性。SDN是斯坦福大學(xué)Nick教授在2008年提出的，在傳統(tǒng)的TCP/IP網(wǎng)絡(luò)中，數(shù)據(jù)平面與控制平面具有緊密耦合的特點，針對不同的網(wǎng)絡(luò)架構(gòu)都必須進行定制化的網(wǎng)絡(luò)架構(gòu)構(gòu)建，導(dǎo)致網(wǎng)絡(luò)后期維護復(fù)雜、成本巨大、，且對于如今用戶更多功能、更加靈活、更復(fù)雜多變的網(wǎng)絡(luò)需求明顯顯得力不從心，所面臨的現(xiàn)實問題和業(yè)務(wù)挑戰(zhàn)持續(xù)增大。SDN則更好地適應(yīng)了網(wǎng)絡(luò)發(fā)展趨勢，采用分層思想，將網(wǎng)絡(luò)的數(shù)據(jù)平面和控制平面完全解耦分離[3-4]，SDN是一種新型網(wǎng)絡(luò)體系結(jié)構(gòu)，是網(wǎng)絡(luò)功能虛擬化的一種實現(xiàn)方式。如圖1所示，SDN架構(gòu)從上往下可以分為應(yīng)用層、控制層、基礎(chǔ)設(shè)施層，應(yīng)用層運行著大量的應(yīng)用與軟件，控制層是整個SDN架構(gòu)的核心，基礎(chǔ)設(shè)施層由基礎(chǔ)物理設(shè)備組成，用于數(shù)據(jù)處理。在分層結(jié)構(gòu)中，控制層通過提供北向接口和南向接口分別實現(xiàn)與應(yīng)用層和基礎(chǔ)設(shè)施層的通信，通過北向接口對接運營商的業(yè)務(wù)應(yīng)用，便于維護人員通過編程的方式實現(xiàn)網(wǎng)絡(luò)部署等服務(wù)；而通過南向接口可實現(xiàn)對數(shù)據(jù)平面網(wǎng)絡(luò)設(shè)備的集中控制。因此SDN架構(gòu)最突出的特點便體現(xiàn)在直接可編程、集中化管控、開放兼容等方面。

圖1 SDN架構(gòu)Fig.1 Structure of SDN

隨著SDN技術(shù)的發(fā)展，SDN控制器也已經(jīng)較為成熟多樣，呈現(xiàn)出開源與商用SDN控制器并存的現(xiàn)狀，較為常用的SDN控制器有Ryu、NOX、FloodLight、Open-Daylight[5]。其中，Ryu控制器因為具有更佳的輕量級優(yōu)勢，基于Python實現(xiàn)的代碼更靈活簡潔，同時提供了各種規(guī)范定義的API接口、網(wǎng)絡(luò)組件等，也可支持多種實體和虛擬交換機，因而得到了廣泛的應(yīng)用。Ryu控制器主要由app、base、cmd、contrib、controller、lib、ofproto、services、tests、topology等組件構(gòu)成[5]，基于特定需求實現(xiàn)特定功能，只需結(jié)合上述組件構(gòu)建自定義的app即可，因此在實驗過程中便于開發(fā)人員進行快速的創(chuàng)建、管理和應(yīng)用。

OpenFlow協(xié)議是SDN眾多南向接口協(xié)議中最為出名、應(yīng)用最廣的協(xié)議[6-7]，如表1所示，一條OpenFlow流表項包含Match Fields、Priority、Instructions、Counters等基本字段、條件字段和動作字段[8]，其中Match Fields的主要作用是在流表項中進行規(guī)則匹配，可用于匹配in_port、dl_dst、dl_src、vlan、tun_id等關(guān)鍵報文字段；Priority定義了流表的優(yōu)先級，流表在處理報文時按照流表優(yōu)先級的高低依次進行報文處理；Instructions則為流表的動作指令集，通過一系列的Instructions定義流表的具體執(zhí)行行為action，如執(zhí)行output、drop、push_vlan、pop_vlan、set_field→tun_id等動作，而且在Instructions指令集中可以包含多種指令類型，通過一系列的action后才完成數(shù)據(jù)報文的處理[9]。

表1 流表項的部分組成情況Table 1 Composition of partial OpenFlow table

OVS（Open vStich）在SDN虛擬交換機中最具影響力、使用最廣泛，已經(jīng)廣泛應(yīng)用于商業(yè)界和學(xué)術(shù)界，尤其是隨著近些年云產(chǎn)品規(guī)模的高速發(fā)展，OVS已經(jīng)成熟運用于各類云平臺中。在云平臺中，對于多租戶的各類場景，租戶對網(wǎng)絡(luò)的需求多種多樣，且隨時都會進行不同的增、刪、改，傳統(tǒng)的網(wǎng)絡(luò)管理方式基本上需要管理人員不斷地手動維護和操作，很難滿足云平臺的網(wǎng)絡(luò)需求，因此基于SDN實現(xiàn)網(wǎng)絡(luò)虛擬化、自動化、靈活化后，能更好地滿足云平臺的網(wǎng)絡(luò)需求?；谠破脚_的虛擬資源編排能力，實現(xiàn)網(wǎng)絡(luò)攻防訓(xùn)練場景的快速構(gòu)建，是當(dāng)前網(wǎng)絡(luò)仿真實驗場的主流技術(shù)方案。OpenStack作為主流的開源云平臺，已廣泛應(yīng)用于各行各業(yè)，基于OpenStack云平臺定制化構(gòu)建網(wǎng)絡(luò)仿真實驗場，生成各類網(wǎng)絡(luò)安全實驗場景也已成為目前網(wǎng)絡(luò)仿真實驗研究中最常用的手段。在OpenStack云平臺中，每臺節(jié)點的OVS虛擬交換機共有br-tun、br-int、br-ex三個虛擬網(wǎng)橋，其中br-tun是隧道網(wǎng)橋，基于隧道技術(shù)的vxlan和GRE網(wǎng)絡(luò)則是使用該網(wǎng)橋進行通信[10]，br-int是集成網(wǎng)橋，網(wǎng)絡(luò)場景生成的所有實例都將通過網(wǎng)卡等虛擬設(shè)備與集成網(wǎng)橋進行連接，br-ex則是用于連接外部網(wǎng)絡(luò)的網(wǎng)橋。

2 研究動機與問題陳述

在進行網(wǎng)絡(luò)仿真場景生成的時候，不僅云平臺內(nèi)部需要構(gòu)建復(fù)雜多樣的拓撲環(huán)境，而且還經(jīng)常需要將某些實體終端集成于虛擬網(wǎng)絡(luò)中，共同構(gòu)建虛實融合的網(wǎng)絡(luò)仿真實驗場場景[11]。云平臺自帶的技術(shù)方案主要是通過網(wǎng)絡(luò)節(jié)點的br-ex網(wǎng)橋，搭建vlan或著flat網(wǎng)絡(luò)實現(xiàn)云平臺中虛擬實例與外界實體終端的通信互連，但基于上述兩種方式分別存在以下不足：vlan使用12 bit標(biāo)記的vlan_id，使得該技術(shù)最多只能夠支持4 096個vlan號，不利于同時構(gòu)建大規(guī)模網(wǎng)絡(luò)場景；而flat網(wǎng)絡(luò)又必須滿足每一個flat網(wǎng)絡(luò)獨占一個網(wǎng)絡(luò)節(jié)點的物理網(wǎng)卡，故受限于網(wǎng)絡(luò)節(jié)點的物理網(wǎng)卡數(shù)量，在實際生產(chǎn)測試環(huán)境中，局限性和弊端性較大，同時上述兩種方式均需要通過網(wǎng)絡(luò)節(jié)點實現(xiàn)與外界的通信，會導(dǎo)致大流量數(shù)據(jù)傳輸時，網(wǎng)絡(luò)節(jié)點存在阻塞的現(xiàn)象。

針對上述問題，部分學(xué)者也進行了虛實融合的研究，如：文獻[12]結(jié)合OpenStck研究了多粒度虛擬化技術(shù)及虛實網(wǎng)絡(luò)一體化融合技術(shù)，實物網(wǎng)絡(luò)通過Cisco邊界路由器接入OpenStack集群，通過BGP（external BGP，EBGP）協(xié)議與虛擬路由器實現(xiàn)有機融合組網(wǎng)，但是在實現(xiàn)過程中需要先在OpenStack數(shù)據(jù)庫中查詢虛擬實例網(wǎng)絡(luò)ID，再結(jié)合查找對應(yīng)的vlan號后，才能進行相應(yīng)配置與連通，不利于實際應(yīng)用，且所有實體網(wǎng)絡(luò)數(shù)據(jù)也都是通過OpenStck網(wǎng)絡(luò)節(jié)點與OpenStck集群中虛擬實例進行連通；文獻[13]通過MPI技術(shù)實現(xiàn)了實體終端靈活接入NS3網(wǎng)絡(luò)仿真平臺，但其實體終端與仿真實例進行通信時，需要進行真實報文與虛擬報文的重構(gòu)轉(zhuǎn)發(fā)，結(jié)構(gòu)復(fù)雜，不適用于大規(guī)模網(wǎng)絡(luò)場景的仿真；文獻[14]分別針對單實體終端和多網(wǎng)段實體終端提出了基于FloatingIP和基于路由節(jié)點的方式實現(xiàn)虛實融合，基于FloatingIP的方式造成了底層物理資源的大量消耗，基于路由節(jié)點的方式同樣未能解決大規(guī)模OpenStck集群中網(wǎng)絡(luò)節(jié)點通信瓶頸的問題；文獻[15]通過將OpenStck中網(wǎng)絡(luò)節(jié)點作為虛實互聯(lián)服務(wù)器，由于受限于服務(wù)器網(wǎng)卡數(shù)量，便通過增加網(wǎng)絡(luò)節(jié)點的數(shù)量和相應(yīng)的網(wǎng)卡數(shù)量來增加實物終端接入的數(shù)量，該方法對接了OpenStack中Neutron數(shù)據(jù)庫和OVS中ovs-db數(shù)據(jù)庫，通過在Neutron數(shù)據(jù)庫建立虛實互聯(lián)的映射表，借助虛擬路由器實現(xiàn)了通連，但存在邏輯復(fù)雜、難以進行大規(guī)模自動化快速部署等問題。

上述研究工作雖然都實現(xiàn)了實體終端與虛擬實例的共同組網(wǎng)，但是卻存在不支持大規(guī)模網(wǎng)絡(luò)場景、結(jié)構(gòu)復(fù)雜、不能適用于實際環(huán)境、容易出現(xiàn)通信瓶頸造成鏈路阻塞等問題。因此采取一種部署簡便、高效、靈活、安全、適用于大規(guī)模網(wǎng)絡(luò)場景構(gòu)建的方式實現(xiàn)網(wǎng)絡(luò)仿真實驗場中虛擬實例與實體終端的互聯(lián)互通、從任意位置接入后可共同組網(wǎng)構(gòu)建融合仿真場景已成為一種迫切需求。為滿足大規(guī)模網(wǎng)絡(luò)場景構(gòu)建需求，設(shè)計采取vxlan網(wǎng)絡(luò)而并非flat或者vlan網(wǎng)絡(luò)；為實現(xiàn)部署靈活、高效，采取基于SDN的方式，利用控制器實現(xiàn)虛實設(shè)備間的靈活組網(wǎng)；為規(guī)避由于云平臺網(wǎng)絡(luò)節(jié)點的通信瓶頸造成鏈路堵塞，采取將實體SDN交換機與各個計算節(jié)點的虛擬OVS交換機分別搭建vxlan隧道，實現(xiàn)多條虛實鏈路的互聯(lián)互通，從根本上杜絕了由網(wǎng)絡(luò)節(jié)點造成通信堵塞的可能。

3 基于SDN的虛實網(wǎng)絡(luò)架構(gòu)設(shè)計

主要介紹基于SDN軟硬件交換機實現(xiàn)虛實融合網(wǎng)絡(luò)仿真實驗場構(gòu)建，該設(shè)計依賴overlay網(wǎng)絡(luò)，通過搭建vxlan隧道實現(xiàn)實體終端的接入。Vxlan網(wǎng)絡(luò)具有和vlan網(wǎng)絡(luò)相似的功能，能夠提供二層的以太網(wǎng)服務(wù)，但vxlan相較于vlan卻具備更好的靈活性和擴展性，其采取24 bit標(biāo)記vxlan_id，能夠支持更多的二層網(wǎng)絡(luò)，達到1 600多萬個二層網(wǎng)段，因此能夠滿足大規(guī)模復(fù)雜云平臺中網(wǎng)絡(luò)場景構(gòu)建。

3.1 云平臺中虛擬實例數(shù)據(jù)走向

在OVS的云平臺中，虛擬實例的數(shù)據(jù)包傳輸會經(jīng)過一系列的虛擬網(wǎng)橋設(shè)備，下面以計算節(jié)點中虛擬實例數(shù)據(jù)包走向進行詳細描述。

如圖2所示，云平臺中虛擬實例通過虛擬網(wǎng)卡等設(shè)備，將數(shù)據(jù)包通過OVS的br-int網(wǎng)橋傳送至br-tun網(wǎng)橋，當(dāng)數(shù)據(jù)包到達OVS的br-tun網(wǎng)橋時，會根據(jù)網(wǎng)橋中多級OpenFlow流表規(guī)則進行轉(zhuǎn)發(fā)，其流表轉(zhuǎn)發(fā)規(guī)則如圖3所示。

圖2 實例數(shù)據(jù)走向Fig.2 Instance flow direction

圖3 流表間的走向Fig.3 Direction of OpenFlow

圖3中各個OpenFlow流表的功能分別為：

table0：做分流處理，根據(jù)報文來源是云平臺內(nèi)部的br-int網(wǎng)橋或云平臺外部（外部發(fā)送過來的數(shù)據(jù)是指數(shù)據(jù)由其余節(jié)點或設(shè)備傳輸至本節(jié)點，并非本節(jié)點中虛擬實例通過br-int網(wǎng)橋傳輸?shù)臄?shù)據(jù)報文），分別轉(zhuǎn)發(fā)至不同的流表作后續(xù)處理，對于內(nèi)部br-int網(wǎng)橋發(fā)送過來的數(shù)據(jù)報文則轉(zhuǎn)發(fā)至table2處理，對于外部發(fā)送過來的數(shù)據(jù)報文則轉(zhuǎn)發(fā)至table4處理；

table2：對于虛擬實例準(zhǔn)備向外發(fā)送的數(shù)據(jù)報文，若是單播包則轉(zhuǎn)至table20，若是多播包則轉(zhuǎn)至table22處理；

table3：將滿足該流表匹配條件的數(shù)據(jù)包直接丟棄；

table4：用于處理外部發(fā)送過來的數(shù)據(jù)報文，具體為剝除vxlan的tun-id，添加vlan tag，實現(xiàn)云平臺內(nèi)部vxlan與vlan的映射轉(zhuǎn)換后轉(zhuǎn)至table10進行處理；

table10：該流表是一條自學(xué)習(xí)流表，實現(xiàn)數(shù)據(jù)報文中mac地址表等的學(xué)習(xí)，并將學(xué)習(xí)到的內(nèi)容放到table20中；

table20：根據(jù)報文的匹配域（vlan、目的mac等），剝離vlan_id，添加vxlan的tun-id，并從指定的vxlan port轉(zhuǎn)發(fā)出去，若未能實現(xiàn)相應(yīng)的匹配，則轉(zhuǎn)至table22進行處理；

table22：同樣是根據(jù)報文的匹配域（vlan、目的mac等），剝離vlan_id，添加vxlan的tun-id，然后進行泛洪廣播，將數(shù)據(jù)報文發(fā)送至所有的vxlan隧道中，實現(xiàn)數(shù)據(jù)報文在云平臺中不同節(jié)點間的傳輸。通過上述OpenFlow流表的轉(zhuǎn)發(fā)規(guī)則，則實現(xiàn)了云平臺中各個虛擬實例之間的相互通信。

3.2 基于SDN的虛實融合網(wǎng)絡(luò)仿真實驗場系統(tǒng)構(gòu)建

3.2.1 系統(tǒng)架構(gòu)

通過上節(jié)虛擬實例之間數(shù)據(jù)走向的分析可知，將實體交換機與云平臺中計算節(jié)點的br-tun網(wǎng)橋通過vxlan隧道進行連接，便能實現(xiàn)實體終端與虛擬實例融合組網(wǎng)通信。為實現(xiàn)簡便、高效、靈活、安全地將實體終端與云平臺中虛擬實例共同組網(wǎng)構(gòu)建高逼真的網(wǎng)絡(luò)仿真實驗場景，采取基于SDN的方式，實現(xiàn)實體終端的接入，構(gòu)建虛實融合網(wǎng)絡(luò)，其系統(tǒng)架構(gòu)如圖4所示。系統(tǒng)架構(gòu)自下而上分別是硬件層、平臺層、中間邏輯層、用戶交互層，硬件層主要通過服務(wù)器、實體SDN交換機等為整個系統(tǒng)搭建硬件環(huán)境支撐；通過硬件構(gòu)建出的OpenStack云平臺、SDN控制器、數(shù)據(jù)庫等組成了平臺層，為中間邏輯層奠定軟件環(huán)境基礎(chǔ)；中間邏輯層通過與用戶交互層的交互獲得繪制和配置好的拓撲信息，再通過調(diào)用平臺層的軟件資源進行邏輯功能的實現(xiàn)。

圖4 系統(tǒng)架構(gòu)Fig.4 System architecture

系統(tǒng)各個模塊間的詳細功能如下所述：

用戶交互層通過前端WEB交互界面實現(xiàn)虛實網(wǎng)絡(luò)場景的拓撲構(gòu)建，其中虛擬資源信息注冊模塊主要提供OpenStack云平臺中虛擬實例的構(gòu)建要素，如鏡像名、實例大小等資源信息，可在生成具體實例時進行選擇；實物設(shè)備信息注冊模塊主要是進行實體終端的注冊入庫，如型號、操作系統(tǒng)、功能和在實體SDN交換機上連接情況等；虛實融合網(wǎng)絡(luò)拓撲繪制模塊主要用于構(gòu)建具體的網(wǎng)絡(luò)實驗場景，通過與虛擬資源信息注冊模塊和實物設(shè)備信息注冊模塊的交互，指定繪制的拓撲場景具體使用的虛擬實例和實體終端信息；虛實融合網(wǎng)絡(luò)參數(shù)配置模塊主要用于虛擬實例的磁盤、CPU、IP等參數(shù)的配置，即將繪制出的場景實例進行具體化配置；虛實網(wǎng)絡(luò)場景生成模塊主要通過與用戶交互層中各個模塊的交互，獲取繪制和配置的拓撲場景，根據(jù)配置好的網(wǎng)絡(luò)拓撲，進行拓撲解析，調(diào)用OpenStack后臺資源按照繪制和配置的網(wǎng)絡(luò)拓撲生成相應(yīng)的虛擬實例；虛實融合處理模塊則主要是結(jié)合SDN控制器實現(xiàn)相應(yīng)的功能，其中虛實信息查詢模塊將查詢到的實體終端在拓撲中所屬vxlan信息反饋給流表構(gòu)造模塊，流表構(gòu)造模塊和流表下發(fā)模塊通過與虛實信息查詢模塊的交互，結(jié)合相應(yīng)的算法實現(xiàn)各級流表的構(gòu)造下發(fā)，流表動作執(zhí)行模塊則根據(jù)下發(fā)的流表執(zhí)行相應(yīng)的具體操作，如數(shù)據(jù)包的組播、丟棄、打vxlan_tag標(biāo)記后再轉(zhuǎn)發(fā)等。

具體生成一次虛實融合網(wǎng)絡(luò)場景的流程圖如圖5所示，用戶交互層根據(jù)虛擬資源信息注冊模塊和實物設(shè)備信息注冊模塊的注冊信息，繪制網(wǎng)絡(luò)拓撲場景，主要繪制虛擬實例和實體終端組網(wǎng)情況；拓撲繪制完成后需要對虛擬實例進行詳細參數(shù)配置，確定實例的鏡像類型、網(wǎng)段參數(shù)等，如對每個實例確定使用Ubuntu或者Windows鏡像，明確虛擬CPU、磁盤等大小。用戶交互層完成上述拓撲繪制和配置后，將所得到的場景信息由中間邏輯層進行具體處理。其中網(wǎng)絡(luò)拓撲解析模塊首先處理場景描述中的網(wǎng)絡(luò)部分信息，調(diào)用OpenStack的Neutron_API逐個生成虛擬網(wǎng)絡(luò)、子網(wǎng)、端口等，再根據(jù)拓撲解析得到的實例信息，調(diào)用Nova_API，通過Nova_scheduler和Nova_compute服務(wù)完成虛擬實例創(chuàng)建請求，再通過調(diào)用OpenStack中Glance和Neutron等組件，結(jié)合解析得到的實例配置信息完成虛擬實例的創(chuàng)建。至此則完成了虛實融合場景構(gòu)建中虛擬實例和網(wǎng)絡(luò)環(huán)境的生成，接下來主要介紹通過虛實融合處理模塊完成虛實鏈路的互聯(lián)互通，首先通過調(diào)用Neutron數(shù)據(jù)庫獲取場景相應(yīng)的vxlan_id信息、具體實體終端需要融入的虛擬網(wǎng)段等，將虛擬實例與實體終端間的報文數(shù)據(jù)上報SDN控制器進行解析處理，結(jié)合流表生成算法進行OpenFlow流表的構(gòu)造并下發(fā)至實體SDN交換機，實體SDN交換機則依據(jù)流表指令完成相應(yīng)的處理動作打通鏈路，實現(xiàn)虛實互通、融合組網(wǎng)，后面將詳細介紹完成虛實融合中鏈路打通和流表生成算法的關(guān)鍵技術(shù)。

3.2.2 系統(tǒng)各模塊交互關(guān)系

圖6顯示了基于SDN的虛實融合網(wǎng)絡(luò)仿真實驗系統(tǒng)中各模塊之間的控制流信息。

圖6 系統(tǒng)模塊之間的控制流信息Fig.6 Control flow information between system modules

系統(tǒng)各模塊之間的控制流為順序執(zhí)行的邏輯流程。首先，虛實融合網(wǎng)絡(luò)拓撲繪制模塊和虛實融合網(wǎng)絡(luò)參數(shù)配置模塊作為系統(tǒng)的輸入端，通過繪制和配置拓撲得到構(gòu)建的網(wǎng)絡(luò)場景具體信息。將得到的網(wǎng)絡(luò)場景具體信息發(fā)送至虛擬網(wǎng)絡(luò)場景生成模塊，虛擬網(wǎng)絡(luò)場景生成模塊進行場景要素的解析，主要解析得到場景構(gòu)建的網(wǎng)段、實例的系統(tǒng)配置、端口連接情況等，解析后分別調(diào)用OpenStack的API生成對應(yīng)的虛擬網(wǎng)絡(luò)和虛擬實例等。虛實融合處理模塊再根據(jù)所生成的網(wǎng)絡(luò)信息，結(jié)合OpenStack的Neutron組件和SDN控制器完成流表的構(gòu)造與下發(fā)，虛擬實例與實體終端則根據(jù)下發(fā)流表所對應(yīng)的指令動作進行相關(guān)通信。

圖7顯示了基于SDN的虛實融合網(wǎng)絡(luò)仿真實驗系統(tǒng)中各模塊之間的數(shù)據(jù)流信息。

圖7 系統(tǒng)模塊之間的數(shù)據(jù)流信息Fig.7 Date flow information between system modules

系統(tǒng)管理員通過虛擬資源信息注冊模塊和實物設(shè)備信息注冊模塊，將虛擬資源信息和實物設(shè)備信息存入數(shù)據(jù)庫中。用戶通過虛實融合網(wǎng)絡(luò)拓撲繪制模塊，在WEB交互界面繪制虛實融合網(wǎng)絡(luò)拓撲場景，然后配置拓撲參數(shù)，完成拓撲參數(shù)配置后將場景具體信息存入數(shù)據(jù)庫中，如IP段、虛擬實例數(shù)量、端口及實體終端連接情況等。場景生成模塊讀取數(shù)據(jù)庫中存儲的場景信息后，生成具體的虛擬網(wǎng)絡(luò)和虛擬實例，同時將虛擬網(wǎng)絡(luò)和虛擬實例的具體生成信息存入數(shù)據(jù)庫中，如實例IP、實例mac、vxlan_id等。虛實融合處理模塊再通過讀取數(shù)據(jù)庫中vxlan_id、實體終端連接情況等數(shù)據(jù)，將其作為關(guān)鍵參數(shù)反饋至SDN控制器，SDN控制器依據(jù)得到的關(guān)鍵參數(shù)結(jié)合流表生成算法完成具體流表的構(gòu)造與下發(fā)。

3.3 基于SDN的虛實融合網(wǎng)絡(luò)仿真關(guān)鍵技術(shù)

上節(jié)所述系統(tǒng)架構(gòu)的具體物理連接圖如圖8所示。

圖8 基于SDN的虛實融合Fig.8 Virtual-real fusion based on SDN

3.3.1 構(gòu)造vxlan隧道

Vxlan隧道是整個虛實融合系統(tǒng)的橋梁，控制器對實體SDN交換機進行全權(quán)管控，通過vxlan隧道打通實體SDN交換機與云平臺各個計算節(jié)點OVS中br-tun隧道網(wǎng)橋之間的鏈路，這也是實現(xiàn)云平臺與實體終端連通交互的前提。具體實現(xiàn)步驟為：

步驟1在云平臺各個計算節(jié)點OVS虛擬交換機的br-tun隧道網(wǎng)橋和實體SDN交換機上分別增加相應(yīng)的vtep_port端口對。

步驟2通過OVS相關(guān)命令，利用步驟1中的vtep_port端口對，創(chuàng)建vxlan隧道，實現(xiàn)實體SDN交換機與云平臺各個計算節(jié)點OVS中br-tun隧道網(wǎng)橋的連通，進而便實現(xiàn)了云平臺中虛擬實例與實體終端的鏈路連通。

步驟3在云平臺各個計算節(jié)點的br-tun隧道網(wǎng)橋中添加守護進程，將新增加的vtep_port信息添加進入br-tun隧道網(wǎng)橋的各級流表中。

3.3.2 流表構(gòu)造與下發(fā)

上述系統(tǒng)架構(gòu)中最為核心的是虛實融合處理模塊，其中流表的構(gòu)造與下發(fā)是整個模塊中最重要的一個部分，其核心則主要在于虛實網(wǎng)絡(luò)信息的查詢和流表構(gòu)造的相應(yīng)算法。SDN控制器流表構(gòu)造和下發(fā)的具體過程如算法1所示，首先SDN實體交換機接收到數(shù)據(jù)報文后先判定是否有可匹配的流表項，如果無可匹配的流表，則觸發(fā)Packet-in機制，以Packet-in消息的形式將數(shù)據(jù)報文上傳至控制器?？刂破鹘邮盏絇acket-in消息形式的報文后，進行相關(guān)的關(guān)鍵信息提取，建立自學(xué)習(xí)機制，通過對in_port、eth_src、eth_dst、tunnel_id等關(guān)鍵字段的解析學(xué)習(xí)，將數(shù)據(jù)報文走向分為從虛擬實例發(fā)送至實體終端和從實體終端發(fā)送至虛擬實例兩個方向，結(jié)合虛實網(wǎng)絡(luò)信息查詢模塊的結(jié)果，分別向?qū)嶓wSDN交換機構(gòu)造和下發(fā)不同優(yōu)先級的OpenFlow流表，實現(xiàn)實體SDN交換機基于不同優(yōu)先級的流表進行數(shù)據(jù)報文的處理。具體如算法1所示：

算法1SDN控制器流表構(gòu)造下發(fā)算法

輸入：Packet-in消息；

輸出：OpenFlow流表項。

//未匹配到流表且數(shù)據(jù)為arp報文則上報控制器

1.If not match && protocols==arp：

//報文是實體終端發(fā)送的廣播包

2.If in_port from Physical and type=Flood：

//學(xué)習(xí)報文的輸入端口、mac等信息

3.Learn（in_port，mac）

//通過數(shù)據(jù)庫獲取vxlan_id信息

4.Request.ge（tvxlan）

//區(qū)分交換機端口進行直接轉(zhuǎn)發(fā)和通過隧道轉(zhuǎn)發(fā)組播流表構(gòu)造

5.SetGroup table[setAction（forward），SetAction(setTun_id，forward）]

//下發(fā)優(yōu)先級為A的流表

6.SetFlowEntry（setGroup table，priority=A）

//若報文是實體終端發(fā)送給虛擬實例的非廣播包

7.Else：

8.Request.ge（tvxlan）

//進行隧道轉(zhuǎn)發(fā)流表構(gòu)造

9.SetAction（setTun_id，forward）]）；

//下發(fā)優(yōu)先級為B的流表

10.SetFlowEntry（setAction，priority=B）

//報文由虛擬實例通過隧道發(fā)送

11.If in_port from OpenStack && vxlan in pro-tocols：

12.If type!==Flood：

//學(xué)習(xí)報文中源端口、mac、vxlan_id等信息

13.Learn（in_port，mac，vni）

14.SetAction（forward）；

//下發(fā)優(yōu)先級同樣為B的流表

15.SetFlowEntry（setAction，priority=B）；

16.Else：

17.SetAction（Flood）；

//下發(fā)優(yōu)先級為C的流表

18.SetFlowEntry（setAction，priority=C）

19.Else：

20.Drop

4 實驗與結(jié)果

將通過大量的仿真實驗來測試所提出的虛實融合方案性能表現(xiàn)，從連通性、隔離性、發(fā)包延遲、吞吐量等方面對方案進行評估。

4.1 實驗設(shè)置

使用多節(jié)點部署的OpenStack云平臺作為本地網(wǎng)絡(luò)仿真實驗平臺，使用盛科V530型號的交換機作為實體SDN交換機，使用Ryu控制器作為SDN控制器，用于云平臺和盛科交換機間的網(wǎng)絡(luò)管理。通過四臺服務(wù)器搭建分布式部署的OpenStack云平臺，其中一臺控制和網(wǎng)絡(luò)復(fù)合節(jié)點的管理網(wǎng)段IP為192.168.36.50，三臺計算節(jié)點的管理網(wǎng)段IP為192.168.36.51、192.168.36.52、192.168.36.53。以臺式終端作為實體終端通過盛科交換機實現(xiàn)與OpenStack云平臺的融合組網(wǎng)。

4.2 實驗結(jié)果

在實驗中，通過虛實融合WEB用戶交互界面進行虛實融合網(wǎng)絡(luò)仿真實驗場景的拓撲繪制，通過生成的不同場景進行不同實驗驗證。

4.2.1 虛實節(jié)點連通性與真實性測試

面向圖9的虛實網(wǎng)絡(luò)拓撲，完成虛實融合網(wǎng)絡(luò)仿真實驗場景的構(gòu)建，將三臺實物終端連接至實體SDN交換機，虛擬實例均設(shè)置為192.168.16.0/24網(wǎng)段，實體終端IP分別設(shè)置為192.168.16.197、192.168.16.198、192.168.16.199，首先從虛擬實例節(jié)點ping實物終端節(jié)點，顯示ping成功；然后重新進行上述場景生成，再從實物終端節(jié)點ping各個虛擬實例節(jié)點，也顯示ping成功，通過Wireshark抓包結(jié)果如圖10所示。

圖9 拓撲繪制Fig.9 Topology drawing

圖10 終端和實例分別采集的報文Fig.10 Packets collected by physic and instances

抓包結(jié)果證明了虛實融合網(wǎng)絡(luò)鏈路的連通性，其次通過對虛擬實例數(shù)據(jù)報文和實體終端數(shù)據(jù)報文的解析對比，可以發(fā)現(xiàn)兩種數(shù)據(jù)報文的大小、內(nèi)容、類型等完全一致，這說明虛實融合網(wǎng)絡(luò)的數(shù)據(jù)報文在虛擬網(wǎng)絡(luò)中的傳輸結(jié)果與實體網(wǎng)絡(luò)中的傳輸結(jié)果完全一致，表明了虛實網(wǎng)絡(luò)下數(shù)據(jù)的真實性。另外，無論是虛擬實例節(jié)點向?qū)嵨锝K端節(jié)點請求建立通信，還是實物終端節(jié)點向虛擬實例節(jié)點請求建立通信，都可以建立正常通信，證明了本文方案的有效性。同時使用Zenmap探測軟件，在實物終端節(jié)點上進行拓撲探測，可以清晰地顯示出云平臺中處于同網(wǎng)段的虛擬實例節(jié)點，也證明了虛實網(wǎng)絡(luò)數(shù)據(jù)鏈路層面的連通性。圖11中中心紅色節(jié)點為實物終端，周邊環(huán)繞的綠色節(jié)點為云平臺中的90個同網(wǎng)段的虛擬實例和實體終端。

圖11 Zenmap探測結(jié)果Fig.11 Result of Zenmap

表2為實體終端與隨機選取的六個虛擬實例連通測試結(jié)果。

表2 部分實例連通性測試結(jié)果Table 2 Results of some VMs’connectivity test

4.2.2 流表構(gòu)造結(jié)果正確性測試

根據(jù)4.2.1小節(jié)所述的虛實融合網(wǎng)絡(luò)仿真實驗場景，基于SDN控制器流表生成算法，設(shè)計了流表自動化配置代碼，首先從虛擬實例節(jié)點ping實物終端節(jié)點，Ryu控制器通過該算法會自動構(gòu)造和下發(fā)流表規(guī)則，虛實節(jié)點ping成功后，登錄實體SDN交換機查看交換機流表信息配置情況如圖12所示；在虛擬實例節(jié)點所在的計算節(jié)點服務(wù)器上，使用命令查看流表規(guī)則，結(jié)果如圖13所示。

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

圖13 計算節(jié)點部分流表Fig.13 Some OpenFlows of computing node

從上述流表信息可以看出，通過設(shè)計的流表構(gòu)造和下發(fā)算法，生成的流表可以使虛擬實例與實體終端實現(xiàn)虛實鏈路的無縫互通。

4.2.3 虛實融合網(wǎng)絡(luò)隔離性測試

在實際的網(wǎng)絡(luò)實驗中，往往會存在多個相同網(wǎng)絡(luò)配置參數(shù)的虛實網(wǎng)絡(luò)場景，它們分別屬于不同的vxlan網(wǎng)絡(luò)，但在這些不同場景中虛擬實例的IP屬于同一個網(wǎng)段，構(gòu)建了如圖14所示的拓撲來驗證方案的隔離性。其結(jié)合4.2.1小節(jié)所生成的網(wǎng)絡(luò)，再創(chuàng)建一個不同vxlan下的192.168.16.0/24的虛擬網(wǎng)絡(luò)，并生成多臺IP段為192.168.16.0/24的虛擬實例。兩個網(wǎng)絡(luò)的vxlan_id分別為vxlan100和vxlan200，實體終端1、2的IP設(shè)備分別為192.168.16.199、192.168.16.200，實體終端1、2通過流表實現(xiàn)隔離，為實現(xiàn)實體終端1與vxlan100的網(wǎng)絡(luò)互聯(lián)互通，實體終端2與vxlan200的網(wǎng)絡(luò)互聯(lián)互通，用戶交互層的前端頁面具體拓撲繪制如圖14所示。實驗隔離性測試結(jié)果如表3所示。

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

表3 隔離性測試結(jié)果Table 3 Result of isolation test

如圖14所示，在之前的流表算法自動構(gòu)造與下發(fā)的基礎(chǔ)上，場景中新增了一組除vxlan不同外，其余網(wǎng)段均相同的虛實融合網(wǎng)絡(luò)。表3的測試結(jié)果顯示，實體終端1只能與vxlan100的虛擬網(wǎng)絡(luò)相互連通，實體終端2只能與vxlan200的虛擬網(wǎng)絡(luò)相互連通，這是因為流表構(gòu)造與下發(fā)算法是依據(jù)vxlan_id作為關(guān)鍵字段進行處理的，通過構(gòu)造與下發(fā)的流表實現(xiàn)了不同虛擬網(wǎng)絡(luò)的相互隔離，證明了方案具有網(wǎng)絡(luò)隔離性，且具有實際可行性。

4.2.4 虛實融合網(wǎng)絡(luò)性能測試

為了驗證所述方案在虛實網(wǎng)絡(luò)中的實際網(wǎng)絡(luò)性能，在同一虛實網(wǎng)絡(luò)中生成不同數(shù)量的虛擬實例進行實驗測試。實驗的三臺計算節(jié)點服務(wù)器，配置均為16核256 GB，本次實驗構(gòu)建了一個虛擬網(wǎng)絡(luò)，在該網(wǎng)絡(luò)中仿真不同數(shù)量規(guī)模的虛擬實例節(jié)點，考慮到虛擬實例的配置參數(shù)對虛擬網(wǎng)絡(luò)仿真規(guī)模的影響，本次實驗時，將OpenStack中虛擬實例的Flavor配置參數(shù)分成三個等級，分別是?。≧AM=512 MB，Root Disk=5 GB）、中（RAM=2 GB，Root Disk=10 GB）、大（RAM=4 GB，Root Disk=20 GB），對小、中、大三種虛擬實例的數(shù)量規(guī)模比例選取為5∶3∶2，針對生成的不同數(shù)量規(guī)模的虛實網(wǎng)絡(luò)場景，分別從通信時延、吞吐量、丟包率等方面進行網(wǎng)絡(luò)性能測試，測試結(jié)果如圖15～17所示。

圖15是本文方法虛實網(wǎng)絡(luò)的通信時延與虛擬實例節(jié)點數(shù)量的關(guān)系曲線圖，針對每一種虛擬實例數(shù)量，均測試10次然后取平均值。從圖中可以看出隨著虛擬節(jié)點數(shù)量規(guī)模增大，本文方法的通信時延也略微增加，但總體上時延依然保持在極低的水平。圖16是虛實網(wǎng)絡(luò)的吞吐量與虛擬實例節(jié)點數(shù)量的關(guān)系曲線圖，針對每一種方法，同樣測試10次然后取平均值。由于實驗環(huán)境中服務(wù)器以及實物終端均為千兆網(wǎng)，所以在虛實網(wǎng)絡(luò)中，吞吐量最大應(yīng)接近1 000 Mb/s。本文所述方法是基于vxlan的網(wǎng)絡(luò)模型，虛擬實例的數(shù)據(jù)報文直接從所在的計算節(jié)點網(wǎng)卡發(fā)出，通過實體SDN交換機直接與實體終端通信，由于實驗中計算節(jié)點有三個，從圖中可以看出，吞吐量受虛擬實例規(guī)模影響較小。圖17是虛實網(wǎng)絡(luò)的丟包率與虛擬實例節(jié)點數(shù)量的關(guān)系曲線圖，在丟包率的測試中，通過在虛擬實例和實物終端之間不斷發(fā)送UDP報文并且不斷調(diào)整源主機的發(fā)送帶寬，從而確定網(wǎng)絡(luò)帶寬的瓶頸。當(dāng)調(diào)整發(fā)送帶寬為940 Mb/s時，隨著虛擬實例節(jié)點規(guī)模增大，本文方法的丟包率略微增加，但是依然在較低的水平。

圖15 網(wǎng)絡(luò)時延與虛擬實例數(shù)量關(guān)系曲線Fig.15 Relationship between network delay and number of virtual instances

圖16 吞吐量與虛擬實例數(shù)量關(guān)系曲線Fig.16 Relationship between throughput and number of virtual instances

圖17 丟包率與虛擬實例數(shù)量關(guān)系曲線Fig.17 Relationship between packet loss rate and number of virtual instances

從通信時延、吞吐量、丟包率的測試結(jié)果來看，基于SDN的虛實融合網(wǎng)絡(luò)仿真具有很好的網(wǎng)絡(luò)性能，并且在虛擬實例節(jié)點數(shù)量增大的情況下，網(wǎng)絡(luò)性能優(yōu)勢依然保持在較好的水平。

5 結(jié)束語

提出了一種基于SDN的虛實融合網(wǎng)絡(luò)仿真構(gòu)建方法，通過實體SDN交換機，利用Ryu控制器將實物終端與OpenStack云平臺構(gòu)建的虛擬實例進行融合組網(wǎng)，實驗證明基于SDN的方式能夠有效適用于大規(guī)模虛實網(wǎng)絡(luò)場景構(gòu)建，在網(wǎng)絡(luò)連通、時延、吞吐量、丟包率等方面較傳統(tǒng)的方式均有較好的表現(xiàn)，該方法未將所有虛實流量全部通過云平臺中網(wǎng)絡(luò)節(jié)點進行傳輸，規(guī)避了網(wǎng)絡(luò)節(jié)點堵塞的可能，同時該方法基于vxlan實現(xiàn)網(wǎng)絡(luò)隔離，在確保虛實場景高可靠的同時也解決了規(guī)模受限的問題，且基于SDN的連接方式可以兼容除OpenStack之外的各類云平臺，具有較好的實際應(yīng)用前景。

當(dāng)實體終端與云平臺存在地域隔離時，在實現(xiàn)虛實網(wǎng)絡(luò)仿真場景構(gòu)建中，還需要將異地實體終端或者通信系統(tǒng)與本地云平臺進行共同融合組網(wǎng)，下一步工作將主要解決以下兩個方面。

（1）實現(xiàn)異地設(shè)備的跨域融合組網(wǎng)，構(gòu)建多地兼容的虛實融合網(wǎng)絡(luò)仿真實驗場。

（2）實現(xiàn)不同云平臺之間的多云組網(wǎng)，完成更大規(guī)?；蛘卟煌δ茉破脚_之間的融合組網(wǎng)，為網(wǎng)絡(luò)攻防演練提供更加復(fù)雜、更加逼真的仿真環(huán)境。