SDN網(wǎng)絡(luò)轉(zhuǎn)發(fā)機(jī)制研究和應(yīng)用場(chǎng)景分析

胡曉宇中國電信股份有限公司上海分公司網(wǎng)絡(luò)操作維護(hù)中心

?

SDN網(wǎng)絡(luò)轉(zhuǎn)發(fā)機(jī)制研究和應(yīng)用場(chǎng)景分析

胡曉宇
中國電信股份有限公司上海分公司網(wǎng)絡(luò)操作維護(hù)中心

摘要：SDN無疑是當(dāng)前網(wǎng)絡(luò)業(yè)界最熱門的研究課題之一，SDN體現(xiàn)了控制和轉(zhuǎn)發(fā)相分離的原則，為網(wǎng)絡(luò)和業(yè)務(wù)的創(chuàng)新帶來了蓬勃的生機(jī)和活力。文章通過構(gòu)建OpenDayLight控制器與Mininet交換模擬器相結(jié)合的測(cè)試環(huán)境，研究了SDN環(huán)境下二/三層網(wǎng)絡(luò)交換的轉(zhuǎn)發(fā)機(jī)制和特性，并對(duì)SDN在網(wǎng)絡(luò)中的應(yīng)用提出了設(shè)想。

關(guān)鍵字：SDN OpenDayLight Mininet 二/三層交換

1　SDN簡介

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

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

光有控制器還不能構(gòu)成完整SDN網(wǎng)，但當(dāng)前硬 件SDN交換機(jī)還很少，也很難找到。幸好有 Mininet推出了基于軟件模擬的交換機(jī)。Mininet項(xiàng)目也是開源的軟件，通過Mininet，在一臺(tái)Linux主機(jī)內(nèi)可以構(gòu)造并模擬多臺(tái)SDN交換機(jī)和終端。使用Python腳本，使用者還可以配置較為復(fù)雜的SDN 網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。同時(shí)Mininet還配備了WireShark抓包軟件，方便SDN開發(fā)者和學(xué)習(xí)者進(jìn)行開發(fā)和研究。

2　基于Opendaylight的SDN網(wǎng)絡(luò)轉(zhuǎn)發(fā)機(jī)制分析

2.1創(chuàng)建和啟動(dòng)SDN網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)

在測(cè)試中我們創(chuàng)建了如下的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，1 臺(tái)OpenDayLight控制器（簡稱Controller，版本為0.1 版），2臺(tái)交換機(jī)（SW），每臺(tái)SW分別連接2臺(tái)主機(jī) （Host），一共4臺(tái)主機(jī)，這些主機(jī)分屬于2個(gè)不同的網(wǎng)段，交換機(jī)與控制器之間采用OpenFlow協(xié)議（簡 稱OF）。

首先在測(cè)試機(jī)（Windows XP系統(tǒng)）上運(yùn)行run.bat 批處理文件啟動(dòng)OpenDayLight，然后在VirtualBox中載入Mininet虛擬機(jī)映像并運(yùn)行。測(cè)試網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)由Python腳本生成，文件保存于虛擬機(jī) /mnt/shared目錄下的topo2_2.py文件內(nèi)：

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（））｝

啟動(dòng)測(cè)試環(huán)境，使用以下命令生成測(cè)試拓?fù)浣Y(jié)構(gòu)：sudo mn--custom /mnt/shared/topo2_2.py--topo mytopo，--controller=remote ip=192.168.56.1。通過啟動(dòng)抓包軟件WireShark可以看到SW向Controller的注冊(cè)過程。在注冊(cè)過程中，Controller會(huì)要求SW提供 OpenFlow版本號(hào)，設(shè)備連接的端口等狀態(tài)等信息。SW1將自己所連接的4個(gè)端口情況上報(bào)給Controller（其中包括與Controller相連的端口），同樣 SW2也會(huì)上報(bào)自己的狀態(tài)。

