第6章SDN實戰基礎案例6.1概述

6.2使用Wireshark抓取OpenFlow消息及相關內容分析6.3利用OpenDaylightYangUI工具下發流表6.4使用OpenFlow流表實現網絡負載均衡6.5基于OpenFlow1.3組表的驗證性實驗6.6SDN網關功能的實現6.7OpenDaylight集群實驗6.8小結復習思考題

本章以及下一章將結合SDN理論的基本知識，特別是OpenFlow協議中有關的技術規范給出若干個實例，這些實例能夠很好地幫助我們理解SDN的基本理論和OpenFlow協議。在開始SDN實戰之前，首先需要具備SDN環境，在投入相對不足的情況下，用戶完全可以自己動手DIY一個小型的SDN。

6.1概述

要想比較深入地了解SDN的網絡特點以及OpenFlow協議中有關概念，切實可行的方法是親自實踐一些典型的案例，這些案例有助于對一些基本概念的理解，例如動作集(ActionSet)與動作列表(ActionList)有何區別?

初學者往往很難理解，但是通過實驗就很容易理解這兩個概念的區別，即兩者中動作執行的順序不一樣，動作集中的動作是在流水線處理的最后一步執行的動作，而動作列表中的動作則是一旦流表項匹配數據包就立即執行該動作。特別對于初學者，除了仔細閱讀OpenFlow協議文檔外，有必要完成一些基本的SDN實驗案例，如同學習編程語言，總是從HelloWorld開始一樣，學習SDN知識同樣要從HelloWorld”開始，那么SDN技術的“HelloWorld”在哪里呢?毫無疑問，應該是如何配置流表并使流表能夠匹配相關的數據包以及改變數據包的轉發行為。

為此，我們將以循序漸進的方式介紹九個實戰案例，這些案例充分展示了SDN的特點，關于SDN可編程特點的案例將在下一章介紹。這些案例主要介紹如何分析OpenFlow各種消息，如何利用流表做到負載均衡，如何實現ARP代理服務器，如何實現DDOS攻擊防御，如何實現多控制器集群，以及如何實現SDN可編程等。

在開始SDN實戰前，首先需要搭建一個SDN環境，在硬件條件相對不足的情況下，建議采用Ubuntu+Mininet+OpenDaylight方式組建一個簡單的SDN。本書采用的是自制的SDN交換機和獨立的OpenDaylight控制器，主要的硬件設備有SDN交換機三臺(便于組網)以及控制器服務器兩臺。主要的軟件有:Ubuntu服務器軟件、OpenvSwitch(OVS)(支持OpenFlow1.3協議)虛擬交換機軟件、OpenDaylight鈹版本的控制器軟件、Iperf網絡性能測試工具、TomcatWeb服務器軟件以及JavaJDK工具等。

可以通過以下三種方法來配置SDN交換機(要求支持OpenFlow1.3協議):

(1)商品化的SDN交換機。目前市場上有一些廠商(如華三、盛科)已經制造出SDN交換機，設備性能較好，但是普遍反映價格較貴。

(2)在PC上安裝OpenvSwitch軟件。OpenvSwitch可以使計算機變成一個OpenFlow交換機，該方法性價比較好，同時性能也相對比較穩定，能夠滿足絕大多數實驗的網絡需求。

(3)使用Mininet模擬環境，可以搭建許多交換機，而且可以任意拓撲，但其性能依賴虛擬機的性能，無法滿足有些實驗的網絡需求。

本書采用上述第(2)種方式，自己DIY若干臺SDNOpenFlow交換機，由于PC機上網口比較少，外加網卡的插槽數量也是有限(1或2塊)，因此建議可以采用如圖6－1所示多網卡主板，該主板提供了6個網絡端口，并配有32G固態硬盤，在Linux操作系統上安裝OpenvSwitch軟件。

注意安裝OpenvSwitch軟件時應仔細閱讀安裝文檔，確保所需要的Linux操作系統版本與OpenvSwitch版本匹配，有關OpenvSwitch的安裝和運行請參考OpenvSwitch官方文檔，特別建議閱讀其中的FAQ(常見問答)文檔，該文檔能夠提供一些交換機的使用注意細節，如支持最新的OpenFlow版本是多少。SDN交換機的數量最好能配置2~3臺以便組成一個小型的SDN，本章6.6節使用2臺SDN交換機組成兩個不同網絡段的SDN，通過配置網關實現不同網段的主機相互通信。

圖6－1自制的SDN交換機

本章的SDN交換機基于Ubuntu14.04Linux操作系統，OpenvSwitch各版本支持的Linux內核如表6－1所示。

安裝完OpenvSwitch軟件后就可以在一臺獨立的服務器(或PC機)上安裝Open-Daylight控制器軟件，安裝OpenDaylight的步驟請參見OpenDaylight官網上的安裝手冊，圖6－2(a)和(b)是利用SDN交換機和普通交換機組成小型SDN的實物圖。建議安裝控制器的服務器內存不低于4G，配有固態硬盤，有條件的話可以采用機架式服務器。由于OpenvSwicth與OpenDaylight的安裝均有詳細的官方安裝手冊，因此不再給出詳細的安裝步驟。

SDN軟件安裝完成后,需要對SDN交換機進行必要的參數配置,以便SDN交換機能夠連接到SDN控制器。配置參數前首先需要熟悉一些在OpenvSwicth中常用的基本概念。

(1)Bridge。網橋代表一個以太網交換機,一個主機中可以創建一個或者多個網橋設備。

2)Port。這里的端口與物理交換機的端口概念類似,每個端口都隸屬于一個網橋。

(3)Interface。Interface指連接到Port的網絡接口設備,通常情況下Port和Interface是一對一的關系,只有在配置Port為bond模式后(所謂網卡bond模式,是指把多個物理網卡綁定為一個邏輯網卡),Port和Interface是一對多的關系。

(4)Controller。Controller指OpenFlow控制器,OpenvSwitch可以同時接受一個或者多個OpenFlow控制器的管理(多控制器集群模式)。

(5)Datapath。Datapath負責執行數據交換,也就是把從接收端口收到的數據包在流表中進行匹配,并執行匹配到的動作。

(6)FlowTable。每個Datapath都和一個流表關聯,當Datapath接收到數據之后,OpenvSwitch會在FlowTable中查找可以匹配的流表項,執行對應的操作,如轉發數據到另外的網絡出端口。

下面通過OpenvSwitch有關命令配置SDN交換機,并將SDN交換機連接到OpenDaylight控制器,連接成功后可以在OpenDaylightDLUX界面中看到交換機的拓撲結構。其步驟如下:

(1)首先創建一個網橋br0,命令如下:

ovs－vsctladd－brbr0

創建成功后通過命令ovs－vsctllist－br可以列出所有網橋。

(2)啟用或關閉網橋,命令如下:

ifconfigbr0up(啟用);ifconfigbr0down(關閉)

(3)向網橋br0上增加端口,命令如下:

add－portbr0ethx

其中,x為端口編號。這里的端口必須是SDN交換機存在的物理端口,如addportbr0eth0、add－portbr0eth1等。

(4)刪除網橋br0上的端口,命令如下:

del－portbr0ethx

其中,x為端口編號。例如,del－portbroeth0刪除eth0端口。

(5)將br0網橋連接至指定的控制器,命令如下:

ovs－vsctlset－controllerbr0tcp:<controllerIP>:<port>

其中,<controllerIP>填寫控制器的IP地址,<port>填寫端口號,端口號可以不寫,默認端口為6633。如ovs－vstctlset－controllerbr0tcp:192.168.3.6,其中,192.168.3.6為控制器的IP地址。

(6)查看br0連接控制器是否成功,命令如下:

ovs－vsctlshow

一旦SDN交換機成功連接上控制器,則會顯示“is_connected:true”字樣,如圖6－3所示,并能夠在OpenDayligtUI界面看到如圖6－4所示的交換機拓撲圖。

至此我們已經具備了一個比較理想的實戰環境,接下來就可以進行相關實戰案例,通過這些案例能夠進一步幫助我們了解SDN的概念和特點。圖6－3交換機連接控制器圖6－4連接交換機后的OpenDaylightWeb界面圖6－4連接交換機后的OpenDaylightWeb界面

6.2使用Wireshark抓取OpenFlow消息及相關內容分析

Wireshark是一款開源網絡協議分析軟件,具備很好的可視化和解碼功能,通過合理的抓取和過濾數據包,能夠幫助我們學習OpenFlow協議的信息交換過程和交換內容,加深對OpenFlow消息的理解,從而更透徹地看清SDN的本質特點。

6.2.1OpenFlow消息

根據OpenFlow協議規定,SDN交換機和控制器之間交換三類消息,即controller－to－switch(控制器到交換機)、asynchronous(異步)和symmetric(對稱)。controllertoswitch消息由控制器發起,用來直接管理、檢查交換機狀態,不強制交換機做出回應,包括features、configuration、modify_state、read_state、packet_out、barrier、role_request和asynchronous_configuration消息;Asynchronous消息由交換機發起,用于控制器更新網絡事件和交換機狀態的

改變,包括packet_in、flow_removed、port_status和error消息;symmetric類型的消息可由交換機或者控制器發起,包括hello、echo、experimenter三種消息。通過網絡抓包工具Wireshark抓取并分析這些消息有助于進一步理解OpenFlow協議的內容。

OpenFlow交換機規范的核心就是建立OpenFlow協議消息的結構體。所有結構體都是用填充和8字節來對齊,即所有結構體必須是8的倍數。所有消息都是以大端模式發送,所謂大端模式,即高字節存儲在低地址位置,低字節保存在高地址位置,反之則為小端模式,例如0x1223abcd的大端模式與小端分別如下所示:

其中,xid實際上就是一個標識該消息的ID號,如有返回配對的消息,則該ID值將出現在返回的消息中。例如,發送features_request消息中的xid是23,則返回features_reply消息中的xid仍然是23。另外,xid的值對某一端而言總是增加的。下面使用枚舉類型給出OpenFlow消息類型編號,一共定義了30個OpenFlow消息。

6.2.2Wireshark工具簡介

1997年底,GeraldCombs需要一個能夠追蹤網絡流量的工具軟件來輔助其工作,于是他開始撰寫Ethereal軟件。Ethereal在開發過程中數次中斷,終于在1998年7月發布了第一個版本0.2.0。此后,GeraldCombs收到了來自全世界的修補程序、錯誤回報與鼓勵信件。不久,GilbertRamirez看到了這套軟件的開發潛力并開始參與低階程式的開發。1998年10月,來自NetworkAppliance公司的GuyHarris開始參與Ethereal的開發工作。

1998年底,一位教授TCP/IP課程的講師RichardSharpe也看到了這套軟件的發展潛力,而后便開始參與開發新協定

的功能。因為在當時新的通信協議的制定并不復雜,因此,他開始在Ethereal上新增的封包捕捉功能幾乎包含了當時所有的通信協議。而此后很多人開始參與Ethereal的開發,多半是因為希望能讓Ethereal捕捉特定的、尚未包含在Ethereal默認的網絡協議的封包。2006年6月,因為商標的問題Ethereal更名為Wireshark。

Wireshark是當前世界上最流行的網絡分析工具,可以捕捉網絡中的數據,并為用戶提供關于網絡和上層協議的各種信息。Wireshark支持Windows和Unix/Linux操作系統,用戶可以利用pcapnetworklibrary編寫自己的程序來進行封包捕捉。在使用Wireshark之前應檢查是否支持OpenFlow1.

3協議(點擊Wireshark窗體的Expression,搜索其中是否具有OF協議,如圖6－5所示)。直接安裝Wireshark一般不支持OpenFlow,可以下載Mininet,安裝Mininet時有安裝選項,這時選擇安裝的Wireshark軟件就可以支持OpenFlow1.3協議。圖6－5驗證Wireshark是否支持OpenFlow

Wireshark主界面如圖6－6(a)所示,其中包括:

(1)窗口1:過濾窗口,可以過濾出需要的內容。

(2)窗口2:點選某條包的詳細信息,可查看該包的MAC層、IP層、傳輸層和應用層信息。

(3)窗口3:顯示包內容的文本信息、字節信息以及數據包的詳細信息,可用來查看協議中的每一個字段,其各行信息分別為

①Frame:物理層的數據幀概況;

②EthernetII:數據鏈路層以太網幀頭部信息;

③InternetProtocolVersion4:互聯網層IP包頭部信息;

④傳輸層數據段頭部信息;

⑤應用層的信息。

(4)窗口4:顯示包列表,包括包的源、目的地址、協議類型、長度和信息等。

在使用過程中,若電腦上有多塊網卡,可以點擊capture→interface,查看哪些網卡可以獲取流量,點擊capture→options,選擇抓取有流量的網卡。點擊start,則Wireshark開始獲取監控網卡接口的實時數據。注意網卡一定要選中混雜模式usepromiscuousmodeonallinterfaces,如圖

6－6(b)所示,否則無法獲取內網的其他信息。圖6－6(a)Wireshark界面介紹圖6－6(b)Wireshark簡單抓包

