OVN架構

原文地址

OVN架構

1、簡介

OVN，即Open Virtual Network，是一個支持虛擬網絡抽象的系統。
OVN補充了OVS的現有功能，增加了對虛擬網絡抽象的原生(native)支持，比如虛擬2層和3層還有安全組（security group）。
DHCP等服務也是其理想的特性。和OVS一樣，OVN之所以設計出來，就是爲了獲得一個可以大規模運行的產品級實現。

1.1、OVN實現部分

OVN的實現包括下面幾個部分：

• 雲管系統（Cloud Management System：CMS）：

  作爲OVN的究極客戶端（通過其用戶及管理員）。
  如果要集成OVN，則需要安裝用於CMS的特定插件及相關軟件（見下文）。OVN最初目標是將OpenStack作爲它的CMS。

  也可能存在這樣的場景：多個CMS管理OVN部署的不同部分。

• 物理或虛擬OVN數據庫節點（或集羣）：

  安裝在OVN實現中心的位置

• 一個或更多的（一般來說有很多）虛擬機管理程序（hypervisor）：

  管理程序必須運行Open vSwitch,並實現OVN source tree裏IntegrationGuide.rst文件中所描述的接口。
  我們可以使用任何Open vSwitch支持的虛擬機監控程序平臺。

• 零個或更多的網關：

  網關通過在隧道和物理以太網端口之間雙向轉發數據包，將基於隧道的邏輯網絡擴展到物理網絡中。
  這樣一來，非虛擬機便可以參與邏輯網絡。網關可以是物理主機、虛擬機或者基於ASIC且支持vtep模式的硬件交換機。

  虛擬機管理程序(Hypervisor)和網關(gateway)一起被稱爲傳輸節點(transport node)或chassis。

1.2、OVN主要部分和軟件交互

下圖展示了OVN的主要部分和相關的軟件交互:

                                 CMS
                                  |
                                  |
                      +-----------|-----------+
                      |           |           |
                      |     OVN/CMS Plugin    |
                      |           |           |
                      |           |           |
                      |   OVN Northbound DB   |
                      |           |           |
                      |           |           |
                      |       ovn-northd      |
                      |           |           |
                      +-----------|-----------+
                                  |
                                  |
                        +-------------------+
                        | OVN Southbound DB |
                        +-------------------+
                                  |
                                  |
               +------------------+------------------+
               |                  |                  |
 HV 1          |                  |    HV n          |
+---------------|---------------+  .  +---------------|---------------+
|               |               |  .  |               |               |
|        ovn-controller         |  .  |        ovn-controller         |
|         |          |          |  .  |         |          |          |
|         |          |          |     |         |          |          |
|  ovs-vswitchd   ovsdb-server  |     |  ovs-vswitchd   ovsdb-server  |
|                               |     |                               |
+-------------------------------+     +-------------------------------+

從圖表的最上面開始，主要有：

• 雲管系統(Cloud Management System): 即最上面的部分

• OVN/CMS 插件（Plugin）：插件是用作OVN接口的CMS組件。在OpenStack中，就是一個Neutron插件。
  插件的主要目的就是將CMS的邏輯網絡配置概念（以CMS可識別的特定格式存儲在CMS的配置數據庫中），轉換爲OVN可以理解的中間格式。

  此組件必須是CMS特定的，因此，需要爲每個與OVN集成的CMS開發一個新插件。上圖中此組件下面的所有組件都是獨立於CMS的。

• OVN北向數據庫（Northbound Database）：接收OVN/CMS插件傳遞的邏輯網絡配置的中間表示。
  數據庫模式與CMS中使用的概念阻抗匹配（impedance matched），因此它直接支持邏輯交換機、路由器、ACL等概念。詳見ovn nb。

  OVN北向數據庫有兩個客戶端：它上面的OVN/CMS插件還有它下面的ovn-northd

• ovn-northd: 它上連OVN北向數據庫，下連OVN南向數據庫。
  它將從北向數據庫中獲得的傳統網絡概念中的邏輯網絡配置，轉換爲它下面的南向數據庫所能理解的邏輯數據路徑流（logical datapath flow）。

• OVN南向數據庫（Southbound Database）：這是本系統的中心。
  它的客戶端(client)包括其上的ovn-northd，以及其下每個傳輸節點上的ovn-controller。

  OVN南向數據庫包含三種數據：
  • 物理網絡(Physical Network (PN))表：指明如何訪問hypervisor和其他節點
  • 邏輯網絡(Logical Network (LN))表：用邏輯數據路徑流（logical datapath flows）來描述邏輯網絡，
  • 綁定表：將邏輯網絡組件的位置鏈接到物理網絡

  OVN南向數據庫的性能必須隨着傳輸節點的變化而變化。這就需要在遇到瓶頸的時候在ovsdb-server上進行一些工作。
  可能需要引入集羣來提升可用性。

其餘組件將被複制到每個虛擬機監控程序（hypervisor）上：

• ovn-controller ：是每個hypervisor和軟件網關上的agent。
  • 北向而言，它連接到南向數據庫來獲取OVN的配置及狀態，並用hypervisor的狀態填充綁定表中的PN表和Chassis列。
  • 南向而言，它作爲OpenFlow controller連接到 ovs-vswitchd 來控制網絡流量 ，
    並連接到本地ovsdb-server來監控和控制Open vSwitch的配置。
• ovs-vswitchd 和 ovsdb-server：Open vSwitch的傳統組件。

2、OVN中的信息流

2.1、配置數據

OVN中的配置數據從北向南流動。

CMS使用其OVN/CMS插件，通過北向數據庫來將邏輯網絡配置傳遞給ovn-northd。
另外一邊，ovn-northd將配置編譯成一個較低級別的形式，並通過南向數據庫將其傳遞給所有chassis。

