SDN（Software Defined Network）軟件定義網絡，字面釋義都說了是“軟件”來定義“網絡”，但有心之人會想：這個“軟件”到底是如何定義了我們所熟知的“網絡”？字字珠璣，今天就來扒一扒，這“軟件”到底是如何定義這“網絡”。

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

SDN，也許你能想到這些：

歸結起來是這樣幾大特征：

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

標準協議接口化：控制器與SDN設備之間的南向協議的標準化以及控制器北向API接口的標準化都是強調了SDN畢竟還是處理“網絡”的工作，應用的事SDN“甭管”?？梢灶惐鹊絆SI七層模型，每層對應了每層的工作，彼此調用互不干涉。

通用硬件：這里和NFV（Network Function Virtualization，網絡功能虛擬化）沒有關系。這里的SDN通用硬件指的是帶有SDN處理芯片的網絡設備或者是能實現SDN功能的網絡設備。并非NFV所強調的x86取代ASIC的設備。

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

SDN網絡設備：網絡設備（硬件網絡設備或x86里面的軟件網絡設備，如vSR/vFW等）+SDN能力（可以是SDN芯片或開啟SDN功能）

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

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

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

北向API：此API的主要作用在于提供SDN控制器及其以下部分（南向控制協議、網絡設備）能夠作為網絡驅動供上層應用調用。此上層應用可以是各種APP，同樣也可以是Openstack、vCloud等云管理平臺。

SDN抽象的模型

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

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

混雜模式交換機：顧名思義，混雜模式交換機就是帶有OPENFLOW功能的傳統交換機，可以根據需要將交換機的一部分轉換成SDN，而其實質是傳統交換機，有所有相關的轉發、控制ASIC芯片。

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

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

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

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

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

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

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

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

SDN Controller通過Openflow和LLDP發現整網拓撲

整網拓撲如上圖所示

背景闡述：

1. 所有交換機彼此互聯
2. 交換機通過帶外方式（或網管網方式）連接Controller
3. 交換機均使用Openflow協議。Openflow使用TCP端口6633或6653作為接收的監聽端口。目前最新Openflow協議為1.5.1，詳見ONF的spec。（https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/Openflow/Openflow-switch-v1.5.1.pdf）
4. 無特殊Controller指定，各類型都OK

那對于傳統交換機而已，正常情況他們是通過LLDP等類似的鄰居發現協議發現彼此網絡設備，形成整網拓撲。而在SDN環境中，設備是無腦的，此時需要借助Openflow和LLDP同時工作，來保障Controller環境下能夠對全網進行拓撲發現。

工作流程介紹：

1. 交換機連線至Controller，通過電信號，Controller發現有支持Openflow的SDN交換機接入，此時，Controller能夠發現三臺SDN交換機接入了。注意，此時三臺設備之間的組網環境Controller是不清楚的。
2. Controller通過packet-out報文，封裝LLDP報文進Openflow，分別分發給每個交換機。此時的packet-out報文中含有動作：分發LLDP報文從交換機的每個端口發出去。
3. 此時交換機A根據Controller的動作指令，將LLDP報文從交換機所有接口發出去。交換機B和交換機C此時都能收到這個報文。
4. LLDP報文經過交換機之間的互聯鏈路到達對端SDN交換機。而此時正因為交換機是SDN無腦交換機，他對于報文的處理都是上送Controller而非本地操作。則此時接受到LLDP的對端交換機會將LLDP報文再次封裝，封裝進packet-in，并上送至Controller。
5. 此時Controller收到對端SDN交換機封裝的packet-in報文，報文里包含原本的LLDP報文。此時Controller就已經知道所有的拓撲連接關系了。

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

背景闡述：

網絡拓撲已發現

1. 控制器采用ODL（OpenDayLight）
2. 本地主機H1（10.0.0.1）和對端主機H2（10.0.0.2）均連接于SDN交換機下面
3. 整個過程是H1請求H2的ARP，H2響應H1

整個解析過程

1. H1去pingH2，即10.0.0.1去ping10.0.0.2。因為沒有H2的MAC，此時需要做一次ARP解析。此時ARP請求（原本是廣播）被SwitchA通過Openflow形式單播上送給Controller（packet-in報文）
2. Controller收到H1的ARP請求，記錄H1位于Switch A下游，且記錄相關的位置信息。
3. 正因為Controller有所有交換機的拓撲及位置信息，此時Controller會給全網中每臺SDN交換機都發送一個10.0.0.0/8網段的ARP請求消息，來請求10.0.0.2的MAC地址。但源IP并非10.0.0.1，而是Controller的網關地址，此處為10.0.0.254。此時報文均為packet-out，即通過Controller手工泛洪，但此泛洪是有選擇性的，只針對同網段（10.0.0.0/8）
4. 所有交換機都能收到此ARP單播請求，而只有Switch B會做出回應，因為H2接在Switch B下游。此時通過packet-in，所有SDN交換機會將此ARP泛洪發送到同網段的端口。
5. H2收到此時的ARP請求，正常做出回應。
6. Switch B收到H2的ARP響應，無腦上送到Controller。Controller收到ARP響應，發現正是前面發出的ARP請求的響應報文。記錄此時的H2位置信息及ARP信息。
7. Controller通過Openflow將ARP響應回應給Switch A，Switch A將報文回送給H1。
8. 此時做個小結，Controller已經完整知道SwitchA/SwitchB/H1/H2的位置信息及MAC/ARP信息。Switch A/H1知道完整的ARP/MAC信息。而SwitchB也有H1/H2的完整IP。唯獨H2此時只知道H1的IP，而不知道H1的MAC。
9. H1的整個ARP請求過程已經完成。接下來要輸送ICMP請求報文。報文經由Switch A正常輸送到H2（此時是實際轉發流量，而且Switch A已有完整轉發路徑，不需要再上送Controller）
10. H2收到ICMP報文，想要回應，但是沒有H1的MAC，需要再次做ARP請求。此時H2請求H1的MAC地址，報文被Switch B上送Controller，Controller已有H1的MAC，則Controller做出回應，將H1的MAC回應給H2。
11. H2收到ARP，則整個過程完整?；貞狪CMP報文。整個業務流打通。

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

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

拋磚引玉，SDN的安全還有很多路要走。

附：SDN Controller哪個最受歡迎

http://www.sdnap.com/sdnap-post/485.html