6.2.3Wireshark抓包過程及消息分析

接下來通過Wireshark捕獲SDN交換和控制器之間傳遞的消息分析來進一步了解OpenFlow協議過程和有關消息內容。

1.Wireshark抓包過程

步驟一:首先啟動SDN控制器上的OpenDaylight,執行OpenDaylight安裝目錄中的/bin/karaf,如圖6－7所示。如果是首次運行OpenDaylight,必須安裝OpenDaylight相關特征組件,再次啟動則不再需要安裝上述組件。安裝OpenDaylight插件的命令如下:

feature:installodl－openflowplugin－flow－servicesodlrestconfodl－l2switch－switchodl－openflowplugin－allodl－dlux－allodl－mdsal－all

其中,odl－restconf是支持RESTAPI的組件;odl－l2switchswitch、odl－openflowplugin－all是交換層和OpenFlow協議插件;odl－dlux－all的主要作用是提供Web界面功能。

啟動并安裝好OpenDaylight功能組件后,就可以使用瀏覽器登錄到OpenDaylightWeb界面(URL:http://localhost:

8080/index.html)。圖6－7OpenDaylight啟動過程

步驟二:在控制器上打開Wireshark軟件,并選定網卡進行抓包,該步驟需要獲取管理員權限,如圖6－8所示。

步驟三:將一臺裝有OpenvSwitch的SDN交換機連接控制器。一旦連接成功,Wireshark抓包軟件就可以捕獲到OpenFlow數據包。圖6－8Wireshark啟動并設置抓包網卡

2.OpenFlow消息分析

1)建立連接(hello消息)

SDN交換機與控制器初次建立OpenFlow連接時,連接的雙方必須立即發送攜帶版本字段的OFPT_HELLO消息,版本代表發送者所支持的最高的OpenFlow協議版本。hello消息可能含有一些可選內容來幫助建立連接,一旦接收到hello消息,接收方必須立即計算出應該使用的協議版本。如果發送和接收的hello消息都包含OFPHET_VERSIONBITMAP的hello元素,并且這些位圖有一些共同的位設置,那雙方協商的協議是最高版本。

否則,協商版本必須是接收到的版本字段中較小的版本。從圖6－9(a)和(b)中可以看出,控制器和交換機的協議版本都為version:4(表示OpenFlow1.3版本),故最終使用的版本為1.3。

如果接收方支持協商的版本,那么雙方將建立連接。否則,接收方必須回應一個OFPT_ERROR消息,此消息帶有OFPET_HELLO_FAILED類型字段、OFPHFC_INCOMPATIBLE字段以及一個解釋數據狀態的隨機ASCII字符串,然后終止連接。圖6－9(ａ)交換機發送的hello消息數據包圖6－9(b)交換機發送的hello消息數據包

2)能力請求及響應(features消息)

控制器通過發送features_request消息請求查詢交換機的身份以及具有的基本功能,交換機必須響應,回答其身份和基本功能。該消息通常在OpenFlow通道建立后運行,features_request消息由控制器發出,交換機則以features_reply消息作為響應,如圖610(a)和(b)所示,消息包括交換機自身的一些基本設置信息,即交換機的能力以及它的一些端口信息等。每一次交換機連到控制器,都會收到控制器的features_request消息,當交換機將自己的features回復給控制器之后,控制器就對交換機有了一個全面的了解,從而為后面的控制提供了控制依據。圖6－10(a)features_request消息數據包圖6－10(b)features_reply消息數據包

3)角色請求及響應

控制器使用role_request消息用來設置OpenFlow通道角色或者查詢這個角色。當交換機連接多個控制器時,這個消息則非常有用,在多控制器的應用中,控制器通常分為主控制器和從控制器。

角色的請求和響應的意義在于,一個交換機可能同時連接多個相同狀態的控制器或者多個從控制器,但是最多同時連接一個主控制器。每個控制器會發送OFPT_ROLE_REQUEST消息給交換機告知自己的身份,交換機必須記住每個控制器連接的身份,見圖6－11(a)和(b)。圖6－11(a)role_request消息數據包圖6－11(b)role_reply消息數據包

4)barrier請求及響應消息

當控制器要想確保消息已送到或想接收到通知來完成操作,可以發送一個barrier_request消息(分界線請求消息)給交換機,此消息不含有任何內容(見圖6－12(a)和(b))。交換機收到該消息進行處理之前,必須處理完所有先前收到的其他消息,包括發送相應的回復或錯誤信息。當處理完成后,交換機必須發送一個消息OFPT_BARRIER_REPLY攜帶xid最初的請求。圖6－12(a)barrier_request消息數據包圖6－12(b)barrier_reply消息數據包

5)flow_mod消息

flow_mod消息涉及流表項的匹配信息,圖6－13顯示了flow_mod匹配項的類型信息,即下發的流表的信息。圖6－13flow_mod消息數據包

6)packet_out消息

控制器用這個packet_out消息發送數據包到交換機特定的端口,并且轉發通過packet_in消息接收到的數據包。packet_out消息必須包括一個完整的數據包或者一個指明交換機中存儲數據包緩沖區的ID。這個消息必須包含一個動作列表,并按指定順序應用這些動作,若動作列表為空,則丟棄該包。圖6－14展示了packet_out消息的基本內容。圖6－14packet_out消息數據包

7)packet_in消息

當交換機接收到的數據包沒有匹配的相應流表規則來進行處理時,那么交換機通過packet_in將數據包轉發給控制器,由控制器來處理該數據包。如果數據包使用流表項或者漏表項轉發到控制器的保留端口,那么一個packet_in消息就會發給控制器,圖6－15為捕獲的packet_in數據包。圖6－15packet_in消息數據包

8)set_config消息

set_config消息由控制器發出,用來設置、查詢交換機的配置參數,交換機僅需要回應來自控制器的查詢消息(見圖6－16)。圖6－16set_config消息數據包

9)stats狀態信息

stats狀態信息可以獲得統計信息,stats_reply消息用于回應stats_request消息,主要是交換機回應給控制器的狀態信息。交換機和控制器連接后,控制器會不斷發送stats_request消息詢問交換機的狀態,圖6－17(a)和(b)是status_request消息和status_reply消息的內容。圖6－17(a)stats_request消息數據包圖6－17(b)stats_reply消息數據包

6.3利用OpenDaylightYangUI工具下發流表

