sdn培訓課程課件

SDN基礎(chǔ)SDN基礎(chǔ)1學習SDN需要的基礎(chǔ)知識傳統(tǒng)的網(wǎng)絡(luò)基礎(chǔ)知識（網(wǎng)絡(luò)工程師)osi七層模型路由（OSPF等等）、交換（ARPVLAN、MAC）tcp/ip4-7層應(yīng)用（loadbanalancefirewallipswaf)Linux操作系統(tǒng)相關(guān)知識（系統(tǒng)工程師）軟件安裝、配置、系統(tǒng)維護命令、虛擬器語言（程序員）JavaC（控制器源代碼、開發(fā)應(yīng)用）

學習SDN需要的基礎(chǔ)知識傳統(tǒng)的網(wǎng)絡(luò)基礎(chǔ)知識（網(wǎng)絡(luò)工程師)Sdn全景圖為什么需要sdn以及sdn解決的問題南向接口、Openflow協(xié)議Controller介紹—*—

Openstack介紹、

Quantu組件Mininet模擬器Opendaylight控制器傳統(tǒng)交換工作原理、與SDN比較SDN產(chǎn)業(yè)格局SDN應(yīng)用案例SDN總體架構(gòu)課程總體框架與SDN相關(guān)的NFV技術(shù)SDN應(yīng)用案例Controller與交換機之間交互數(shù)據(jù)Sdn全景圖為什么需要sdn以及sdn解決的問題南向接口、OSDN是什么，不是什么SDN是SoftwareDefinedNetwork的縮寫Network而非networking表明是一種框架，一種網(wǎng)絡(luò)設(shè)計理念，而非一種構(gòu)建技術(shù)Ospf(openshortestpathfirst)mpls(MultiprotocolLabelSwitching)stp(spanningtreeprotocol)SDN是什么，不是什么SDN是SoftwareDefinSdn起源Sdn公認的起源地是美國斯坦福大學MartinCasadoNickMcKeownSdn起源Sdn公認的起源地是美國斯坦福大學Ethane項目一個關(guān)于網(wǎng)絡(luò)安全與管理的科研項目。這個項目試圖通過一個集中的網(wǎng)絡(luò)控制器，讓網(wǎng)絡(luò)管理員可以方便的定義基于網(wǎng)絡(luò)流的安全控制策略，并且應(yīng)用到網(wǎng)絡(luò)設(shè)備中。受此項目啟發(fā)，如果將傳統(tǒng)網(wǎng)絡(luò)設(shè)備的數(shù)據(jù)轉(zhuǎn)發(fā)（dataplane)和路由控制（controlplane)兩個功能模塊分離提供，通過集中式的控制器以標準化的接口對各種網(wǎng)絡(luò)設(shè)備進行管理和配置，那么將為網(wǎng)絡(luò)資源的設(shè)計、管理和使用提供更多可能性。好的架構(gòu)都是演進來的---Ethane項目Ethane項目好的架構(gòu)都是演進來的---Ethane項目NOX控制器，用來集中控制控制器與設(shè)備之間的Openflow協(xié)議.希望每臺交換機提供一個標準化的統(tǒng)一接口?；趏penflow為網(wǎng)絡(luò)帶來的可編程的特性，提出了SDN的概念。另外一種說法，KateGreen于2009年在TechnologyReview網(wǎng)站上評選年度十大前沿技術(shù)時提出。NOX控制器，用來集中控制技術(shù)變革源于需求數(shù)據(jù)中心的資源：計算、存儲、網(wǎng)絡(luò)新技術(shù)：服務(wù)器虛擬化、存儲虛擬化、自動化管理工具傳統(tǒng)網(wǎng)絡(luò)很難滿足不斷變化的數(shù)據(jù)中心的需求。技術(shù)變革源于需求數(shù)據(jù)中心的資源：計算、存儲、網(wǎng)絡(luò)傳統(tǒng)網(wǎng)絡(luò)瓶頸電信的可用級別是5個9，高度依賴于單個設(shè)備的高可用性隨著云計算、云數(shù)據(jù)中心技術(shù)的發(fā)展，需要網(wǎng)絡(luò)配置更快速、更靈活。傳統(tǒng)網(wǎng)絡(luò)設(shè)備是封閉的黑盒子，對應(yīng)用開放接口很少（snmp,telnet),無法滿足新業(yè)務(wù)加載需要。傳統(tǒng)網(wǎng)絡(luò)瓶頸電信的可用級別是5個9，高度依賴于單個設(shè)備的高可SDN如何解決這些問題控制平面、轉(zhuǎn)發(fā)平面分離，集中化部署。提供可編程接口，應(yīng)用加載更靈活。高可用性依賴于分布式的大規(guī)模網(wǎng)絡(luò)。SDN如何解決這些問題控制平面、轉(zhuǎn)發(fā)平面分離，集中化部署。SDN相關(guān)組織中科信軟高級技術(shù)培訓中心－SDN相關(guān)組織中科信軟高級技術(shù)培訓中心－sdn培訓課程課件從幾個方面看網(wǎng)絡(luò)使用者驅(qū)動

組織的發(fā)起者GoogleFacebook和微軟等公司都不是網(wǎng)絡(luò)設(shè)備的制造商ONFOverviewONF董事會成員有十幾個，無一來自設(shè)備廠商，全部都是網(wǎng)絡(luò)服務(wù)提供商、電信運營商甚至風險投資商員工。他們的觀點是董事會里只有用戶和網(wǎng)絡(luò)運營商，負責做出所有重要決定，他們控制著前進的方向，定義標準的接口，任何一家廠商都無法控制用戶。從幾個方面看網(wǎng)絡(luò)使用者驅(qū)動 組織的發(fā)起者GoogleONF工作ONFOpenflow1.11.21.31.4的標準，OF-Config協(xié)議1.01.1推動全球范圍的SDN研討，廠商之間交換機、控制器互通測試。ONF工作ONFOpenflow1.11.21ONF組織架構(gòu)

BoardofDirectors（董事會）TechnicalAdvisoryGroup（技術(shù)顧問組）ChipMakers’AdvisoryBoard(芯片商顧問委員會）

成員全部來自全球知名的芯片廠，目前國內(nèi)只有huaweiztecentecWorkingGroups

ONF組織架構(gòu) BoardofDirectors（董事ONFPlugfestTestingandoperability工作組負責

包括標準一致性的測試和互聯(lián)互通的測試。每年負責組織Plugfest測試活動。ONFPlugfestTestingandoperaONFPlugfest 2012年，參與廠商很少2014年5月，中國和美國對接測試，很多國內(nèi)的廠商參與。ONFPlugfest 2012年，參與廠商很少ODL（opendaylight) 中科信軟高級技術(shù)培訓中心－ODL（opendaylight) 中科信軟高級技術(shù)培訓中心ODL背景ODL不算是SDN標準組織，是一個推進SDN發(fā)展，實現(xiàn)一個開源的SDNcontroller的組織，不制定SDN相關(guān)標準Ciscojuniper等廠商希望繼續(xù)自己的領(lǐng)導地位。ONF成立并推動SDN的動機之一就是防止廠商鎖定，ODL是想繼續(xù)維持現(xiàn)有產(chǎn)業(yè)格局。ONF最初制定者（大學教授、學生）對網(wǎng)絡(luò)的考慮欠缺，導致產(chǎn)品很難商業(yè)化，需要廠商來參與完善，使SDN趨于成熟ODL背景ODL不算是SDN標準組織，是一個推進SDN發(fā)展，ONF和ODL的利益沖突產(chǎn)業(yè)界出于自身利益考慮，圍繞網(wǎng)絡(luò)開放方式（南向、北向）和程度尚存在較大分歧,ONF強調(diào)“南向”接口開放，OpenDaylight強調(diào)“北向”接口開放推動“南向接口”的標準化ONF希望徹底擺脫廠商鎖定，所以希望所有接口標注化南向接口可以百花齊放，認為sdn最核心的就是控制和轉(zhuǎn)發(fā)分析，南向不需要標準化。一方面希望推動sdn發(fā)展，另一方面又希望保留廠商的定制的權(quán)利，特別是不規(guī)定轉(zhuǎn)發(fā)面的硬件的標準化。ONF和ODL的利益沖突產(chǎn)業(yè)界出于自身利益考慮，圍繞網(wǎng)絡(luò)其他的一些組織

