OVN架構
OVN（即Open Virtual Network）是一款支援虛擬網路抽象的軟體系統。OVN在OVS現有功能的基礎上原生支援虛擬網路抽象，例如虛擬L2，L3覆蓋網路以及完全組。諸如DHCP，DNS的服務也是其關注的內容。就像OVS一樣，OVN的設計目標是可以大規模執行的高質量生產級實施方案。

OVN部署由以下幾個元件組成：

CMS（雲管理系統）。這是OVN的終端使用者（通過其使用者和管理員）。與OVN整合需要安裝與CMS特定的外掛和相關軟體（見下文）。OVN最初的目標CMS是OpenStack。我們通常會說一個CMS，但多個CMS也可以管理一個OVN的不同部分。

安裝在一箇中央位置的OVN資料庫，可以是物理節點，虛擬節點，甚至是一個叢集。

一個或多個（通常是很多）虛擬機器管理程式（hypervisors）。hypervisors必須執行Open vSwitch並執行IntegrationGuide.rst在OVS原始碼樹中所述的介面。任何支援的OVS的hypervisor平臺都是可以接受的。

零個或多個閘道器。 閘道器通過在隧道和物理乙太網埠之間雙向轉發資料包，將基於隧道的邏輯網路擴充套件到物理網路。這允許非虛擬機器器參與邏輯網路。閘道器可能是物理機，虛擬機器或基於ASIC同時支援vtep模式的硬體交換機。

hypervisor和閘道器一起被稱為傳輸節點或chassis

下圖顯示了OVN和相關的主要元件的軟體互動:

從圖的頂部開始，依次為：

首先是如上文所述的雲管理系統。

OVN/CMS外掛是連線到OVN的CMS元件。 在OpenStack中，這是一個Neutron外掛。該外掛的主要目的是轉換CMS中的邏輯網路的配置為OVN可以理解的中間表示。這個元件是必須是CMS特定的，所以對接一個新的CMS需要開發新的外掛對接到OVN。所有在這個元件下面的其他元件是與CMS無關的。

OVN北向資料庫接收由OVN/CMS外掛傳遞的邏輯網路配置的中間表示。資料庫模式與CMS中使用的概念是“阻抗匹配的”，因此它直接支援邏輯交換機，路由器，ACL等概念。有關詳細資訊，請參見ovn-nb。（OVN北向資料庫只有兩個客戶端：在它上面的OVN/CMS外掛和在它下面的ovn-northd）

ovn-northd用於連線到它上面的OVN北行資料庫和它下面的OVN南行資料庫。它將傳統網路概念（從OVN北行資料庫中取得）的邏輯網路配置轉換為其下面的OVN南行資料庫中的邏輯資料路徑流。

OVN南行資料庫是系統的中心。（OVN南向資料庫也只有兩個客戶端：它上面是ovn-northd以及在它下面的每個傳輸節點上的ovn-controller）。OVN南向資料庫包含三種類型的資料：指定如何到達hypervisor和其他節點的物理網路（PN）表；用於描述邏輯網路的邏輯資料路徑流的邏輯網路（LN）表；用於將邏輯網路元件的位置連結到物理網路的繫結表。hypervisor填充PN和Port_Binding表，而ovn-northd填充LN表。

為了叢集的可用性，OVN南行資料庫效能必須隨傳輸節點的數量而擴充套件。這可能需要一些ovsdb-server上的工作。

其餘元件在每個hypervisor中都是一樣的

ovn-controller是每個hypervisor和軟體閘道器上的OVN代理。北向，它連線到OVN南行資料庫以瞭解OVN配置和狀態，並把hypervisor的狀態填充繫結表中的Chassis列以及PN表。南向，它連線到ovs-vswitchd作為OpenFlow控制器用於控制網路通訊，並連線到本地ovsdb-server以允許它監視和控制Open vSwitch的配置。

ovs-vswitchd和ovsdb-server是標準的Open vSwitch元件。

OVN中的資訊流
OVN中的配置資料從北向南流動。CMS通過其OVN/CMS外掛，通過北向資料庫將邏輯網路配置傳遞給ovn-northd。反過來，ovn-northd將配置資訊編譯為較低級別的表單，並通過南行資料庫將其傳遞到所有的chassis。

OVN中的狀態資訊從南向北流動。OVN目前僅提供以下幾種形式的狀態資訊：

首先，ovn-northd在北向Logical_Switch_Port表中填充up列：如果南向Port_Binding表中邏輯埠的chassis列非空，則設定為true，否則設定為false。這使CMS能夠檢測虛擬機器的網路連線何時可用。

其次，OVN向CMS提供關於其配置實現的反饋，即CMS提供的配置是否已經生效。 此功能要求CMS參與序列號協議，其工作方式如下：

當CMS更新北向資料庫中的配置時，作為同一事務的一部分，它會增加NB_Global表中的nb_cfg列的值。（這隻有當CMS想知道何時配置已經實現時才是必要的。）
當ovn-northd根據北向資料庫的給定快照更新南行資料庫時，作為同一事務的一部分，它將北向NB_Global表中的nb_cfg列複製到南行資料庫SB_Global表中。（因此，監視兩個資料庫的觀察者可以確定南行資料庫何時與北向資料庫一致）
在ovn-northd從南向資料庫伺服器收到其更改已提交的確認後，會將北向資料庫NB_Global表中的sb_cfg列更新為被推下去的nb_cfg版本號。（因此，CMS或其他觀察者可以確定南行資料庫何時被捕獲而沒有連線到南行資料庫）
每個chassis上的ovn-controller程序會接收更新的南行資料庫，並更新nb_cfg。該過程依次更新chassis上的Open vSwitch例項中安裝的物理流。從Open vSwitch收到確認物理流已更新的確認後，它會在南行資料庫的自己的chassis記錄中更新nb_cfg。
ovn-northd監視南向資料庫中所有chassis記錄中的nb_cfg列。它跟蹤所有記錄中的最小值，並將其複製到北行NB_Global表中的hv_cfg列中。（因此，CMS或其他觀察者可以確定所有的hypervisor何時與北向資料庫裡的配置一致）
Chassis啟動
OVN部署中的每個chassis必須配置專用於OVN使用的Open vSwitch網橋，稱為整合網橋。如果需要，系統啟動指令碼可以在啟動ovn-controller之前建立此網橋。如果ovn-controller啟動時這個網橋不存在，它會自動建立，使用下面建議的預設配置。 整合橋上的埠包括：