在OpenvSwicth交換機上配置OpenFlow流表的方式有兩種,一是直接利用OpenvSwicth命令進行流表的增/刪管理操作;二是用戶可以通過OpenDaylight控制器中的YangUI工具進行流表參數配置并下發到不同的SDN交換機上。OpenDaylight初次啟動后安裝odldluxall組件,該組件為用戶提供了一個用于管理OpenDaylight的Web界面,通過該界面用戶能夠清楚地了解網絡的拓撲結構、交換機接口、端口信息、配置信息以及統計信息。本節將詳細介紹YangUI中關于流表參數的設置。

6.3.1Yang模型工具簡介

Yang是一種數據建模語言,NETCONF協議、NETCONF遠程調用和NERCONF通知通過Yang模型進行模塊化配置數據和狀態數據。NETCONF協議是一種最新的基于XML的網絡配置和管理的協議,該協議提出了一整套對于網絡設備的配置信息和狀態信息進行管理的機制。Yang模塊定義了基于NETCONF操作使用的層次化結構的數據,它提供了NETCONF客戶端和服務器之間完全的數據描述。

國際互聯網工程任務組(IETF)通過REF6020、REF6021和REF6022三個文檔分別定義了Yang語言、數據類型和模型,用于對NETCONF協議所操作的數據進行建模。Yang模型通過樹形結構的節點定義描述了數據模型的層級嵌套結構以及各屬性的數據類型。Yang具有自己的語法格式,也可以無差別地轉換為XML格式,并稱之為YIN。轉換可以使用第三方工具(pyang)進行。

6.3.2下發流表前的網絡配置

首先啟動OpenDaylight控制器,并確保控制器和主機已經連接到SDN交換機(OVS)。為了能夠準確地理解各種配置參數的含義,我們配置了如圖6－18的網絡設備,其中,SDN交換機一臺,PC機四臺(各主機的IP地址、MAC地址和端口號如表6－2所示)。通過YangUI參數配置以達到通過主機PC1pingPC2,結果返回的數據包是主機PC3的數據包的目的。圖6－18在OpenDaylightWeb界面上顯示的網絡拓撲結構

6.3.3利用OpenDaylightYangUI下發流表的實現過程

在OpenDaylight啟動后,可以在交換機端使用ovsofctldumpflowsbr0命令查詢已有流表的信息,這些流表是由OpenDaylight交換機在接收到SDN交換機發送的LLDP協議數據包后被動下發的流表,如圖6－19所示。在后面下發流表的過程中,可以通過該命令時刻關注流表是否下發成功以及是否匹配成功。圖6－19控制器默認下發的流表條目

通過YangUI模塊提供的Web界面進行流表的配置操作,包括GET、PUT、POST和DELETE操作。

(1)GET:從OpenDaylight獲取數據。

(2)PUT和POST:保存配置數據,發送數據給OpenDaylight。PUT和POST的區別在于,如果所請求的URL資源不存在,PUT會創建資源,而POST則不會。因此,在下面的配置中,一般采用PUT操作。

(3)DELETE:刪除配置,發送數據給OpenDaylight。

下面是OpenDaylightWeb界面提供的YangUI工具進行下發流表的操作步驟。如圖6－20所示,點擊操作界面中的左側菜單YangUI,并在界面的右側選擇opendaylightinventory,點擊展開后可以看到有兩個子項,分別是operational和config。其中,operational僅用于查看相關的網絡配置參數,只有在config子項中才能手動配置流表。圖6－20YangUI主頁面

接下來通過YangUI手動配置流表并下發到交換機,以實現主機PC1pingPC2,流表將發往PC2的數據包改變路徑發往PC3,同時PC3返回相應的數據包給PC1,其效果相當于PC1pingPC3。在配置流表之前,首先要分析需要用到哪些流表以及匹配條件和相關動作。眾所周知,ping命令發送和接收的是ICMPecho_request和ICMPecho_reply數據包,ICMP報文是在IP數據包內部傳輸的,因此,只需要配置一條流表項。匹配規則設定為:以太網幀類型為IP,目的IP地址為PC2的地址,動作為改變目的IP地址、MAC地址以及物理端口,其流表配置步驟及參數設置如下。

1.添加table0并在table0中添加一個流表項(flow)

flowid的配置如圖6－21所示,其中tableid的值必須為0。當tableid的值大于0時,交換機不會主動去執行該table的值,除非在tableid為0的流表中添加一個gototable(流水線操作)的動作,將流表轉到下一個流表。flowid規定為任意大于等于0的整數,當有多個flowid的時候,交換機會根據id的值從小到大依次執行。圖6－21flowid配置

2.設置流表匹配項

流表匹配項的配置如圖6－22所示,其中,ethernettype的值為0x0800,表示匹配的是IP數據包。ethernettype常見的值還有0x0806(ARP)和0x88CC(LLDP)。另外,匹配選用的是layer3match中的ipv4match。需要特別注意的是其中ipv4source和ipv4destination字段的填寫規范,填寫形式為:點分十進制IP/子網掩碼(CIDR無類別域間路由),子網掩碼為0或者32代表全匹配。當SDN中主機數量比較多時,如果為每一臺主機分別配置流表或流表項,勢必造成流表項數量過多,因此,可以通過子網掩碼的設置進行IP地址聚類。

例如,設置匹配規則為源IP地址192.168.1.100/31,則意味著主機IP地址是192.168.1.100和192.168.1.101的流表項均匹配成功。如果子網掩碼填寫錯誤,將不能成功下發流表,或者下發的流表不會達到預期的效果。

圖6－22流表匹配項配置

3.選擇指令類型

指令類型分為applyactionscase、writeactionscase、clearactionscase和gototablecase四種類型。其中,applyactionscase代表立即執行行動列表中指定的行動而不改變

行動集,在兩個表之間傳遞或者執行同類型的多個行動的時候,這個指令可用來修改數據包;writeactionscase代表將指定的動作添加到當前動作集中,如果已經存在該類型的動作,則覆蓋原來的動作;clearactionscase代表立即清除動作集中所有的動作;gototablecase代表指定流水線處理進程中的下一張表的ID。

本實驗設置指令類型為applyactionscase,如圖6－23所示。請注意行動列表與行動集的區別,行動列表中的動作是要立即執行的,即一旦流表項匹配成功,則立即執行行動列表中的動作。而行動集中的動作并不會立即執行,而是要等到流水線處理完所有的流表項后再執行。

圖6－23指令類型選擇

4.為指令添加行動列表

這里需要添加三個動作,分別為改變目的IP地址、目的MAC地址和目的物理端口。action:0使用的是setdldstactioncase命令,其作用是改變目的主機的MAC地址(改為PC3的MAC地址,其中dl是datalink的縮寫,即數據鏈路層);action:1使用的是setnwdstactioncase命令,其作用是改變目的主機的IP地址(改為PC3的IP地址,其中nw是network的縮寫,即IP網絡層);action:2使用的是outputactioncase命令,用于改變數據包的出端口(改為出端口為3)。圖6－24中的(a)、(b)和(c)表示配置了以上三個動作。圖6－24(a)order:0動作配置圖6－24(b)order:1動作配置圖6－24(c)order:2動作配置