中科信軟高級技術(shù)培訓中心－其他的一些組織 中科信軟高級技術(shù)培訓中心－Sdn架構(gòu)應(yīng)用層、控制層（控制平面）轉(zhuǎn)發(fā)層（轉(zhuǎn)發(fā)平面）北向接口南向接口Sdn架構(gòu)應(yīng)用層、北向接口南向接口三個層次、兩個接口

應(yīng)用層、控制層、轉(zhuǎn)發(fā)層南向接口、北向接口三個層次、兩個接口 應(yīng)用層、控制層、轉(zhuǎn)發(fā)層應(yīng)用層、控制層、轉(zhuǎn)發(fā)層應(yīng)用層Loadbalancefirewallnatqosips自動拓撲生成控制層各種控制器轉(zhuǎn)發(fā)層

硬件交換機、軟件的交換機（ovs)SDN交換機和傳統(tǒng)交換機融合應(yīng)用層、控制層、轉(zhuǎn)發(fā)層應(yīng)用層南向、北向接口南向接口（主要指Openflow）

南向接口是傳統(tǒng)網(wǎng)絡(luò)的術(shù)語，被借用過來。南向接口指的是控制平面跟數(shù)據(jù)轉(zhuǎn)發(fā)平面之間的接口。北向接口（例如Restapi)

傳統(tǒng)網(wǎng)絡(luò)里，北向接口是指交換機控制平面和網(wǎng)管軟件之間的接口，比如snmp.在SDN里，指控制平面controller跟應(yīng)用程序之間的接口，目前該接口尚無標準。比南向接口復雜，應(yīng)用層業(yè)務(wù)千變?nèi)f化。南向、北向接口南向接口（主要指Openflow）業(yè)界比較認可的SDN特征屬性控制面與轉(zhuǎn)發(fā)面分離開放的可編程接口集中化的網(wǎng)絡(luò)控制網(wǎng)絡(luò)業(yè)務(wù)的自動化應(yīng)用程序控制業(yè)界比較認可的SDN特征屬性控制面與轉(zhuǎn)發(fā)面分離傳統(tǒng)網(wǎng)絡(luò)cisco的三層模型傳統(tǒng)網(wǎng)絡(luò)cisco的三層模型傳統(tǒng)網(wǎng)絡(luò)的三層與sdn區(qū)別

逐設(shè)備單獨控制，純分布式控制控制面和轉(zhuǎn)發(fā)面在同一個設(shè)備中，緊密耦合管理員無法直接操作轉(zhuǎn)發(fā)行為（管理員配置網(wǎng)絡(luò)協(xié)議，網(wǎng)絡(luò)協(xié)議通過自身的運行去影響轉(zhuǎn)發(fā)行為，無法改變協(xié)議本身的行為）傳統(tǒng)網(wǎng)絡(luò)的三層與sdn區(qū)別 逐設(shè)備單獨控制，純分布式控制控制面與轉(zhuǎn)發(fā)面分離

傳統(tǒng)的交換機。雙控制卡，端口卡。控制面與轉(zhuǎn)發(fā)面分離

傳統(tǒng)的交換機。ControllerSDN的至高點Controller，廠商搶占的至高點，ControllerSDN的至高點Controller從功能層面controller分為以下幾個模塊：底層通信模塊：openflow中目前controller與switch之間使用的是socket連接，所以控制器底層的通信是socket。openflow協(xié)議。socket收到的數(shù)據(jù)的處理規(guī)則需按照openflow協(xié)議去處理。上層應(yīng)用：根據(jù)openflow協(xié)議處理后的數(shù)據(jù)，開發(fā)上層應(yīng)用，比如pox中就l2_learning,l3_learning等應(yīng)用。更多的應(yīng)用需要用戶自己去開發(fā)。從功能層面controller分為以下幾個模塊：對sdn的誤解SDN一定要使用Openflow協(xié)議來配置轉(zhuǎn)發(fā)面OpenFlow只是發(fā)展最早、目前影響力最大的南向接口，但并不是唯一的。Opendaylight已經(jīng)提出了新的接口，包括現(xiàn)存的以及新定義的，PCEP、netconf、XMPP對sdn的誤解SDN一定要使用Openflow協(xié)議來配置轉(zhuǎn)發(fā)對sdn的誤解SDN設(shè)備都是靠靜態(tài)配置的sDNController都是集中式的對sdn的誤解SDN設(shè)備都是靠靜態(tài)配置的Openflow協(xié)議詳解Openflow是先于SDN提出的。SDN框架里，不規(guī)定任何具體的技術(shù)實現(xiàn)，。而Openflow是一個具體的協(xié)議，這個協(xié)議實現(xiàn)了SDN這個框架里的南向接口。SDN是獨一無二的，但是Openflow有競爭者。前面提到，控制面和轉(zhuǎn)發(fā)面通過標準的接口進行通信，這個接口稱為南向接口。Openflow用來控制設(shè)備，網(wǎng)絡(luò)設(shè)備反饋信息給控制器。Openflow協(xié)議詳解Openflow是先于SDN提出的。Openflow標準分析

Openflow從1.0開始，歷經(jīng)1.1、1.2、1.3，現(xiàn)在已經(jīng)到了1.4.控制面和轉(zhuǎn)發(fā)面的功能都逐漸豐富，但是仍在不斷的演進之中。Openflow標準分析 Openflow從1.0開始，歷經(jīng)Openflow標準分析Openflow一部分運行在Controller上，一部分運行在Switch上。具體定義了Controller如何來控制交換機，交換機如何來反饋的一系列過程。兩者之間的消息格式、消息類型，一系列標準術(shù)語。Openflow標準分析Openflow一部分運行在ContOpenflow交換機的主要部件可以認為在邏輯上由兩部分組成：端口（Port）和流表（Flowtable）