在任何chassis上，OVN用來維護邏輯網路連線的隧道埠。ovn-controller負責新增，更新並刪除這些隧道埠。
在hypervisor上，將要連線到邏輯網路的任何VIF。hypervisor本身或Open vSwitch與hypervisor（IntegrationGuide.rst中描述的）之間的整合將處理此問題。（這不是OVN的一部分，也不是OVN的新功能;這是在支援OVS的虛擬機器管理程式上已經完成的預先整合工作）
在閘道器上，用於邏輯網路連線的物理埠。系統啟動指令碼在啟動ovn-controller之前將此埠新增到網橋。在更復雜的設定中，這可以是到另一個橋的patch埠，而不是物理埠。
其他埠不應連線到整合網橋。特別是，連線到底層網路的物理埠（與把物理埠連線到邏輯網路的的閘道器埠相反）不能連線到整合網橋。 底層物理埠應該連線到單獨的Open vSwitch網橋（實際上它們根本不需要連線到任何網橋）

整合橋應按照如下所述進行配置。每個這些設定的效果都記錄在檔案OVS-vswitchd.conf.db中：

fail-mode=secure：在ovn-controller啟動之前，避免在隔離的邏輯網路之間切換資料包。有關更多資訊，請參閱ovs-vsctl中的Controller Failure Settings部分。

other-config:disable-in-band=true：抑制整合網橋的帶內控制流。由於OVN使用本地控制器（通過Unix域套接字）而不是遠端控制器，所以這樣的控制流顯然是不常見的。然而，對於同一系統中的某個其他橋可能有一個帶內遠端控制器，在這種情況下，這可能會抑制帶內控制器通常建立的流量。請參閱有關文件以獲取更多資訊。

整合網橋的習慣命名是br-int，但是其他名字也可能被使用的。

邏輯網路
邏輯網路實現與物理網路相同的概念，但它們通過隧道或其他封裝與物理網路隔離。這允許邏輯網路具有單獨的IP和其他地址空間，這些地址空間與用於物理網路的地址空間可以重疊並且沒有衝突。邏輯網路拓撲結構可以不考慮底層物理網路的拓撲結構。