5.流表其他信息的配置

如圖6－25所示,最后需要配置流表的優先級和生命時間。由于在OpenDaylight控制器中自動產生的內部流表優先級(priority)默認值為1到100,因此,手工配置流表的優先級應大于100(優先級越大,流表越先執行),新流表才能在控制器自動產生的內部流表之前生效。idle－imeout和hard－timeout是交換機端流表的生存時間,如果hard－timeout值不為零,則無論有多少數據包與之匹配,交換機經過hard－timeout時間后會刪除該流表項。

如果給定非零idle－timeout的值,那么在idletimeout時間內沒有數據包達到并匹配該流表時,交換機要刪除這個流表項。當idletimeout和hard-timeout其中一個發生超時時,交換機必須實現流表項超時并且從流表中刪除該流表項。當這兩個字段同時為0時,表示下發到交換機的流表項在交換機啟動期間永久的存在于交換機中(除非控制器下發刪除該流表的指令)。cookie表示由控制器選擇的不透明數據值,用來標識流表。

圖6－25流表其他信息配置

6.使用PUT方式將流表下發到交換機

改變操作方式為PUT,并點擊最右邊的Send按鈕則下發上述配置的流表(如圖6－26(a)所示)。若發送成功,則界面上將出現“Requestsentsuccessful”字樣,但是這并不表明該流表成功下發到交換機上。如果配置的參數錯誤,OpenDaylight并不能指出其中的錯誤。目前,OpenDaylight只能針對輸入參數做一些簡單的錯誤檢查,必須在交換機上查看流表信息來確定是否下發成功。如圖6－26(b)所示,證明流表下發成功。圖6－26(a)通過PUT方法向控制器發送流表圖6－26(b)交換機上顯示流表已下發

7.測試實際結果

在PC1上pingPC2,交換機上顯示流表匹配的數據包已達到3條(n_packets=3),如圖6－26(c)所示。圖6－26(c)交換機上顯示流表已匹配3條數據包

6.3.4使用gototable指令下發流表

在實際開發使用過程中,由于流表數量眾多,不會只在一個table中進行下發流表,而是在多個流表中下發相應的動作,使用go－to－table指令實現流表的跳轉以達到流水線的效果。特別注意的是,go－to－table指令實現跳轉的表id必須大于跳轉之前的表id,同時,在表跳轉結束之前不能出現output動作,否則流表就不會跳轉到下一個流表。下面使用go－to－table指令實現與前面配置的流表達到相同的效果,主要步驟如下:

1.配置table0

(1)table0的匹配條件和前一小節的匹配條件一樣,ethernettype字段設置為0x0800,ipv4destination設置為192.168.1.102/32。

(2)為table0添加指令,該指令將與table0匹配到的數據包進一步轉發到table1上進行更為細粒度的處理。

(3)設置table0的優先級和生命時間,完成該項后使用PUT下發該流表。．

2.配置table1

參照6.3.3中配置table0的方式同樣配置table1的匹配域、行動列表和流表的其他配置信息,填寫完成后使用PUT下發該流表,在流表配置信息中,table_id字段需要設置為1(見圖6－27(a))。

3.在交換機上查看流表信息并實際測試結果

在圖6－27(b)中可以看到cookie等于0x44444444的table0流表和cookie等于0x666666的table1流表,證明流表0與流表1下發成功。在PC1上執行pingPC2的操作,結果如圖6－27(c)所示,此時兩條流表匹配的數據包均已增加(n_packets均為3),表明流表已經起到了匹配效果。圖6－27(a)table0添加gototable指令圖6－27(b)table0和table1下發成功圖6－27(c)使用table0和table1流表數據包匹配成功

6.4使用OpenFlow流表實現網絡負載均衡

本節將介紹如何用利用OpenDaylightBeryllium版本Web界面中的YangUI工具并結合OpenvSwitch下發流表來動態改變網絡路徑以達到實現網絡負載均衡的效果。

6.4.1網絡負載均衡原理

負載均衡(LoadBalance,LB)是一種服務器或網絡設備的集群技術。負載均衡將從外部接收到的負載盡量有效地平均分配到多臺服務器或網絡設備,使得每臺服務器或設備的負載達到相對平衡的狀態,從而使資源達到最優,響應任務的時間盡可能小,處理的吞吐量盡可能大,提高使用在諸如Web服務器、FTP服務器和其他關鍵任務服務器上的因特網服務器程序的可用性和可伸縮性。

負載均衡有兩方面的含義:

第一層含義是將單個重負載的運算分擔到多臺節點設備上作并行處理,每個節點設備處理結束后,再將結果匯總返回給用戶,使得系統處理能力得到大幅度提高,這就是常說的集群(clustering)技術。

第二層含義就是進行大量的并發訪問或將數據流量分擔到多臺節點設備上分別處理,減少用戶等待響應的時間,這主要針對的是Web服務器、FTP服務器、企業關鍵應用服務器等網絡應用。

通常,負載均衡會根據網絡的不同層次(網絡七層)來劃分,其中第二層的負載均衡指將多條物理鏈路當作一條單一的聚合邏輯鏈路使用,這就是鏈路聚合技術。它不是一種獨立的設備,而是交換機等網絡設備的常用技術。現代負載均衡技術通常操作于網絡的第四層或第七層,這是針對網絡應用的負載均衡技術,它完全脫離于交換機、服務器而成為獨立的技術設備。

服務器負載均衡有三大基本特征:

(1)負載均衡算法;

(2)健康檢查;

(3)會話保持。

這三個特征是保證負載均衡正常工作的基本要素。在沒有部署負載均衡設備之前,用戶直接訪問服務器地址,是一對一的訪問。當單臺服務器由于性能不足無法處理眾多用戶的訪問時,就要考慮用多臺服務器來提供服務,實現的方式就是負載均衡。負載均衡設備的實現原理是把多臺服務器的地址映射成一個對外的服務IP,通常稱之為VIP(虛擬IP),這個過程對用戶端是透明的,用戶實際上不知道服務器是做了負載均衡的,以為他們訪問的還是一個目的IP,那么當用戶的訪問到達負載均衡設備后,如何把用戶的訪問分發到合適的服務器就是負載均衡設備要做的工作了,具體來說,用到的就是上述的三大特征。