OpenFlow的交換機包括一個或多個流表和一組表，執(zhí)行分組查找和轉(zhuǎn)發(fā)，和到一個外部控制器OpenFlow的信道，用于交換機與控制器進行通信，控制器通過OpenFlow協(xié)議來管理交換機。Openflow交換機的主要部件可以認為在邏輯上由兩部分組成openflow的switch可以從以下方式獲得實體of交換機，目前市場上有一些廠商已經(jīng)制造出of交換機，但是普遍反映價格較貴！性能最好。在實體機上安裝OVS，OVS可以使計算機變成一個openflow交換機。性能相對穩(wěn)定。使用mininet模擬環(huán)境?？梢源罱ㄔS多交換機，任意拓撲，性能依賴虛擬機的性能。openflow的switch可以從以下方式獲得Openflow端口OpenFlow交換機必須支持三種類型的OpenFlow的端口：物理端口，邏輯端口和保留端口物理端口OpenFlow的物理端口為交換機定義的端口，對應(yīng)于一個交換機的硬件接口。例如，以太網(wǎng)交換機上的物理端口與以太網(wǎng)接口一一對應(yīng)。在某些部署中，OpenFlow交換機可以實現(xiàn)交換機的硬件虛擬化。在這些情況下，一個OpenFlow物理端口可以代表一個與交換機硬件接口對應(yīng)的虛擬切片。Openflow端口OpenFlow交換機必須支持三種類型邏輯端口OpenFlow的邏輯端口為交換機定義的端口，并不直接對應(yīng)一個交換機的硬件接口。邏輯端口是更高層次的抽象概念，可能是交換機中不使用OpenFlow的端口（如鏈路匯聚組，隧道，環(huán)回接口）。邏輯端口可能包括報文封裝，可以映射到不同的物理端口。這些邏輯端口的處理動作相對于openflow處理來說必須是透明的，而且這些端口必須通過openflow處理起作用，像硬件接口一樣。物理端口和邏輯端口之間的唯一區(qū)別是：一個邏輯端口的數(shù)據(jù)包可能有一個叫做隧道ID的額外的元數(shù)據(jù)字段與它相關(guān)聯(lián)；而當一個邏輯端口上接收到的分組被發(fā)送到控制器時，其邏輯端口和底層的物理端口都要報告給控制器。邏輯端口OpenFlow的邏輯端口為交換機定義的端口，并不直保留端口OpenFlow的保留端口。它們指定通用的轉(zhuǎn)發(fā)動作，如發(fā)送到控制器，泛洪，或使用非OpenFlow的方法轉(zhuǎn)發(fā)，如“正?！苯粨Q機處理。某些交換機只支持那些標記為“Required”的保留端口，至于“Optional”的端口可以根據(jù)需要可選。保留端口OpenFlow的保留端口。它們指定通用的轉(zhuǎn)發(fā)動作，Required保留端口Required:ALL:表示交換機轉(zhuǎn)發(fā)特定數(shù)據(jù)包到所有端口，它僅可用于為輸出端口。在這種情況下，數(shù)據(jù)包被復制后發(fā)送到所有的標準端口，包括數(shù)據(jù)包的入端口，這些端口被配置OFPPC_NO_FWD。?Required:CONTROLLER:表示的OpenFlow控制器的控制通道，它可以用作一個入端口或作為一個出端口。當用作一個出端口，封裝數(shù)據(jù)包中為數(shù)據(jù)包消息，并使用的OpenFlow協(xié)議發(fā)送（見A.4.1）。當用作一個入口端口，確認來自控制器的數(shù)據(jù)包。?Required:TABLE:表示openflow流水線的開始。這個端口僅在輸出行為的時候有效，此時交換機提交報文給第一流表使數(shù)據(jù)包可以通過定期通過OpenFlow流水線處理。?Required:INPORT:代表數(shù)據(jù)包進入端口。用于輸出端口時，只允許入端口發(fā)送的數(shù)據(jù)包通過。?Required:ANY:特別值，用在未指定端口的OpenFlow指令（端口通配符）。不能使用的入口端口，也不作為一個輸出端口。Required保留端口Required:ALL:表示交可選保留端口Optional:LOCAL:表示交換機的本地網(wǎng)絡(luò)堆棧和管理堆棧。可以用作一個入口端口或作為一個輸出端口。本地端口使遠程實體通過OpenFlow網(wǎng)絡(luò)和交換機以及其網(wǎng)絡(luò)服務(wù)互通，而不是通過一個單獨的控制網(wǎng)絡(luò)進行互通。使用一組合適的默認流表項，本地端口可以用來實現(xiàn)一個帶內(nèi)控制器的連接。?Optional:NORMAL:代表傳統(tǒng)的非OpenFlow流水線（見5.1）。僅可用于為一個輸出端口，使用普通的流水線處理數(shù)據(jù)包。如果交換機不能轉(zhuǎn)發(fā)數(shù)據(jù)包從OpenFlow流水線到普通流水線，它必須表明它不支持這一行動。?Optional:FLOOD:表示使用普通流水線處理進行泛洪（見5.1）?？捎糜谧鳛橐粋€輸出端口，一般可以講數(shù)據(jù)包發(fā)往所有標準端口，但不能發(fā)往入端口或OFPPS_BLOCKED狀態(tài)的端口。交換機也可以通過數(shù)據(jù)包的VLANID選擇哪些端口泛洪。只有OpenFlow-only交換機不支持NORMAL端口和FLOOD端口，而OpenFlow-hybrid交換機均支持上述端口（見5.1）。轉(zhuǎn)發(fā)數(shù)據(jù)包到FLOOD端口依賴交換機上的實現(xiàn)和配置，而使用一組類型進行轉(zhuǎn)發(fā)可以使控制器能夠更靈活地實現(xiàn)泛洪可選保留端口Optional:LOCAL:表示交換機的本交換機處理包流程Controller告訴交換機，當報文進來哪些port的時候，就查哪些流表，匹配一條表項（Flowentry）之后，執(zhí)行這條流表項規(guī)定的指令，轉(zhuǎn)發(fā)、丟棄、執(zhí)行查找下一個流表交換機處理包流程Controller告訴交換機，當報文進來哪

控制器使用OpenFlow的協(xié)議，它可以添加、更新和刪除流流表中的表項，既主動或者被動響應(yīng)數(shù)據(jù)包。在交換機中的每個流表中包含的一組流表項;每個流表項包含匹配字段，計數(shù)器和一組指令，用來匹配數(shù)據(jù)包匹配開始于第一個流程表，并可能會繼續(xù)額外的流表。流表項匹配數(shù)據(jù)包按照優(yōu)先級的順序，從每個表的第一個匹配表項開始。如果找到匹配的項，那么具體流表項按照指令去執(zhí)行。如果在流表中未找到匹配項，結(jié)果取決于漏表的流表項配置：（例如，數(shù)據(jù)包可被轉(zhuǎn)發(fā)到OpenFlow的信道控制器、丟棄、或者可以繼續(xù)到下一個的流表）sdn培訓課程課件OpenFlow兼容的交換機有兩種類型：OpenFlow-only和OpenFlow-hybrid。OpenFlow-only交換機只支持OpenFlow操作，在這些交換機中的所有數(shù)據(jù)包都由OpenFlow流水線處理，否則不能被處理。OpenFlow-hybrid交換機支持OpenFlow的操作和普通的以太網(wǎng)交換操作，即傳統(tǒng)的L2以太網(wǎng)交換，VLAN隔離，L3路由（IPv4的路由，IPv6路由），ACL和QoS處理。這些交換機提供一個交換機外的分類機制，使流量路由到OpenFlow流水線或普通流水線。例如，某個交換機可以使用VLAN標簽或數(shù)據(jù)包的輸入端口，來決定是否使用一個流水線或其他流水線，或者它可指導所有數(shù)據(jù)包都到OpenFlow流水線進行處理。OpenFlow兼容的交換機有兩種類型：每個OpenFlow交換機的流水線包含多個流表，每個流表包含多個流表項。OpenFlow的流水線處理定義了數(shù)據(jù)包如何與那些流表進行交互。OpenFlow交換機需要具有至少一個流表，并可以有更多的可選擇的流表。只有一個單一的流表的OpenFlow交換機是有效的，而且在這種情況下流水線處理進程可以大大簡化。每個OpenFlow交換機的流水線包含多個流表，每個流表包含F(xiàn)low、FlowTable（流表）、FlowEntry（流表項）FlowEntry（流表項），

流表項是流表里的最小單位。流表項組成如下MatchFields（匹配字段）：對數(shù)據(jù)包匹配。包括入口端口和數(shù)據(jù)包報頭，以及由前一個表指定的可選的元數(shù)據(jù)。Priority（優(yōu)先級）：流表項的匹配次序Counters（計數(shù)器）：更新匹配數(shù)據(jù)包的計數(shù)Instructions（指令）：修改行動集或流水線處理Timeouts超時：最大時間計數(shù)或流有效時間?cookie：由控制器選擇的不透明數(shù)據(jù)值?？刂破饔脕磉^濾流統(tǒng)計數(shù)據(jù)、流改變和流刪除。但處理數(shù)據(jù)包時不能使用。Flow、FlowTable（流表）、FlowEntrFlow、FlowTable（流表）、FlowEntry（流表項）流表項通過匹配字段和優(yōu)先級決定，在一個流表中匹配字段和優(yōu)先級共同確定唯一的流表項。所有字段通配（所有字段省略）和優(yōu)先級等于0的流表項被稱為table-miss流表項（見5.4）。of1.3之后table變成多級流表，有256級。而of1.0中table只在table0中。Flow、FlowTable（流表）、FlowEntr流表的匹配過程OpenFlow交換機在接收一個數(shù)據(jù)包時，執(zhí)行在圖中所示的功能。交換機開始執(zhí)行一個查找表中的第1流表，并基于流水線處理數(shù)據(jù)匹配字段從數(shù)據(jù)包中提取。數(shù)據(jù)包匹配字段中的值用于查找匹配的流表項。如果流表項字段具有值的ANY（字段省略），它就可以匹配包頭中的所有可能的值。如果交換機支持任意的的位掩碼對特定的匹配字段，這些掩碼可以更精確地進行匹配。數(shù)據(jù)包與表進行匹配，優(yōu)先級最高的表項必須被選擇，此時與選擇流表項相關(guān)的計數(shù)器也會被更新，選定流表項的指令集也被執(zhí)行。如果有多個匹配的流表項具有相同的最高的優(yōu)先級的，所選擇的流表項被確定為未定義表項。只有控制器記錄器在傳統(tǒng)的流信息中沒有設(shè)置OFPFF_CHECK_OVERLAP位并且增加了重復的表項的時候，這種情況才能出現(xiàn)。如果在流水線處理前，交換機配置包含OFPC_FRAG_REASM標志，IP碎片必須被重新組裝。