當(dāng)SW設(shè)備完成設(shè)備注冊(cè)后，Controller將進(jìn)行網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)的發(fā)現(xiàn)或更新。當(dāng)網(wǎng)絡(luò)中有一臺(tái)新的 SW接入后，Controller通過OF Packet Out指令要求SW1 在其所有端口上發(fā)出LLDP（Link Layer Discovery Protocol，EEE802.1ab）鏈路探測(cè)包。LLDP的源MAC 為Controller分配，這里為00：00：00：00：00：01（對(duì)每一個(gè)交換機(jī)，Controller都會(huì)分配一個(gè)這樣的MAC作為 SW標(biāo)識(shí)），LLDP目的MAC地址為組播地址。相鄰的 SW2將接收到LLDP，SW2由于無法識(shí)別這條流，會(huì)將OF協(xié)議再發(fā)到Controller上。通過LLDP的發(fā)送和接收，Controller可計(jì)算出交換機(jī)之間的拓?fù)潢P(guān)系，網(wǎng)絡(luò)的拓?fù)潢P(guān)系可作為轉(zhuǎn)發(fā)流表生成和實(shí)現(xiàn)網(wǎng)絡(luò)可視化的基礎(chǔ)。（注：與交換機(jī)SW相鄰的主機(jī)也會(huì)收到 LLDP，但并不會(huì)處理）

2.2SDN網(wǎng)絡(luò)二轉(zhuǎn)發(fā)機(jī)制

生成網(wǎng)絡(luò)拓?fù)浜?，還要在Controller上為每一個(gè)三層網(wǎng)段設(shè)置一個(gè)網(wǎng)關(guān)地址（即使是二層轉(zhuǎn)發(fā)也必須設(shè)置），然后將交換機(jī)的接口與三層網(wǎng)關(guān)相關(guān)聯(lián)。這里將SW1的2號(hào)（連接h1）和SW3的2號(hào)口（連接h2）分別與網(wǎng)關(guān)10.0.0.254關(guān)聯(lián)，將SW1的3號(hào)（連接h3）和 SW3的3號(hào)口（連接h4）分別與網(wǎng)關(guān)20.0.0.254關(guān)聯(lián)。這一過程好比在SDN內(nèi)劃分了不的三層網(wǎng)段，并將設(shè)備物理接口與三層對(duì)應(yīng)，類似為以太網(wǎng)劃分 VLAN和增加三層虛接口的過程。然后對(duì)各個(gè)Host的主機(jī)IP地址、子網(wǎng)掩碼和默 認(rèn)網(wǎng)關(guān)進(jìn)行逐一設(shè)置。在Mininet提示符mininet>下如下設(shè)置：

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網(wǎng)絡(luò)中，處于末端的主機(jī)Host并不會(huì)知道其連接的網(wǎng)絡(luò)是SDN，某臺(tái)主機(jī)要發(fā)送數(shù)據(jù)包到另一臺(tái)主機(jī)，仍然需要進(jìn)行IP到MAC地址的ARP解析。但SDN的處理機(jī)制與普通二層以太交換機(jī)洪泛 +MAC地址學(xué)習(xí)機(jī)制存在卻存在很大的差異，其過程如下：

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

Controller發(fā)現(xiàn)這個(gè)ARP消息是h1（10.0.0.1）發(fā)出，它也同時(shí)得到了h1的位置信息（OF包中會(huì)指出是哪個(gè)交換機(jī)的哪個(gè)端口發(fā)出了數(shù)據(jù)包）。此時(shí)Controller可以計(jì)算網(wǎng)絡(luò)拓?fù)洌玫饺W(wǎng)各節(jié)點(diǎn)到10.0.0.1的轉(zhuǎn)發(fā)路徑，并將轉(zhuǎn)發(fā)流表通過OF Flow Modify消息推送到每一臺(tái)交換機(jī)上。

由于收到了ARP，Controller會(huì)要求每一臺(tái)SW 所對(duì)應(yīng)10.0.0.0/8網(wǎng)段的非SW互聯(lián)端口（只有這些端口是連接主機(jī)或傳統(tǒng)網(wǎng)絡(luò)的）發(fā)出ARP來請(qǐng)求 10.0.0.2的MAC地址。這里Controller并不是簡單的將收到ARP原封不動(dòng)的發(fā)出，而是將源IP改為 10.0.0.254，也就是前面我們?cè)贑ontroller上配置的網(wǎng)關(guān)IP地址，然后發(fā)出。

