通信網(wǎng)banner.jpg)
相關(guān)專(zhuān)題：
SDN（Software Defined Network）軟件定義網(wǎng)絡(luò)，字面釋義都說(shuō)了是“軟件”來(lái)定義“網(wǎng)絡(luò)”，但有心之人會(huì)想：這個(gè)“軟件”到底是如何定義了我們所熟知的“網(wǎng)絡(luò)”？字字珠璣，今天就來(lái)扒一扒，這“軟件”到底是如何定義這“網(wǎng)絡(luò)”。
眾所周知，SDN軟件定義網(wǎng)絡(luò)，核心思想就是所謂的“轉(zhuǎn)發(fā)、控制分離”，正所謂一談SDN必談“轉(zhuǎn)發(fā)、控制”，一傳十十傳百，口口相傳。當(dāng)我們這些產(chǎn)品經(jīng)理到客戶(hù)現(xiàn)場(chǎng)交流SDN時(shí)，或許客戶(hù)也能娓娓道來(lái)“轉(zhuǎn)發(fā)、控制、分離”。但事實(shí)是怎么樣呢，不妨我們以SDN為題做個(gè)頭腦風(fēng)暴，看看談到SDN我們都想到了哪些關(guān)鍵詞，并以此來(lái)總結(jié)出SDN幾大特征庫(kù)。
SDN，也許你能想到這些：
歸結(jié)起來(lái)是這樣幾大特征：
Controller控制器集中控制：集中式/分布式控制器無(wú)非是把原本網(wǎng)絡(luò)設(shè)備從孤立的單點(diǎn)做了橫向的擴(kuò)張，將所有SDN化的網(wǎng)絡(luò)設(shè)備統(tǒng)一被控制。這就好比將N臺(tái)SDN小交換機(jī)“揉”成一臺(tái)SDN大交換機(jī)，統(tǒng)一管理，統(tǒng)一配置。
標(biāo)準(zhǔn)協(xié)議接口化：控制器與SDN設(shè)備之間的南向協(xié)議的標(biāo)準(zhǔn)化以及控制器北向API接口的標(biāo)準(zhǔn)化都是強(qiáng)調(diào)了SDN畢竟還是處理“網(wǎng)絡(luò)”的工作，應(yīng)用的事SDN“甭管”�？梢灶�(lèi)比到OSI七層模型，每層對(duì)應(yīng)了每層的工作，彼此調(diào)用互不干涉。
通用硬件：這里和NFV（Network Function Virtualization，網(wǎng)絡(luò)功能虛擬化）沒(méi)有關(guān)系。這里的SDN通用硬件指的是帶有SDN處理芯片的網(wǎng)絡(luò)設(shè)備或者是能實(shí)現(xiàn)SDN功能的網(wǎng)絡(luò)設(shè)備。并非NFV所強(qiáng)調(diào)的x86取代ASIC的設(shè)備。
正如下圖所示，把SDN抽象出來(lái)看，其實(shí)包括了這樣五個(gè)部分：
SDN網(wǎng)絡(luò)設(shè)備：網(wǎng)絡(luò)設(shè)備（硬件網(wǎng)絡(luò)設(shè)備或x86里面的軟件網(wǎng)絡(luò)設(shè)備，如vSR/vFW等）+SDN能力（可以是SDN芯片或開(kāi)啟SDN功能）
SDN控制器：能處理SDN功能的控制器，可以是軟件方式或軟件嵌入硬件的方式。常見(jiàn)的有：floodlight、POX、NOX、OpenDaylight、Ryu、NSX等
SDN APP：這更像是我們熟悉的網(wǎng)絡(luò)上層功能，例如QOS、路由功能、Overlay功能等等。相比于傳統(tǒng)網(wǎng)絡(luò)，原本孤立的管理/配置如今被SDN統(tǒng)一化了，一個(gè)APP代表了整個(gè)SDN管理域內(nèi)的所有此APP功能。好處就好比，網(wǎng)絡(luò)出口要防DDOS攻擊，調(diào)用了一個(gè)APP就能自動(dòng)做黑洞引流操作；又好比，領(lǐng)導(dǎo)要開(kāi)視頻會(huì)議，調(diào)用一個(gè)QOS的APP就能全局做帶寬質(zhì)量保障；又例如，通過(guò)SDN負(fù)載均衡APP，可以實(shí)現(xiàn)根據(jù)不同業(yè)務(wù)/參數(shù)進(jìn)行負(fù)載輪詢(xún)。
南向控制協(xié)議：這里場(chǎng)景的控制協(xié)議是Openflow，但絕非僅僅Openflow。可以實(shí)現(xiàn)控制功能的協(xié)議其實(shí)很多，除了最知名的Openflow以外，還有：Netconf、PCEP、LISP、MP-BGP、SNMP等等。
北向API：此API的主要作用在于提供SDN控制器及其以下部分（南向控制協(xié)議、網(wǎng)絡(luò)設(shè)備）能夠作為網(wǎng)絡(luò)驅(qū)動(dòng)供上層應(yīng)用調(diào)用。此上層應(yīng)用可以是各種APP，同樣也可以是Openstack、vCloud等云管理平臺(tái)。
SDN抽象的模型
.png)
通常情況下，啟用SDN的交換機(jī)可以分成兩種模式：純SDN交換機(jī)和混雜模式交換機(jī)。
純SDN交換機(jī)：交換機(jī)無(wú)腦工作，所有處理過(guò)程均依賴(lài)于Openflow或類(lèi)似南向控制協(xié)議，主流的有：BGP/LISP/SNMP/NETCONF等。此時(shí)的交換機(jī)也叫做白盒交換機(jī)，其中交換機(jī)簡(jiǎn)化很多芯片功能，但增強(qiáng)了流表轉(zhuǎn)發(fā)的功能，其中流表主要由ACL的TCAM芯片提供。只有這類(lèi)TCAM能匹配SDN里面的十五元組，可以根據(jù)組特性進(jìn)行轉(zhuǎn)發(fā)。
混雜模式交換機(jī)：顧名思義，混雜模式交換機(jī)就是帶有OPENFLOW功能的傳統(tǒng)交換機(jī)，可以根據(jù)需要將交換機(jī)的一部分轉(zhuǎn)換成SDN，而其實(shí)質(zhì)是傳統(tǒng)交換機(jī)，有所有相關(guān)的轉(zhuǎn)發(fā)、控制ASIC芯片。
Openflow標(biāo)準(zhǔn)定義了控制器與交換機(jī)之間的交互協(xié)議，以及一組交換機(jī)操作。這個(gè)控制器—交換機(jī)協(xié)議運(yùn)行在安全傳輸層協(xié)議(TLS)或無(wú)保護(hù)TCP連接之上。Openflow使用TCP端口6633或6653。
每個(gè)流表中每個(gè)流條目包括三個(gè)部分：
(1) 匹配match—使用ingress port，packet header以及前一個(gè)flow table傳遞過(guò)來(lái)的metadata；
(2) 計(jì)數(shù)counter---對(duì)匹配成功的包進(jìn)行計(jì)數(shù)；
(3) 操作instruction—修改action set或者流水線(xiàn)處理
交換機(jī)針對(duì)SDN有一個(gè)比較重要的消息類(lèi)型：Packet-In，主要針對(duì)未知數(shù)據(jù)流無(wú)法命中流表的時(shí)候，作上送控制器的操作。
同樣，SDN控制器也有一個(gè)比較重要的消息類(lèi)型：Packet-Out，主要針對(duì)下游SDN被管理設(shè)備，用于控制器指定從交換機(jī)的特定端口發(fā)送數(shù)據(jù)包，或者用于轉(zhuǎn)發(fā)通過(guò)Packet-in消息接收到的數(shù)據(jù)包。Packet-Out報(bào)文中包含明確的Action動(dòng)作。
接下來(lái)，通過(guò)兩個(gè)例子來(lái)展示“SDN新網(wǎng)絡(luò)”如何利用“軟件”解決傳統(tǒng)網(wǎng)絡(luò)中的問(wèn)題。同樣，可以幫助產(chǎn)品經(jīng)理能夠在跟客戶(hù)交流SDN的過(guò)程中，更深入的闡述SDN的大致工作過(guò)程，以“軟件定義”的角度來(lái)闡釋傳統(tǒng)網(wǎng)絡(luò)中常見(jiàn)的拓?fù)浒l(fā)現(xiàn)、ARP通訊等問(wèn)題。
SDN Controller通過(guò)Openflow和LLDP發(fā)現(xiàn)整網(wǎng)拓?fù)?/strong>
.png)
整網(wǎng)拓?fù)淙缟蠄D所示
背景闡述：
- 所有交換機(jī)彼此互聯(lián)
- 交換機(jī)通過(guò)帶外方式（或網(wǎng)管網(wǎng)方式）連接Controller
- 交換機(jī)均使用Openflow協(xié)議。Openflow使用TCP端口6633或6653作為接收的監(jiān)聽(tīng)端口。目前最新Openflow協(xié)議為1.5.1，詳見(jiàn)ONF的spec。（https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/Openflow/Openflow-switch-v1.5.1.pdf）
- 無(wú)特殊Controller指定，各類(lèi)型都OK
那對(duì)于傳統(tǒng)交換機(jī)而已，正常情況他們是通過(guò)LLDP等類(lèi)似的鄰居發(fā)現(xiàn)協(xié)議發(fā)現(xiàn)彼此網(wǎng)絡(luò)設(shè)備，形成整網(wǎng)拓?fù)�。而在SDN環(huán)境中，設(shè)備是無(wú)腦的，此時(shí)需要借助Openflow和LLDP同時(shí)工作，來(lái)保障Controller環(huán)境下能夠?qū)θW(wǎng)進(jìn)行拓?fù)浒l(fā)現(xiàn)。
工作流程介紹：
- 交換機(jī)連線(xiàn)至Controller，通過(guò)電信號(hào)，Controller發(fā)現(xiàn)有支持Openflow的SDN交換機(jī)接入，此時(shí)，Controller能夠發(fā)現(xiàn)三臺(tái)SDN交換機(jī)接入了。注意，此時(shí)三臺(tái)設(shè)備之間的組網(wǎng)環(huán)境Controller是不清楚的。
- Controller通過(guò)packet-out報(bào)文，封裝LLDP報(bào)文進(jìn)Openflow，分別分發(fā)給每個(gè)交換機(jī)。此時(shí)的packet-out報(bào)文中含有動(dòng)作：分發(fā)LLDP報(bào)文從交換機(jī)的每個(gè)端口發(fā)出去。
- 此時(shí)交換機(jī)A根據(jù)Controller的動(dòng)作指令，將LLDP報(bào)文從交換機(jī)所有接口發(fā)出去。交換機(jī)B和交換機(jī)C此時(shí)都能收到這個(gè)報(bào)文。
- LLDP報(bào)文經(jīng)過(guò)交換機(jī)之間的互聯(lián)鏈路到達(dá)對(duì)端SDN交換機(jī)。而此時(shí)正因?yàn)榻粨Q機(jī)是SDN無(wú)腦交換機(jī)，他對(duì)于報(bào)文的處理都是上送Controller而非本地操作。則此時(shí)接受到LLDP的對(duì)端交換機(jī)會(huì)將LLDP報(bào)文再次封裝，封裝進(jìn)packet-in，并上送至Controller。
- 此時(shí)Controller收到對(duì)端SDN交換機(jī)封裝的packet-in報(bào)文，報(bào)文里包含原本的LLDP報(bào)文。此時(shí)Controller就已經(jīng)知道所有的拓?fù)溥B接關(guān)系了。
SDN控制器對(duì)于ARP報(bào)文的處理
.png)
背景闡述：
網(wǎng)絡(luò)拓?fù)湟寻l(fā)現(xiàn)
- 控制器采用ODL（OpenDayLight）
- 本地主機(jī)H1（10.0.0.1）和對(duì)端主機(jī)H2（10.0.0.2）均連接于SDN交換機(jī)下面
- 整個(gè)過(guò)程是H1請(qǐng)求H2的ARP，H2響應(yīng)H1
整個(gè)解析過(guò)程
- H1去pingH2，即10.0.0.1去ping10.0.0.2。因?yàn)闆](méi)有H2的MAC，此時(shí)需要做一次ARP解析。此時(shí)ARP請(qǐng)求（原本是廣播）被SwitchA通過(guò)Openflow形式單播上送給Controller（packet-in報(bào)文）
- Controller收到H1的ARP請(qǐng)求，記錄H1位于Switch A下游，且記錄相關(guān)的位置信息。
- 正因?yàn)镃ontroller有所有交換機(jī)的拓?fù)浼拔恢眯畔�，此時(shí)Controller會(huì)給全網(wǎng)中每臺(tái)SDN交換機(jī)都發(fā)送一個(gè)10.0.0.0/8網(wǎng)段的ARP請(qǐng)求消息，來(lái)請(qǐng)求10.0.0.2的MAC地址。但源IP并非10.0.0.1，而是Controller的網(wǎng)關(guān)地址，此處為10.0.0.254。此時(shí)報(bào)文均為packet-out，即通過(guò)Controller手工泛洪，但此泛洪是有選擇性的，只針對(duì)同網(wǎng)段（10.0.0.0/8）
- 所有交換機(jī)都能收到此ARP單播請(qǐng)求，而只有Switch B會(huì)做出回應(yīng)，因?yàn)镠2接在Switch B下游。此時(shí)通過(guò)packet-in，所有SDN交換機(jī)會(huì)將此ARP泛洪發(fā)送到同網(wǎng)段的端口。
- H2收到此時(shí)的ARP請(qǐng)求，正常做出回應(yīng)。
- Switch B收到H2的ARP響應(yīng)，無(wú)腦上送到Controller。Controller收到ARP響應(yīng)，發(fā)現(xiàn)正是前面發(fā)出的ARP請(qǐng)求的響應(yīng)報(bào)文。記錄此時(shí)的H2位置信息及ARP信息。
- Controller通過(guò)Openflow將ARP響應(yīng)回應(yīng)給Switch A，Switch A將報(bào)文回送給H1。
- 此時(shí)做個(gè)小結(jié)，Controller已經(jīng)完整知道SwitchA/SwitchB/H1/H2的位置信息及MAC/ARP信息。Switch A/H1知道完整的ARP/MAC信息。而SwitchB也有H1/H2的完整IP。唯獨(dú)H2此時(shí)只知道H1的IP，而不知道H1的MAC。
- H1的整個(gè)ARP請(qǐng)求過(guò)程已經(jīng)完成。接下來(lái)要輸送ICMP請(qǐng)求報(bào)文。報(bào)文經(jīng)由Switch A正常輸送到H2（此時(shí)是實(shí)際轉(zhuǎn)發(fā)流量，而且Switch A已有完整轉(zhuǎn)發(fā)路徑，不需要再上送Controller）
- H2收到ICMP報(bào)文，想要回應(yīng)，但是沒(méi)有H1的MAC，需要再次做ARP請(qǐng)求。此時(shí)H2請(qǐng)求H1的MAC地址，報(bào)文被Switch B上送Controller，Controller已有H1的MAC，則Controller做出回應(yīng)，將H1的MAC回應(yīng)給H2。
- H2收到ARP，則整個(gè)過(guò)程完整。回應(yīng)ICMP報(bào)文。整個(gè)業(yè)務(wù)流打通。
可以看到，最關(guān)鍵的應(yīng)該是第三步，即Controller發(fā)送偽裝ARP報(bào)文給全局同網(wǎng)段交換機(jī)，以此來(lái)實(shí)現(xiàn)ARP廣播的同樣效果。但也正是這樣一個(gè)看似合理的安全行為，帶來(lái)了很多不安全的隱患�？梢韵胂�，Controller有幾種方式可以獲取終端主機(jī)的MAC情況：1.通過(guò)免費(fèi)ARP的方式、2.定時(shí)申請(qǐng)下游終端的MAC方式，都可以保證對(duì)下游終端MAC的始終更新。
但同樣，集中Controller的方式也帶來(lái)了單點(diǎn)安全的風(fēng)險(xiǎn)考慮，一旦一臺(tái)下游主機(jī)中毒，不斷變化自己的MAC不斷做出更新動(dòng)作，此時(shí)會(huì)極大消耗Controller的資源，形成DOS攻擊。同樣，Controller的安全如果不是很堅(jiān)固，則一旦被攻破，所有終端信息一覽無(wú)余。
拋磚引玉，SDN的安全還有很多路要走。
作者：王彬 來(lái)源：廠(chǎng)商供稿