流表的匹配過程OpenFlow交換機在接收一個數(shù)據(jù)包時，執(zhí)行Table-miss每一個流表必須支持能處理table-miss的流表項。table-miss表項指定在流表中如何處理與其他流表項未匹配的數(shù)據(jù)包（見5.1）。比如數(shù)據(jù)包發(fā)送到控制器，丟棄數(shù)據(jù)包或直接將包扔到后續(xù)的表。table-miss的流表項也有它的匹配字段和優(yōu)先級（見5.2），它通配所有匹配字段（所有領(lǐng)域省略），并具有最低的優(yōu)先級（0）。table-miss流表項的匹配可能不屬于正常范圍內(nèi)流表支持的匹配，例如精確匹配表可能不支持在其他流表項中使用通配符，但必須支持table-miss的通配符流表項。table-miss流表項可能沒有與正常流表項（見A.3.5.5）相同的能力。交換機最好支持和OpenFlow的以前版本的處理能力相同的table-miss流表項：將數(shù)據(jù)包發(fā)送到控制器，丟棄數(shù)據(jù)包或直接包到后續(xù)的表。table-miss表項的行為在許多方面像任何其他流表項：默認情況下，在流表中不存在table-miss表項。控制器可以在任何時候添加或刪除它（見6.4），而且它可能會超時失效（見5.5）。table-miss流表項可以匹配流表中其他表項中不能匹配的數(shù)據(jù)。當數(shù)據(jù)包與table-miss表項匹配時，table-miss表項指令就會執(zhí)行（見5.9）。如果該table-miss表項直接將數(shù)據(jù)包通過CONTROLLER端口發(fā)送到控制器（見4.5），那么報文中的信息必須與一個table-miss表項匹配（見A.4.1）。如果該table-miss表項不存在，默認情況下，流表項無法的數(shù)據(jù)包將被丟棄（丟棄）。一個交換機的配置，例如使用OpenFlow的配置協(xié)議，可以覆蓋此默認值，指定其他行為。Table-miss每一個流表必須支持能處理table-m流表項的刪除流表項可以通過兩種方式在流表中刪除，控制器的請求或交換機流超時機制。交換流超時機制運行基于相關(guān)的控制器和流表項的狀態(tài)和配置。每個流的表項具有一個和它相關(guān)的idle_timeout和hard_timeout值。如果兩個值中有一個不為零，交換機必須注意的流表項的老化時間，因為交換機可能刪除該項。如果給定非零hard_timeout的值，那么一段時間后，可以導致流表項被刪除，無論有多少數(shù)據(jù)包與之匹配。如果給定非零idle_timeout的值，那么如果在一段時間沒有報文與之匹配，可以導致流表項被刪除。交換機必須實現(xiàn)流表項超時和刪除功能?？刂破骺煞e極的從流表中通過發(fā)送流表修改信息（OFPFC_DELETE，或OFPFC_DELETE_STRICT）刪除流表項。流表項被刪除時，無論是控制器控制或流表項超時機制，交換機必須檢查流表項的OFPFF_SEND_FLOW_REM標志。如果該標志被設(shè)置，該交換機必須將流刪除消息發(fā)送到控制器。每個流清除消息中包含的流表項的完整的描述、清除的原因（超時或刪除），在清除時的流表項的持續(xù)時間，在清除時的流的統(tǒng)計數(shù)據(jù)。流表項的刪除流表項可以通過兩種方式在流表中刪除，控制器的請指令每個流表項中包含一組的指令，當一個數(shù)據(jù)包匹配表項時指令會被執(zhí)行。這些指令可以更改數(shù)據(jù)包，行動組和/或流水線處理。?OptionalInstruction:Metermeterid:直接將包計量后丟棄。?OptionalInstruction:Apply-Actionsaction(s):立即進行指定的行動，而不改變行動集。這個指令經(jīng)常用來修改數(shù)據(jù)包，在兩個表之間或者執(zhí)行同類型的多個行動的時候。?OptionalInstruction:Clear-Actions:在行動集中立即清除所有的行動。?RequiredInstruction:Write-Actionsaction(s):將指定的行動添加到正在運行的行動集中。?OptionalInstruction:Write-Metadatametadata/mask:在元數(shù)據(jù)區(qū)域記錄元數(shù)據(jù)。?RequiredInstruction:Goto-Tablenext-table-id:指定流水線處理進程中的下一張表的ID。指令每個流表項中包含一組的指令，當一個數(shù)據(jù)包匹配表項時指令行動集行動集與每個報文相關(guān)，默認情況下是空的。一個流表項可以使用Write-Action指令或者Clear-Action指令修改行動集。行動集在表間被累加。當一個表項的指令集沒有包含Goto-Table指令時，流水線處理就停止了，然后報文的行動集就被執(zhí)行。行動集包含所有的行動，無論他們以什么順序加入到行動集中，行動的順序均按照下列順序執(zhí)行。如果行動集包含組行動，那么組行動存儲段中的行動也按照下列順序執(zhí)行。當然，交換機也可以支持通過Apply-Actions指令修改行動執(zhí)行順序。1.copyTTLinwards:applycopyTTLinwardactionstothepacket2.pop:applyalltagpopactionstothepacket3.push-MPLS:applyMPLStagpushactiontothepacket4.push-PBB:applyPBBtagpushactiontothepacket5.push-VLAN:applyVLANtagpushactiontothepacket6.copyTTLoutwards:applycopyTTLoutwardsactiontothepacket7.decrementTTL:applydecrementTTLactiontothepacket8.set:applyallset-fieldactionstothepacket9.qos:applyallQoSactions,suchassetqueuetothepacket10.group:如果指定了組行動，那么按照這個序列中的順序執(zhí)行組行動存儲段里的行動。11.output:如果沒有指定組行動，報文就會按照output行動中指定的端口轉(zhuǎn)發(fā)。Output行動最后執(zhí)行。如果組行動和輸出行動均存在，那么組行動優(yōu)先級高。如果兩者均不存在，那么報文被丟棄。行動集行動集與每個報文相關(guān)，默認情況下是空的。一個流表項可行動RequiredAction:Output.報文輸出到指定端口OptionalAction:Set-Queue.設(shè)置報文的隊列ID，為了Qos的需要。RequiredAction:Drop.丟棄。RequiredAction:Group.用組表處理報文.OptionalAction:Push-Tag/Pop-Tag.OptionalAction:Set-Field.設(shè)置報文包頭的類型和修改包頭的值。OptionalAction:Change-TTL.修改TTL值。行動RequiredAction:Output.報文OpenflowchannelOpenflow通道是交換機連接控制器的接口。通過這個接口，控制器可以對交換機進行管理和配置，接收到交換機的事件，并且想交換機發(fā)送數(shù)據(jù)包。消息被封裝為openflow協(xié)議中規(guī)定的格式在控制器和交換機之間傳輸，這個控制器—交換機協(xié)議運行在安全傳輸層協(xié)議(TLS)或無保護TCP連接之上。OpenflowchannelOpenflow通道是交換Controller和交換機之間消息類型支持三種消息類型：controller-to-switchasynchronous（異步）symmetric（對稱）

每一類消息又有多個子消息類型。controller-to-switch消息由控制器發(fā)起，用來管理或獲取switch狀態(tài)；asynchronous消息由switch發(fā)起，用來將網(wǎng)絡(luò)事件或交換機狀態(tài)變化更新到控制器；symmetric消息可由交換機或控制器發(fā)起。Controller和交換機之間消息類型支持三種消息類型：controller-to-switch消息類型