只有h2（10.0.0.2）才會(huì)響應(yīng)ARP，它將ARP Response發(fā)送到SW2。SW2也不知道如何處理，因此將ARP封裝在OF協(xié)議中發(fā)送到Controller。Controller發(fā)現(xiàn)這是ARP響應(yīng)，而之前正是10.0.0.1發(fā)送的ARP請(qǐng)求，因此它會(huì)將該ARP通過OF協(xié)議發(fā)到 SW1，同時(shí)指示SW1將其送出的端口（也就是h1對(duì) 應(yīng)的端口）。SW1執(zhí)行這一操作。 Controller在收到h2的ARP后也得知了10.0.0.2的位置，它根據(jù)網(wǎng)絡(luò)拓?fù)溆?jì)算，可以得到全網(wǎng)到達(dá) 10.0.0.2的轉(zhuǎn)發(fā)路徑，并將流表通過OF Flow Modify 消息推送到每一臺(tái)交換機(jī)上。

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

h2發(fā)現(xiàn)是ICMP PING Request，源是h1，但是此時(shí)它尚未有h1的MAC，于是還要進(jìn)行一次ARP解析，SW2再次將ARP發(fā)送Controller，Controller已經(jīng)得知h1的MAC，可直接響應(yīng)，并通過OF向SW2返 回ARP結(jié)果和所需要送出的端口（h2接入的端口）。 h2學(xué)到ARP后，即可構(gòu)造ICMP Response包，發(fā)送到SW2，SW2根據(jù)h1目的地址匹配轉(zhuǎn)發(fā)表將其轉(zhuǎn)發(fā)到SW1，SW1根據(jù)h1目的地址匹配轉(zhuǎn)發(fā)表將其發(fā)送到h1對(duì)應(yīng)的端口。h1 到h2的雙向通道至此完全打通。

2.3SDN網(wǎng)絡(luò)三層轉(zhuǎn)發(fā)機(jī)制

在分析完二層轉(zhuǎn)發(fā)機(jī)制后，我們重新啟動(dòng)拓?fù)浣Y(jié)構(gòu)，回到初始狀態(tài)（交換機(jī)上無任何流表），測(cè)試一下SDN如何實(shí)現(xiàn)兩個(gè)不同網(wǎng)段主機(jī)之間的轉(zhuǎn)發(fā)。輸入h1 ping h4，同時(shí)使用WireShark抓包，可發(fā)現(xiàn)如下結(jié)果：

對(duì)于三層轉(zhuǎn)發(fā)，主機(jī)首先判斷目的IP與自己不在同一網(wǎng)段內(nèi)，因此要將數(shù)據(jù)包發(fā)向默認(rèn)網(wǎng)關(guān)，在此之前它必須解析網(wǎng)關(guān)的MAC。h1發(fā)出ARP，請(qǐng)求 網(wǎng)關(guān)10.0.0.254的MAC。SW1不知道如何處理，將其通過OF協(xié)議發(fā)送到Controller。

Controller上配置了網(wǎng)關(guān)地址10.0.0.254，它即以自己的MAC地址回應(yīng)ARP，并指示SW1將ARP響應(yīng)發(fā)送到與h1相連的接口。同時(shí)Controller也知道了 h1的存在，通過路徑計(jì)算，得到每一臺(tái)交換機(jī)去往10.0.0.1的路徑，并通過OF Flow Modify將流表推送到每一臺(tái)交換機(jī)上。

主機(jī)h1收到網(wǎng)關(guān)的ARP，它構(gòu)造ICMP PING Request數(shù)據(jù)包，其中源和目MAC分別為h1和網(wǎng)關(guān) 10.0.0.254的MAC，源和目IP分別為h1和h4的IP，此 包發(fā)向SW1。

SW1上并沒有到達(dá)20.0.0.2的流表，因此 將緩存這個(gè)數(shù)據(jù)包。同時(shí)SW1則也會(huì)將該包通過OF 協(xié)議發(fā)送到Controller，Controlller發(fā)現(xiàn)該包是要去向 20.0.0.2，而此目的主機(jī)位置未知。因此Controller會(huì)要求每一臺(tái)SW的對(duì)應(yīng)20.0.0.0/8網(wǎng)段的非SW互聯(lián)端口發(fā)出ARP來請(qǐng)求20.0.0.2的SW2地址，其中ARP的源IP為20.0.0.0/8的網(wǎng)關(guān)地址20.0.0.254。

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

