SDN網絡轉發機制研究和應用場景分析

胡曉宇中國電信股份有限公司上海分公司網絡操作維護中心

?

SDN網絡轉發機制研究和應用場景分析

胡曉宇
中國電信股份有限公司上海分公司網絡操作維護中心

摘要：SDN無疑是當前網絡業界最熱門的研究課題之一，SDN體現了控制和轉發相分離的原則，為網絡和業務的創新帶來了蓬勃的生機和活力。文章通過構建OpenDayLight控制器與Mininet交換模擬器相結合的測試環境，研究了SDN環境下二/三層網絡交換的轉發機制和特性，并對SDN在網絡中的應用提出了設想。

關鍵字：SDN OpenDayLight Mininet 二/三層交換

1　SDN簡介

軟件定義網絡（Software Defined Network， SDN） 最早由斯坦福大學clean slate研究組提出。SDN的核心是控制與承載相分離，實現網絡開放，使流量可以被靈活控制，從而為上層的業務和應用提供更優化的服務。SDN的概念提出后，迅速得到了各方面的響應，在IT界、網絡屆掀起了一股熱潮。2010年，開放網絡基金會ONF成立，ONF致力于開發 OpenFlow協議，以規范控制器與交換機之間南向接口標準化，目前最新發布的版本為1.4。

在控制器方面，借鑒在IT和互聯網上的成功經驗，開源成為一股不可抵擋的趨勢。NOX，POX， Floodlight等均采用公開源代碼的形式，任何人都可以學習SDN，只要有相應的IT編程能力，都可以為 SDN的控制器的完善做出貢獻。各大設備廠商也正視SDN的挑戰，2013年4月IBM、Cisco、微軟、NEC、Juniper、BigSwitch（后退出）等多家IT巨頭合作啟動了OpenDayLight項目。OpenDayLight采用 JAVA開發，是一套開源的SDN框架。其初期版本已經發布，本次實驗使用的就是這個版本。該版本支持簡單轉發應用（Simple Forwarding），可以支持二/ 三層轉發，而目前其它開源控制器僅見有支持二層 轉發的能力。可見OpenDaylight已經開始領先。

光有控制器還不能構成完整SDN網，但當前硬 件SDN交換機還很少，也很難找到。幸好有 Mininet推出了基于軟件模擬的交換機。Mininet項目也是開源的軟件，通過Mininet，在一臺Linux主機內可以構造并模擬多臺SDN交換機和終端。使用Python腳本，使用者還可以配置較為復雜的SDN 網絡拓撲結構。同時Mininet還配備了WireShark抓包軟件，方便SDN開發者和學習者進行開發和研究。

2　基于Opendaylight的SDN網絡轉發機制分析

2.1創建和啟動SDN網絡拓撲結構

在測試中我們創建了如下的網絡拓撲結構，1 臺OpenDayLight控制器（簡稱Controller，版本為0.1 版），2臺交換機（SW），每臺SW分別連接2臺主機 （Host），一共4臺主機，這些主機分屬于2個不同的網段，交換機與控制器之間采用OpenFlow協議（簡 稱OF）。

首先在測試機（Windows XP系統）上運行run.bat 批處理文件啟動OpenDayLight，然后在VirtualBox中載入Mininet虛擬機映像并運行。測試網絡的拓撲結構由Python腳本生成，文件保存于虛擬機 /mnt/shared目錄下的topo2_2.py文件內：

from mininet.topo

import Topo class MyTopo（Topo）：

“Simple topology example.”

def __init__（self）：

“Create custom topo.”

# Initialize topology

Topo.__init__（self）

# Add hosts and switches

Host1 = self.addHost（‘h1’）

Host2 = self.addHost（‘h2’）

Host3 = self.addHost（‘h3’）

Host4 = self.addHost（‘h4’）

Switch1 = self.addSwitch（‘s1’）

Switch2 = self.addSwitch（‘s2’）

# Add links

self.addLink（Switch1，Switch2 ）

self.addLink（Switch1，Host1 ）

self.addLink（Switch2，Host2 ）

self.addLink（Switch1，Host3 ）

self.addLink（Switch2，Host4 ）

topos =｛‘mytopo’： （lambda： MyTopo（））｝

啟動測試環境，使用以下命令生成測試拓撲結構：sudo mn--custom /mnt/shared/topo2_2.py--topo mytopo，--controller=remote ip=192.168.56.1。通過啟動抓包軟件WireShark可以看到SW向Controller的注冊過程。在注冊過程中，Controller會要求SW提供 OpenFlow版本號，設備連接的端口等狀態等信息。SW1將自己所連接的4個端口情況上報給Controller（其中包括與Controller相連的端口），同樣 SW2也會上報自己的狀態。