controller-to-switchFeatures在建立傳輸層安全會話（TransportLayerSecuritySession）的時候，控制器發(fā)送feature請求消息給交換機，交換機需要應(yīng)答自身支持的功能。Configuration控制器設(shè)置或查詢交換機上的配置信息。交換機僅需要應(yīng)答查詢消息。Modify-state控制器管理交換機流表項和端口狀態(tài)等。Read-state控制器向交換機請求一些諸如流、網(wǎng)包等統(tǒng)計信息。Packet-out控制器通過交換機指定端口發(fā)出網(wǎng)包。Barrier控制器確保消息依賴滿足，或接收完成操作的通知Role-Request當交換機連接了多個Controller，Controller用這個消息向交換機通告自己的角色。Asynchronous-Conguration當交換機連接到多個Controller的時候，Controller用這個消息來告訴交換機，它對哪些交換機的消息感興趣controller-to-switch消息類型

contasynchronousPacket-in交換機收到一個網(wǎng)包，在流表中沒有匹配項，則發(fā)送Packet-in消息給控制器。如果交換機緩存足夠多，網(wǎng)包被臨時放在緩存中，網(wǎng)包的部分內(nèi)容（默認128字節(jié)）和在交換機緩存中的的序號也一同發(fā)給控制器；如果交換機緩存不足以存儲網(wǎng)包，則將整個網(wǎng)包作為消息的附帶內(nèi)容發(fā)給控制器。Flow-removed交換機中的流表項因為超時或修改等原因被刪除掉，會觸發(fā)Flow-removed消息。Port-status交換機端口狀態(tài)發(fā)生變化時（例如down掉），觸發(fā)Port-status消息。Error交換機發(fā)生問題時觸發(fā)消息。asynchronousSymmetricHello交換機和控制器用來建立連接。Echo交換機和控制器均可以向?qū)Ψ桨l(fā)出Echo消息，接收者則需要回復Echoreply。該消息用來測量延遲、是否連接保持等。Vendor交換機提供額外的附加信息功能。為未來版本預留。SymmetricOpenflow通信流程

交換機啟動完成之后，會像controllerIP:controllerport發(fā)送數(shù)據(jù)。controller啟動之后，監(jiān)聽指定端口，默認6633TCP3次握手之后，建立連接，這個是底層的通信，是整一套系統(tǒng)的基礎(chǔ)設(shè)施。Openflow通信流程

交換機啟動完成之后，會像contrHello包OFPT_HELLO創(chuàng)建socket之后，sw跟controller會彼此發(fā)送hello數(shù)據(jù)包。目的：協(xié)議協(xié)商。內(nèi)容：本方支持的最高版本的協(xié)議成果：使用雙方都支持的最低版本協(xié)議。成功：建立連接失?。篛FPT_ERROR(TYPE:OFPT_HELLO_FAILED,CODE=0),終止連接。Hello包OFPT_HELLOofp_error_type={0:"OFPET_HELLO_FAILED",1:"OFPET_BAD_REQUEST",2:"OFPET_BAD_ACTION",3:"OFPET_FLOW_MOD_FAILED",4:"OFPET_PORT_MOD_FAILED",5:"OFPET_QUEUE_OP_FAILED"}錯誤類型對應(yīng)的type還會有對應(yīng)的code.所以報錯的格式為：OFPT_ERRORTYPE:CODE:[PAYLOAD]具體的錯誤信息。如TYPE:0CODE:0為：*OFPHFC_INCOMPATIBLE*ofp_error_type={0:"OFPET_HOFPT_ECHO分類：對稱信息OFPT_ECHO_REQUEST,OFPT_ECHO_REPLY作用：查詢連接狀態(tài)，確保通信通暢。當沒有其他的數(shù)據(jù)包進行交換時，controller會定期循環(huán)給sw發(fā)送OFPT_ECHO_REQUEST。OFPT_ECHOOFPT_FEATURES當sw跟controller完成連接之后，控制器會向交換機下發(fā)OFPT_FEATYRES_REQUEST的數(shù)據(jù)包，目的是請求交換機的信息。發(fā)送時間：連接建立完成之后發(fā)送數(shù)據(jù)：OFPT_FEATURES_REQUEST對稱數(shù)據(jù)：OFPT_FEATURES_REPLY目的：獲取交換機的信息OFPT_FEATURESOFPT_PACKET_IN在控制器獲取完交換機的特性之后，交換機開始處理數(shù)據(jù)。對于進入交換機而沒有匹配流表，不知道如何操作的數(shù)據(jù)包，交換機會將其封裝在packet_in中發(fā)給controller。包含在packet_in中的數(shù)據(jù)可能是很多種類型，arp和icmp是最常見的類型。當然產(chǎn)生packet_in的原因不止一種，產(chǎn)生packet_in的原因主要有一下兩種：OFPR_NO_MATCHOFPR_ACTION無法匹配的數(shù)據(jù)包會產(chǎn)生packet_in,action也可以指定將數(shù)據(jù)包發(fā)給packet_in,也就是說我們可以利用這一點，將需要的數(shù)據(jù)包發(fā)給控制器。OFPT_PACKET_INpacket_in事件之后，一般會觸發(fā)兩類事件：packet_outflow_mod如果是廣播包，如arp，控制器一般會將其包裝起來，封裝成packet_out數(shù)據(jù)包，將其發(fā)給交換機，讓其flood,flood操作是將數(shù)據(jù)包往除去in_port以外的所有端口發(fā)送數(shù)據(jù)包。packet_in事件之后，一般會觸發(fā)兩類事件：OFPT_PACKET_OUT很多人不是特別了解packet_out的作用。作用：通過控制器發(fā)送交換機希望發(fā)送的數(shù)據(jù)例子：arp在廣播的時候，在ofsw中不能直接將arp廣播，而是，將其封裝在packet_out里面，交換機泛洪的是packet_out。我個人觀點，這個數(shù)據(jù)包，是一個兼容性之的數(shù)據(jù)包，為了實現(xiàn)信令，不得不處理arp，但是arp又不能直接處理，所以將其封裝在packet_out,從而能夠在of的sw中傳播，從而在openflow里實現(xiàn)arp等IP網(wǎng)的功能。OFPT_PACKET_OUTControllerController是一個運行在獨立服務(wù)器上的程序。有多種語言實現(xiàn)。

廣義的Controller,支持多種協(xié)議，Openflow只是其中一種。也奉行控制和轉(zhuǎn)發(fā)的分離的SDN原則，但是也可以通過別的南向協(xié)議去控制轉(zhuǎn)發(fā)設(shè)備。目前Opendaylight開發(fā)的就是這樣的控制器。

狹義的Controller就是只支持Openflow協(xié)議的控制器。ControllerController是一個運行在獨立服務(wù)Controller屬性

北向接口

每個Controller都有面向用戶應(yīng)用程序的編程接口，稱為北向接口。應(yīng)用的千變?nèi)f化，決定了北向接口也很難標準化比如CLI、Snmp.目前最流行的北向接口是RESTAPI接口。集成的應(yīng)用和服務(wù)

除了提供編程接口，可以加載應(yīng)用，一般大的廠商的控制器都會提供一些應(yīng)用和服務(wù)。例如路由協(xié)議、ACL、Aos、防火墻。提供差異化的服務(wù)，占領(lǐng)市場。南向接口

除了Openflow，還有Netconf、XMPP、LISP等?？刂品绞絾我坏募惺降腃ontroller會帶來很多問題：安全攻擊、高可用性、穩(wěn)定性等

所以Controller一定是分布式部署的（Onix支持Openflow協(xié)議版本