2.2、狀態信息

OVN中的狀態信息從南向北流動。

OVN目前只提供幾種形式的狀態信息。

• 1、首先：ovn-northd填充北向Logical_Switch_Port表中的up列：
  如果南向端口綁定表中的邏輯端口chassis列非空，則將其設爲true，否則爲false。
  這讓CMS可以檢測VM的網絡何時起來（come up）。

• 2、其次：OVN向CMS提供其配置實現的反饋，即CMS提供的配置是否已經生效。
  該特性需要CMS參與序列號協議（sequence number protocol），其工作方式如下：

  • 1) 當CMS更新北向數據庫中的配置時，作爲同一事務的一部分，它將增加NB_Global表中的nb_cfg列的值。
    （只有當CMS想知道配置何時實現時，這纔是必要的。）

  • 2) 當ovn-northd基於北向數據庫的給定快照（snapshot）更新南向數據庫時，作爲同一事務的一部分，
    它將nb_cfg從北向數據庫的NB_Global複製到南向數據庫的SB_Global表中。
    （這樣一來，監視兩個數據庫的觀察者就可以確定南向數據庫何時趕上北向數據庫。）

  • 3) 在ovn northd從southerbound數據庫服務器收到其更改已提交的確認之後，
    它將NB_Global表中的sb_cfg更新爲被已被推到下面的nb_cfg版本。
    （這樣一來，CMS或另一個觀察者可以確定南向數據庫何時被掛起（caught up），而不用與南向數據庫連接）。

  • 4) 每個chassis上的ovn-controller控制器進程接收更新後的南向數據庫和更新後的nb_cfg。
    該過程也會更新chassis的Open vSwitch實例上安裝的物理流（physical flows）。
    當它從Open vSwitch收到物理流已更新的確認信息時，就會在南向數據庫中更新自己的Chassis記錄中的nb_cfg。

  • 5) ovn-northd 監視所有南向數據庫中Chassis記錄的nb_cfg列。
    它跟蹤所有記錄中的最小值，並將其複製到北向NB_Global表的hv_cfg列中。
    （這樣一來，CMS或另一個觀察者就可以確定什麼時候所有hypervisor都趕上了北向配置。）

3、Chassis 設置

OVN部署中的每個Chassis都必須配置一個專門用於ovn的Open vSwitch網橋，稱爲集成網橋(integration bridge)。
如果需要，系統啓動腳本可以在啓動OVN控制器之前創建此網橋。
當OVN控制器啓動時此網橋不存在的話，就將使用下面建議的默認配置來自動創建它。

集成網橋上的端口包括：

• 任何機箱上，OVN用來保持邏輯網絡連接的隧道（tunnel）端口:

  OVN控制器將添加、更新和刪除這些隧道端口。

• 在hypervisor中，任何要連接到邏輯網絡的VIF:
  hypervisor本身，或者vSwitch和hypervisor之間的集成（在integrationguide.rst中描述）會負責處理這個問題。

這不是OVN的一部分，也不是OVN的新內容；這些都是預存在的集成工作，早已經在支持OVS的 hypervisor上實現了。

• 在網關上，用於邏輯網絡連接的物理端口：
  系統啓動腳本在啓動ovn控制器之前將此端口添加到網橋。
  在更復雜的設置中，也可能是是另一個網橋的補丁端口（patch port），而不是物理端口。

其他端口不應連接到集成網橋上。
尤其是，附加到底層網絡（underlay network）的物理端口（與附加到邏輯網絡物理端口的網關端口相反）不能連接到集成網橋。
底層物理端口應該連接到單獨的Open vSwitch網橋（事實上，它們根本不需要連接到任何網橋）。

集成網橋應該按照下面描述的方式配置。每個配置的效果都記錄在ovs-vswitchd.conf.db中：

fail-mode=secure
    避免在OVN控制器啓動之前在隔離的邏輯網絡之間交換數據包。
    詳細信息請參閱ovs vsctl中的 控制器故障設置。
    
other-config:disable-in-band=true
    抑制集成網橋的帶內控制流(in-band  control  flows)。
    由於OVN使用本地控制器（通過Unix域套接字）而不是遠程控制器，所以這樣的控制流顯然是不常見的。
    然而，對於同一系統中的某個其他網橋可能有一個帶內（in-band）遠程控制器，在這種情況下，這可能對帶內控制器正常建立的流量進行抑制。
    請參閱有關文檔以獲取更多信息。

集成橋的慣用名稱是br-int，但可以使用另一個名稱。

4、邏輯網絡（Logical Network）

邏輯網絡（logical network）實現了與物理網絡（physical network）一樣的概念，
不過他們通過通道(tunnel)或者其他封裝手段，與物理網絡隔離開來。
這就讓邏輯網絡可以擁有單獨的IP和其他地址空間，如此一來，便可以與物理網絡所用的IP和地址空間無衝突地重疊。
安排邏輯網絡拓撲的時候，可以不用考慮它們運行所在的物理網絡拓撲。

OVN裏的邏輯網絡概念包含:

• 邏輯交換機（Logical switch）：以太網交換機的邏輯版本
• 邏輯路由器（Logical router）：IP路由器的邏輯版本。邏輯交換機及路由器都可以接入複雜的拓撲裏。
• 邏輯數據通路（Logical datapath）：邏輯版本的OpenFlow交換機。邏輯交換機及路由器都以邏輯數據通路形式實現。
• 邏輯端口（Logical port）：代表了邏輯交換機和邏輯路由器之間的連接點。一些常見類型的邏輯端口有：
  • 邏輯端口（Logical port）:代表VIF。
  • 本地網絡端口（Localnet port）：代表邏輯交換機與物理網絡之間的連接點。
    他們實現爲OVS補丁端口（OVS patch port），架設在集成網橋和單獨的Open vSwitch網橋之間，
    從而作爲底層網絡連接的端口。
  • 邏輯補丁端口（Logical patch port）：代表了邏輯交換機和邏輯路由器之間的連接點，
    有時候還可作爲對等邏輯路由器（peer logical router）連接點。
    每個這樣的連接點都有一對邏輯補丁端口，每側一個。
  • 本地端口端口（Localport port）：代表了邏輯路由器和VIF之間的本地連接點。
    這些端口存在於每個機箱中（未綁定到任何特定的機箱），來自它們的流量永遠不會通過隧道（tunnel）。
    本地端口一般來說只生成目標指向本地目的地的通信，通常是對其接收到請求的響應。
    其中一個用例便是：OpenStack Neutron如何使用Localport端口爲每個hyperviso上的VM提供元數據（metadata）服務。
    元數據代理進程連接到每個主機（host）上的此端口，同一個網絡中的所有VM都將通過相同的IP/MAC地址來訪問它，
    所有流量都不通過隧道發送。想了解更多可以查看鏈接

5、VIF的生命週期

單獨呈現表（Table）和其模式的話會很難理解。這裏有一個例子。

虛擬機監控程序（hypervisor）上的VIF是一個虛擬網絡接口，他們要麼連接到VM上要麼連接到容器
上（容器直接在該hypervisor上運行）。這與在VM中運行的容器的接口不同:

本例中的步驟通常涉及到OVN和OVN Northbound database模式的詳細信息。想了解這些數據庫的完整信息，
請分別參閱ovn-sb和ovn-nb。

• 1、當CMS管理員使用CMS用戶界面或API創建新的VIF，並將其添加到交換機（由OVN作爲邏輯交換機實現）時，VIF的生命週期開始。
  CMS更新自身配置，主要包括：將VIF唯一的持久標識符vif-id和以太網地址mac相關聯。

• 2、CMS插件通過向Logical_Switch_Port表添加一行來更新OVN北向數據庫以囊括新的VIF信息。
  新行之中，名稱是vif-id，mac是mac，交換機指向OVN邏輯交換機的Logical_Switch記錄，其他列則被適當地初始化。

• 3、ovn-northd收到OVN北向數據庫的更新。相應的，它做出響應，在南向數據庫的Logical_Flow表的添加新行，以映射新的端口。比如：添加一個流來識別發往給新端口的MAC地址的數據包，並且更新傳遞廣播和多播數據包的流以囊括新的端口。它還在“綁定”表中創建一條記錄，並填充用於識別chassis的列之外的所有列。

• 4、每個hypervisor上的ovn-controller都會接收上一步ovn-northd在Logical_Flow表所做的更新。
  但如果持有VIF的虛擬機關機，ovn-controller就無能爲力了。
  例如，它不能發送數據包或從VIF接收數據包，因爲VIF實際上並不存在了。

• 5、最終，用戶啓動擁有該VIF的VM。在VM啓動的hypervisor上，
  hypervisor與Open vSwitch（IntegrationGuide.rst中所描述的）之間的集成，是通過將VIF添加到OVN集成網橋上實現的，
  此外還需要在external_ids：iface-id中存儲vif-id，以指示該接口是新VIF的實例。

  這些代碼在並不是OVN的新功能；在支持OVS的虛擬機管理程序上就已經預先集成了。

• 6、在啓動VM的hypervisor上，ovn-controller在新的接口中注意到external_ids：iface-id。
  作爲響應，在OVN南向數據庫中，它將更新綁定表的chassis列中的相應行，這些行鏈接邏輯端口external_ids：iface-id到hypervisor。
  之後，ovn-controller更新本地虛擬機hypervisor的OpenFlow表，以便正確處理進出VIF的數據包。

• 7、一些CMS系統，包括OpenStack，只有在網絡準備就緒的情況下才能完全啓動虛擬機。
  爲了支持這個功能，ovn-northd一旦發現Binding表中的chassis列的某行更新了，
  則通過更新OVN北向數據庫的Logical_Switch_Port表中的up列來向上標識這個變化，以表明VIF現在已經啓動。

  如果使用此功能，CMS則可通過允許VM執行來繼續進行後面的反應。

• 8、在VIF所在的每個hypervisor上，ovn-controller會覺察到綁定表中完全填充的行。
  這爲ovn-controller提供了邏輯端口的物理位置，
  因此每個實例都會更新其交換機的OpenFlow流表（基於OVN數據庫Logical_Flow表中的邏輯數據路徑流），以便通過隧道來正確處理進出VIF的數據包。

• 9、最終，用戶關閉持有該VIF的VM。在VM關閉的hypervisor上，VIF將從OVN集成網橋中刪除。

• 10、在VM關閉的hypervisor上，ovn-controller發現到VIF已被刪除。作爲響應，它將刪除邏輯端口綁定表中的Chassis列的內容。

• 11、在每個hypervisor上，ovn-controller都會發現綁定錶行中空的Chassis列。
  這意味着ovn-controller不再知道邏輯端口的物理位置，因此每個實例都會更新其OpenFlow表以反映這一點。

• 12、最終，當VIF（或其整個VM）不再被任何人需要時，管理員使用CMS用戶界面或API刪除VIF。CMS更新自己的配置。

• 13、CMS插件通過刪除Logical_Switch_Port表中的相關行來從OVN北向數據庫中刪除VIF。

• 14、ovn-northd收到OVN北向數據庫的更新，然後相應地更新OVN南向數據庫，
  方法是：從OVN南向數據庫的Logical_Flow表和綁定表中刪除或更新與已銷燬的VIF相關的行。