6.4.2基于SDN的負載均衡

基于SDN的服務器負載均衡網絡中,負載均衡服務器不再直接修改TCP數據包的源IP、源端口、目的IP端口以及目的MAC地址,而是通過下發流表的方式由SDN交換機完成網絡地址轉換(NetworkAddressTranslation,NAT)功能。SDN負載均衡器僅僅用于產生、修改或刪除流表規則,不再具體轉發客戶端的任何數據包。SDN負載均衡器產生的流表主要依據健康檢查和相應的負載均衡算法。

基于SDN的服務器負載均衡的關鍵是對SDN流表的設置,一方面,流表的數量不能過多,否則影響動態維護流表的性能,因此通常采用源IP地址模糊匹配的方式;另一方面,流表匹配IP地址范圍也不能過度寬泛,這樣不利于對網絡流量變化的實時響應,也不利于對突變流量的主機準確定位。

負載均衡又分為靜態負載均衡和動態負載均衡。靜態負載均衡方法是在算法執行之前,通過對系統的一些性能參數以及經驗值參數的分析總結得出的分配策略。這種方法易于實施,開銷少,但方案制定難度比較大。而動態負載均衡利用系統運行時對網絡用戶任務量以及信息傳輸速率等因素的實時分析,得到動態分配策略。此方法可通過編程實現流表的下發以及實時的改變,利用SDN技術在流和任務調度上靈活性的優勢,通過OpenFlow協議對服務節點流量及負載狀況進行實時監測。

SDN負載均衡技術不管應用于用戶訪問服務器資源,還是應用于多鏈路出口,均大大提高了資源的利用率,顯著降低了用戶的網絡部署成本,提升了用戶的網絡使用體驗。

6.4.3OpenDaylightWeb界面

OpenDaylightWeb界面主要使用了OpenDaylight用戶接口DLUX,DLUX提供了多種多樣的Karaffeatures組件,使得啟動和關閉相分離。在Beryllium版本中,與DLUX相關的特征組件主要有:odl－dlux－core、odl－dlux－node、odl－dlux－yangui、odl－dlux－Yangvisualizer。

DLUX還有其他應用,如Nodes、YangUI等。其中,YangUI模塊已在6.3節詳細介紹,下面主要介紹Nodes模塊和Topology模塊。

1.Nodes模塊

(1)在如圖6－28(a)所示的Nodes模塊中,用鼠標單擊左邊Nodes,右邊將顯示連接該控制器的所有節點、節點連接器和統計的列表信息。

(2)在SearchNodes中輸入一個節點的Id,通過節點連接器搜索相應節點。

(3)點擊NodeConnectors查看詳細信息,可以查看的信息有端口Id、端口名稱、每個交換機的端口號、MAC地址等,如圖6－28(b)所示。

(4)點擊統計行中的Flows查看具體節點的流表統計信息,有表Id、匹配包、活躍狀態的流等,如圖6－28(c)所示。圖6－28(a)Nodes節點列表圖6－28(b)NodeConnectors詳細信息圖6－28(c)Flows查看具體節點的流表統計信息

2.Topology模塊

(1)用鼠標單擊左邊面板的Topology,可以在右邊查看圖形化顯示,如圖6－29所示。

(2)在主機、鏈路或者交換機上懸停鼠標,可以顯示源和目的端口。

(3)使用鼠標滾輪可以放大和縮小圖標驗證拓撲。圖6－29網絡拓撲結構

6.4.4實現網絡負載均衡的網絡設置

由于本次實驗涉及的協議是HTTP協議,HTTP協議的下層是TCP協議,TCP在通信時會進行三次握手。首先在PC1上安裝Tomcat7.0.72版本,在PC2上安裝Tomcat8.5.6版本。實驗的最終結果是,當PC3客戶端給PC1服務器發送SYN包時,由于流表的作用改變了出端口,導致PC3的發送路徑發生了改變,因此,當PC3登錄到PC1的Tomcat時,結果

出現了PC2安裝的Tomcat版本界面。這就表明可以通過流表改變網絡流量的訪問路徑,從而達到均衡負載的作用。

本次實驗用到的主要設備有:安裝有OpenDaylightBeryllium版本的控制器一臺、Open

vSwitch2.5.0版本的交換機一臺、終端PC機三臺。終端PC機的配置信息如表6－3所示,網絡拓撲圖如圖6－30所示。圖6－30網絡拓撲圖

6.4.5通過下發流表改變網絡訪問路徑

本次實驗的目的是通過YangUI工具下發流表,實現在PC3主機的瀏覽器登錄PC1的Tomcat,返回界面是PC2的Tomcat。

首先啟動PC1和PC2上的Tomcat服務器軟件。啟動Tomcat的方法是在Tomcat的安裝目錄里的bin目錄下輸入命令:./startup.sh,然后通過瀏覽器分別驗證Tomcat是否啟動正常。在PC3主機的瀏覽器上輸入:PC1或PC2的IP地址:8080,即PC3登錄到PC1和PC2上的Tomcat服務器后返回的頁面,如圖6－31和圖6－32所示。注意兩個服務器上安裝的Tomcat版本不一樣。圖6－31PC3登錄PC1的Tomcat主界面圖6－32PC3登錄PC2的Tomcat主界面

步驟1:首先啟動ODL控制器,并確保控制器和主機已經連接到OVS交換機(詳細啟動過程在6.3節已提及)。啟動后可使用ovsofctldumpflowsbr0命令在交換機端查詢已有流表的信息。

步驟2:創建新的流表進行下發。

(1)打開YangUI添加table0,并在table0中添加一個id為1(假定編號為1)的flow1進行流表配置。此流表的作用是為了匹配到TCP協議中的第一次和第三次握手(包由PC3發出)并改變包的目的主機信息,如圖6－33(a)所示。圖6－33(a)添加flow1

(2)添加匹配字段。如圖3－33(b)所示,以太網類型字段為2048(0x0800),代表ip數據包,ipprotocol為6代表匹配的協議為TCP協議。layer3的配置規則如圖6－33(c)所示,設置IPv4目的地址為192.168.1.101/0。

(3)為flow1添加指令。其中,applyactionscase表示不改變行動集立即執行指定的行動。在兩個表之間傳遞或者執行同類型的多個行動的時候,這個指令可用來修改數據包,見圖6－33(d)。圖6－33(b)設置以太網類型為ip圖6－33(c)設置匹配目的地址為192.168.1.101/0(PC1)圖6－33(d)添加applyactionscase指令