Controller屬性 北向接口Onix分布式Controller模型所有基于Onix的控制器都采用內(nèi)存數(shù)據(jù)庫的概念來用于狀態(tài)管理。每個控制器只控制部分設(shè)備。并且只發(fā)送匯聚后的信息到邏輯控制服務(wù)器。邏輯控制服務(wù)器了解全網(wǎng)拓撲，從而達到分布控制的目的Onix分布式Controller模型所有基于Onix的控制主要的控制器Floodlight(BigSwitch公司BigNetwrokController的開源版本)Ryu（日本的NTT實驗室發(fā)起的開源項目）PoxOpentrail（Juniper公司）OpendaylightGreenNetworkHuaweiZte主要的控制器Floodlight(BigSwitch公司BOpenflow系統(tǒng)性能指標

交換機處理帶寬-----芯片決定，無法優(yōu)化流表項數(shù)量-----芯片決定流表項下發(fā)能力-----即每秒能安裝流表條數(shù)。跟Openflow交換機收包/處理包能力、芯片對流表的處理能力、Controller軟件能力Openflow系統(tǒng)性能指標 交換機處理帶寬-----芯片決傳統(tǒng)路由、交換與SDN比較傳統(tǒng)交換依賴于傳統(tǒng)路由、交換與SDN比較傳統(tǒng)交換依賴于sdn培訓課程課件sdn培訓課程課件網(wǎng)絡(luò)虛擬化現(xiàn)在提到虛擬化一般是指服務(wù)器虛擬化（ServerVirtualization)、存儲虛擬化（StorageVirtualization)

網(wǎng)絡(luò)虛擬化（NetworkVirtualization)SDN的誕生跟虛擬化密切相關(guān)，網(wǎng)絡(luò)虛擬化跟SDN最密切，其次是服務(wù)器虛擬化。網(wǎng)絡(luò)虛擬化現(xiàn)在提到虛擬化一般是指服務(wù)器虛擬化（Server服務(wù)器虛擬化

IBM與1965年發(fā)布IBM7044運行在IBM的大型機上，昂貴的硬件資源在多個用戶之間分享。個人計算機的虛擬化隨著CPU/硬盤/內(nèi)存技術(shù)的飛速發(fā)展而出現(xiàn)。

1999年，Vmware推出了第一款基于X86架構(gòu)的虛擬化軟件

到了云時代，各種公有云、私有云服務(wù)，虛擬化提高的設(shè)備的利用率。

每個虛擬化的產(chǎn)品的核心部分叫做Hypervisor,就是超級管理員。

服務(wù)器虛擬化 IBM與1965年發(fā)布IBM7044網(wǎng)絡(luò)虛擬化同一個Server之中的虛擬機需要通信，會內(nèi)置虛擬交換機的功能。在內(nèi)部形成一個虛擬網(wǎng)絡(luò)不通物理位置的虛擬機需要通信，不同租戶需要安全隔離。虛擬機的管理盡量與物理網(wǎng)絡(luò)解耦，虛擬機的增加、刪除、遷移，盡量不依賴物理設(shè)備。講虛擬機之間通過Tunnel技術(shù)來實現(xiàn)，就是所謂的Underlay、Overlay.將Tunnel的終結(jié)點放在服務(wù)器的虛擬交換機上。網(wǎng)絡(luò)虛擬化同一個Server之中的虛擬機需要通信，會內(nèi)置虛擬Overlay 虛擬機之間連接不依賴與物理網(wǎng)絡(luò)（對于物理網(wǎng)絡(luò)是透明的），虛擬機之間仍可以二層轉(zhuǎn)發(fā)。虛擬機遷移，不需要修改ip和mac地址。只需要重新在軟件里指定跟某個Tunnel關(guān)聯(lián)，這樣，自動化的基礎(chǔ)就有了。Tunnel中攜帶獨一無二的標志，表示一個虛擬網(wǎng)絡(luò)，不通Tunnel之間隔離，無法通信，除此之外，還可以加入負載均衡、防火墻等，組成網(wǎng)絡(luò)虛擬化平臺。Overlay 虛擬機之間連接不依賴與物理網(wǎng)絡(luò)（對于物理網(wǎng)絡(luò)虛擬化市場格局虛擬機VmwareXenKVMHyper-V，最初都是比較簡單的虛擬交換機。2008年，Cisco聯(lián)合Vmware推出了Nexus1000V,增加了網(wǎng)絡(luò)工程，支持Vxlan.2012年，Nicira的虛擬機平臺NVP出現(xiàn)，改變市場格局。Vmware收購了NiciraIBM的DOVENEC的VTNBigSwitch的BigVirtualNetwork(ovs的商業(yè)化版本)虛擬化市場格局虛擬機VmwareXenKVM三種tunnel技術(shù)VxlanNvGRESTT三種tunnel技術(shù)VxlanVxlanVirtualExtensibleLAN(虛擬可擴展局域網(wǎng)）CiscoVmwareArista等共同推出的網(wǎng)絡(luò)虛擬化的Tunnel技術(shù)。將原始報文封裝在一個UDPtunnelHeader里面（在原始報文前面加上L2+IP+UDP+Vxlan頭）。Vxlan頭部VNI信息將傳統(tǒng)網(wǎng)絡(luò)的Vlan從4K擴展到16M

IEEE802.1q標簽幀格式,vlantag—tci-vid(表示VLAN12bits），存儲Vlan是12bit,4096k

VxlanVirtualExtensibleLANNvGRE NetworkVirtualizationusingGenericRoutingEncapsulation)由微軟推出。GRE是很早就存在的技術(shù)，但是用在網(wǎng)絡(luò)虛擬化環(huán)境中，還缺少兩點:

1、無法對VLAN進行擴展2、無法很好的做負載均衡微軟重新定義了GRETunnel頭部里的GREKey字段，其中高24bits用來做跟Vxlan一樣的VNIID，也把VLAN擴展到了16M。用原始報文的頭部信息計算Hash值，把Hash值的低8位寫到這個字段的低8bits.但是需要交換機在做負載均衡計算的時候支持用GRE的這個字段。NvGRE NetworkVirtualizationuSTTStatelessTransportTunnelingNicira提出，主要用于自己的NVP平臺。Vxlan、GvGRE既可以在硬件交換機也可以在虛擬交換機運行。STT只能在虛擬交換機運行。STTStatelessTransportTunneli三種組網(wǎng)方案數(shù)據(jù)中心的網(wǎng)絡(luò)邊緣應(yīng)該延伸到服務(wù)器的虛擬交換機中。傳統(tǒng)硬件方案。優(yōu)勢包括性能和網(wǎng)絡(luò)可見性。折中方案。云的管理平臺配置的軟件交換機替換成配置硬件交換機。三種組網(wǎng)方案數(shù)據(jù)中心的網(wǎng)絡(luò)邊緣應(yīng)該延伸到服務(wù)器的虛擬交換機中Sdn和網(wǎng)絡(luò)虛擬化的結(jié)合

有了SDN、網(wǎng)絡(luò)虛擬化，做到自動化配置就水到渠成。需要平臺來集中管理、分配存儲、計算節(jié)點、網(wǎng)絡(luò)。Openstack未使用SDN技術(shù)之前，虛擬化平臺天然也是集中控制、部署的。SDN可以集成到Openstack或者其他平臺，最終用戶通過平臺去控制虛擬網(wǎng)絡(luò)資源，缺少SDN，自動化的效果會大打折扣。Sdn和網(wǎng)絡(luò)虛擬化的結(jié)合 有了SDN、網(wǎng)絡(luò)虛擬化，做到自動化Openstack介紹OpenStack是一個美國國家航空航天局和Rackspace合作研發(fā)的，開放源代碼項目。OpenStack是一個云平臺管理的項目，它不是一個軟件。這個項目由幾個主要的組件組合起來完成一些具體的工作。OpenStack是一個旨在為公共及私有云的建設(shè)與管理提供軟件的開源項目。它的社區(qū)擁有超過130家企業(yè)及1350位開發(fā)者，這些機構(gòu)與個人都將OpenStack作為基礎(chǔ)設(shè)施即服務(wù)（簡稱IaaS）資源的通用前端。OpenStack項目的首要任務(wù)是簡化云的部署過程并為其帶來良好的可擴展性。本文希望通過提供必要的指導信息，幫助大家利用OpenStack前端來設(shè)置及管理自己的公共云或私有云。。OpenStack包含兩個主要模塊：Nova和Swift，前者是NASA開發(fā)的虛擬服務(wù)器部署和業(yè)務(wù)計算模塊；后者是Rackspace開發(fā)的分布式云存儲模塊，兩者可以一起用，也可以分開單獨用。Openstack介紹OpenStack是一個美國國家航空航中科信軟高級技術(shù)培訓中心－中科信軟高級技術(shù)培訓中心－OpenstackQuantum組件

OpenstackQuantum組件邏輯上分三層最上面的一部分是OpenStack的控制平臺，它通過用戶操作直接或者間接向網(wǎng)絡(luò)組件Neutron發(fā)送標準的命令。

第二層是Neutron組件，它通常是位于一個獨立的控制節(jié)點上（一臺服務(wù)器），它有一套標準的API對應(yīng)上層應(yīng)用發(fā)給它的每個命令，這些API包括create_network、create_port、create_subnet等創(chuàng)建多租戶網(wǎng)絡(luò)以及創(chuàng)建Firewall、LoadBalancer等各種業(yè)務(wù)的API。這套API從SDN的架構(gòu)來看屬于北向接口。在Neutron組件內(nèi)部有很多個不同的插件（plugin），這些插件大多數(shù)都是vSwitch插件，例如OVS、LinuxBridge和OpenFlowController等，也有部分硬件交換機插件，目前已經(jīng)存在的包括Cisco、Arista和Mellanox，相信后面還會有公司會提交。用戶可以選擇自己的網(wǎng)絡(luò)使用哪種方式，然后選擇相應(yīng)的插件，這些插件會處理NeutronAPI調(diào)用，將它們轉(zhuǎn)換為每種插件對應(yīng)的switch所提供的API調(diào)用，然后通過各自定義的方式，發(fā)消息去調(diào)用虛擬交換機或者物理交換機提供的API，這套API從SDN的架構(gòu)來看屬于南向接口。邏輯上分三層Sdn產(chǎn)業(yè)格局現(xiàn)在各個大廠在SDN市場的爭奪，更多的是對Controller定義權(quán)和控制權(quán)的爭奪，未來應(yīng)用為王.元老派

Arista核心產(chǎn)品是交換機，通過和BigSwitch、Vmware使用他們的虛擬化平臺和應(yīng)用Brocade傳統(tǒng)產(chǎn)品是存儲交換機。推出了自己的SDN交換機Citrix虛擬化軟甲XenServer.2012年推出自己的控制器（ADC)Cisco控制器CiscoOne(支持Openflow、onePK南向接口)Nexus系列交換機Dell積極跟進。收購Force10networks公司。HP子公司H3C，有自己的控制器、switch.Huawei從芯片、交換機、控制器、各種服務(wù)接口。IBMOpendaylight主要發(fā)起、推動者之一?？刂破?、交換機。Juniper收購控制器公司ContrailNEC戰(zhàn)略部署比較早的公司之一Redhat、Vmware、radware