• 15、在每個hypervisor上，ovn-controller接收在上一步中的Logical_Flow表的更新內容，並更新OpenFlow表。

  不過可能沒有太多要做，因爲VIF已經變得無法訪問，它在上一步中就從綁定表中刪除了。

6、VM內部容器接口的生命週期

OVN通過將寫在OVN_NB數據庫中的信息，轉換成每個hypervisor中的OpenFlow流表來提供虛擬網絡抽象。

如果想要爲多租戶提供安全的虛擬網絡連接，那麼OVN控制器便應該是唯一可以修改Open vSwitch中的流的實體時候。當Open vSwitch集成網橋駐留在虛擬機管理程序中時，虛擬機內運行的租戶工作負載（ tenant workloads ）是無法對Open vSwitch流進行任何更改的。

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

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

在虛擬機內創建多個容器時，會有多個CIF關聯。爲了便於OVN支持虛擬網絡抽象，
與這些CIF關聯的網絡流量需要到達hypervisor中運行的Open vSwitch集成網橋。
OVN還應能夠區分來自不同CIF的網絡流量。

6.1、區分CIP網絡流量的方法

有兩種方法可以區分CIF的網絡流量：

6.1.1、1:1

第一種方法是爲每個CIF都提供一個VIF（1:1）：

這意味着hypervisor中可能有很多網絡設備。由於管理所有VIF會造成額外的CPU消耗，這會使OVS變慢。
這也意味着在VM中創建容器的實體也應該能夠在hypervisor中創建相應的VIF。

6.1.2、 1:2

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

• 1、CIF的生命週期從虛擬機內部創建容器開始，該容器可以是由創建虛擬機的同一CMS創建，或擁有該虛擬機的租戶創建，
  甚至可以是由與最初創建虛擬機的CMS不同的容器編制系統所創建。
  無論創建容器的實體是誰，它需要知道與虛擬機的網絡接口關聯的vif-id，容器接口的網絡流量將通過該網絡接口來流通。
  創建容器接口的實體也需要在該虛擬機內部選擇一個未使用的VLAN。

• 2、創建容器的實體（直接或間接通過CMS管理底層基礎結構）通過向Logical_Switch_Port表添加一行來更新OVN南向數據庫以囊括新的CIF。
  在新行中，name是任何唯一的標識符，parent_name是CIF網絡流量預計要經過的VM的vif-id，tag是標識該CIF網絡流量的VLAN標記。

• 3、ovn-northd收到OVN北向數據庫的更新。反過來，它通過添加相應行到OVN南向數據庫的Logical_Flow表來反映新的端口，
  並通過在Binding表中創建一個新行(填充除了標識列以外的所有列)，來相應地更新OVN南向數據庫的chassis。

• 4、在每個hypervisor上，ovn-controller訂閱綁定表中的更改。
  當由ovn-northd創建的新行中包含Binding表的parent_port列中的值時，
  擁有與external_ids：iface-id中的vif-id相同值的ovn集成網橋上的ovn-controller,將會更新本地hypervisor的OpenFlow流表，
  這樣來自具有特定VLAN標記的VIF的數據包便可以得到正確的處理。之後，它會更新綁定表的chassis列以反映物理位置。

• 5、底層網絡準備就緒後，便只能在容器內啓動應用程序。
  爲了支持這個功能，ovn-northd在綁定表中通知更新的chassis列，
  並更新OVN Northbound數據庫的Logical_Switch_Port表中的up列，以表示CIF現在已經啓動。
  負責啓動容器應用程序的實體查詢到該值並啓動應用程序。

• 6、最後，創建並啓動容器的實體，會停止容器。實體則通過CMS（或直接）刪除Logical_Switch_Port表中的行。

• 7、ovn-northd接收OVN Northbound更新，並相應地更新OVN Southbound數據庫，
  方法是從OVN Southbound數據庫Logical_Flow表中刪改與已經銷燬的CIF相關聯的行。
  同時也會刪除該CIF綁定表中的行。

• 8、在每個hypervisor中，ovn-controller接收在上一步中Logical_Flow表的更新。
  ovn-controller會更新本地的OpenFlow表以反映更新。

7、數據包的物理處理生命週期

本節介紹數據包如何通過OVN從一個虛擬機或容器傳輸到另一個。

這個描述着重於數據包的物理處理。有關數據包邏輯生命週期的描述，請參考ovn-sb中的Logical_Flow表。

爲了清楚起見，本節提到了一些數據和元數據字段，總結如下：

7.1、涉及的數據和元數據字段

• 隧道密鑰。當OVN在Geneve或其他隧道中封裝數據包時，會附加額外的數據，以使接收的OVN實例正確處理。
  取決於特定的封裝形式，會採取不同的形式，但在每種情況下，我們都將其稱爲“隧道密鑰”。
  請參閱文末的“隧道封裝”以瞭解詳細信息。

• 邏輯數據路徑字段。表示數據包正在被處理的邏輯數據路徑的字段。
  OVN使用OpenFlow 1.1+簡單地（且容易混淆地）調用“元數據”來存儲logical datapath字段。
  （該字段作爲隧道密鑰的一部分通過隧道進行傳遞。）

• 邏輯輸入端口字段。表示數據包從哪個邏輯端口進入logical datapath的字段。
  OVN將其存儲在Open vSwitch擴展寄存器14中。Geneve和STT隧道將這個字段作爲隧道密鑰的一部分傳遞。
  雖然VXLAN隧道沒有明確地帶有邏輯輸入端口，OVN只使用VXLAN與網關進行通信，從OVN的角度來看，
  只有一個邏輯端口，因此OVN可以在輸入到OVN時，將邏輯輸入端口字段設置爲該邏輯輸入的邏輯管道。