當SW設備完成設備注冊后，Controller將進行網絡拓撲結構的發現或更新。當網絡中有一臺新的 SW接入后，Controller通過OF Packet Out指令要求SW1 在其所有端口上發出LLDP（Link Layer Discovery Protocol，EEE802.1ab）鏈路探測包。LLDP的源MAC 為Controller分配，這里為00：00：00：00：00：01（對每一個交換機，Controller都會分配一個這樣的MAC作為 SW標識），LLDP目的MAC地址為組播地址。相鄰的 SW2將接收到LLDP，SW2由于無法識別這條流，會將OF協議再發到Controller上。通過LLDP的發送和接收，Controller可計算出交換機之間的拓撲關系，網絡的拓撲關系可作為轉發流表生成和實現網絡可視化的基礎。（注：與交換機SW相鄰的主機也會收到 LLDP，但并不會處理）

2.2SDN網絡二轉發機制

生成網絡拓撲后，還要在Controller上為每一個三層網段設置一個網關地址（即使是二層轉發也必須設置），然后將交換機的接口與三層網關相關聯。這里將SW1的2號（連接h1）和SW3的2號口（連接h2）分別與網關10.0.0.254關聯，將SW1的3號（連接h3）和 SW3的3號口（連接h4）分別與網關20.0.0.254關聯。這一過程好比在SDN內劃分了不的三層網段，并將設備物理接口與三層對應，類似為以太網劃分 VLAN和增加三層虛接口的過程。然后對各個Host的主機IP地址、子網掩碼和默 認網關進行逐一設置。在Mininet提示符mininet>下如下設置：

h1 ifconfig h1-eth0 10.0.0.1 netmask 255.0.0.0

h2 ifconfig h2-eth0 10.0.0.2 netmask 255.0.0.0

h3 ifconfig h3-eth0 20.0.0.1 netmask 255.0.0.0

h4 ifconfig h4-eth0 20.0.0.2 netmask 255.0.0.0

h1 route add default gw 10.0.0.254

h2 route add default gw 10.0.0.254

h3 route add default gw 20.0.0.254

h4 route add default gw 20.0.0.254

接著讓Host1 PING Host2，輸入h1 ping h2。

在SDN網絡中，處于末端的主機Host并不會知道其連接的網絡是SDN，某臺主機要發送數據包到另一臺主機，仍然需要進行IP到MAC地址的ARP解析。但SDN的處理機制與普通二層以太交換機洪泛 +MAC地址學習機制存在卻存在很大的差異，其過程如下：

當源主機h1（10.0.0.1）發出ARP解析 h2（10.0.0.2）后，交換機SW1并不知道如何轉發該包，因此將其通過OF消息發送到Controller處理。

Controller發現這個ARP消息是h1（10.0.0.1）發出，它也同時得到了h1的位置信息（OF包中會指出是哪個交換機的哪個端口發出了數據包）。此時Controller可以計算網絡拓撲，得到全網各節點到10.0.0.1的轉發路徑，并將轉發流表通過OF Flow Modify消息推送到每一臺交換機上。

由于收到了ARP，Controller會要求每一臺SW 所對應10.0.0.0/8網段的非SW互聯端口（只有這些端口是連接主機或傳統網絡的）發出ARP來請求 10.0.0.2的MAC地址。這里Controller并不是簡單的將收到ARP原封不動的發出，而是將源IP改為 10.0.0.254，也就是前面我們在Controller上配置的網關IP地址，然后發出。

只有h2（10.0.0.2）才會響應ARP，它將ARP Response發送到SW2。SW2也不知道如何處理，因此將ARP封裝在OF協議中發送到Controller。Controller發現這是ARP響應，而之前正是10.0.0.1發送的ARP請求，因此它會將該ARP通過OF協議發到 SW1，同時指示SW1將其送出的端口（也就是h1對 應的端口）。SW1執行這一操作。 Controller在收到h2的ARP后也得知了10.0.0.2的位置，它根據網絡拓撲計算，可以得到全網到達 10.0.0.2的轉發路徑，并將流表通過OF Flow Modify 消息推送到每一臺交換機上。

h1收到ARP Response后完成ARP解析過程，然后它構造ICMG PING Request數據包，其中源和目MAC分別為h1和h2的MAC，源和目IP分別為h1 和h2的IP。由于SW1和SW2都已經成功的裝載了到h1（10.0.0.2）的流表，因此該數據包將被順利發送到h2。

h2發現是ICMP PING Request，源是h1，但是此時它尚未有h1的MAC，于是還要進行一次ARP解析，SW2再次將ARP發送Controller，Controller已經得知h1的MAC，可直接響應，并通過OF向SW2返 回ARP結果和所需要送出的端口（h2接入的端口）。 h2學到ARP后，即可構造ICMP Response包，發送到SW2，SW2根據h1目的地址匹配轉發表將其轉發到SW1，SW1根據h1目的地址匹配轉發表將其發送到h1對應的端口。h1 到h2的雙向通道至此完全打通。