OVN中的邏輯網路概念包括： 
* 邏輯交換機，乙太網交換機的邏輯版本。 
* 邏輯路由器，IP路由器的邏輯版本。邏輯交換機和路由器可以連線成複雜的拓撲結構。 
* 邏輯資料路徑，OpenFlow交換機的邏輯版本。 邏輯交換機和路由器都是作為邏輯資料路徑實現的。 
* 邏輯埠，邏輯交換機和邏輯路由器內外的連線點。 一些常見的邏輯埠型別是：

  * 表示VIF的邏輯埠
  * Localnet埠，代表邏輯交換機和物理網路之間的連線點。在整合網橋與底層物理埠附加到的獨立Open vSwitch網橋之間的OVS patch埠即是Localnet埠。
  * 邏輯patch埠，表示邏輯交換機和邏輯路由器之間的連線點，在某些情況下，則是對等邏輯路由器之間的連線點。每個連線點都有一對邏輯連線埠，每端連線一個埠。
  * Localport埠，代表邏輯交換機和VIF之間的本地連線點。這些埠存在於每個chassis（不限於任何特定的chassis），並且來自它們的流量將永遠不會穿過隧道。Localport埠僅生成目的地為本地目的地的流量，通常響應於其收到的請求。一個用例是OpenStack Neutron如何使用Localport埠將元資料提供給駐留在每個hypervisor上的虛擬機器。元資料代理程序連線到每個主機上的此埠，並且同一網路中的所有虛擬機器將使用相同的IP/MAC地址到達它，而不通過隧道傳送任何流量。更多細節可以在[https://docs.openstack.org/developer/networking/ovn/design/metadata_api.html](https://docs.openstack.org/developer/networking/ovn/design/metadata_api.html)上看到。
VIF的生命週期
資料庫表和他們的模式是孤立的，很難理解。這是一個例子。

hypervisor上的VIF是連線到在該hypervisor上直接執行的虛擬機器或容器的虛擬網路介面（這與執行在虛擬機器內的容器的介面不同）

本示例中的步驟通常涉及OVN和OVN北向資料庫模式的詳細資訊。請分別參閱ovn-sb和ovn-nb部分了解這些資料庫的完整內容。

當CMS管理員使用CMS使用者介面或API建立新的VIF並將其新增到交換機（由OVN作為邏輯交換機實現的交換機）時，VIF的生命週期開始。CMS更新其自己的配置，主要包括將VIF唯一的持久識別符號vif-id和乙太網地址mac相關聯。
CMS外掛通過向Logical_Switch_Port表新增一行來更新OVN北向資料庫以包括新的VIF資訊。在新行中，名稱是vif-id，mac是mac，交換機指向OVN邏輯交換機的Logical_Switch記錄，而其他列被適當地初始化。
ovn-northd收到OVN北向資料庫的更新。然後通過新增新行到OVN南向資料庫Logical_Flow表中反映新的埠來對OVN南向資料庫進行相應的更新，例如，新增一個流來識別發往新埠的MAC地址的資料包應該傳遞給它，並且更新傳遞廣播和多播資料包的流以包括新的埠。它還在“繫結”表中建立一個記錄，並填充除識別chassis列之外的所有列。
在每個hypervisor上，ovn-controller接收上一步ovn-northd在Logical_Flow表所做的更新。但只要擁有VIF的虛擬機器關機，ovn-controller也無能為力。例如，它不能傳送資料包或從VIF接收資料包，因為VIF實際上並不存在於任何地方。
最終，使用者啟動擁有該VIF的VM。在VM啟動的hypervisor上，hypervisor與Open vSwitch（IntegrationGuide.rst中所描述的）之間的整合是通過將VIF新增到OVN整合網橋上，並在external_ids：iface-id中儲存vif-id，以指示該介面是新VIF的例項。（這些程式碼在OVN中都不是新功能;這是已經在支援OVS的虛擬機器管理程式上已經完成的預先整合工作。）
在啟動VM的hypervisor上，ovn-controller在新的介面中注意到external_ids：iface-id。作為響應，在OVN南向資料庫中，它將更新繫結表的chassis列中連結邏輯埠從external_ids：iface-id到hypervisor的行。之後，ovn-controller更新本地虛擬機器hypervisor的OpenFlow表，以便正確處理去往和來自VIF的資料包。
一些CMS系統，包括OpenStack，只有在網路準備就緒的情況下才能完全啟動虛擬機器。為了支援這個功能，ovn-northd發現Binding表中的chassis列的某行更新了，則通過更新OVN北向資料庫的Logical_Switch_Port表中的up列來向上指示這個變化，以指示VIF現在已經啟動。如果使用此功能，CMS則可以通過允許VM執行繼續進行後續的反應。
在VIF所在的每個hypervisor上，ovn-controller注意到繫結表中完全填充的行。這為ovn-controller提供了邏輯埠的物理位置，因此每個例項都會更新其交換機的OpenFlow流表（基於OVN資料庫Logical_Flow表中的邏輯資料路徑流），以便通過隧道正確處理去往和來自VIF的資料包。
最終，使用者關閉擁有該VIF的VM。在VM關閉的hypervisor中，VIF將從OVN整合網橋中刪除。
在VM關閉的hypervisor上，ovn-controller注意到VIF已被刪除。作為響應，它將刪除邏輯埠繫結表中的Chassis列的內容。
在每個hypervisor中，ovn-controller都會注意到繫結錶行中空的Chassis列。這意味著ovn-controller不再知道邏輯埠的物理位置，因此每個例項都會更新其OpenFlow表以反映這一點。
最終，當VIF（或其整個VM）不再被任何人需要時，管理員使用CMS使用者介面或API刪除VIF。CMS更新其自己的配置。
CMS外掛通過刪除Logical_Switch_Port表中的相關行來從OVN北向資料庫中刪除VIF。
ovn-northd收到OVN北向資料庫的更新，然後相應地更新OVN南向資料庫，方法是從OVN南向d資料庫Logical_Flow表和繫結表中刪除或更新與已銷燬的VIF相關的行。
在每個hypervisor上，ovn-controller接收在上一步中的Logical_Flow表更新並更新OpenFlow表。儘管可能沒有太多要做，因為VIF已經變得無法訪問，它在上一步中從繫結表中刪除。
VM內部容器介面的生命週期
OVN通過將寫在OVN_NB資料庫中的資訊轉換成每個hypervisor中的OpenFlow流表來提供虛擬網路抽象。如果OVN控制器是唯一可以修改Open vSwitch中的流的實體，則只能為多租戶提供安全的虛擬網路連線。當Open vSwitch整合網橋駐留在虛擬機器管理程式中時，虛擬機器內執行的租戶工作負載無法對Open vSwitch流進行任何更改的。

如果基礎架構提供程式信任容器內的應用程式不會中斷和修改Open vSwitch流，則可以在hypervisors中執行容器。當容器在虛擬機器中執行時也是如此，此時需要有一個駐留在同一個VM中由OVN控制器控制的Open vSwitch整合網橋。對於上述兩種情況，工作流程與上一節（“VIF的生命週期”）中的示例所解釋的相同。

本節討論在虛擬機器中建立容器並將Open vSwitch整合網橋駐留在虛擬機器管理程式中時，容器介面（CIF）的生命週期。在這種情況下，即使容器應用程式發生故障，其他租戶也不會受到影響，因為執行在VM內的容器無法修改Open vSwitch整合橋中的流。

在虛擬機器內建立多個容器時，會有多個CIF關聯。為了便於OVN支援虛擬網路抽象，與這些CIF關聯的網路流量需要到達hypervisor中執行的Open vSwitch整合網橋。OVN還應該能夠區分來自不同CIF的網路流量。有兩種方法可以區分CIF的網路流量：

第一種方法是為每個CIF提供一個VIF（1:1）。這意味著hypervisor中可能有很多網路裝置。由於管理所有VIF額外的CPU消耗，這會使OVS變慢。 這也意味著在VM中建立容器的實體也應該能夠在hypervisor中建立相應的VIF。

第二種方法是為所有CIF提供一個VIF（1:n）。然後，OVN可以通過每個資料包中寫入的標籤來區分來自不同CIF的網路流量。OVN使用這種機制並使用VLAN作為標記機制。

CIF的生命週期始於在虛擬機器內部建立容器開始，該容器可以是由建立虛擬機器同一CMS建立或擁有該虛擬機器的租戶建立，甚至可以是與最初建立虛擬機器的CMS不同的容器編制系統所建立。無論建立容器的實體是誰，它需要知道需要知道與虛擬機器的網路介面關聯的vif-id，容器介面的網路流量將通過該網路介面經過。建立容器介面的實體也需要在該虛擬機器內部選擇一個未使用的VLAN。
建立容器的實體（直接或間接通過管理底層基礎結構的CMS）通過向Logical_Switch_Port表新增一行來更新OVN南向資料庫以包含新的CIF。在新行中，name是任何唯一的識別符號，parent_name是CIF網路流量預計要經過的VM的vif-id，tag是標識該CIF網路流量的VLAN標記。
ovn-northd收到OVN北向資料庫的更新。反過來，它通過新增相應行到OVN南向資料庫的Logical_Flow表來反映新的埠，並通過在Binding表中建立一個新行並填充除了標識列以外的所有列，來相應地更新OVN南向資料庫的chassis。
在每個hypervisor上，ovn-controller訂閱繫結表中的更改。當由ovn-northd建立的新行中包含Binding表的parent_port列中的值時，擁有與external_ids：iface-id中的vif-id相同值的ovn整合網橋上的ovn-controller更新本地hypervisor的OpenFlow流表，這樣來自具有特定VLAN標記的VIF的資料包得到正確的處理。之後，它會更新繫結表的chassis列以反映物理位置。
底層網路準備就緒後，只能在容器內啟動應用程式。為了支援這個功能，ovn-northd在繫結表中通知更新的chassis列，並更新OVN Northbound資料庫的Logical_Switch_Port表中的up列，以表示CIF現在已經啟動。負責啟動容器應用程式的實體查詢此值並啟動應用程式。
最後，建立並啟動容器的實體如果要停止它。實體則通過CMS（或直接）刪除Logical_Switch_Port表中的行。
ovn-northd接收OVN Northbound更新，並相應地更新OVN Southbound資料庫，方法是從OVN Southbound資料庫Logical_Flow表中刪除或更新與已經銷燬的CIF相關的行。同時也會刪除該CIF的繫結表中的行。
在每個hypervisor中，ovn-controller接收在上一步中Logical_Flow表的更新.ovn-controller更新本地OpenFlow表以反映更新。
資料包的物理處理生命週期
本節介紹資料包如何通過OVN從一個虛擬機器或容器傳輸到另一個虛擬機器或容器。這個描述著重於一個數據包的物理處理。有關資料包邏輯生命週期的描述，請參考ovn-sb中的Logical_Flow表。

為了清楚起見，本節提到了一些資料和元資料欄位，總結如下：

隧道金鑰。當OVN在Geneve或其他隧道中封裝資料包時，會附加額外的資料，以使接收的OVN例項正確處理。這取決於特定的封裝形式，採取不同的形式，但在每種情況下，我們都將其稱為“隧道金鑰”。請參閱文末的“隧道封裝”以瞭解詳細資訊。
邏輯資料路徑欄位。表示資料包正在被處理的邏輯資料路徑的欄位。OVN使用OpenFlow 1.1+簡單地（並且容易混淆）呼叫“元資料”來儲存邏輯資料路徑欄位。 （該欄位作為隧道金鑰的一部分通過隧道進行傳遞。）
邏輯輸入埠欄位。表示資料包從哪個邏輯埠進入邏輯資料路徑的欄位。OVN將其儲存在Open vSwitch擴充套件暫存器14中。Geneve和STT隧道將這個欄位作為隧道金鑰的一部分傳遞。雖然VXLAN隧道沒有明確的攜帶邏輯輸入埠，OVN只使用VXLAN與閘道器進行通訊，從OVN的角度來看，只有一個邏輯埠，因此OVN可以在輸入到OVN時將邏輯輸入埠欄位設定為該邏輯輸入的邏輯管道。
邏輯輸出埠欄位。表示資料包將離開邏輯資料路徑的邏輯埠的欄位。在邏輯入口管道的開始，它被初始化為0。 OVN將其儲存在Open vSwitch擴充套件暫存器15中。Geneve和STT隧道將這個欄位作為隧道金鑰的一部分傳遞。VXLAN隧道不傳輸邏輯輸出埠欄位，由於VXLAN隧道不在隧道金鑰中攜帶邏輯輸出埠欄位，所以當OVN管理程式從VXLAN隧道接收到資料包時，將資料包重新提交給流表8以確定輸出埠。當資料包到達流表32時，通過檢查當資料包從VXLAN隧道到達時設定的MLF_RCV_FROM_VXLAN標誌，將這些資料包重新提交到表33以供本地傳送。
邏輯埠的conntrack區域欄位。表示邏輯埠的連線跟蹤區域的欄位。值只在本地有意義，跨chassis之間是沒有意義的。在邏輯入口管道的開始，它被初始化為0。OVN將其儲存在Open vSwitch擴充套件暫存器13中。
路由器的conntrack區域欄位。表示路由器的連線跟蹤區域的欄位。值只在本地有意義，跨chassis之間是沒有意義的。OVN在Open vSwitch擴充套件暫存器11中儲存DNATting的區域資訊，在Open vSwitch擴充套件暫存器12中儲存SNATing的區域資訊。
邏輯流標誌。邏輯標誌旨在處理保持流表之間的上下文以便確定後續表中的哪些規則匹配。值只在本地有意義，跨chassis之間是沒有意義的。OVN將邏輯標誌儲存在Open vSwitch擴充套件暫存器10中。
VLAN ID。VLAN ID用作OVN和巢狀在VM內的容器之間的介面（有關更多資訊，請參閱上面VM內容器介面的生命週期）。
首先，hypervisor上的VM或容器通過連線到OVN整合網橋的埠上傳送資料包。詳細的生命週期如下：

OpenFlow流表0執行物理到邏輯的轉換。它匹配資料包的入口埠。其操作通過設定邏輯資料路徑欄位以標識資料包正在穿越的邏輯資料路徑 以 及設定邏輯輸入埠欄位來標識入口埠，從而實現用邏輯元資料標註資料包。然後重新提交到表8進入邏輯入口管道。

如果源自巢狀在虛擬機器內的容器的資料包有稍微不同的方式處理。可以根據VIF特定的VLAN ID來區分始發容器，因此物理到邏輯轉換流程在VLAN ID欄位上還需要匹配，並且動作將VLAN標頭剝離。在這一步之後，OVN像處理其他資料包一樣處理來自容器的資料包。

流表0還處理從其他chassis到達的資料包。它通過入口埠（這是一個隧道）將它們與其他資料包區分開來。與剛剛進入OVN流水線的資料包一樣，這些操作使用邏輯資料路徑和邏輯入口埠元資料來註釋這些資料包。另外，動作設定了邏輯輸出埠欄位，這是可用的，因為在進行ovn隧道封裝前，邏輯輸出埠是已知的。這三個資訊是從隧道封裝元資料中獲取的（請參閱隧道封裝瞭解編碼細節）。然後操作重新提交到表33進入邏輯出口管道。

OpenFlow流表8至31執行OVN Southbound資料庫中的Logical_Flow表的邏輯入口管道。這些流表完全用於邏輯埠和邏輯資料路徑等邏輯概念的表示。ovn-controller的一大部分工作就是把它們轉換成等效的OpenFlow（尤其翻譯資料庫表：把Logical_Flow表0到表23翻譯為成為OpenFlow流表8到31）。

每個邏輯流都對映到一個或多個OpenFlow流。一個實際的資料包通常只匹配其中一個，儘管在某些情況下它可以匹配多個這樣的資料流（這不是一個問題，因為它們都有相同的動作）。 ovn-controller使用邏輯流的UUID的前32位作為OpenFlow流的cookie。（這不一定是唯一的，因為邏輯流的UUID的前32位不一定是唯一的。）

一些邏輯流程可以對映到Open vSwitch“連線匹配”擴充套件（參見ovs-field部分文件）。流連線操作使用的OpenFlow cookie為0，因為它們可以對應多個邏輯流。一個OpenFlow流連線匹配包含conj_id上的匹配。

如果某個邏輯流無法在該hypervisor上使用，則某些邏輯流可能無法在給定的hypervisor中的OpenFlow流表中表示。例如，如果邏輯交換機中沒有VIF駐留在給定的hypervisor上，並且該hypervisor上的其他邏輯交換機不可訪問（例如，從hypervisor上的VIF開始的邏輯交換機和路由器的一系列跳躍），則邏輯流可能不能在那裡所表示。

大多數OVN操作在OpenFlow中具有相當明顯的實現（具有OVS擴充套件），例如，next實現為resubmit，field =常量; 至於set_field，下面有一些更詳細地描述：

output

通過將資料包重新提交給表32來實現。如果流水線執行多於一個的輸出動作，則將每個單獨地重新提交給表32.這可以用於將資料包的多個副本傳送到多個埠。（如果資料包在輸出操作之間未被修改，並且某些拷貝被指定給相同的hypervisor，那麼使用邏輯多播輸出埠將節省hypervisor之間的頻寬。）

get_arp(P, A)

get_nd(P, A)

通過將引數儲存在OpenFlow欄位中來實現，然後重新提交到表66，ovn-controller使用OVN南向資料庫中的MAC_Binding表生成的此66流表。如果表66中存在匹配，則其動作將繫結的MAC儲存在乙太網目的地地址欄位中。

OpenFlow操作儲存並恢復用於上述引數的OpenFlow欄位，OVN操作不必知道這個臨時用途。

put_arp(P, A, E)

put_nd(P, A, E)

通過將引數儲存在OpenFlow欄位中實現，通過ovn-controller來更新MAC_Binding表。

OpenFlow操作儲存並恢復用於上述引數的OpenFlow欄位，OVN操作不必知道這個臨時用途。

OpenFlow流表32至47在邏輯入口管道中執行輸出動作。具體來說就是表32處理到遠端hypervisors的資料包，表33處理到hypervisors的資料包，表34檢查其邏輯入口和出口埠相同的資料包是否應該被丟棄。

邏輯patch埠是一個特殊情況。邏輯patch埠沒有物理位置，並且有效地駐留在每個hypervisor上。因此，用於輸出到本地hypervisor上的埠的流表33也自然地將輸出實現到單播邏輯patch埠。但是，將相同的邏輯應用到作為邏輯多播組一部分的邏輯patch埠會產生資料包重複，因為在多播組中包含邏輯埠的每個hypervisor也會將資料包輸出到邏輯patch埠。因此，多播組執行表32中的邏輯patch埠的輸出。

表32中的每個流匹配邏輯輸出埠上的單播或多播邏輯埠，其中包括遠端hypervisor上的邏輯埠。每個流的操作實現就是傳送一個數據包到它匹配的埠。對於遠端hypervisor中的單播邏輯輸出埠，操作會將隧道金鑰設定為正確的值，然後將隧道埠上的資料包傳送到正確的遠端hypervisor。（當遠端hypervisor收到資料包時，表0會將其識別為隧道資料包，並將其傳遞到表33中。）對於多播邏輯輸出埠，操作會將資料包的一個副本傳送到每個遠端hypervisor，就像單播目的地一樣。如果多播組包括本地hypervisor上的一個或多個邏輯埠，則其動作也重新提交給表33. 表32還包括：

根據標誌MLF_RCV_FROM_VXLAN匹配從VXLAN隧道接收到的資料包的高優先順序的規則，然後將這些資料包重新提交給表33進行本地傳遞。 從VXLAN隧道收到的資料包由於缺少隧道金鑰中的邏輯輸出埠欄位而到達此處，因此需要將這些資料包提交到表8以確定輸出埠。
根據邏輯輸入埠匹配從localport型別的埠接收到的資料包並將這些資料包重新提交到表33以進行本地傳送的較高優先順序規則。每個 hypervisor都存在localport型別的埠，根據定義，它們的流量不應該通過隧道出去。
如果沒有其他匹配，則重新提交到流表33的備用流。
對於駐留在本地而不是遠端的邏輯埠，表33中的流表類似於表32中的流表。對於本地hypervisor中的單播邏輯輸出埠，操作只是重新提交給表34.對於在本地hypervisor中包括一個或多個邏輯埠的多播輸出埠，對於每個這樣的邏輯埠P，操作將邏輯輸出埠改變為P ，然後重新提交到表34。

一個特殊情況是，當資料路徑上存在localnet埠時，通過切換到localnet埠來連線遠端埠。在這種情況下，不是在表32中增加一個到達遠端埠的流，而是在表33中增加一個流以將邏輯輸出埠切換到localnet埠，並重新提交到表33，好像它被單播到本地hypervisor的邏輯埠上。

表34匹配並丟棄邏輯輸入和輸出埠相同並且MLF_ALLOW_LOOPBACK標誌未被設定的資料包。它重新提交其他資料包到表40。

OpenFlow表40至63執行OVN Southbound資料庫中的Logical_Flow表的邏輯出口流程。出口管道可以在分組交付之前執行驗證的最後階段。 最終，它可以執行一個輸出動作，ovn-controller通過重新提交到表64來實現。流水線從不執行輸出的資料包被有效地丟棄（雖然它可能已經通過穿過物理網路的隧道傳送）。

出口管道不能改變邏輯輸出埠或進行進一步的隧道封裝。

當設定MLF_ALLOW_LOOPBACK時，表64繞過OpenFlow環回。邏輯環回在表34中被處理，但是OpenFlow預設也防止環回到OpenFlow入口埠。因此，當MLF_ALLOW_LOOPBACK被設定時，OpenFlow表64儲存OpenFlow入口埠，將其設定為0，重新提交到表65以獲得邏輯到物理轉換，然後恢復OpenFlow入口埠，有效地禁用OpenFlow回送防止。當MLF_ALLOW_LOOPBACK未被設定時，表64流程僅僅重新提交到表65。

OpenFlow表65執行與表0相反的邏輯到物理翻譯。它匹配分組的邏輯輸出埠。 其操作將資料包輸出到代表該邏輯埠的OVN整合網橋埠。如果邏輯出口埠是一個與VM巢狀的容器，那麼在傳送資料包之前，會加上具有適當VLAN ID的VLAN標頭再進行傳送。

邏輯路由器和邏輯patch埠
通常，邏輯路由器和邏輯patch埠不具有物理位置，並且實際上駐留在hypervisor上。邏輯路由器和這些邏輯路由器後面的邏輯交換機之間的邏輯patch埠就是這種情況，VM（和VIF）連線到這些邏輯交換機。

考慮從一個虛擬機器或容器傳送到位於不同子網上的另一個VM或容器的資料包。資料包將按照前面“資料包的物理生命週期”部分所述，使用表示傳送者所連線的邏輯交換機的邏輯資料路徑，遍歷表0至65。在表32中，資料包本地重新提交到hypervisor上的表33的回退流。在這種情況下，從表0到表65的所有處理都在資料包傳送者所在的hypervisor上進行。

當資料包到達表65時，邏輯出口埠是邏輯patch埠。表65中的實現取決於OVS版本，雖然觀察到的行為意圖是相同的：

在OVS版本2.6和更低版本中，表65輸出到代表邏輯patch埠的OVS的patch埠。在OVS patch埠的對等體中，分組重新進入OpenFlow流表，標識其邏輯資料路徑和邏輯輸入埠都是基於OVS patch埠的OpenFlow埠號。

在OVS 2.7及更高版本中，資料包被克隆並直接重新提交到入口管道中的第一個OpenFlow流表，將邏輯入口埠設定為對等邏輯patch埠，並使用對等邏輯patch埠的邏輯資料路徑（其實是表示邏輯路由器）。

分組重新進入入口流水線以便再次遍歷表8至65，這次使用表示邏輯路由器的邏輯資料路徑。處理過程繼續，如前一部分“資料包的物理生命週期”部分所述。當資料包到達表65時，邏輯輸出埠將再次成為邏輯patch埠。以與上述相同的方式，這個邏輯patch埠將使得資料包被重新提交給OpenFlow表8至65，這次使用目標VM或容器所連線的邏輯交換機的邏輯資料路徑。

該分組第三次也是最後一次遍歷表8至65。如果目標VM或容器駐留在遠端hypervisor中，則表32將在隧道埠上將該分組從傳送者的hypervisor傳送到遠端hypervisor。最後，表65將直接將資料包輸出到目標VM或容器。

以下部分描述了兩個例外，其中邏輯路由器或邏輯patch埠與物理位置相關聯的情況。

閘道器路由器
閘道器路由器是繫結到物理位置的邏輯路由器。這包括邏輯路由器的所有邏輯patch埠以及邏輯交換機上的所有對等邏輯patch埠。在OVN Southbound資料庫中，這些邏輯patch埠的Port_Binding條目使用l3gateway型別而不是patch型別，以便區分這些邏輯patch埠繫結到chassis。

當hypervisor在代表邏輯交換機的邏輯資料路徑上處理資料包時，並且邏輯出口埠是表示與閘道器路由器連線的l3閘道器埠時，該暑假包將匹配表32中流表，通過隧道埠將資料包傳送給閘道器路由器所在的chassis。表32中的處理過程與VIF相同。

閘道器路由器通常用於分散式邏輯路由器和物理網路之間。分散式邏輯路由器及其後面的邏輯交換機（虛擬機器和容器附加到的邏輯交換機）實際上駐留在每個hypervisor中。分散式路由器和閘道器路由器通過另一個邏輯交換機連線，有時也稱為連線邏輯交換機。另一方面，閘道器路由器連線到另一個具有連線到物理網路的localnet埠的邏輯交換機。

當使用閘道器路由器時，DNAT和SNAT規則與閘道器路由器相關聯，閘道器路由器提供可處理一對多SNAT（又名IP偽裝）的中央位置。

分散式閘道器埠
分散式閘道器埠是邏輯路由器patch埠，可以將分散式邏輯路由器與具有本地網路埠的邏輯交換機連線起來。

分散式閘道器埠的主要設計目標是儘可能多地在VM或容器所在的hypervisor上本地處理流量。只要有可能，應該在該虛擬機器或容器的hypervisor上完全處理從該虛擬機器或容器到外部世界的資料包，最終遍歷該hypervisor上的所有localnet埠例項到物理網路。只要有可能，從外部到虛擬機器或容器的資料包就應該通過物理網路直接導向虛擬機器或容器的hypervisor，資料包將通過localnet埠進入整合網橋。

為了允許上面段落中描述的分組分散式處理，分散式閘道器埠需要是有效地駐留在每個hypervisor上的邏輯patch埠，而不是繫結到特定chassis的l3個閘道器埠。但是，與分散式閘道器埠相關的流量通常需要與物理位置相關聯，原因如下：

localnet埠所連線的物理網路通常使用L2學習。任何通過分散式閘道器埠使用的乙太網地址都必須限制在一個物理位置，這樣上游的L2學習就不會混淆了。從分散式閘道器埠向具有特定乙太網地址的localnet埠發出的流量必須在特定chassis上傳送出分散式閘道器埠的一個特定例項。具有特定乙太網地址的localnet埠（或來自與localnet埠相同的邏輯交換機上的VIF）的流量必須定向到該特定chassis上的邏輯交換機的chassis埠例項。

由於L2學習的含義，分散式閘道器埠的乙太網地址和IP地址需要限制在一個物理位置。為此，使用者必須指定一個與分散式閘道器埠關聯的chassis。請注意，使用其他乙太網地址和IP地址（例如，一對一NAT）穿過分散式閘道器埠的流量不限於此chassis。

對ARP和ND請求的回覆必須限制在一個單一的物理位置，在這個位置上應答的乙太網地址。這包括分散式閘道器埠的IP地址的ARP和ND回覆，這些回覆僅限於與分散式閘道器埠關聯的使用者的chassis。

為了支援一對多SNAT（又名IP偽裝），其中跨多個chassis分佈的多個邏輯IP地址被對映到單個外部IP地址，將有必要以集中的方式處理特定chassis上的某些邏輯路由器。由於SNAT外部IP地址通常是分散式閘道器埠IP地址，並且為了簡單起見，使用與分散式閘道器埠相關聯的相同chassis。

ovn-northd文件中描述了對特定chassis的流量限制的詳細資訊。

雖然分散式閘道器埠的大部分物理位置相關方面可以通過將某些流量限制到特定chassis來處理，但還需要一個額外的機制。當資料包離開入口管道，邏輯出口埠是分散式閘道器埠時，需要表32中兩個不同的動作集中的一個：

如果可以在傳送者的hypervisor上本地處理該分組（例如，一對一的NAT通訊量），則該分組應該以正常的方式重新提交到表33，用於分散式邏輯patch埠。
但是，如果資料包需要在與分散式閘道器埠關聯的chassis（例如，一對多SNAT流量或非NAT流量）上處理，則表32必須將該資料包在隧道埠上傳送到該chassis。
為了觸發第二組動作，已經添加了chassisredirect型別的南向資料庫的Port_Binding表。將邏輯出口埠設定為型別為chassisredirect的邏輯埠只是一種方式，表明雖然該資料包是指向分散式閘道器埠的，但需要將其重定向到不同的chassis。在表32中，具有該邏輯輸出埠的分組被髮送到特定的chassis，與表32將邏輯輸出埠是VIF或者型別為13的閘道器埠的分組指向不同的chassis的方式相同。一旦分組到達該chassis，表33將邏輯出口埠重置為代表分散式閘道器埠的值。對於每個分散式閘道器埠，除了表示分散式閘道器埠的分散式邏輯patch埠外，還有一個型別為chassisredirect的埠。

分散式閘道器埠的高可用性
OVN允許您為分散式閘道器埠指定chassis的優先順序列表。這是通過將多個Gateway_Chassis行與OVN_Northbound資料庫中的Logical_Router_Port關聯來完成的。

當為閘道器指定了多個chassis時，所有可能向該閘道器傳送資料包的chassis都將啟用到所有配置的閘道器chassis的通道上的BFD。當前閘道器的主chassis是目前最高優先順序的閘道器chassis，當前是根據BFD狀態判斷為主chassis。

有關L3閘道器高可用性的更多資訊，請參閱 
http://docs.openvswitch.org/en/latest/topics/high-availability

VTEP閘道器的生命週期
閘道器其實是一種chassis，用於在邏輯網路的OVN管理部分和物理VLAN之間轉發流量，將基於隧道的邏輯網路擴充套件到物理網路。

以下步驟通常涉及OVN和VTEP資料庫模式的詳細資訊。請分別參閱ovn-sb，ovn-nb和vtep，瞭解關於這些資料庫的全文。

VTEP閘道器的生命週期始於管理員將VTEP網關注冊為VTEP資料庫中的Physical_Switch表項。連線到此VTEP資料庫的ovn-controller-vtep將識別新的VTEP閘道器，並在OVN_Southbound資料庫中為其建立新的Chassis表條目。

然後，管理員可以建立一個新的Logical_Switch表項，並將VTEP閘道器埠上的特定vlan繫結到任何VTEP邏輯交換機。一旦VTEP邏輯交換機繫結到VTEP閘道器，ovn-controller-vtep將檢測到它，並將其名稱新增到OVN_Southbound資料庫中chassis表的vtep_logical_switches列。請注意，VTEP邏輯交換機的tunnel_key列在建立時未被填充。當相應的vtep邏輯交換機繫結到OVN邏輯網路時，ovn-controller-vtep將設定列。

現在，管理員可以使用CMS將VTEP邏輯交換機新增到OVN邏輯網路。為此，CMS必須首先在OVN_Northbound資料庫中建立一個新的Logical_Switch_Port表項。然後，該條目的型別列必須設定為“vtep”。 接下來，還必須指定options列中的vtep-logical-switch和vtep-physical-switch金鑰，因為多個VTEP閘道器可以連線到同一個VTEP邏輯交換機。

OVN_Northbound資料庫中新建立的邏輯埠及其配置將作為新的Port_Binding表項傳遞給OVN_Southbound資料庫。 ovn-controller-vtep將識別更改並將邏輯埠繫結到相應的VTEP閘道器chassis。禁止將同一個VTEP邏輯交換機繫結到不同的OVN邏輯網路，則會在日誌中產生警告。

除繫結到VTEP閘道器chassis外，ovn-controller-vtep會將VTEP邏輯交換機的tunnel_key列更新為繫結OVN邏輯網路的相應Datapath_Binding表項的tunnel_key。

接下來，ovn-controller-vtep將對OVN_Northbound資料庫中的Port_Binding中的配置更改作出反應，並更新VTEP資料庫中的Ucast_Macs_Remote表。這使得VTEP閘道器可以瞭解從哪裡轉發來自擴充套件外部網路的單播流量。

最終，當管理員從VTEP資料庫取消註冊VTEP閘道器時，VTEP閘道器的生命週期結束。ovn-controller-vtep將識別該事件並刪除OVN_Southbound資料庫中的所有相關配置（chassis表條目和埠繫結）。

當ovn-controller-vtep終止時，將清除OVN_Southbound資料庫和VTEP資料庫中的所有相關配置，包括所有註冊的VTEP閘道器及其埠繫結的Chassis表條目以及所有Ucast_Macs_Remote表項和Logical_Switch隧道金鑰。

安全
針對南向資料庫的基於角色的訪問控制
為了提供額外的安全性以防止OVNchassis受到攻擊，從而防止流氓軟體對南向資料庫狀態進行任意修改，從而中斷OVN網路，從而有了針對南向資料庫的基於角色的訪問控制策略（請參閱ovsdb-server部分以獲取更多詳細資訊）。

基於角色的訪問控制（RBAC）的實現需要在OVSDB模式中新增兩個表：RBAC_Role表，該表由角色名稱進行索引，並將可以對給定角色修改的各個表的名稱對映到許可權表中的單個行，其中包含該角色的詳細許可權資訊，許可權表本身由包含以下資訊的行組成：

Table Name

關聯表的名稱。本欄主要作為幫助人們閱讀本表內容。
1
認證標準

一組包含列名稱的字串。至少一個列或列的內容：要修改，插入或刪除的行中的鍵值必須等於嘗試作用於該行的客戶端的ID,以便授權檢查通過。如果授權標準為空，則禁用授權檢查，並且該角色的所有客戶端將被視為授權。
1
插入/刪除

行插入/刪除許可權(布林值)，指示相關表是否允許插入和刪除行。 如果為true，則授權客戶端允許插入和刪除行。
1
可更新的列

一組包含可能由授權客戶端更新或變異的列或列名稱的金鑰對。只有在客戶的授權檢查通過並且所有要修改的列都包含在這組可修改的列中時，才允許修改行中的列。
1
OVN南行資料庫的RBAC配置由ovn-northd維護。啟用RBAC時，只允許對Chassis，Encap，Port_Binding和MAC_Binding表進行修改，並且重新分配如下：

Chassis

授權：客戶端ID必須與機箱名稱匹配。
插入/刪除：允許授權的行插入和刪除。
更新：授權時可以修改列nb_cfg，external_ids，encaps和vtep_logical_switches。
Encap授權

授權：禁用（所有客戶端都被認為是授權的)。未來在這個表格中新增一個“建立chassis名稱”列，並用它來進行授權檢查。
插入/刪除：允許授權的行插入和刪除。
更新：列型別，選項和IP可以修改。
Port_Binding