• 邏輯輸出端口字段。表示數據包將離開logical datapath的邏輯端口的字段。在邏輯入口管道的開始，它被初始化爲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內容器接口的生命週期）。

7.2、詳細的生命週期

首先，hypervisor上的VM或容器通過連接到OVN集成網橋的端口上,來發送數據包。詳細的生命週期如下：

• 1、OpenFlow流表0執行物理到邏輯的轉換。它匹配數據包的入口（ingress）端口。
  其通過設置邏輯數據路徑 字段以標識數據包正在穿越的邏輯數據路徑，並設置邏輯輸入端口字段來標識入口端口，
  從而實現用邏輯元數據標註數據包。然後重新提交到表8進入邏輯入口管道。

源自嵌套在虛擬機內的容器的數據包有稍微不同的方式處理。
可以根據VIF特定的VLAN ID來區分始發容器，因此物理到邏輯的轉換流程將在VLAN ID字段上需要匹配，
且在VLAN header剝離時也會進行匹配。在這一步之後，OVN像處理其他數據包一樣處理來自容器的數據包。

流表0還處理從其他chassis到達的數據包。它通過入口端口（這是一個隧道）將它們與其他數據包區分開來。
與剛剛進入OVN流水線的數據包一樣，這些操作使用邏輯數據路徑和邏輯入口端元數據來註釋這些數據包。
另外，設置邏輯輸出端口字段的操作也是可用的，因爲在OVN中，隧道發生在邏輯輸出端口已知之後。
這三個信息是從隧道封裝元數據中獲取的（請參閱隧道封裝瞭解編碼細節）。
然後操作重新提交到表33以進入邏輯出口管道。