(4)為flow1指令添加指令和行動列表。動作0是為了改變目的主機的MAC地址(改為PC2主機的MAC地址);動作1是改變目的主機的IP地址(改為PC2主機的IP地址);動作2是改變數據包的出端口(改為PC2主機的端口號)。此配置目的是把包的目的主機改為PC2,從而改變數據包發送的路徑,即由發往PC1改為發往PC2,如圖6－33(e)、(f)、(g)所示。圖6－33(e)添加動作0,修改目的MAC地址為PC2的MAC地址圖6－33(f)添加動作1,修改目的IP地址為PC2的IP地址圖6－33(g)添加動作2,出端口改為2(連接PC2)

(5)在table0中添加一個id為2的flow2并進行流表配置。此流表的作用是為了匹配到TCP協議中的第二次握手(包由PC2發出)并改變包的發送源主機信息。如圖6－34(a)所示,匹配規則為入端口2。

(6)為flow2添加指令和行動列表。動作0是為了改變目的主機的MAC地址(改為PC1主機的MAC地址);動作1是改變目的主機的IP地址(改為PC1主機的IP地址);動作2是改變數據包的出端口(改為PC3主機的端口號)。此配置目的是把包的發送源主機改為PC1,但是出端口卻改到PC3上,從而實現路徑的轉移,如圖6－34(a)、(b)、(c)所示。圖6－34(a)添加flow2圖6－34(b)添加動作0圖6－34(c)添加動作1圖6－34(d)添加動作2

(7)為流表添加優先級等其他信息(其中優先級的注意點在6.3節已提及),如圖6－35所示。圖6－35流表其他消息配置

(8)使用PUT將配置好的流表下發到交換機。交換機端的流表信息如圖6－36所示,證明流表下發成功。圖6－36數據包匹配前的流表信息

步驟3:在PC3主機的瀏覽器中輸入192.168.1.101:8080,目的是登錄到PC1的Tomcat。

由圖637可以看出,登錄PC1主機的Tomcat,得到的卻是PC2主機的Tomcat界面。通過再次查看交換機端的流表信息,發現控制器下發的流表有數據包被匹配。圖6－37Tomcat登錄信息圖6－37Tomcat登錄信息

6.5基于OpenFlow1.3組表的驗證性實驗

6.5.1組表的基本概念及主要作用根據OpenFlow協議中對組(group)的定義,組是動作桶(bucket)的集合,是其中的一個或多個動作桶應用到每一個數據包上的手段。

一個組表的表項是由組編號(一個32位的無符號整數,是組的唯一標識)、組類型(確定組語義)、計數器、動作桶集合(一系列有序的動作桶,其中的每個動作桶包含了一組要執行的動作和相關參數)組成。組類型分為4種:all、select、indirect和fastfailover。all表示要執行組中的所有動作桶;select表示有選擇地執行動作桶集合中的一個動作桶;

indirect表示動作桶集合中的動作桶只有一個;fastfailover表示執行動作桶集合中第一個有效的動作桶。在流表的動作類型中有一個groupationcase選項,可以指定執行的動作是某個group。由此可以看出,group本質上相當于是一個可以為所有流表“共享”的動作集合。

本次實驗主要驗證group類型為all和select的使用,all類型的group理解起來相對比較簡單,而select類型的group則要復雜一些。當數據包應用select類型的group時,如何選擇其中的某一個動作桶呢?選擇的依據是基于SDN交換機設置的調度算法,如基于用戶某個配置項的元組/數組的哈希算法或簡單的循環算法,所有的調度算法配置信息對于SDN交換機來說都是屬于外部的。當數據包發往一個當前宕掉的端口時,交換機能將該數據包改發到一個預留端口(如將數據包轉發到當前活躍的端口上),而不是繼續將數據包發送給這個已經宕掉的端口。

6.5.2實驗網絡環境配置

本次實驗中用到的主要設備有:安裝有OpenDaylightBeryllium版本的控制器一臺、Open

vSwitch2.5.0版本的交換機一臺、安裝有iperf工具的終端PC機三臺。終端PC機的配置信息如表6－4所示,網絡拓撲結構如圖6－38所示。圖6－38組表實驗網絡拓撲結構

6.5.3利用OpenDaylightYangUI工具實現簡單的組表下發

本節將利用OpenDaylightYangUI工具配置組表,并學習如何使用組表進行數據包的轉發,主要步驟如下:

步驟1:在OpenDaylightYangUI工具中進行組表配置。

瀏覽OpenDaylightDLUXWeb界面,點擊OpenDaylightYangUI樹形菜單下的opendaylightinventory/config/nodes/node{id}/group,group配置參數如圖6－39(a)和(b)所示。注意組表類型(type)應設置為groupall,而不能設置bucketweight字段,因為weight為

select的特有字段其他組表類型不能使用。groupid設置為1,動作(action)配置為出端口4。

參數配置完后選擇操作類型為“PUT”,然后點擊“

Send”按鈕發送參數到控制器上,控制器通過OpenFlow消息下發給SDN交換機。可以通過交換機端的查詢命令查看組表:

ovs－ofctldump－groupsbr0－OOpenFlow13

其中,－OOpenFlow13是指定查詢組表的協議為OpenFlow1.3。從配置界面中可以看出,一個組表是多個bucket組成,每個bucket又由多個action組成,如圖3－39(

c)所示。圖6－39(a)group參數配置界面圖6－39(b)group中的action參數配置界面圖6－39(c)在交換機端查看組表

步驟2:在OpenDaylightYangUI工具中進行流表配置。

首先在table0中添加flow1,并為flow1添加匹配規則,這里的配置規則設置為ethernettype為2048(幀類型為IP),目的IP地址為192.168.1.103/0。然后設置flow1的動作列表,其中,動作1的action選擇groupactioncase,groupid設置為1。最后將該流表保存并下發到交換機,如圖6－40(a)和(b)所示。圖6－40(a)配置flow1的匹配參數圖6－40(b)指定flow1的動作跳轉到group1

由圖6－40(c)可以看出,流表下發成功。注意此處查看流表的命令為ovsofctldumpflowsbr0OOpenFlow13。若直接使用命令ovsofctldumpflowsbr0,則用的是OpenFlow1.0協議查看流表,將不會查詢到group的存在,顯示為ctions=drop,這是因為OpenFlow1.0還不支持組表。圖6－40(c)查看table0flow1是否下發成功

步驟3:驗證組表是否執行指定動作。

在PC1(192.168.1.101)上pingPC3(192.168.1.103),結果能夠成功ping通,同時發現流表table0flow1的n_packets數值增加(見圖6－41),表明在流表中使用組表成功。圖6－41查看table0flow1匹配數據包的數值變化

6.5.4類型為all的組表的使用