2.3SDN網絡三層轉發機制

在分析完二層轉發機制后，我們重新啟動拓撲結構，回到初始狀態（交換機上無任何流表），測試一下SDN如何實現兩個不同網段主機之間的轉發。輸入h1 ping h4，同時使用WireShark抓包，可發現如下結果：

對于三層轉發，主機首先判斷目的IP與自己不在同一網段內，因此要將數據包發向默認網關，在此之前它必須解析網關的MAC。h1發出ARP，請求 網關10.0.0.254的MAC。SW1不知道如何處理，將其通過OF協議發送到Controller。

Controller上配置了網關地址10.0.0.254，它即以自己的MAC地址回應ARP，并指示SW1將ARP響應發送到與h1相連的接口。同時Controller也知道了 h1的存在，通過路徑計算，得到每一臺交換機去往10.0.0.1的路徑，并通過OF Flow Modify將流表推送到每一臺交換機上。

主機h1收到網關的ARP，它構造ICMP PING Request數據包，其中源和目MAC分別為h1和網關 10.0.0.254的MAC，源和目IP分別為h1和h4的IP，此 包發向SW1。

SW1上并沒有到達20.0.0.2的流表，因此 將緩存這個數據包。同時SW1則也會將該包通過OF 協議發送到Controller，Controlller發現該包是要去向 20.0.0.2，而此目的主機位置未知。因此Controller會要求每一臺SW的對應20.0.0.0/8網段的非SW互聯端口發出ARP來請求20.0.0.2的SW2地址，其中ARP的源IP為20.0.0.0/8的網關地址20.0.0.254。

只有h4（20.0.0.2）才會響應ARP，它將ARP Response發送到SW2。SW2不知道如何處理，因此將ARP封裝在OF協議中發送到Controller。Controller 接到這個ARP響應，也同時得到了h4的位置是處于 SW2的某一端口之下。Controller通過路徑計算，得到每一臺交換機去往20.0.0.2的流表，并通過OF Flow Modify消息推流表到每一臺交換機上。

SW1在裝載流表后可向正確的接口上轉發 之前緩存的ICMP數據包，當然SW2也可順利轉發。 SW2還會該ICMP包的目的地址修改為h4的，以確保主機正確接收（之前Controller下發的目的地址 10.0.0.1流表中已指出這個操作）。

注：對與主機相鄰的交換機SW不僅要指該主機 所對應流的出端口，還需要對目的MAC地址進行改 寫以匹配主機MAC，因此下發的流表內有2個動作 （Action），對于二層轉發亦然。

此時h4會收到ICMP Request，它發現是不同網段主機發出的ICMP請求，因此仍要通過ARP解析出自己的默認網關。此請求發送到SW2后仍要通過OF 協議轉發到Controller，Controller用自己的MAC進行響應，然后通過OF協議發往SW2，并最終發送到h4。

主機h4收到ARP后可構造ICMP PING Response，其中源和目MAC分別為h4和網關 20.0.0.254的MAC，源和目IP分別為h4和h1的IP。此包發向SW2，然后經過SW1，同樣SW1在將其轉發到目的端口前會將目的MAC地址修改為h1的 MAC。之后h1 和h4之間的通道被完全打通。

當網絡的所有主機都完成一次的通信后，SDN 控制器就感知了所有網絡節點的狀態。通過控制器提供的界面，可以看到網絡的可視化視圖 （http：//192.168.56.1：8080），與我們之前給出的網絡拓撲完全一致！

讓我們觀察一下各交換機上的流表，可見每個交換機裝載了正確的流表。隨后SW將定期向 Controller匯報流的狀態，如匹配流的數量，轉發的字節數量、生存時間等。這些流和它們的狀態在 OpenDayLight的控制臺上都可以看到。

3　SDN應用于電信運營商網絡的場景初探

電信的傳統運營模式下，網絡一旦建成便很難做更改和調整。在業務開通和優化階段，要對海量的節點一一做配置，工作量大。SDN網絡能實現對全網的統一管理和配置，靈活組網，隨時響應新特性升級和新業務開通，而且由于SDN網絡的自動化部署和運維故障診斷，減少了網絡的人工干預，也降低了網絡的出錯率和維護費用，這也將直接影響到用戶體驗和感知。我們從兩個案例分析SDN如何解決目前電信網絡所遇到的問題，分別是二層環路問題和智能管道問題。

3.1SDN應用于電信接入網二層環路檢測和避免