SW1在裝載流表后可向正確的接口上轉(zhuǎn)發(fā) 之前緩存的ICMP數(shù)據(jù)包，當(dāng)然SW2也可順利轉(zhuǎn)發(fā)。 SW2還會(huì)該ICMP包的目的地址修改為h4的，以確保主機(jī)正確接收（之前Controller下發(fā)的目的地址 10.0.0.1流表中已指出這個(gè)操作）。

注：對(duì)與主機(jī)相鄰的交換機(jī)SW不僅要指該主機(jī) 所對(duì)應(yīng)流的出端口，還需要對(duì)目的MAC地址進(jìn)行改 寫以匹配主機(jī)MAC，因此下發(fā)的流表內(nèi)有2個(gè)動(dòng)作 （Action），對(duì)于二層轉(zhuǎn)發(fā)亦然。

此時(shí)h4會(huì)收到ICMP Request，它發(fā)現(xiàn)是不同網(wǎng)段主機(jī)發(fā)出的ICMP請(qǐng)求，因此仍要通過ARP解析出自己的默認(rèn)網(wǎng)關(guān)。此請(qǐng)求發(fā)送到SW2后仍要通過OF 協(xié)議轉(zhuǎn)發(fā)到Controller，Controller用自己的MAC進(jìn)行響應(yīng)，然后通過OF協(xié)議發(fā)往SW2，并最終發(fā)送到h4。

主機(jī)h4收到ARP后可構(gòu)造ICMP PING Response，其中源和目MAC分別為h4和網(wǎng)關(guān) 20.0.0.254的MAC，源和目IP分別為h4和h1的IP。此包發(fā)向SW2，然后經(jīng)過SW1，同樣SW1在將其轉(zhuǎn)發(fā)到目的端口前會(huì)將目的MAC地址修改為h1的 MAC。之后h1 和h4之間的通道被完全打通。

當(dāng)網(wǎng)絡(luò)的所有主機(jī)都完成一次的通信后，SDN 控制器就感知了所有網(wǎng)絡(luò)節(jié)點(diǎn)的狀態(tài)。通過控制器提供的界面，可以看到網(wǎng)絡(luò)的可視化視圖 （http：//192.168.56.1：8080），與我們之前給出的網(wǎng)絡(luò)拓?fù)渫耆恢拢?/p>

讓我們觀察一下各交換機(jī)上的流表，可見每個(gè)交換機(jī)裝載了正確的流表。隨后SW將定期向 Controller匯報(bào)流的狀態(tài)，如匹配流的數(shù)量，轉(zhuǎn)發(fā)的字節(jié)數(shù)量、生存時(shí)間等。這些流和它們的狀態(tài)在 OpenDayLight的控制臺(tái)上都可以看到。

3　SDN應(yīng)用于電信運(yùn)營商網(wǎng)絡(luò)的場(chǎng)景初探

電信的傳統(tǒng)運(yùn)營模式下，網(wǎng)絡(luò)一旦建成便很難做更改和調(diào)整。在業(yè)務(wù)開通和優(yōu)化階段，要對(duì)海量的節(jié)點(diǎn)一一做配置，工作量大。SDN網(wǎng)絡(luò)能實(shí)現(xiàn)對(duì)全網(wǎng)的統(tǒng)一管理和配置，靈活組網(wǎng)，隨時(shí)響應(yīng)新特性升級(jí)和新業(yè)務(wù)開通，而且由于SDN網(wǎng)絡(luò)的自動(dòng)化部署和運(yùn)維故障診斷，減少了網(wǎng)絡(luò)的人工干預(yù)，也降低了網(wǎng)絡(luò)的出錯(cuò)率和維護(hù)費(fèi)用，這也將直接影響到用戶體驗(yàn)和感知。我們從兩個(gè)案例分析SDN如何解決目前電信網(wǎng)絡(luò)所遇到的問題，分別是二層環(huán)路問題和智能管道問題。

3.1SDN應(yīng)用于電信接入網(wǎng)二層環(huán)路檢測(cè)和避免