• 2、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連接匹配(`conjunctive match)擴展（參見ovs-field部分文檔）。
  流連接操作使用的OpenFlow cookie爲0，因爲它們可以對應多個邏輯流。
  關於OpenFlow流的連接匹配包含conj_id上的匹配。

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

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

  • output
    通過將數據包重新提交給表32來實現。如果pipeline執行多於一個的輸出動作，則將每個動作單獨地重新提交給表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操作不必知道這個臨時用途。

• 3、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。

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

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

• 5、當設置MLF_ALLOW_LOOPBACK時，表64繞過OpenFlow環回(loopback )。
  邏輯環回在表34中被處理，但是OpenFlow默認也防止環回到OpenFlow入口端口。
  因此，當MLF_ALLOW_LOOPBACK被設置時，OpenFlow表64保存OpenFlow入口端口，將其設置爲0，
  重新提交到表65以獲得邏輯到物理轉換，然後恢復OpenFlow入口端口，有效地禁用OpenFlow回送防止。
  當MLF_ALLOW_LOOPBACK未被設置時，表64流程僅僅重新提交到表65。

• 6、OpenFlow表65執行與表0相反的邏輯到物理(logical-to-physica)翻譯。它匹配分組的邏輯輸出端口。
  其將數據包輸出到代表該邏輯端口的OVN集成網橋端口。
  如果邏輯出口端口是一個與VM嵌套的容器，那麼在發送數據包之前，會加上具有適當VLAN ID的VLAN標頭再進行發送。

8、邏輯路由器和邏輯patch端口

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

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

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

• 在OVS版本2.6和更低版本中，表65輸出到代表邏輯patch端口的OVS的patch端口。
  在OVS patch端口的peer中，分組重新進入OpenFlow流表，標識其邏輯數據路徑和邏輯輸入端口都基於OVS patch端口的OpenFlow端口號。

• 在OVS 2.7及更高版本中，數據包被克隆並直接重新提交到入口管道中的第一個OpenFlow流表，將邏輯入口端口設置爲對等邏輯patch端口，
  並使用對等邏輯patch端口的logical datapath（其實表示的是邏輯路由器）。

包重新進入入口流水線（ingress pipeline）以便再次遍歷表8至65，這次使用表示邏輯路由器的邏輯數據路徑。

處理過程繼續，如前一部分“數據包的物理生命週期”部分所述。當數據包到達表65時，邏輯輸出端口將再次成爲邏輯patch端口。
使用與上述相同的方式，這個邏輯patch端口將使得數據包被重新提交給OpenFlow表8至65，這次使用目標VM或容器所連接的邏輯交換機的邏輯數據路徑。

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

以下部分描述了兩個例外情況：邏輯路由器或邏輯patch端口與物理位置相關聯。

8.1、網關路由器

網關路由器是綁定到物理位置的邏輯路由器。這包括邏輯路由器的所有邏輯patch端口以及邏輯交換機上的所有對等邏輯patch端口。
在OVN Southbound數據庫中，這些邏輯patch端口的Port_Binding條目使用l3gateway類型而不是patch類型，以便區分這些邏輯patch端口綁定到chassis。

當hypervisor在代表邏輯交換機的邏輯數據路徑上處理數據包，並且邏輯出口端口是表示與網關路由器連接的l3gateway時，
該包將匹配表32中的流表，通過隧道端口將數據包發送給網關路由器所在的chassis。表32中的處理過程與VIF相同。

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

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

8.2、分佈式網關端口

分佈式網關端口是邏輯路由器patch端口，可以將分佈式邏輯路由器和具有本地網絡端口的邏輯交換機連接起來。

分佈式網關端口的主要設計目標，是儘可能多的在VM或容器所在的hypervisor上本地處理流量。
只要有可能，就應該在該虛擬機或容器的hypervisor上，完全處理從該虛擬機或容器到外部世界的數據包，
最終遍歷該hypervisor上到物理網絡的所有localnet端口實例。
只要有可能，從外部到虛擬機或容器的數據包，就應該通過物理網絡直接導向虛擬機或容器的hypervisor，數據包將通過localnet端口進入集成網橋。

爲了允許上面段落中描述的分組分佈式處理，分佈式網關端口應該是有效地駐留在每個hypervisor上的邏輯patch端口，而不是綁定到特定chassis的l3gateway端口。
但是，與分佈式網關端口相關的流量通常需要與物理位置相關聯，原因如下：

• 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類型的端口。

8.3、分佈式網關端口的高可用性

OVN允許您爲分佈式網關端口指定chassis的優先級列表。

這是通過將多個Gateway_Chassis行與OVN_Northbound數據庫中的Logical_Router_Port關聯來完成的。

當爲網關指定了多個chassis時，所有可能向該網關發送數據包的chassis都將啓用通道上的BFD，這些隧道通往所有配置的網關chassis。

當前網關的主chassis是當前最高優先級的網關chassis，該chassis根據BFD狀態被當做主chassis。

有關L3網關高可用性的更多信息，請參閱鏈接

9、連接到邏輯路由器的多個LocalNet邏輯交換機

可以有多個邏輯交換機，每個交換機都有一個本地網絡端口（代表物理網絡）連接到邏輯路由器，
其中一個localnet邏輯交換機可以通過分佈式網關端口提供外部連接，其餘的localnet邏輯交換機在物理網絡中使用VLAN標記。
需要爲所有這些localnet網絡在chassis上正確配置ovn網橋映射（ovn-bridge-mappings）。

9.1、東西向路由

這些帶有localnet VLAN標記的邏輯交換機之間的東西路由工作方式，與普通邏輯交換機幾乎相同。
當虛擬機發送這樣的數據包時，則：

• 1、它首先進入源localnet邏輯交換機數據路徑的入口（ingress）管道，然後進入出口(egress)管道。
  然後，它通過源chassis中的邏輯路由器端口進入邏輯路由器數據路徑(datapath)的入口管道。

• 2、進行路由決策（Routing decision）。

• 3、數據包從路由器數據路徑（datapath）進入目的地localnet邏輯交換機數據路徑的入口管道，然後出口管道，
  並通過localnet端口從集成（integration）網橋再到提供者（provider）網橋（屬於目的地邏輯交換機）。

• 4、目標chassis通過localnet端口接收數據包並將其發送到集成網橋（integration bridge）。
  數據包（packet）進入目的地localnet邏輯交換機的入口管道，然後離開管道，最後被送到目的地VM端口。

9.2、外部流量

當虛擬機發送外部流量（需要NATting），並且承載虛擬機的chassis沒有分佈式網關端口時，會發生以下情況：

• 1、數據包首先進入源LocalNet邏輯交換機數據路徑（datapath）的入口管道，然後離開管道。
  然後，它通過源chassis中的邏輯路由器端口進入邏輯路由器數據路徑的入口管道。

• 2、進行路由決策。由於網關路由器或分佈式網關端口不在源chassis中，流量通過隧道端口重定向到網關機箱。

• 3、網關chassis通過隧道端口接收數據包，數據包進入邏輯路由器數據路徑的出口管道。NAT規則將在這裏被應用。
  然後，數據包進入提供外部連接的localnet邏輯交換機數據路徑的入口管道，接着離開管道，最後通過提供外部連接的邏輯交換機的localnet端口離開。

儘管這樣做有效，但當從計算chassis發送到網關chassis時，VM通信量將被隧道化。
爲了使其正常工作，必須降低localnet邏輯交換機的MTU，以考慮隧道封裝。

10、連接到邏輯路由器的帶有localnet VLAN標記的邏輯交換機的集中路由

爲了克服上一節中描述的隧道封裝(tunnel encapsulation)問題，
OVN支持爲帶有localnet VLAN標記的邏輯交換機，啓用集中路由的選項。

CMS可以配置選項：將所有連接到相應邏輯交換機（帶有localnet vlan標記）logical_router_port的reside-on-redirect-chassis選項設爲true ，
這會導致網關chassis（承載分佈式網關端口）處理這些網絡的所有路由，使其集中化。
它將回復對邏輯路由器端口IP的ARP請求。

如果邏輯路由器沒有連接到提供外部連接的localnet邏輯交換機的分佈式網關端口，則OVN將忽略此選項。
當VM發送需要路由的東西向流量時，會發生以下情況：

• 1、包首先進入入口管道，然後進入源localnet邏輯交換機數據路徑的出口管道，
  並通過源localnet邏輯交換機的localnet端口發送出去（而不是發送到路由器管道）。

• 2、網關chassis通過源localnet邏輯交換機的localnet端口接收數據包並將其發送到集成網橋。
  然後，數據包進入入口(ingress)管道，接着離開源localnet邏輯交換機數據路徑的管道，並進入邏輯路由器數據路徑的入口管道。

• 3、進行路由決策（Routing decision）。

• 4、數據包從路由器數據路徑（datapath）進入目的地localnet邏輯交換機數據路徑的入口管道，然後離開管道。
  接着，它通過localnet端口離開集成橋到提供者（provider）橋（屬於目標邏輯交換機）。

• 5、目標chassis通過localnet端口接收數據包並將其發送到集成網橋。
  數據包進入目的地localnet邏輯交換機的入口管道，然後離開管道，最後到達目的地VM端口。

當vm發送需要NATting的外部流量時，會發生以下情況：

• 1、 包首先進入入口管道，然後進入源localnet邏輯交換機數據路徑的出口管道，
  並通過源localnet邏輯交換機的localnet端口發送出去（而不是發送到路由器管道）。

• 2、網關機箱通過源localnet邏輯交換機的localnet端口接收數據包並將其發送到集成網橋。
  然後，數據包進入入口管道，之後離開源localnet邏輯交換機數據路徑的管道，並進入邏輯路由器數據路徑的入口管道。

• 3、進行路由決策（Routing decision）並應用NAT規則

• 4、數據包從路由器數據路徑，進入提供外部連接的localnet邏輯交換機數據路徑的入口管道，然後從出口管道流出。
  最後，它通過localnet端口離開集成橋到提供者橋（屬於提供外部連接的邏輯交換機）。

對於反向外部流量，將發生以下情況：

• 1、網關機箱從提供外部連接的邏輯交換機的localnet端口接收數據包。
  然後，數據包進入localnet邏輯交換機（提供外部連接）的入口管道，接着離開管道。
  之後，數據包進入邏輯路由器數據路徑的入口管道。

• 2、 邏輯路由器數據路徑的入口管道應用unNATting規則。
  然後，數據包進入源localnet邏輯交換機的入口管道，接着離開管道。
  由於源vm不在網關chassis中，因此數據包通過源邏輯交換機的localnet端口發送。

• 3、源chassis通過localnet端口接收數據包並將其發送到集成網橋。
  數據包進入源localnet邏輯交換機的入口管道，然後離開管道，最後被送到源VM端口。

11、VTEP網關的生命週期

網關其實是一種chassis，用於在邏輯網絡的OVN管理部分和物理VLAN之間轉發流量，將基於隧道的邏輯網絡擴展到物理網絡。

以下步驟通常涉及OVN和VTEP數據庫模式的詳細信息。請分別參閱ovn-sb，ovn-nb和vtep，瞭解關於這些數據庫的詳細信息。

• 1、VTEP網關的生命週期始於管理員將VTEP網關注冊爲VTEP數據庫中的Physical_Switch表項。
  連接到此VTEP數據庫的ovn-controller-vtep將識別新的VTEP網關，
  並在OVN_Southbound數據庫中爲其創建新的Chassis表條目。

• 2、然後，管理員可以創建一個新的Logical_Switch表項，並將VTEP網關端口上的特定vlan綁定到任意VTEP邏輯交換機。
  一旦VTEP邏輯交換機綁定到VTEP網關，ovn-controller-vtep將檢測到它，
  並將其名稱添加到OVN_Southbound數據庫中chassis表的vtep_logical_switches列。

請注意，VTEP邏輯交換機的tunnel_key列在創建時未被填充。
當相應的vtep邏輯交換機綁定到OVN邏輯網絡時，ovn-controller-vtep纔將設置列內容。

• 3、現在，管理員可以使用CMS將VTEP邏輯交換機添加到OVN邏輯網絡。
  爲此，CMS必須首先在OVN_Northbound數據庫中創建一個新的Logical_Switch_Port表項。
  然後，該條目的類型列必須設置爲“vtep”。
  接下來，還必須指定options列中的vtep-logical-switch和vtep-physical-switch密鑰，
  因爲多個VTEP網關可以連接到同一個VTEP邏輯交換機。

• 4、OVN_Northbound數據庫中新創建的邏輯端口及其配置將作爲新的Port_Binding表項傳遞給OVN_Southbound數據庫。
  ovn-controller-vtep將識別更改內容並將邏輯端口綁定到相應的VTEP網關chassis。

禁止將同一個VTEP邏輯交換機綁定到不同的OVN邏輯網絡，否則會在日誌中產生警告。

• 5、除綁定到VTEP網關chassis外，ovn-controller-vtep還會將VTEP邏輯交換機的tunnel_key列，
  更新爲綁定OVN邏輯網絡的相應Datapath_Binding表項的tunnel_key。

• 6、接下來，ovn-controller-vtep將對OVN_Northbound數據庫中的Port_Binding中的配置更改作出反應，
  並更新VTEP數據庫中的Ucast_Macs_Remote表。
  這使得VTEP網關可以瞭解從哪裏轉發來自擴展外部網絡的單播流量。

• 7、最終，當管理員從VTEP數據庫註銷VTEP網關時，VTEP網關的生命週期結束。
  ovn-controller-vtep將識別該事件並刪除OVN_Southbound數據庫中的所有相關配置（chassis表條目和端口綁定）。

• 8、當ovn-controller-vtep終止時，將清除OVN_Southbound數據庫和VTEP數據庫中的所有相關配置，
  包括所有註冊的VTEP網關及其端口綁定的Chassis表條目，以及所有Ucast_Macs_Remote表項和Logical_Switch隧道密鑰。

12、安全

12.1、針對南向數據庫的基於角色的訪問控制

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

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

• Table Name
  關聯表的名稱。本欄存在主要是爲了幫助人們閱讀本表內容。

• 認證（Auth Criteria）
  一組包含列名稱的字符串（或者是列的column:key對，這些列包含了string:string映射關係）。
  至少一個列或列的內容：要修改，插入或刪除的行中的鍵值必須等於嘗試作用於該行的客戶端的ID,

  要刪改的行中，至少有一個column:key值或者列的內容，必須和嘗試作用於該行的客戶端的ID相同，以便授權檢查通過。

  如果授權標準爲空，則禁用授權檢查，並且該角色扥所有客戶端將被視爲已授權。

• 插入/刪除（Insert/Delete）
  行插入/刪除權限(布爾值)，指示相關表是否允許增刪行。 如果爲true，則授權客戶端增刪行。

• 可更新的列（Updatable Columns）
  一組字符串，他們包含了可能由授權客戶端更新或變異的列或 column:key對。

  只有在客戶的授權檢查通過，並且所有要修改的列都包含在這組可修改的列中時，才允許修改行中的列。

  OVN南向數據庫的RBAC配置由ovn-northd維護。
  啓用RBAC時，只允許對Chassis / Encap / Port_Binding和MAC_Binding表進行修改，
  並且重新分配如下：

  • Chassis

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

  • Encap授權

    • 授權：客戶端ID必須與chassis 名稱匹配。
    • 插入/刪除：允許授權的行插入和刪除。
    • 更新：列類型，選項和IP可以修改。

  • Port_Binding

    • 授權：禁用（所有客戶端都被認爲是授權的)。
      未來改進可能會添加列（或external_ids的key），以控制哪個chassis允許綁定每個端口。
    • 插入/刪除：不允許行插入/刪除（ovn-northd維護此表中的行）
    • 更新：只允許對chassis列進行修改。

  • MAC_Binding

    • 授權：禁用（所有客戶被認爲是授權的）
    • 插入/刪除：允許行插入/刪除。
    • 更新：logical_port，ip，mac和datapath列可以由ovn-controller修改。

要爲ovn-controller連接到南向數據庫啓用RBAC，需要以下步驟：

• 1、爲證書CN字段設置爲chassis名稱的每個chassis創建SSL證書

  例如，對於帶有external-ids：system-id = chassis-1的chassis，
  通過命令ovs-pki -B 1024 -u req + sign chassis-1 switch。

• 2、當連接到南向數據庫時配置每個ovn-controller使用SSL。（
  例如通過ovs-vsctl set open . external-ids:ovn-remote=ssl:x.x.x.x:6642。

• 3、使用“ovn-controller”角色配置南向數據庫SSL遠程。

  例如通過ovn-sbctl set-connection role=ovn-controller pssl:6642。

12.2、使用IPsec加密隧道通信

OVN隧道流量需流經物理路由器和交換機，而這些物理設備可能不受信任（公共網絡中的設備），或者可能受到危害。
對隧道流量啓用加密可以防止對流量數據進行監視和操作。

隧道流量是用IPsec加密的。
CMS設置北向NB_Global表中的IPsec列，以啓用或禁用IPsec加密。
如果ipsec爲true，則所有OVN隧道都將加密。
如果ipsec爲false，則不會加密OVN隧道。

當CMS更新北向NB_Global表中的ipsec列時，ovn-northd將該值複製到南向SB_Global表中的ipsec列。
每個chassis中的ovn-controller監視南向數據庫，並相應地設置OVS隧道接口的選項。
OVS隧道接口選項由ovs-monitor-ipsec守護程序監視，該守護程序通過配置IKE守護程序來啓動ipsec連接。

Chassis使用證書相互驗證。如果隧道中的另一端提供由受信任的CA簽名的證書，
並且公用名（CN）與預期的Chassis名匹配，則驗證成功。

基於角色的訪問控制（RBAC）中使用的SSL證書可以在IPsec中使用。也可以使用ovs-pki創建不同的證書。
證書要求是x.509 version 3，並且將CN字段和SubjectAltName字段設置爲Chassis名稱。

在啓用IPsec之前，需要在每個Chassis中安裝CA證書、Chassis證書和私鑰。
請參閱ovs vswitchd.conf.db來設置基於CA的IPsec身份驗證。

13、設計決策

13.1、隧道（tunnel）封裝

OVN標註從一個hypervisor發送到另一個的邏輯網絡包，這些包包含以下三個元數據，他們以encapsulation-specific的方式編碼：

• 1、24位邏輯數據路徑標識符，來自OVN Southbound數據庫Datapath_Binding表中的隧道密鑰列。
• 2、15位邏輯入口端口標識符。ID 0被保留在OVN內部供內部使用。
  可以將ID 1到32767（包括端點）分配給邏輯端口（請參閱OVN Southbound Port_Binding表中的tunnel_key列）。
• 3、16位邏輯出口端口標識符。ID 0到32767與邏輯入口端口具有相同的含義。
  可以將32768到65535的ID分配給logical多播組（請參閱OVN Southbound Multicast_Group表中的tunnel_key列）。

對於hypervisor到hypervisor的流量，OVN僅支持Geneve和STT封裝，原因如下：

• 1、只有STT和Geneve支持OVN使用的大量元數據（每個數據包超過32位）（如上所述）。
• 2、STT和Geneve使用隨機化的UDP或TCP源端口，允許在底層使用ECMP的環境中，在多個路徑之間進行高效分發。
• 3、NIC支持對STT和Geneve封裝和解封裝。

由於其靈活性，hypervisor之間的首選封裝方案是Geneve。
對於Geneve封裝，OVN在Geneve VNI中傳輸邏輯數據路徑標識符。
OVN將類別爲0x0102，類型爲0x80的TLV中的邏輯入口端口和邏輯出口端口從MSB傳輸到LSB，其編碼爲32位，如下所示：

 1       15          16
+---+------------+-----------+
|rsv|ingress port|egress port|
+---+------------+-----------+
 0

不支持Geneve的網卡環境，因爲性能的原因，可能更偏向STT封裝。
對於STT封裝，OVN將STT 64位隧道ID中所有三個邏輯元數據編碼如下，從MSB到LSB分別是：

   9          15          16         24
+--------+------------+-----------+--------+
|reserved|ingress port|egress port|datapath|
+--------+------------+-----------+--------+
   0

爲了連接到網關，除了Geneve和STT之外，OVN還支持VXLAN，因爲在top-of-rack (ToR)交換機上，只有VXLAN是普遍支持的。、
目前，網關具有與由VTEP模式定義的能力匹配的特徵集，因此元數據的比特數是必需的。
將來，不支持封裝大量元數據的網關可能會繼續減少功能集。