傳統網絡中如果存在網絡環路，會致使廣播在交換機之間不斷惡性循環產生廣播風暴，在PON接入網維護中我們常常遇到這樣的問題，環路查錯需要大量時間，使大量用戶的業務受到波及而中斷。傳統以太網對二層網絡環路的解決辦法主要可以采用STP協議，STP通過阻斷冗余鏈路來消除網絡中的環路，在活動路徑發生故障時，便激活冗余鏈路，恢復網絡的連通性。但是STP協議的問題是網絡中大量端口處于閉塞狀態，網絡利用率低下，且收斂速度慢。

SDN基于網絡拓撲結構感知和流表下發的轉發方式可以解決環路問題，通過模擬發現，網絡中的主機都能實現與其它主機之間的雙向通信，并沒有受到環路影響。通過觀察交換機和控制器的流表，發現它們均采用最短路徑達到目標主機，因此網絡中沒有任何一條線路處于閉塞狀態，既避免了環路，又提升了網絡的利用效率。

3.2SDN應用于電信流量調度和智能管道

在傳統IP網絡中，轉發路徑是路由器之間通過運行各類路由協議，如RIPOSPFIS-ISBGP等路由協議，功能都是計算從源到目的最短路徑。在轉發時網絡上的路由器都會將網絡流量發送到最短路徑所對應的網絡接口，基于最短路徑優先的傳統IP網絡的缺點在于無法對網絡的流量實施控制，最短的路徑上可能集中了大量的網絡流量，部分鏈路可能極其繁忙，而其它鏈路可能得不到充分的利用，這在電信網絡運營商中十分普遍。而SDN的出現解決了這個問題，GOOGLE采用 SDN進行流量工程計算，其網絡利用率從原先傳統 IP方式的40%提升到了接近100%，此舉大大降低了廣域網的運營成本。我們通過調用SDN提供的API 接口實現了與GOOGLE類似的對流量控制模擬。

1）在正常情況下，10.0.0.6-10.0.0.7根據最 短路徑優先的原則進行轉發；

2）sw1和sw5流量擁塞，控制器可感知流量變化；通過調用API，向控制器下發策略，使 10.0.0.6到10.0.0.7的流量走長路徑，即 sw1-sw2-sw3-sw4-sw5，從而避開擁塞路徑；

3）sw1和sw5流量恢復正常，控制器可感知變化；通過調用API，向控制器下發策略，撤銷策略，使10.0.0.6-10.0.0.7的流量仍走回最短路徑，即 sw1-sw5 我們可交換機的轉發行為進行控制，比如S2進 行流表編程。需要下發兩條流表，一為從主機 h6（10.0.0.6）到主機h7（10.0.0.7），流的出接口為 S2的第2個接口；而另一條為反方向從h7到h6，流 的出接口為S2的第1個接口。

根據計算可以得到h6與h7路徑上的所有交換機上的轉發流表，將這些流報分別存于相關文件內，當需要時，就可以通過腳本下發到SDN控制器上，并觸發流更新，使網絡在h6-h7之間的生成一條新的轉發路徑。

4　小結

通過對OpenDayLight控制下SDN網絡轉發行為 分析和應用的實驗可以看到： OpenDayLight實現了控制和承載相分離，轉 發以整網的拓撲結構為基礎，Controller通過處理主 機之間、主機與網關之間的ARP報文來獲得主機的 位置，采用最短路徑優先算法計算到達目的主機的 流表并下發到網絡內的各個交換機上；Open DayLight不僅支持二層轉發還可支持三層轉發，實 現環路避免和廣播控制。

OpenDayLight控制下的SDN網絡上已經沒有 二/三層設備之分，網絡充分扁平化。同一SDN內，理論上可以在允許的地址范圍內為主機分配任意可用的IP地址。這種做法解除了主機位置與IP網段的緊耦合，避免了IP地址段的碎片不能得到利用的尷尬。同時交換機與交換機之間也無需配置大量互聯 IP地址，又節約了地址空間。

OpenDayLight不僅是一款軟件，同時也是一個開放的平臺，一個未來網絡架構的開放基礎。通過調用OpenDayLight的API接口，可以對網絡的流量進行感知，對轉發行為進行控制，從而達到原有網絡無法實現的控制能力，為運營商智能管道調控提供強大的手段。

網絡軟件化的趨勢將不可阻擋，SDN將在支持數據中心虛擬化、運營商智能管道、網絡安全方面大放異彩。

參考文獻

［1］OpenFlow規范：https：//www.opennetworking.org/sdnresources/onf-specifications/openflow

［2］OpenDayLight項目：http：//wiki.opendaylight.org/

［3］Mininet項目：http：//mininet.org/

［4］Virtual Box：https：//www.virtualbox.org/

［5］《走近Google基于SDN的B4網絡》：http：//www.csdn. net/article/2013-11-25/2817613