本節對group類型為all的組表語義進行驗證,在組類型是all的組表中,動作桶集合中的所有動作桶均被執行。PC1(192.168.1.101)和PC3(192.168.1.103)作為服務器,PC2(192.168.1.102)作為客戶端僅向PC1發送數據,然后配置組表實現將發往PC1的UDP數據復制一份發往PC3。

客戶端和服務器上均采用iperf軟件。iperf是一個網絡性能測試工具,可以測試TCP和UDP的帶寬質量,可以報告帶寬、延遲抖動和數據包丟失。詳細步驟如下:

(1)在主機PC1和PC3上分別以服務器方式運行iperf。使用UDP協議的服務器程序端口設置為5001,如圖6－42(a)和(b)所示。啟動命令為

perf－s－p5001－u－i1

其中,－s表示服務器,－u表示采用UDP協議,－p5001表示指定監聽端口為5001,－i1表示每隔1秒打印一次報告。圖6－42(a)在PC1上啟動iperf服務器程序圖6－42(b)在PC3上啟動iperf服務器程序

(2)使用OpenvSwicth命令直接在交換機上添加組表。設置groupid為0,組類型為all,兩個動作桶分別設置為數據包發往不同的主機(PC1和PC3)。其中,第一個動作桶設置為bucket=output:1,不修改目的MAC地址和目的IP地址,因為進入交換機的數據包本來就是要發往PC1的,所以該動作桶是直接將PC2的數據包發往PC1。第二個動作桶除了發往指定端口外,還需要修改目的MAC地址和目的IP地址,即將發往PC1的數據包發往PC3。只有這兩個動作桶都執

行,PC1和PC3才能都收到同樣的數據包,如圖6－42(c)所示。設置完組表后,最好能夠查看一下組表設置是否正確。設置命令如下:

ovs－ofctladd－groupbr0－OOpenflow13group_id=0,type=all,bucket=output:1,bucket=mod_dl_dst:00:1c:25:e2:26,mod_nw_dst:192.168.1.103,output:圖6－42(c)直接在交換機上添加組表

(3)使用OpenvSwicth命令直接在交換機上添加流表,如圖6－42(d)所示,動作設置為action=group:1。圖6－42(d)直接在交換機上添加流表

(4)在主機PC2上使用iperf向主機PC1發送UDP數據包,發送結果如圖6－42(e)所示,發現PC1和PC3在組表作用下能夠同時收到客戶端發送的數據包。發送數據命令為

iperf－c192.168.1.101－t3－ui1

其中,c表示為客戶端程序,t3表示連續發送3秒時間,其他參數與上述命令一樣。圖6－42(e)PC2上啟動iperf客戶端程序并發送數據包

上述結果如圖6－42(f)、(g)、(h)所示。容易看出,PC1和PC3接收的UDP數據包數量完全一樣,這充分說明在組表類型為all時,流表會把匹配上的數據包復制給組表里的每個bucket進行處理。圖6－42(f)PC3上接收到客戶端程序發送的數據包圖6－42(g)PC1上接收到客戶端程序發送的數據包圖6－42(h)交換機上流表應用group后的數據變化

6.5.5類型為select的組表的使用

當group類型為select時,交換機會為數據包選擇動作桶集合中的某一動作桶來執行相應的動作,而選擇的依據依賴于交換機設置的選擇算法。接下來驗證group類型為select時是否具有上述特性,只需將6.5.4中添加的group語句稍加修改即可,將組表類型改為select以及在每個動作桶上增加weight屬性。如圖6－43(a)所寫的添加命令,第一次在兩個動作桶上均添加weight為50的值,實驗結果表明只有PC1接收到數據包,而PC3未收到任何數據包。

第二次將第一個動作桶的weight值改為2,將第二個動作桶的weight值改為90(見圖6－43(b)),結果表明這次是PC1接收不到任何數據,而PC3接收到了全部數據。上述實驗結果說明,當group類型為select時,確實只執行動作桶集合中的某一個動作桶。

由于實驗的局限性,因為不清楚交換機的選擇算法以及動作桶集合中的動作桶數量偏少(只有2個),因此實驗并沒有達到所有接收的數據包能夠部分選擇第一個動作桶,部分數據包選擇第二個動作桶的效果。圖6－43(a)在交換機上添加group類型為select的組表(weight值為0)圖6－43(b)在交換機上添加group類型為select的組表(weight值為2)

6.6SDN網關功能的實現

在開放系統互連參考模型(OSI)中,網關有兩種實現思路,一種是面向連接的網關,一種是面向無連接的網關。網關又叫網間連接器或協議轉換器,它在傳輸層上實現網絡的互聯,是復雜的網絡連接設備,僅用于兩個高層協議不同的網絡互聯。在真實的網絡環境中,大多數網關運行在OSI七層模型的最上層,也就是我們熟知的應用層。

6.6.1SDN中的網關

一般傳統網絡中數據包的轉發是通過一系列的路由協議完成的,而在SDN中,數據包的轉發與處理則是通過SDN控制器和SDN交換機的方式實現的,數據包進入到SDN交換機進行流表的匹配。若匹配不成功,交換機會執行table_miss、丟棄或者通過pack_in消息上傳給控制器,由控制器決定處理方式,并通過pack_out消息將處理決定發送給交換機,使得交換機具備處理該類數據包的能力;若匹配成功,數據包將按照流表的動作進行處理。但是在這個過程中,會面臨

不同子網間的通信問題。

例如,現在有兩臺主機A和B,分別連接同一臺SDN交換機,主機A的IP地址為192.168.1.101,子網掩碼為255.255.255.0,主機B的IP地址為192.168.2.101,子網掩碼為255.255.255.0。此時我們用主機Aping主機B,當主機A發送ARP請求數據包進入到交換機中時,交換機接收到該數據包并進行匹配,然后執行相應動作,將ARP請求數據包發送給主機B。當主機B收到主機A的ARP請求數據包時,由于主機B與主機A分屬于不同的子網,主機B會將該數據包丟棄,導致主機A和B無法通信。

那么,如何才能使得兩臺不在同一子網的主機在SDN中實現相互通信呢?這時候就需要用到網關。SDN中網關的實現主要有兩種思路:第一種是利用傳統的網關服務器,將兩個不同的子網通過網關服務器連接起來,從而實現不同網段之間的通信;第二種是將控制器當做網關,當數據包進入交換機時,由于不同網段之間不能通信,故交換機將數據包發送給控制器,控制器作為網關服務器對數據包進行處理后轉發給交換機,從而實現網關的功能。

本節將對第一種思路給出實現步驟,實際的網絡拓撲結構如