路由協議和架構/軟體定義網路簡介
網際網路仍然是30年前定義的那樣：一個非常高效的管道，以高速傳輸位元，幾乎使用相同的協議和相同的理念。
網路裝置是整體式的：每個路由器除了包含用於報文轉發的專用硬體外，還包含自己的作業系統和自己的應用程式。這種基礎設施對創新封閉：客戶無法安裝軟體元件，而是由硬體製造商設定，而硬體製造商如果已經是市場領導者（例如思科），則對創新不感興趣。
軟體定義網路（SDN）引入了對網路進行程式設計的可能性，它基於三個支柱
- 控制和轉發功能分離：軟體，智慧元件，與硬體分離；
- 控制集中化：整個網路由一個控制器協調，它由一個網路作業系統和使用者定義的網路應用程式（例如路由協議、負載均衡器、防火牆）組成；
- 定義明確的介面:
- 北向：網路作業系統向網路應用程式公開API；
- 南向：網路作業系統驅動網路節點，網路節點由簡單的報文轉發硬體組成。
網路作業系統是一個軟體層，它為上層應用程式提供網路的全域性抽象檢視。從網路“上方”的檢視可以實現例如流量工程：決策由負載均衡器的集中邏輯做出，因此對所有網路節點都一致
- 主動模式：在裝置開始轉發報文之前，控制器先驗地用所有會話所需的規則填充轉發表；
- 被動模式：當會話中的第一個報文到達時，裝置將其傳送給控制器，控制器做出決策並通知裝置該會話中轉發報文所需的規則。
一個網路切片層可以向軟體顯示一個與實際物理基礎設施不同的網路拓撲：它可以配置為向每個系統操作例項顯示不同的虛擬拓撲（例如實際鏈路的子集）→ 某個公司的流量策略隻影響屬於該公司的網路部分。
- 問題
- 控制器：它可能構成單點故障和瓶頸；
- 通用性：防火牆需要檢查所有報文，不僅僅是會話中的第一個報文→ 裝置和控制器之間會產生大量流量；
- 可擴充套件性：為了獲得高效能，轉發硬體不能太簡單；
- 經濟：硬體簡化有悖於主要網路供應商的經濟利益。
OpenFlow，在2008年左右推出，是南向介面的實現。
它可以以多種方式部署
- 規則：它們通常是基於流的，也就是說，根據（MAC 地址、IP 地址、TCP 埠）元組定義；
- 控制器：它通常是物理集中式的，但它甚至可以是物理分散式的（即使仍然是邏輯集中式的）；
- 模式：它通常是被動的，但沒有什麼可以阻止使用主動模式。
一個或多個操作與每個規則相關聯，例如
- 將報文轉發到埠(s)；
- 封裝並轉發到控制器；
- 丟棄報文；
- 傳送到正常的處理管道（即經典路由表）；
- 修改欄位（例如 NAT：更改地址和埠）。
- OpenFlow 1.3
它引入了一些有趣的功能
- 轉發表被分成多個子表（例如防火牆、路由等），每個應用程式訪問其子表→ 每個報文在表中按順序進行多次匹配；
- 虛擬交換機（vSwitch，例如 Open vSwitch）：它不是在硬體中實現，而是在由軟體程序模擬的交換機上執行→ 在兩個不同伺服器上的兩個 vSwitch 之間可以建立 GRE 邏輯隧道，穿過傳統的交換機網路：
#網路功能虛擬化.
- 問題
- 資料平面：它只處理報文轉發→ 它適合於報文轉發是相對於資料平面來說占主導地位的環境（例如資料中心），但它似乎不適合 ISP 網路；
- 實用性：南向介面不像北向介面那樣有趣：它由網路作業系統開發者使用，而不是由應用程式開發者使用；
- 硬體成本：規則可以基於大量的欄位，這使得條目非常寬→ 所需的 TCAM 昂貴且發熱量大；
- 靈活性：與開放網路基金會 (ONF)（VMware）相比，OpenDaylight 專案（思科）更喜歡網路配置協議（NETCONF），它不會明確地制定規則，而是不知道讀取或設定的值的語義→ 它可以被 SDN 控制器用來配置裝置上的一些高階功能，例如 ISP 網路上檢測到故障為嚴重時使用的“備份路由”。
不僅要將報文轉發到正確的方向，還要提供面向資料平面的服務，這些服務處理報文（例如防火牆、NAT、網路監控器）。
如今，服務可以新增到接入路由器 (BNG)，也可以透過服務卡新增，方法是連線稱為裝置的盒子：一個裝置是一個獨立的離散硬體裝置，具有整合軟體（韌體），專門用於提供特定服務。裝置透過物理線纜串聯連線，形成一個靜態服務鏈，每個報文必須經過所有服務才能退出裝置。
- 缺點
- 敏捷性 在供應新服務方面：裝置應該與裝置物理連線；
- 靈活性：為了連線一個新的裝置，鏈需要暫時斷開，停止網路服務；
- 可靠性：有故障的裝置會斷開鏈，停止網路服務；
- 最佳化：每個裝置都具有固定的可用資源，在工作高峰期間，它無法利用此時可能由另一個裝置釋放的資源。
每個裝置都連線到 OpenFlow 交換機的輸出埠和輸入埠，流量透過動態確定的服務鏈，服務鏈透過定義從交換機埠到另一個埠的路徑的 OpenFlow 規則來決定。
- 優點
- 靈活性: 新增新裝置需要 SDN 控制器在不停止網路服務的情況下動態更改 OpenFlow 規則；
- 可靠性: SDN 控制器對 OpenFlow 規則的動態更改足以恢復網路服務；
- 業務: 路徑可以根據客戶（公司）進行區分→流量只經過客戶購買的服務。
- 缺點
- 敏捷性 在供應新服務方面：裝置應該與裝置物理連線；
- 最佳化: 每個裝置都有固定數量的可用資源，在工作高峰期，它無法利用此時其他裝置可能留出的空閒資源；
- 向後相容性: 裝置應更換為支援 OpenFlow 的交換機。
服務在純軟體流程中實現：交換機連線到在多個遠端伺服器上模擬的 OpenFlow vSwitches，每個伺服器都有一個能夠執行 **虛擬機器** (VM) 的虛擬機器管理程式，服務在其中執行。
- 擴充套件
服務效能可以透過三種方式增強
- **垂直擴充套件**：為 VM 分配更多硬體資源→如果服務無法適當地 利用可用硬體（例如，單執行緒程式從多執行緒環境中獲益不多），這可能還不夠；
- **水平擴充套件**：多個 VM 在同一臺物理伺服器上並行執行→需要一個 負載均衡器 將流量傳送到負載最輕的 VM，VM 需要 同步；
- 多臺伺服器: 多個 VM 在多臺物理伺服器上並行執行→需要另一個負載均衡器將流量傳送到負載最輕的伺服器。
- 優點
- 敏捷性 在配置新服務方面：可以透過下載和啟動軟體映像來動態啟用新服務；
- 最佳化: 伺服器硬體資源在 VM 之間共享；
- 向後相容性: 如果交換機不支援 OpenFlow，則可以在不更換裝置的情況下利用 vSwitches 之間的 GRE 隧道；
- 整合: 晚上可以減少並行執行的 VM 數量（**縮減**）並減少分配的硬體資源（**縮減**）。
- 缺點
- 流量: 經典的 NFV 模型可能需要資料包在伺服器之間跨交換機傳輸，從而阻塞伺服器所在的網路；
- 效率: 伺服器使用通用 CPU，而不是專用硬體（例如線路卡），並且目前尚無有效的硬體加速技術；
- 遷移: 當用戶移動時，VM 例項應移動到最近的伺服器，並應儘快啟動；
- 可擴充套件性: 該架構具有很高的可擴充套件性潛力，但在多個服務例項並行執行時，會遇到同步和負載均衡問題。
**OpenStack**，於 2010 年推出，是一個開源的分散式作業系統
- Linux
- 它處理它執行的 單個本地 主機；
- 程序 是執行單元；
- OpenStack
- 它執行在稱為 **控制器節點** 的 遠端伺服器 上；
- 它處理雲中的 多個分散式 物理伺服器，稱為 **計算節點**；
- 虛擬機器 是執行單元。
每個 **計算節點** 包括以下元件
- 傳統作業系統: 它處理物理伺服器上的本地硬體；
- 代理: 它接收來自控制器節點的命令，例如啟動 VM；
- vSwitch（例如 Open vSwitch）：它將伺服器連線到網路基礎設施。
**控制器節點** 的一項任務是在當前負載最輕的計算節點上啟動 VM。