Sdn產(chǎn)業(yè)格局現(xiàn)在各個大廠在SDN市場的爭奪，更多的是對Co新生代廠商BigSwitch成立于2010年，主導開源的FloodlightCentec芯片公司。GreenNetworksxNet新生代廠商BigSwitch成立于2010年，主導互聯(lián)網(wǎng)、云服務(wù)公司

Google第一個宣布用openflow改造自己網(wǎng)絡(luò)的巨頭。自己研發(fā)SDN交換機。沒有加入ODLFacebook發(fā)起ONP（OpenNetworkProject）項目，研究網(wǎng)絡(luò)硬件的標準化。也沒有加入ODLAmazon、微軟百度/阿里/騰訊

處在學習、研究階段?；ヂ?lián)網(wǎng)、云服務(wù)公司 Google第一個宣布用openfloSDN案例分析GoogleB4Google網(wǎng)絡(luò)有兩種，一種是數(shù)據(jù)中心內(nèi)部網(wǎng)絡(luò)，另外一種是WAN網(wǎng)。其中廣域網(wǎng)又分兩種，一種是數(shù)據(jù)中心之間互聯(lián)，另一種是面向用戶訪問的網(wǎng)絡(luò)。SDN案例分析分3個層次

物理設(shè)備層（SwitchHardware)

局部網(wǎng)絡(luò)控制層（SiteController）

全局控制層（global)分3個層次第一層的交換機是自己設(shè)計，請OEM廠商代工第二層在每個數(shù)據(jù)中心出口部署了服務(wù)器集群，每個服務(wù)器運行一個Controller，基于Onix分布式改造。一個名叫Paxos的程序負責進行Controller的選舉。Controller之上有兩個協(xié)議RAP（RoutingApplicationProxy）。另一個是TEagent,跟全局的Gateway通信第三層，全局的TE服務(wù)器通過SDNGateway從各個數(shù)據(jù)中心的控制器收集鏈路信息，從而掌握路徑信息。第一層的交換機是自己設(shè)計，請OEM廠商代工對帶寬的分配和路徑計算是核心所在。公開的第一個使用分布式Controller的SDN應(yīng)用案例。證明即使在Google這種規(guī)模的網(wǎng)絡(luò)中，SDN也適用。國內(nèi)外的大公司紛紛效仿，比如國內(nèi)的企鵝。

對帶寬的分配和路徑計算是核心所在。Mininet安裝三種安裝方式1、下載虛擬器鏡像文件

官方推薦2、gitclone源文件gitclonegit:///mininet/mininet3、安裝包Mininet安裝Mininet使用Sudomn默認會啟動一個包含2臺主機、1臺交換機的網(wǎng)絡(luò)--controller配置Controller參數(shù)sudomn--controller=remote,ip=,port=6635--topotreelinearsingle--costom讀取自定義拓撲文件

Mininet使用Sudomn默認會啟動一個包含2臺主自定義拓撲自定義拓撲加載自定義拓撲sudomn--custom/mininet/custom/xx.py--topomytopo加載自定義拓撲sudomn--custom/miniFloodlightapt-getinstallbuild-essentialdefault-jdkantpython-deveclipseApt-getinstallgitgitclonegit:///floodlight/floodlight.gitcdfloodlightgitcheckoutstableantFloodlightapt-getinstallbuil啟動Floodlight啟動floodlightjava-jartarget/floodlight.jar管理頁面

啟動Floodlight啟動floodlight1、有時候讀書是一種巧妙地避開思考的方法。1月-231月-23Tuesday,January3,20232、閱讀一切好書如同和過去最杰出的人談話。12:53:1712:53:1712:531/3/202312:53:17PM3、越是沒有本領(lǐng)的就越加自命不凡。1月-2312:53:1712:53Jan-2303-Jan-234、越是無能的人，越喜歡挑剔別人的錯兒。12:53:1712:53:1712:53Tuesday,January3,20235、知人者智，自知者明。勝人者有力，自勝者強。1月-231月-2312:53:1712:53:17January3,20236、意志堅強的人能把世界放在手中像泥塊一樣任意揉捏。03一月202312:53:17下午12:53:171月-237、最具挑戰(zhàn)性的挑戰(zhàn)莫過于提升自我。。一月2312:53下午1月-2312:53January3,20238、業(yè)余生活要有意義，不要越軌。2023/1/312:53:1712:53:1703January20239、一個人即使已登上頂峰，也仍要自強不息。12:53:17下午12:53下午12:53:171月-2310、你要做多大的事情，就該承受多大的壓力。1/3/202312:53:17PM12:53:1703-1月-2311、自己要先看得起自己，別人才會看得起你。1/3/202312:53PM1/3/202312:53PM1月-231月-2312、這一秒不放棄，下一秒就會有希望。03-Jan-2303January20231月-2313、無論才能知識多么卓著，如果缺乏熱情，則無異紙上畫餅充饑，無補于事。Tuesday,January3,202303-Jan-231月-2314、我只是自己不放過自己而已，現(xiàn)在我不會再逼自己眷戀了。1月-2312:53:1703January202312:53謝謝大家1、有時候讀書是一種巧妙地避開思考的方法。12月-2212月105SDN基礎(chǔ)SDN基礎(chǔ)106學習SDN需要的基礎(chǔ)知識傳統(tǒng)的網(wǎng)絡(luò)基礎(chǔ)知識（網(wǎng)絡(luò)工程師)osi七層模型路由（OSPF等等）、交換（ARPVLAN、MAC）tcp/ip4-7層應(yīng)用（loadbanalancefirewallipswaf)Linux操作系統(tǒng)相關(guān)知識（系統(tǒng)工程師）軟件安裝、配置、系統(tǒng)維護命令、虛擬器語言（程序員）JavaC（控制器源代碼、開發(fā)應(yīng)用）

