用戶名: 密碼: 驗證碼:

SDN中“軟件”如何定義“網(wǎng)絡”

摘要:SDN(Software Defined Network)軟件定義網(wǎng)絡,字面釋義都說了是“軟件”來定義“網(wǎng)絡”,但有心之人會想:這個“軟件”到底是如何定義了我們所熟知的“網(wǎng)絡”?

  ICCSZ訊   SDN(Software Defined Network)軟件定義網(wǎng)絡,字面釋義都說了是“軟件”來定義“網(wǎng)絡”,但有心之人會想:這個“軟件”到底是如何定義了我們所熟知的“網(wǎng)絡”?字字珠璣,今天就來扒一扒,這“軟件”到底是如何定義這“網(wǎng)絡”。

  眾所周知,SDN軟件定義網(wǎng)絡,核心思想就是所謂的“轉(zhuǎn)發(fā)、控制分離”,正所謂一談SDN必談“轉(zhuǎn)發(fā)、控制”,一傳十十傳百,口口相傳。當我們這些產(chǎn)品經(jīng)理到客戶現(xiàn)場交流SDN時,或許客戶也能娓娓道來“轉(zhuǎn)發(fā)、控制、分離”。但事實是怎么樣呢,不妨我們以SDN為題做個頭腦風暴,看看談到SDN我們都想到了哪些關鍵詞,并以此來總結(jié)出SDN幾大特征庫。

  SDN,也許你能想到這些:

  

 

  歸結(jié)起來是這樣幾大特征:

  Controller控制器集中控制:集中式/分布式控制器無非是把原本網(wǎng)絡設備從孤立的單點做了橫向的擴張,將所有SDN化的網(wǎng)絡設備統(tǒng)一被控制。這就好比將N臺SDN小交換機“揉”成一臺SDN大交換機,統(tǒng)一管理,統(tǒng)一配置。

  標準協(xié)議接口化:控制器與SDN設備之間的南向協(xié)議的標準化以及控制器北向API接口的標準化都是強調(diào)了SDN畢竟還是處理“網(wǎng)絡”的工作,應用的事SDN“甭管”。可以類比到OSI七層模型,每層對應了每層的工作,彼此調(diào)用互不干涉。

  通用硬件:這里和NFV(Network Function Virtualization,網(wǎng)絡功能虛擬化)沒有關系。這里的SDN通用硬件指的是帶有SDN處理芯片的網(wǎng)絡設備或者是能實現(xiàn)SDN功能的網(wǎng)絡設備。并非NFV所強調(diào)的x86取代ASIC的設備。

  正如下圖所示,把SDN抽象出來看,其實包括了這樣五個部分:

  SDN網(wǎng)絡設備:網(wǎng)絡設備(硬件網(wǎng)絡設備或x86里面的軟件網(wǎng)絡設備,如vSR/vFW等)+SDN能力(可以是SDN芯片或開啟SDN功能)

  SDN控制器:能處理SDN功能的控制器,可以是軟件方式或軟件嵌入硬件的方式。常見的有:floodlight、POX、NOX、OpenDaylight、Ryu、NSX等

  SDN APP:這更像是我們熟悉的網(wǎng)絡上層功能,例如QOS、路由功能、Overlay功能等等。相比于傳統(tǒng)網(wǎng)絡,原本孤立的管理/配置如今被SDN統(tǒng)一化了,一個APP代表了整個SDN管理域內(nèi)的所有此APP功能。好處就好比,網(wǎng)絡出口要防DDOS攻擊,調(diào)用了一個APP就能自動做黑洞引流操作;又好比,領導要開視頻會議,調(diào)用一個QOS的APP就能全局做帶寬質(zhì)量保障;又例如,通過SDN負載均衡APP,可以實現(xiàn)根據(jù)不同業(yè)務/參數(shù)進行負載輪詢。

  南向控制協(xié)議:這里場景的控制協(xié)議是Openflow,但絕非僅僅Openflow??梢詫崿F(xiàn)控制功能的協(xié)議其實很多,除了最知名的Openflow以外,還有:Netconf、PCEP、LISP、MP-BGP、SNMP等等。

  北向API:此API的主要作用在于提供SDN控制器及其以下部分(南向控制協(xié)議、網(wǎng)絡設備)能夠作為網(wǎng)絡驅(qū)動供上層應用調(diào)用。此上層應用可以是各種APP,同樣也可以是Openstack、vCloud等云管理平臺。

  SDN抽象的模型

  

 

  通常情況下,啟用SDN的交換機可以分成兩種模式:純SDN交換機和混雜模式交換機。

  純SDN交換機:交換機無腦工作,所有處理過程均依賴于Openflow或類似南向控制協(xié)議,主流的有:BGP/LISP/SNMP/NETCONF等。此時的交換機也叫做白盒交換機,其中交換機簡化很多芯片功能,但增強了流表轉(zhuǎn)發(fā)的功能,其中流表主要由ACL的TCAM芯片提供。只有這類TCAM能匹配SDN里面的十五元組,可以根據(jù)組特性進行轉(zhuǎn)發(fā)。

  混雜模式交換機:顧名思義,混雜模式交換機就是帶有OPENFLOW功能的傳統(tǒng)交換機,可以根據(jù)需要將交換機的一部分轉(zhuǎn)換成SDN,而其實質(zhì)是傳統(tǒng)交換機,有所有相關的轉(zhuǎn)發(fā)、控制ASIC芯片。

  Openflow標準定義了控制器與交換機之間的交互協(xié)議,以及一組交換機操作。這個控制器—交換機協(xié)議運行在安全傳輸層協(xié)議(TLS)或無保護TCP連接之上。Openflow使用TCP端口6633或6653。

  每個流表中每個流條目包括三個部分:

  (1) 匹配match—使用ingress port,packet header以及前一個flow table傳遞過來的metadata;

  (2) 計數(shù)counter---對匹配成功的包進行計數(shù);

  (3) 操作instruction—修改action set或者流水線處理

  交換機針對SDN有一個比較重要的消息類型:Packet-In,主要針對未知數(shù)據(jù)流無法命中流表的時候,作上送控制器的操作。

  同樣,SDN控制器也有一個比較重要的消息類型:Packet-Out,主要針對下游SDN被管理設備,用于控制器指定從交換機的特定端口發(fā)送數(shù)據(jù)包,或者用于轉(zhuǎn)發(fā)通過Packet-in消息接收到的數(shù)據(jù)包。Packet-Out報文中包含明確的Action動作。

  接下來,通過兩個例子來展示“SDN新網(wǎng)絡”如何利用“軟件”解決傳統(tǒng)網(wǎng)絡中的問題。同樣,可以幫助產(chǎn)品經(jīng)理能夠在跟客戶交流SDN的過程中,更深入的闡述SDN的大致工作過程,以“軟件定義”的角度來闡釋傳統(tǒng)網(wǎng)絡中常見的拓撲發(fā)現(xiàn)、ARP通訊等問題。

  SDN Controller通過Openflow和LLDP發(fā)現(xiàn)整網(wǎng)拓撲

  

 

  整網(wǎng)拓撲如上圖所示

  背景闡述:

  所有交換機彼此互聯(lián)

  交換機通過帶外方式(或網(wǎng)管網(wǎng)方式)連接Controller

  交換機均使用Openflow協(xié)議。Openflow使用TCP端口6633或6653作為接收的監(jiān)聽端口。目前最新Openflow協(xié)議為1.5.1,詳見ONF的spec。(https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/Openflow/Openflow-switch-v1.5.1.pdf)

  無特殊Controller指定,各類型都OK

  那對于傳統(tǒng)交換機而已,正常情況他們是通過LLDP等類似的鄰居發(fā)現(xiàn)協(xié)議發(fā)現(xiàn)彼此網(wǎng)絡設備,形成整網(wǎng)拓撲。而在SDN環(huán)境中,設備是無腦的,此時需要借助Openflow和LLDP同時工作,來保障Controller環(huán)境下能夠?qū)θW(wǎng)進行拓撲發(fā)現(xiàn)。

  工作流程介紹:

  交換機連線至Controller,通過電信號,Controller發(fā)現(xiàn)有支持Openflow的SDN交換機接入,此時,Controller能夠發(fā)現(xiàn)三臺SDN交換機接入了。注意,此時三臺設備之間的組網(wǎng)環(huán)境Controller是不清楚的。

  Controller通過packet-out報文,封裝LLDP報文進Openflow,分別分發(fā)給每個交換機。此時的packet-out報文中含有動作:分發(fā)LLDP報文從交換機的每個端口發(fā)出去。

  此時交換機A根據(jù)Controller的動作指令,將LLDP報文從交換機所有接口發(fā)出去。交換機B和交換機C此時都能收到這個報文。

  LLDP報文經(jīng)過交換機之間的互聯(lián)鏈路到達對端SDN交換機。而此時正因為交換機是SDN無腦交換機,他對于報文的處理都是上送Controller而非本地操作。則此時接受到LLDP的對端交換機會將LLDP報文再次封裝,封裝進packet-in,并上送至Controller。

  此時Controller收到對端SDN交換機封裝的packet-in報文,報文里包含原本的LLDP報文。此時Controller就已經(jīng)知道所有的拓撲連接關系了。

  SDN控制器對于ARP報文的處理

  

 

  背景闡述:

  網(wǎng)絡拓撲已發(fā)現(xiàn)

  控制器采用ODL(OpenDayLight)

  本地主機H1(10.0.0.1)和對端主機H2(10.0.0.2)均連接于SDN交換機下面

  整個過程是H1請求H2的ARP,H2響應H1

  整個解析過程

  H1去pingH2,即10.0.0.1去ping10.0.0.2。因為沒有H2的MAC,此時需要做一次ARP解析。此時ARP請求(原本是廣播)被SwitchA通過Openflow形式單播上送給Controller(packet-in報文)

  Controller收到H1的ARP請求,記錄H1位于Switch A下游,且記錄相關的位置信息。

  正因為Controller有所有交換機的拓撲及位置信息,此時Controller會給全網(wǎng)中每臺SDN交換機都發(fā)送一個10.0.0.0/8網(wǎng)段的ARP請求消息,來請求10.0.0.2的MAC地址。但源IP并非10.0.0.1,而是Controller的網(wǎng)關地址,此處為10.0.0.254。此時報文均為packet-out,即通過Controller手工泛洪,但此泛洪是有選擇性的,只針對同網(wǎng)段(10.0.0.0/8)

  所有交換機都能收到此ARP單播請求,而只有Switch B會做出回應,因為H2接在Switch B下游。此時通過packet-in,所有SDN交換機會將此ARP泛洪發(fā)送到同網(wǎng)段的端口。

  H2收到此時的ARP請求,正常做出回應。

  Switch B收到H2的ARP響應,無腦上送到Controller。Controller收到ARP響應,發(fā)現(xiàn)正是前面發(fā)出的ARP請求的響應報文。記錄此時的H2位置信息及ARP信息。

  Controller通過Openflow將ARP響應回應給Switch A,Switch A將報文回送給H1。

  此時做個小結(jié),Controller已經(jīng)完整知道SwitchA/SwitchB/H1/H2的位置信息及MAC/ARP信息。Switch A/H1知道完整的ARP/MAC信息。而SwitchB也有H1/H2的完整IP。唯獨H2此時只知道H1的IP,而不知道H1的MAC。

  H1的整個ARP請求過程已經(jīng)完成。接下來要輸送ICMP請求報文。報文經(jīng)由Switch A正常輸送到H2(此時是實際轉(zhuǎn)發(fā)流量,而且Switch A已有完整轉(zhuǎn)發(fā)路徑,不需要再上送Controller)

  H2收到ICMP報文,想要回應,但是沒有H1的MAC,需要再次做ARP請求。此時H2請求H1的MAC地址,報文被Switch B上送Controller,Controller已有H1的MAC,則Controller做出回應,將H1的MAC回應給H2。

  H2收到ARP,則整個過程完整?;貞狪CMP報文。整個業(yè)務流打通。

  可以看到,最關鍵的應該是第三步,即Controller發(fā)送偽裝ARP報文給全局同網(wǎng)段交換機,以此來實現(xiàn)ARP廣播的同樣效果。但也正是這樣一個看似合理的安全行為,帶來了很多不安全的隱患??梢韵胂螅珻ontroller有幾種方式可以獲取終端主機的MAC情況:1.通過免費ARP的方式、2.定時申請下游終端的MAC方式,都可以保證對下游終端MAC的始終更新。

  但同樣,集中Controller的方式也帶來了單點安全的風險考慮,一旦一臺下游主機中毒,不斷變化自己的MAC不斷做出更新動作,此時會極大消耗Controller的資源,形成DOS攻擊。同樣,Controller的安全如果不是很堅固,則一旦被攻破,所有終端信息一覽無余。

內(nèi)容來自:C114
本文地址:http://m.odinmetals.com//Site/CN/News/2015/06/30/20150630002717533000.htm 轉(zhuǎn)載請保留文章出處
關鍵字: SDN
文章標題:SDN中“軟件”如何定義“網(wǎng)絡”
【加入收藏夾】  【推薦給好友】 
免責聲明:凡本網(wǎng)注明“訊石光通訊咨詢網(wǎng)”的所有作品,版權(quán)均屬于光通訊咨詢網(wǎng),未經(jīng)本網(wǎng)授權(quán)不得轉(zhuǎn)載、摘編或利用其它方式使用上述作品。 已經(jīng)本網(wǎng)授權(quán)使用作品的,應在授權(quán)范圍內(nèi)使用,反上述聲明者,本網(wǎng)將追究其相關法律責任。
※我們誠邀媒體同行合作! 聯(lián)系方式:訊石光通訊咨詢網(wǎng)新聞中心 電話:0755-82960080-188   debison