授權：禁用（所有客戶端都被認為是授權的)。未來的增強可能會新增列（或關鍵字external_ids），以控制哪個chassis允許繫結每個埠。
插入/刪除：不允許行插入/刪除（ovn-northd維護此表中的行）
更新：只允許對機箱列進行修改。
MAC_Binding

授權：禁用（所有客戶被認為是授權
插入/刪除：允許行插入/刪除。
更新：logical_port，ip，mac和datapath列可以由ovn-controller修改。
為ovn-controller連線到南行資料庫啟用RBAC需要以下步驟：

為證書CN欄位設定為chassis名稱的每個chassis建立SSL證書（例如，對於帶有external-ids：system-id = chassis-1的chassis，通過命令“ovs-pki -B 1024 -u req + sign chassis-1 switch“）。

當連線到南向資料庫時配置每個ovn-controller使用SSL。（例如通過”ovs-vsctl set open . external-ids:ovn-remote=ssl:x.x.x.x:6642”)。

使用“ovn-controller”角色配置南向資料庫SSL遠端。(例如通過 “ovn-sbctl set-connection role=ovn-controller pssl:6642”)。

設計決策
隧道封裝
OVN標註它從一個hypervisor傳送的邏輯網路資料包到另一個hypervisor，包含以下三個元資料，這是在封裝特定的方式編碼：