學習SDN需要的基礎(chǔ)知識傳統(tǒng)的網(wǎng)絡(luò)基礎(chǔ)知識（網(wǎng)絡(luò)工程師)Sdn全景圖為什么需要sdn以及sdn解決的問題南向接口、Openflow協(xié)議Controller介紹—*—

Openstack介紹、

Quantu組件Mininet模擬器Opendaylight控制器傳統(tǒng)交換工作原理、與SDN比較SDN產(chǎn)業(yè)格局SDN應(yīng)用案例SDN總體架構(gòu)課程總體框架與SDN相關(guān)的NFV技術(shù)SDN應(yīng)用案例Controller與交換機之間交互數(shù)據(jù)Sdn全景圖為什么需要sdn以及sdn解決的問題南向接口、OSDN是什么，不是什么SDN是SoftwareDefinedNetwork的縮寫Network而非networking表明是一種框架，一種網(wǎng)絡(luò)設(shè)計理念，而非一種構(gòu)建技術(shù)Ospf(openshortestpathfirst)mpls(MultiprotocolLabelSwitching)stp(spanningtreeprotocol)SDN是什么，不是什么SDN是SoftwareDefinSdn起源Sdn公認的起源地是美國斯坦福大學MartinCasadoNickMcKeownSdn起源Sdn公認的起源地是美國斯坦福大學Ethane項目一個關(guān)于網(wǎng)絡(luò)安全與管理的科研項目。這個項目試圖通過一個集中的網(wǎng)絡(luò)控制器，讓網(wǎng)絡(luò)管理員可以方便的定義基于網(wǎng)絡(luò)流的安全控制策略，并且應(yīng)用到網(wǎng)絡(luò)設(shè)備中。受此項目啟發(fā)，如果將傳統(tǒng)網(wǎng)絡(luò)設(shè)備的數(shù)據(jù)轉(zhuǎn)發(fā)（dataplane)和路由控制（controlplane)兩個功能模塊分離提供，通過集中式的控制器以標準化的接口對各種網(wǎng)絡(luò)設(shè)備進行管理和配置，那么將為網(wǎng)絡(luò)資源的設(shè)計、管理和使用提供更多可能性。好的架構(gòu)都是演進來的---Ethane項目Ethane項目好的架構(gòu)都是演進來的---Ethane項目NOX控制器，用來集中控制控制器與設(shè)備之間的Openflow協(xié)議.希望每臺交換機提供一個標準化的統(tǒng)一接口。基于openflow為網(wǎng)絡(luò)帶來的可編程的特性，提出了SDN的概念。另外一種說法，KateGreen于2009年在TechnologyReview網(wǎng)站上評選年度十大前沿技術(shù)時提出。NOX控制器，用來集中控制技術(shù)變革源于需求數(shù)據(jù)中心的資源：計算、存儲、網(wǎng)絡(luò)新技術(shù)：服務(wù)器虛擬化、存儲虛擬化、自動化管理工具傳統(tǒng)網(wǎng)絡(luò)很難滿足不斷變化的數(shù)據(jù)中心的需求。技術(shù)變革源于需求數(shù)據(jù)中心的資源：計算、存儲、網(wǎng)絡(luò)傳統(tǒng)網(wǎng)絡(luò)瓶頸電信的可用級別是5個9，高度依賴于單個設(shè)備的高可用性隨著云計算、云數(shù)據(jù)中心技術(shù)的發(fā)展，需要網(wǎng)絡(luò)配置更快速、更靈活。傳統(tǒng)網(wǎng)絡(luò)設(shè)備是封閉的黑盒子，對應(yīng)用開放接口很少（snmp,telnet),無法滿足新業(yè)務(wù)加載需要。傳統(tǒng)網(wǎng)絡(luò)瓶頸電信的可用級別是5個9，高度依賴于單個設(shè)備的高可SDN如何解決這些問題控制平面、轉(zhuǎn)發(fā)平面分離，集中化部署。提供可編程接口，應(yīng)用加載更靈活。高可用性依賴于分布式的大規(guī)模網(wǎng)絡(luò)。SDN如何解決這些問題控制平面、轉(zhuǎn)發(fā)平面分離，集中化部署。SDN相關(guān)組織中科信軟高級技術(shù)培訓中心－SDN相關(guān)組織中科信軟高級技術(shù)培訓中心－sdn培訓課程課件從幾個方面看網(wǎng)絡(luò)使用者驅(qū)動

組織的發(fā)起者GoogleFacebook和微軟等公司都不是網(wǎng)絡(luò)設(shè)備的制造商ONFOverviewONF董事會成員有十幾個，無一來自設(shè)備廠商，全部都是網(wǎng)絡(luò)服務(wù)提供商、電信運營商甚至風險投資商員工。他們的觀點是董事會里只有用戶和網(wǎng)絡(luò)運營商，負責做出所有重要決定，他們控制著前進的方向，定義標準的接口，任何一家廠商都無法控制用戶。從幾個方面看網(wǎng)絡(luò)使用者驅(qū)動 組織的發(fā)起者GoogleONF工作ONFOpenflow1.11.21.31.4的標準，OF-Config協(xié)議1.01.1推動全球范圍的SDN研討，廠商之間交換機、控制器互通測試。ONF工作ONFOpenflow1.11.21ONF組織架構(gòu)

BoardofDirectors（董事會）TechnicalAdvisoryGroup（技術(shù)顧問組）ChipMakers’AdvisoryBoard(芯片商顧問委員會）

成員全部來自全球知名的芯片廠，目前國內(nèi)只有huaweiztecentecWorkingGroups

ONF組織架構(gòu) BoardofDirectors（董事ONFPlugfestTestingandoperability工作組負責

包括標準一致性的測試和互聯(lián)互通的測試。每年負責組織Plugfest測試活動。ONFPlugfestTestingandoperaONFPlugfest 2012年，參與廠商很少2014年5月，中國和美國對接測試，很多國內(nèi)的廠商參與。ONFPlugfest 2012年，參與廠商很少ODL（opendaylight) 中科信軟高級技術(shù)培訓中心－ODL（opendaylight) 中科信軟高級技術(shù)培訓中心ODL背景ODL不算是SDN標準組織，是一個推進SDN發(fā)展，實現(xiàn)一個開源的SDNcontroller的組織，不制定SDN相關(guān)標準Ciscojuniper等廠商希望繼續(xù)自己的領(lǐng)導地位。ONF成立并推動SDN的動機之一就是防止廠商鎖定，ODL是想繼續(xù)維持現(xiàn)有產(chǎn)業(yè)格局。ONF最初制定者（大學教授、學生）對網(wǎng)絡(luò)的考慮欠缺，導致產(chǎn)品很難商業(yè)化，需要廠商來參與完善，使SDN趨于成熟ODL背景ODL不算是SDN標準組織，是一個推進SDN發(fā)展，ONF和ODL的利益沖突產(chǎn)業(yè)界出于自身利益考慮，圍繞網(wǎng)絡(luò)開放方式（南向、北向）和程度尚存在較大分歧,ONF強調(diào)“南向”接口開放，OpenDaylight強調(diào)“北向”接口開放推動“南向接口”的標準化ONF希望徹底擺脫廠商鎖定，所以希望所有接口標注化南向接口可以百花齊放，認為sdn最核心的就是控制和轉(zhuǎn)發(fā)分析，南向不需要標準化。一方面希望推動sdn發(fā)展，另一方面又希望保留廠商的定制的權(quán)利，特別是不規(guī)定轉(zhuǎn)發(fā)面的硬件的標準化。ONF和ODL的利益沖突產(chǎn)業(yè)界出于自身利益考慮，圍繞網(wǎng)絡(luò)其他的一些組織

中科信軟高級技術(shù)培訓中心－其他的一些組織 中科信軟高級技術(shù)培訓中心－Sdn架構(gòu)應(yīng)用層、控制層（控制平面）轉(zhuǎn)發(fā)層（轉(zhuǎn)發(fā)平面）北向接口南向接口Sdn架構(gòu)應(yīng)