傳統(tǒng)網(wǎng)絡(luò)中如果存在網(wǎng)絡(luò)環(huán)路，會(huì)致使廣播在交換機(jī)之間不斷惡性循環(huán)產(chǎn)生廣播風(fēng)暴，在PON接入網(wǎng)維護(hù)中我們常常遇到這樣的問題，環(huán)路查錯(cuò)需要大量時(shí)間，使大量用戶的業(yè)務(wù)受到波及而中斷。傳統(tǒng)以太網(wǎng)對(duì)二層網(wǎng)絡(luò)環(huán)路的解決辦法主要可以采用STP協(xié)議，STP通過阻斷冗余鏈路來消除網(wǎng)絡(luò)中的環(huán)路，在活動(dòng)路徑發(fā)生故障時(shí)，便激活冗余鏈路，恢復(fù)網(wǎng)絡(luò)的連通性。但是STP協(xié)議的問題是網(wǎng)絡(luò)中大量端口處于閉塞狀態(tài)，網(wǎng)絡(luò)利用率低下，且收斂速度慢。

SDN基于網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)感知和流表下發(fā)的轉(zhuǎn)發(fā)方式可以解決環(huán)路問題，通過模擬發(fā)現(xiàn)，網(wǎng)絡(luò)中的主機(jī)都能實(shí)現(xiàn)與其它主機(jī)之間的雙向通信，并沒有受到環(huán)路影響。通過觀察交換機(jī)和控制器的流表，發(fā)現(xiàn)它們均采用最短路徑達(dá)到目標(biāo)主機(jī)，因此網(wǎng)絡(luò)中沒有任何一條線路處于閉塞狀態(tài)，既避免了環(huán)路，又提升了網(wǎng)絡(luò)的利用效率。

3.2SDN應(yīng)用于電信流量調(diào)度和智能管道

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

1）在正常情況下，10.0.0.6-10.0.0.7根據(jù)最 短路徑優(yōu)先的原則進(jìn)行轉(zhuǎn)發(fā)；

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

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

根據(jù)計(jì)算可以得到h6與h7路徑上的所有交換機(jī)上的轉(zhuǎn)發(fā)流表，將這些流報(bào)分別存于相關(guān)文件內(nèi)，當(dāng)需要時(shí)，就可以通過腳本下發(fā)到SDN控制器上，并觸發(fā)流更新，使網(wǎng)絡(luò)在h6-h7之間的生成一條新的轉(zhuǎn)發(fā)路徑。

4　小結(jié)

通過對(duì)OpenDayLight控制下SDN網(wǎng)絡(luò)轉(zhuǎn)發(fā)行為 分析和應(yīng)用的實(shí)驗(yàn)可以看到： OpenDayLight實(shí)現(xiàn)了控制和承載相分離，轉(zhuǎn) 發(fā)以整網(wǎng)的拓?fù)浣Y(jié)構(gòu)為基礎(chǔ)，Controller通過處理主 機(jī)之間、主機(jī)與網(wǎng)關(guān)之間的ARP報(bào)文來獲得主機(jī)的 位置，采用最短路徑優(yōu)先算法計(jì)算到達(dá)目的主機(jī)的 流表并下發(fā)到網(wǎng)絡(luò)內(nèi)的各個(gè)交換機(jī)上；Open DayLight不僅支持二層轉(zhuǎn)發(fā)還可支持三層轉(zhuǎn)發(fā)，實(shí) 現(xiàn)環(huán)路避免和廣播控制。

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

OpenDayLight不僅是一款軟件，同時(shí)也是一個(gè)開放的平臺(tái)，一個(gè)未來網(wǎng)絡(luò)架構(gòu)的開放基礎(chǔ)。通過調(diào)用OpenDayLight的API接口，可以對(duì)網(wǎng)絡(luò)的流量進(jìn)行感知，對(duì)轉(zhuǎn)發(fā)行為進(jìn)行控制，從而達(dá)到原有網(wǎng)絡(luò)無法實(shí)現(xiàn)的控制能力，為運(yùn)營商智能管道調(diào)控提供強(qiáng)大的手段。

網(wǎng)絡(luò)軟件化的趨勢(shì)將不可阻擋，SDN將在支持?jǐn)?shù)據(jù)中心虛擬化、運(yùn)營商智能管道、網(wǎng)絡(luò)安全方面大放異彩。

參考文獻(xiàn)

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

［2］OpenDayLight項(xiàng)目：http：//wiki.opendaylight.org/

［3］Mininet項(xiàng)目：http：//mininet.org/

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

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