24位邏輯資料路徑識別符號，來自OVN Southbound資料庫Datapath_Binding表中的隧道金鑰列。
15位邏輯入口埠識別符號。ID 0保留在OVN內部供內部使用。可以將ID 1到32767（包括端點）分配給邏輯埠（請參閱OVN Southbound Port_Binding表中的tunnel_key列）。
16位邏輯出口埠識別符號。ID 0到32767與邏輯入口埠具有相同的含義。可以將包含32768到65535的ID分配給邏輯組播組（請參閱OVN Southbound Multicast_Group表中的tunnel_key列）。
對於hypervisor到hypervisor的流量，OVN僅支援Geneve和STT封裝，原因如下：

只有STT和Geneve支援OVN使用的大量元資料（每個資料包超過32位）（如上所述）。
STT和Geneve使用隨機化的UDP或TCP源埠，允許在底層使用ECMP的環境中在多個路徑之間進行高效分發。
NIC支援對STT和Geneve封裝和解封裝。
由於其靈活性，hypervisor之間的首選封裝是Geneve。對於Geneve封裝，OVN在Geneve VNI中傳輸邏輯資料路徑識別符號。OVN將類別為0x0102，型別為0x80的TLV中的邏輯入口埠和邏輯出口埠從MSB傳輸到LSB，其編碼為32位，如下所示：

網絡卡缺少支援Geneve的環境可能更喜歡STT封裝以達到效能的原因。對於STT封裝，OVN將STT 64位隧道ID中的所有三個邏輯元資料編碼如下，從MSB到LSB：

為了連線到閘道器，除了Geneve和STT之外，OVN還支援VXLAN，因為在機架交換機(ToR）上只支援VXLAN。目前，閘道器具有與由VTEP模式定義的能力匹配的特徵集，因此元資料的位元數是必需的。 將來，不支援封裝大量元資料的閘道器可能會繼續減少功能集。
原文：https://blog.csdn.net/ptmozhu/article/details/78644825?utm_source=blogxgwz3