ovn-architecture

参考

1 Name

 ovn-architecture,Open Virtual Network architecture

2 Description

 OVN是一个支持虚拟网络抽象的系统。OVN补充了OVS现有的功能，增加了对虚拟网络抽象(如virtual L2和)的本机支持L3覆盖和安全组.像DHCP这样的服务也是需要的特性。就像OVS一样，OVN的设计目标是拥有一个生产质量的实现，可以大规模运行.
 OVN部署包含多个组件：

• (1)一个云管理系统(CMS)，它是OVN的最终客户端(通过其用户和管理员)。OVN集成需要安装一个特定于cms的插件和相关软件(见下面)。OVN最初将OpenStack定位为CMS
  
   我们通常说的是“the”CMS，但是我们可以想象多个CMS管理一个OVN部署的不同部分的场景。
• (2)安装在中央位置的OVN数据库物理或虚拟节点(或最终的集群)。
• (3)一个或多个(通常是多个)hypervisors。Hypervisors必须运行Open vSwitch并实现IntegrationGuide中描述的接口。在OVS源树中的rst。可以接受Open vSwitch支持的任何管理程序平台
• (4)零个或多个网关。网关通过在隧道和物理以太网端口之间双向转发数据包，将基于隧道的逻辑网络扩展为物理网络。这允许非虚拟化的机器参与到逻辑网络中。网关可以是物理主机、虚拟机或支持vtep(5)模式的基于asic的硬件交换机
  
   Hypervisors以及gateway同时被称为传输节点或者chassis。

下图显示了OVN的主要组件和相关软件的交互方式。从图的顶部开始，我们有:

• (1)Cloud Management System
• (2)OVN/CMS插件是CMS作用到OVN的组件。在OpenStack,该组件是Neutron plugin。这个插件的主要目的是将存储在CMS配置数据库中的逻辑网络配置概念转换成OVN可以理解的中间表示。
  
   这个组件必须是特定于CMS的，因此需要为与OVN集成的每个CMS开发一个新的插件。图中这个组件下面的所有组件都是独立于CMS的
• (3)OVN Northbound Databse接收由OVN/CMS插件传递下来的逻辑网络配置的中间表示。数据库模式旨在与CMS中使用的概念进行阻抗匹配，以便它直接支持逻辑交换机、路由器、acl等概念。详情见ovn-nb(5)
  
   OVN向北的数据库只有两个客户端:上面的OVN/CMS插件和下面的OVN-northd。
• (4)ovn−northd连接上面的OVN向北的数据库和下面的OVN向南的数据库。它按照传统网络概念(取自OVN向北的数据库)将逻辑网络配置转换为下面的OVN向南的数据库中的逻辑数据路径流
  
• (5)OVN Southbound Database是系统的核心。在它上面的客户端是ovn−northd(8)，在它下面的每个传输节点上的客户端是ovn−controller(8)。
  
   OVN南向数据库包含3个类型数据：
  • 1)Physical Network(PN) tables
    
     指定了如何到达hypervisor以及其它节点
  • 2)Logical Network(LN) tables
    
     用“逻辑数据路径流”来描述逻辑网络。
  • 3)Binding tables
    
     链接逻辑网络设备组件位置到物理网络上。hypervisors(应该是其之上的ovn-controller)填充PN(Encap、Chassis)以及Port_Binding表，而ovn-northd填充LN表(logical_flow)
    
     OVN向南的数据库性能必须随着传输节点的数量而扩展。由于遇到瓶颈，这可能需要在ovsdb服务器(1)上进行一些工作。可能需要集群来获得可用性。
• (6)其余组件被复制到每个hypervisor:
  • 1)ovn-controller
    
     是每个hypervisor上的agent以及软件网关。北向，其链接到OVN Southboun Database来学习OVN配置及状态。同时根据hypervisor的状态填充PN表，以及Binding表中的Chassis列。南向，其作为OpenFlow控制器连接到ovs-vswitchd,控制覆盖网络流量，并且连接到ovsdb-server,允许其监控并配置Open vSwitch配置
  • 2)ovs-vswitchd及ovsdb-server是Open vSwitch的常规组件
    

注意：OVN Northbound Database及Southbound Database是基于ovsdb-server实现的

2.1 Information Flow in OVN(OVN中的信息流向)

 OVN中的配置数据从北流向南。CMS通过其OVN/CMS插件，通过ovn北向数据库，将逻辑网络配置传输给ovn-northd。ovn-northd编译配置到一个更低级别的形式，并通过南向数据库传给所有的chassis。

 OVN中的状态信息从南流向北。OVN目前只提供几种形式的状态信息。

• (1)允许CMS探测VM网络在什么时候启动。如果逻辑端口的chassis列在向南向的Port_Binding表中是非空的，则ovn-north在北向数据库中将Logical_Switch_Port表up列设置为true，否则为false。
  
• (2)OVN向CMS提供配置实现的反馈。即来自CMS的配置是否生效。该特性要求CMS参与一系列协议，其工作方式如下。
  
  • 1)当CMS更新北行的数据库中的配置时，作为同一事务的一部分，它会增加NB_Global表中nb_cfg列的值。(只有当CMS想知道配置是何时实现的时候，才需要这样做。)
  • 2)当ovn northd根据北向数据库的给定快照更新南向数据库时，它将从北向数据库的NB_Global复制nb_cfg到南向数据库的SB_Global表中，作为同一事务的一部分。(因此，监视两个数据库的观察者可以确定向南的数据库何时赶上了向北的数据库。)
  • 3)当ovn-northd从南向数据库服务器接收到其更改已提交的确认后，它将北向NB_Global表中的sb_cfg更新为下推的nb_cfg版本。(因此，CMS或其他观察者可以确定在没有连接到南向数据库的情况下，南向数据库何时被捕获。)
  • 4)每个chassis上的ovn−controller进程接收更新后的南向数据库，以及更新后的nb_cfg。这个过程反过来更新安装在chassis的Open vSwitch实例中的物理流。当它从Open vSwitch接收到物理流已经更新的确认信息时，它将在南行数据库中更新自己的chassis记录中的nb_cfg
  • 5)ovn-northd监视南行数据库中所有chassis记录中的nb_cfg列。它跟踪所有记录中的最小值，并将其复制到向北的NB_Global表中的hv_cfg列中。(因此，CMS或其他观察者可以确定所有管理程序何时赶上了向北的配置。)

2.2 Chassis Setup

 OVN部署中的每个chassis都必须配置一个专用于OVN使用的Open vSwitch网桥，称为集成网桥。如果需要，系统启动脚本可以在启动ovn控制器之前创建这个桥。如果在ovn-controller启动时此桥不存在，则将使用下面建议的缺省配置自动创建它。集成网桥上的端口包括:

• (1)在任何chassis上，OVN用于维护逻辑网络连接的隧道端口。ovn-controller负责添加、更新、删除这些隧道端口。
• (2)在一个hypervisor上，任何附加到逻辑网络上的VIF。hypervisor本身或者Open vSwitch以及hyperfisor的集成，关心它((这不是OVN的一部分，亦不是OVN的新产品;这是在支持OVS的管理程序上已经完成的预先存在的集成工作)
• (3)在网关上，用于逻辑网络连接的物理端口。系统启动脚本在启动ovn−controller之前将这个端口添加到桥上。在更复杂的设置中，这可以是到另一个网桥的patch.

 其他端口不应该附加到集成网桥上。特别地，附加到底层网络的物理端口(与网关端口相反，网关端口是附加到逻辑网络的物理端口)不能附加到集成桥接上。底层的物理端口应该连接到一个单独的Open vSwitch Bridge上(实际上，它们根本不需要连接到任何桥接器上)。

 集成网桥应该按照下面描述的方式配置。这些设置的效果都记录在ovs vswitch .conf.db(5)中:

• 1)fail-mode=secure:
  
   在ovn-controller启动之前，避免在隔离的逻辑网络之间交换数据包。更多信息，请参见ovs−vsctl(8)中的控制器故障设置
• 2)other−config:disable−in−band=true
   抑制集成网桥的带内控制流。这样的流不太可能出现，因为OVN使用本地控制器(overaUnix域套接字)而不是远程控制器。然而，对于同一系统中的其他网桥，也有可能使用带内遥控器，在这种情况下，这会抑制带内控制通常设置的流量。有关更多信息，请参阅文档。
  
   通常集成桥接器的名称是br-int，但也可以使用其他名称

2.3 Logical Networks

 一个逻辑网络的实现远程与一个网络网络相同。但是它们使用隧道或其它封装技术与物理网络隔离。这允许逻辑网络拥有独立的IP和其他地址空间，这些地址空间与物理网络使用的地址空间重叠而不冲突。逻辑网络拓扑可以在不考虑其所运行的物理网络拓扑的情况下进行安排。

 OVN逻辑网络概念包括：

• (1)Logical switches，以太网交换机的逻辑版本
• (2)Logical routers, IP路由器的逻辑版本。逻辑交换机和路由器可以连接到复杂的拓扑结构中.
• (3)Logical datapaths,是OpenFlow switch的逻辑版本。逻辑交换机和路由器都是作为逻辑数据路径实现的
• (4)Logical ports,表示示逻辑交换机和逻辑路由器的连接点。一些常见的逻辑端口类型是
  • 1)Logical ports代表VIFs
  • 2)Localnet ports(ovn0),表示逻辑交换机和物理网络之间的连接点。它们被实现为集成网桥和底层物理网络附加的单独Open vSwitch网桥间的OVS patch端口。
  • 3)Logical patch ports,表示逻辑交换机和逻辑路由器之间以及在某些情况下对等逻辑路由器之间的连接点。在每一个这样的连接点上都有一对逻辑补丁端口，每边一个
  • 4)Localport端口(_h)表示逻辑交换机和VIFs之间的本地连接点。这些端口存在于每个chassis中(不绑定到任何特定的chassis)，来自它们的通信不会通过隧道。localport预期只生成发送到本地目的地的流量，通常是为了响应它接收到的请求。一个用例是OpenStack Neutron如何使用localport端口为驻留在每个管理程序上的VM提供元数据。一个元数据代理进程连接到每个主机上的这个端口，同一网络中的所有VM将以相同的IP/MAC地址到达它，而不会通过网络传输任何流量。更多的细节可以在https://docs.openstack.org/developer/networkovn/design/metadata_api.html看到

2.4 Life Cycle of a VIF(VIF的生命周期)

 单独呈现的表及其模式很难理解。这里有一个例子

 hypervisor上的一个VIF是虚拟网络的接口，其链接到一个VM或者一个直接运行在hypervisors上的容器。

 本例中的步骤通常引用OVN和OVN向北的数据库模式的详细信息.有关这些数据库的完整信息，分别参见ovn−sb(5)和ovn−nb(5)

• (1)当CMS管理员使用CMS用户界面或API创建一个新的VIF并将其添加到交换机(由OVN作为逻辑交换机实现)时，VIF的生命周期就开始了。CMS更新自己的配置。这包括将唯一持久的标识符vif-id和以太网地址mac与VIF相关联。
  
• (2)CMS插件通过向Logical_Switch_Port表添加一行来更新OVN北向的数据库，以包含新的VIF。在新行中，name为vif-id, mac为mac，switch指向OVN逻辑交换机的Logical_Switch记录，其他列也相应地初始化。
  
• (3)ovn-northd接收到ovn北向数据库更新，并对OVN南向数据库执行关联更新。通过往OVN南向数据库Logical_Flow表插入行来反应新Port(比如，添加一个流来识别发送到新端口MAC地址的数据包应该被发送到该端口以及更新传输广播和多播数据包的流，以包含新的端口)。其同时在Binding表中创建了一条记录，填充除标识chassis的列以外的所有列
• (4)在每个hypervisor上，ovn控制器接收ovn northd在上一步中进行的Logical_Flow表更新。只要拥有VIF的VM关闭电源，ovn控制器就做不了什么;例如，它不能安排向VIF发送数据包或从VIF接收数据包，因为VIF实际上并不存在于任何地方
• (5)最终，用户对拥有VIF的VM进行开机。VM使能的hypervisor上，hypervisor=和Open vSwitch的集成(described in IntegrationGuide.rst，实际是CNI)添加VIF到OVN集成网桥，并且在新VIF的external_ids:iface-id属性上存储vif-id(ovs上以_h结尾的interface)实现VIF的实例化。(这些代码在OVN中都不是新的;这是在支持OVS的hypervisor上已经完成的预先存在的集成工作)
  
• (6)在启动VM的hypervisor上，ovn-controller注意到external_ids:iface−id 在新接口中。作为响应，在OVN南向数据库中，它更新Binding表的Chassis列，用于将逻辑端口从external_ids: iface−id链接到hypervisor上。之后，ovn−controller更新本地hypervisor的OpenFlow表，以便正确处理进出VIF的数据包
• (7)一些CMS系统(包括OpenStack)只有在联网准备就绪时才能完全启动VM。为了支持这一点，ovn _northd注意到Binding表中已更新的chassis列，并通过向上更新ovn Northbound数据库的Logical_Switch_Port表中的up列，以表明VIF现在已经启动。如果CMS使用了这个特性，那么它就可以通过允许VM继续执行来做出反应
  
• (8)除了VIF所在的hypervisor之外，在每个hypervisor中，ovn-controller都会注意到Binding表中已完全填充的行。这为ovn-controller提供了逻辑端口的物理位置，因此每个实例更新其交换机的OpenFlow表(基于ovn DB Logical_Flow表中的逻辑数据路径流)，以便能够通过隧道正确处理进出VIF的数据包
  
• (9)最后，用户关闭拥有VIF的VM。在关闭VM的hypervisor上，VIF从OVN集成网桥(应该就是ovs上的VIF实例)上删除
  
• (10)在关闭VM的hypervisor上，ovn−controller注意到VIF被删除了。作为响应，它删除逻辑端口的绑定表中的chassis内容
  
• (11)在每个hypervisor上，ovn-controller会注意到逻辑端口的Binding表行中的空chassis列。这意味着ovn-controller不再知道逻辑端口的物理位置，因此每个实例更新其OpenFlow表以反映这一点
  
• (12)最终，当任何人不再需要VIF(或它的整个VM)时，管理员将使用CMS用户界面或API删除VIF。CMS更新自己的配置
• (13)CMS插件通过删除Logical_Switch_Port表中的VIF行，从向北的OVN数据库中删除VIF
• (14)ovn-northd接收到ovn north-bound更新，并相应地更新ovn南向数据库，方法是删除或更新ovn南向数据库Logical_Flow表和Binding表中与已销毁的VIF相关的行
• (15)在每个hypervisor上，ovn-controller获取Logical_Flow表更新(ovn-northd在上一步实现)。ovn-controller更新OpenFlow表，来反应更新。尽管这时可能没有什么要做的了。因为在上一步中将VIF从绑定表中删除时，它已经不可访问了

2.5 Life Cycle of a Container Interface Inside a VM

 OVN通过将写入OVN_NB数据库的信息转换为hypervisor中的OpenFlow流来提供虚拟网络抽象。对于多租户的安全网络，只有在OVN控制器是唯一可以修改Open vSwitch中流的实体时才会提供。

 如果基础设施提供者信任容器内的应用程序不会中断并修改Open vSwitch流，那么容器可以在hypervisors中运行。当容器在VMs中运行,并且具有OVN控制器添加流的Open vSwitch集成网桥驻留在相同的VM中。对于上述两种情况，工作流与上一节(“VIF的生命周期”)中的示例所解释的相同。

 本节讨论CIF的生命周期，当容器在VM中创建，并且Open vSwitch集成网桥驻留在hypervisor上。在该案例中，即使容器应用出错，其它租户不会受到影响，因为容器在VM中运行，不会修改Open vSwitch集成网桥中的流

 当多个容器在VM中创建时，这里分配了多个CIFS。分配给CIF的网络流量需要到达为了OVN，运行在hpyervisor上的集成网桥，以支持虚拟网络抽象。OVN应该能够区分来自不同CIFs的网络流量。这里用两者方式来区分CIFs的网络流量。

• (1)为每个CIF提供VIF(1:1模型)，这意味着将会在hypervisor上有大量的网络设备。这将会使ovs变慢，因为有多少VIF就要有多少额外的CPU 周期来管理它。这也意味着，在VM中创建容器的实体，也需要能够在hypervisor中创建关联的VIFs.
• (2)第二种方式是为所有的CIF提供单一的VIF。OVN通过每个包中的tag来区分来自不同CIF的网络流量。OVN使用这种机制，并使用VLAN作为tag机制
• 1)当创建VM的相同CMS或拥有该VM的租户或与最初创建VM的CMS不同的组件编排系统在VM中生成容器时，CIF的生命周期就开始了。无论是谁创建了容器，它需要知道分配给用于容器接口网络流量通行的VM网络接口的vif-id。该实体，同时需要在VM中选择未使用的VLAN
• 2)容器衍生实体(直接或通过管理底层基础设施的CMS)通过向Logical_Switch_Port表添加一行，更新OVN向北的数据库以包含新的CIF。在新行中，name是任何唯一标识符，parent_name是CIF的网络流量预期要经过的VM的vif-id，标记是标识该CIF的网络流量的VLAN标记。
• 3)ovn-northd接收ovn北向数据库更新。然后，它对OVN南向数据库进行相应的更新，方法是向OVN南向数据库的Logical_Flow表中添加行以反映新的端口，并在绑定表中创建新行，填充除标识chassis列之外的所有列
• 4)在每个hypervisor,ovn-controller订阅Binding表的更新。当ovn-northd创建一个新行，其中包含Binding表的parent_port列中的值时，ovn−contrller(其所在hypervisor的ovn集成网桥在external_ids:iface-id与vif-id有相同的值),更新本地hypervisor的OpenFlow表，以使带有特定VLAN标记的VIF和VIF之间的数据包得到正确处理。然后，它更新绑定的chassis列以反映物理位置。
• 5)只有在底层网络准备就绪后，才能在容器内启动应用程序。为了支持这一点，ovn-northd注意到Binding中已更新的chassis列，并更新ovn- Northbound数据库Logical_Switch_Port表中的up列，以表明CIF现在已经启动。负责启动容器应用程序的实体查询此值并启动应用程序
• 6)最终，创建和启动容器的实体将停止它。实体通过CMS(或直接)删除它在Logical_Switch_Port表中的行
• 7)ovn−northd接收到ovn向北的更新，并相应地更新ovn向南的数据库，方法是删除或更新ovn向南数据库Logical_Flow表中与已销毁的CIF相关的行。它还删除Binding表中用于CIF的行
• 8)在每个hypervisor上，ovn控制器接收ovn- northd在上一步中进行的Logical_Flow表更新。ovn控制器更新OpenFlow表以反映更新

2.6 Architectural Physical Life Cycle of a Packet

 该章节描述了一个数据包是如何通过OVN从一个虚拟机或容器到另外一个的。该描述着重关注数据包的物理处理。数据包的逻辑生命周期参考ovn-sb中的Logical_Flow表。

2.6.1 数据和元数据字段说明

 本节提到了几个数据和元数据字段，这里总结了一下:

• (1)tunnel key
  
   OVN将数据包分装在Geneve或者其它隧道中，它附加额外的数据，以允许接收OVN实例正确地处理它。根据特定的封装方式，它有不同的形式，但在每种情况下，我们在这里将其称为“tunnel key”。详情请参阅下面的Tunnel Encapsulations。
• (2)logical datapath field
  
   一种字段，表示处理信息包所通过的逻辑数据路径。OVN使用OpenFlow 1.1+中层位metadata的字段来存储逻辑数据路径的字段。(该字段作为隧道key的一部分通过隧道。)
• (3)logical input port field
  
   表示信息包从其中进入逻辑数据路径的逻辑端口的字段。OVN将其存储在Open vSwitch扩展寄存器14中。
  
   Geneve和STT隧道通过该字段作为隧道密钥的一部分。尽管VXLAN隧道没有明确逻辑输入端口,OVN只使用VXLAN与网关通信(从OVN看只包含一个逻辑端口),以便OVN逻辑输入端口字段设置为这个OVN逻辑管道入口。
• (4)logical output port field
  
   表示信息包将从其中离开逻辑数据路径的逻辑端口的字段。在逻辑入口管道开始时，它被初始化为0。OVN将其存储在Open vSwitch扩展寄存器号15中
  
   Geneve和STT隧道通过该字段作为隧道密钥的一部分。VXLAN隧道不传输逻辑输出端口字段。由于VXLAN隧道在隧道密钥中不携带逻辑输出端口字段，所以当OVN hypervisor从VXLAN隧道接收到一个包时，将该包重新提交给表8，以确定输出端口;当数据包到达表32时，通过检查MLF_RCV_FROM_VXLAN标志(当数据包从VXLAN隧道到达时设置)，将这些数据包重新提交到表33进行本地发送
  
• (5)conntrack zone field for logical ports
  
   表示逻辑端口的连接跟踪区域的字段。该值仅具有本地意义，在chassis之间没有意义。在逻辑入口管道开始时，它被初始化为0。OVN将其存储在Open vSwitch扩展寄存器13中
• (6)conntrack zone fields for routers
  
   字段，表示路由器的连接跟踪区域。这些值只在本地有意义，在底盘之间没有意义。OVN在Open vSwitch扩展寄存器编号11中存储用于DNATting的区域信息，在Open vSwitch扩展寄存器编号12中存储用于SNAT的区域信息
• (7)logical flow flags
  
   逻辑标志用于处理表之间的上下文，以决定匹配后续表中的哪些规则。这些值只在本地有意义，在chassis之间没有意义。OVN将逻辑标志存储在Open vSwitch扩展寄存器10中
• (8)VLAN ID
  
   VLAN ID用作OVN和嵌套在VM中的容器之间的接口(更多信息，请参阅上面VM中容器接口的生命周期)。
  

2.6.2 包生命周期

 开始时，在入hypervisor上的vm或容器在附加在OVn集成网桥上的port发送数据包。然后

• (1)OpenFlow表0执行物理到逻辑的转换。其匹配数据包入口。其action用逻辑元数据注释该数据包(通过设置逻辑数据路径字段来标识信息包正在穿过的逻辑数据路径，并设置逻辑输入端口字段来标识入口端口)
  
   来自嵌套在VM中的容器的包以略微不同的方式处理。可以根据特定于vif的VLAN ID来区分原始容器，因此物理到逻辑转换流额外匹配VLAN ID，而action将删除VLAN头。按照这个步骤，OVN处理来自容器的包就像处理任何其他包一样
  
   表0还处理来自其他chassis的数据包。其通过数据包入口端口是否为隧道端口将它们与其它数据包区分开。与刚进入OVN流水线的数据包一样，action用逻辑数据路径和逻辑入口端口元数据对这些数据包进行注释。此外，这些操作设置了逻辑输出端口字段，这是因为在OVN中隧道化发生在知道逻辑输出端口之后。这三条信息是从隧道封装元数据中获得的(参见隧道封装了解编码细节)。然后，操作重新提交到表33，以进入逻辑出口pipeline
  
• (2)OpenFlow表8到31执行从OVN南向数据库获取的Logical_Flow对应的逻辑入流水线。这些表完全按照逻辑概念(如逻辑端口和逻辑数据路径)来表示。ovn控制器的一大部分工作是将它们转换为等效的OpenFlow(特别是转换表号:Logical_Flow表0到23变成OpenFlow表8到31)。
  
   每个逻辑流映射到一个或多个OpenFlow流。实际的包通常只匹配其中一个流，尽管在某些情况下它可以匹配多个流(这不是问题，因为所有这些流都具有相同的操作)。ovn−controller使用逻辑流UUID的前32位作为其OpenFlow流或流的cookie。(这不一定是惟一的，因为逻辑流UUID的前32位不一定是惟一的。)
  
   一些逻辑流可以映射到Open vSwitch"conjunctive match"扩展(参见ovs字段(7))。带有连接动作的流使用OpenFlow cookie为0，因为它们可以对应多个逻辑流。连接匹配的OpenFlow流包括conj_id上的匹配
  
   某些逻辑流可能不会在给定的hypervisor上的OpenFlow表中表示，如果它们不能在该hypervisor上使用的话。例如，如果给定的hypervisor上的逻辑交换机中没有VIF，并且逻辑交换机在该hypervisor上无法以其他方式访问(例如，从hypervisor上的VIF开始，通过逻辑交换机和路由器进行一系列跳转)，则逻辑流可能不在其中表示:
  
  &esmp;大多数OVN操作在OpenFlow中都有对应的实现(包括ovs扩展)。next;被实现为resubmit,field=constant;被实现为set_fileld.一些值得更多细节的action:
  • 1)output:
    
     通过重新提交数据包到表32实现。如果pipeline执行多个output操作，那么每个操作都将分别重新提交到表32。这可以用来将包的多个副本发送到多个端口。(如果包在输出操作之间没有被修改，并且一些副本被发送到相同的hypervisor，那么使用逻辑多播输出端口可以节省hypervisor之间的带宽。)
  • 2)get_arp(P,A);
    
     get_nd(p,A);
    
     通过将参数存储到OpenFlow字段中，然后重新提交到表66来实现，ovn控制器使用从ovn南行数据库中的MAC_Binding表生成的流填充该表。如果在表66中有匹配，那么它的操作将绑定的MAC存储在以太网目标地址字段中。(OpenFlow操作保存并恢复用于参数的OpenFlow字段，因此OVN操作不必知道这种临时使用。)
  • 3)get_arp(P,A,E);
    
     get_nd(p,A,E);
    
     通过将参数存储到OpenFlow字段中，然后向ovn控制器输出一个包来实现，ovn控制器更新MAC_Binding表.(OpenFlow操作保存并恢复用于参数的OpenFlow字段，因此OVN操作不必知道这种临时使用。)
• (3)OpenFlow表32到47在逻辑入口管道中实现输出操作。具体来说，表32处理发送到远程hypervisor的数据包，表33处理发送到本地hypervisor的数据包，而表34检查是否应该丢弃逻辑入口和出口端口相同的数据包。
  
   逻辑补丁端口是一种特殊情况。逻辑补丁端口没有物理位置，它有效地驻留在每个hypervisor程序上。因此，用于输出到本地hypervisor上端口的流表33自然也实现了输出到单播逻辑补丁端口。但是，将相同的逻辑应用到逻辑多播组的逻辑补丁端口会产生包重复，因为在多播组中包含逻辑端口的每个hypervisor也会将包输出到逻辑补丁端口。因此，多播组实现了表32中逻辑补丁端口的输出
  
   表32中的每个流为单播或组播匹配逻辑出口(其信息中包含了一个远程hypervisor的逻辑端口)。每个流执行发送数据包到它匹配的出口的action.对于远程hypervisor上的单播逻辑输出端口，action将隧道键设置为正确的值，然后将隧道端口上的包发送到正确的hypervisor。(当远程hypervisor接收到数据包时，表0将识别出它是经过隧道的数据包，并将其传递给表33)。对于多播逻辑输出端口，操作将数据包的一个副本发送到每个hypervisor，方法与单播目的地相同。如果一个多播组包含本地hypervisor上的一个或多个逻辑端口，那么它的操作也将重新提交给表33。表32还包括：
  • 1)基于标志MLF_RCV_FROM_VXLAN匹配从VXLAN隧道接收的数据包的高优先级规则，并将这些数据包重新提交到表33进行本地传递。从VXLAN隧道接收的数据包到达这里是因为隧道key中缺少逻辑输出端口字段，因此需要将这些数据包提交到表8以确定输出端口
  • 2)一个高优先级规则，根据逻辑输入端口匹配从localport类型的端口接收的数据包，并将这些数据包重新提交到表33以进行本地传递。每个hypervisor上都存在localport类型的端口，根据定义，它们的流量不应该通过隧道流出。
  • 3)匹配带有MLF_RCV_FROM_VXLAN标志数据包的高优先级规则被设置，其目的地址是组播地址。该标记表明即使组播地址包含远端hypervisors的的端口，该数据包也不应该被发送到远端hypervisor。该flag用于，当ovn-controller是组播包的源。由于每个ovn−controller实例都是这些数据包的始发方，因此数据包只需要被发送到本地端口。
  • 4)回退流，如果没有其他匹配项，它将重新提交到表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南向数据库中的Logical_Flow表执行逻辑出口流水线。出口流水线可以在包传递之前执行最后一个验证阶段。最后，它可能会执行一个输出操作，ovn−controller通过重新提交到表64来实现这个输出操作。对于管道从未执行过输出的包，将有效地丢弃(尽管它可能已经通过物理网络的隧道传输)
  
   出口pipline不能更改逻辑输出端口或导致进一步的隧道
• (5)当MLF_ALLOW_LOOPBACK被设置时，表64绕过了OpenFlow的环回。逻辑环回在表34中被处理，但是OpenFlow默认情况下也阻止环回到OpenFlow的入口端口。因此，当设置MLF_ALLOW_LOOPBACK时，OpenFlow表64保存OpenFlow入口端口，将其设置为零，重新提交到表65进行逻辑-物理转换，然后恢复OpenFlow入口端口，从而有效地禁用OpenFlow环回防止。当MLF_ALLOW_LOOPBACK未设置时，表64流简单地重新提交到表65
  
• (6)与表0相反，OpenFlow表65执行从逻辑到物理的转换。它匹配数据包的逻辑出口端口。它的操作将数据包输出到连接到表示该逻辑端口的OVN集成桥的端口。如果逻辑出口端口是一个嵌套在VM中的容器，那么在发送数据包之前，操作会推送一个带有适当VLAN ID的VLAN头
  
   

2.7 Logical Routers and Logical Patch Ports

 通常，逻辑路由器和逻辑补丁端口没有物理位置，而是有效地驻留在hypervisor中。对于vm(和VIFs)附加到的逻辑路由器和逻辑交换机之间的逻辑补丁端口，情况就是如此

 考虑从一个虚拟机或容器发送到另一个虚拟机或驻留在不同子网上的容器的数据包。信息包将遍历表0到65，如前一节所述，使用逻辑数据路径表示发送方附加到的逻辑交换机。在表32中，包将使用回退流，该回退流在同一hypervisor上本地重新提交到表33。在这种情况下，从表0到表65的所有处理都发生在发送方所在的hypervisor上.

 当数据包到达表65时，逻辑出口端口是一个逻辑补丁端口。表65中的实现因OVS版本的不同而不同，尽管观察到的行为是相同的。(在OVS版本2.6和更早版本中，表65输出到一个表示逻辑补丁端口的OVS补丁端口。数据包从表0中的OVS补丁端口的对等端重新进入OpenFlow流表，该表根据OVS补丁端口的OpenFlow端口号识别逻辑数据路径和逻辑输入端口。在OVS 2.7及更高版本中，数据包被克隆并直接重新提交到入口管道中的第一个OpenFlow流表，将逻辑入口端口设置为对等逻辑补丁端口，并使用对等逻辑补丁端口的逻辑数据路径(其代表逻辑路由器)。)

 数据包重入ingress pipeline以便再次遍历表8到表65，这一次使用代表逻辑路由器的逻辑数据路径。处理将按照前一节中描述的包的体系结构物理生命周期进行。当数据包到达表65时，逻辑出口端口将再次成为逻辑补丁端口。按照上面描述的相同方式，这个逻辑补丁端口将导致数据包重新提交到OpenFlow表8到65，这次使用逻辑数据路径表示目标VM或容器附加到的逻辑交换机

 数据包第三次(也是最后一次)遍历表8到65。如果目标VM或容器驻留在远程管理程序上，那么表32将通过隧道端口将数据包从发送方的hypervisor发送到hypervisor。最后，表65将把数据包直接输出到目标VM或容器

 下面的部分描述了两个例外，其中逻辑路由器和/或逻辑补丁端口与物理位置相关联。

• (1)Gateway Routers
  
   一个网关路由器是绑定到物理位置的逻辑路由器。其包含了所有逻辑路由器的patch port以及所有逻辑交换机上对等逻辑patch端口。在OVN南向数据库中这些逻辑补丁端口的Port_Binding条目使用l3gateway类型而不是patch，以便区分绑定到一个chassis的逻辑patch端口。
  
   当一个hypervisor在代表逻辑交换机的逻辑datapath上处理数据包时，逻辑出口端口是一个l3gateway端口，代表连接到一个网关路由器。该数据包将会匹配流表32中的一条流，其在一个tunnel端口上发送数据包到网关路由器所在的chassis上。表32中的处理方式与VIF相同。
  
   网关路由器通常用于分布式逻辑路由器和物理网络之间。vm和容器附加到的分布式逻辑路由器及其背后的逻辑交换机有效地驻留在每个hypervisor上。分布式路由器和网关路由器由另一个逻辑交换机连接，有时称为连接逻辑交换机。在另一端，网关路由器连接到另一个逻辑交换机，该交换机有一个连接到物理网络的localnet端口
  
   当使用网关路由器时，DNAT和SNAT规则与网关路由器相关联，网关路由器提供一个中央位置，可以处理一对多的SNAT(又名IP伪装)

• (2)Distributed Gateway Ports
  
   分布式网关端口是逻辑路由器补丁端口，它通过localnet端口直接将分布式逻辑路由器连接到逻辑交换机
  
   分布式网关端口的主要设计目标是允许在VM或容器所在的hypervisor上本地处理尽可能多的通信。只要可能，从VM或容器到外部世界的包应该在VM或容器的hypervisor上完全处理，最终通过该管理程序上的localnet端口实例到物理网络。只要有可能，应该通过物理网络将来自外部的包直接定向到VM或容器的hypervisor，包将进入其中
  
   为了允许对上面段落中描述的包进行分布式处理，分布式网关端口需要是有效驻留在每个hypervisor上的逻辑补丁端口，而不是绑定到特定chassis上的l3gateway端口。然而，与分布式网关端口相关联的流通常需要与物理位置相关联，原因如下:

  • 1)ocalnet端口所连接的物理网络通常使用L2学习。任何
    在分布式网关端口上使用的以太网地址必须被限制到一个单一的物理位置，这样上游L2学习就不会混淆。将分布式网关端口发送到具有特定以太网地址的localnet端口的流量必须发送到一个特定chassis上的分布式网关端口的一个特定实例。必须将从localnet端口(或从与localnet端口相同逻辑交换机上的VIF)接收的具有特定以太网地址的流量定向
    
     由于L2学习的影响，需要将以太网地址和分布式网关端口的IP地址限制在一个单一的物理位置。由于这个原因，用户必须指定一个与分布式网关端口相关联的chassis。注意，使用其它以太网地址和IP地址(例如一对一NAT)穿越分布式网关端口的流量不受此底盘的限制
    
     对ARP和ND请求的响应必须被限制在一个物理位置，其中以太网地址在应答驻留。这包括ARP和ND应答的分布式网关端口的IP地址，它被限制到与分布式网关端口相关联的用户的chassis
    
  • 2)为了支持一对多SNAT(又名IP伪装)，在这种情况下，分布在多个chassis上的多个逻辑IP地址被映射到单个外部IP地址，将有必要以集中的方式在chassis箱上处理一些逻辑路由器处理。由于SNAT外部IP地址通常是分布式网关端口IP地址，为了简单起见，使用与分布式网关端口相关联的相同chassis
    

 对于特定chassis的流限制的细节在ovn - northd文档中进行了描述

 虽然分布式网关端口的大多数物理位置相关方面可以通过将一些流限制到特定的机箱来处理，但是需要一个额外的机制。当一个包离开入口pipeline和逻辑出口端口是分布式网关端口时，在表32中需要两组不同的动作之一

• 1)当数据包可以在发送方hypervisor本地处理时(比如一对一NAT)，按照分布式逻辑补丁端口的正常方式，数据重新提交给表33。
• 2)然而，如果包需要在与分布式网关端口相关联的chassis上处理(例如一对多SNAT流量或非nat流量)，那么表32必须在隧道端口上将包发送到该chassis

 为了触发第二组操作，添加了南向Port_Binding的chassisredirect类型。将逻辑出口端口设置为chassisredirect逻辑端口类型是一种简单的方法，表明尽管包的目的地是分布式网关端口，但它需要被重定向到不同的chassis。在表32中，具有此逻辑出口端口的数据包被发送到特定的chassis，与表32将逻辑出口端口为VIF或类型l3gateway端口的数据包发送到不同chassis的方法相同。一旦包到达该chassis，表33将逻辑出口端口重置为表示分布式网关端口的值。对于每个分布式网关端口，除了代表分布式网关端口的分布式逻辑补丁端口外，还有一个类型chassisredirect端口

• (3) High Availability for Distributed Gateway Ports

 OVN允许您为分布式网关端口指定一个优先级的chassis列表。这是通过将多个gateway_底chassis与OVN_Northbound数据库中的Logical_Router_Port关联来实现的

 当多个底盘为网关指定时，所有可能发送数据包到该网关的chassis将启用BFD在隧道上到所有配置的网关chassi。网关的当前主chassis是最高优先级的chassis，根据BFD状态当前被视为活动的.

 有关L3网关高可用性的更多信息，请参考http://docs.openvswitch.org/en/latest/topics/high-availability。

2.8 Multiple localnet logical switches connected to a Logical Router

 可能会有多个有一个localnet端口的逻辑交换机连接到一个逻辑路由器。其中一个localnet逻辑交换机可以通过分布式网关端口提供外部连接，其余的localnet逻辑交换机在物理网络中使用VLAN标记。对于所有这些本地网络，ovn-bridge-mappings应该在chassis上进行适当的配置

2.8.1 East West routing

 这些标记为localnet VLAN的逻辑交换机之间的东西路由工作方式几乎与普通逻辑交换机相同。当虚拟机发送这样一个数据包时，那么:

• (1)它首先进入源localnet逻辑交换机数据路径的入口流水线和出口流水线。然后，它通过源chassis中的逻辑路由器端口进入逻辑路由器数据路径的入口流水线
• (2)进行路由决策
• v3)数据包从路由器数据路径进入目的localnet逻辑交换机datapath的出入口流水线。然后通过localnet端口从集成网桥进入提供商网桥(属于目的逻辑交换机)。
• (4)目标chassis通过localnet端口接收数据包并将其发送到集成桥接器。数据包进入目的localnet逻辑交换机的入口流水线，然后出口流水线，最后被发送到目的VM端口

2.8.2 External traffic

 当一个虚拟机发送一个外部流量(需要NATting)，而托管虚拟机的chassis没有一个分布式网关port时，会发生以下情况

• (1)该数据包首先会进入本地逻辑交换机datapath的出入流水线。然后通过源chassis的逻辑路由器端口进入逻辑路由器datapath的入口流水线。
• (2)进行路由决策。由于网关路由器或分布式网关端口不驻留在源chassis中，流量通过隧道端口被重定向到网关chassis
• (3)网关chassis通过隧道端口接收包，包进入逻辑路由器数据路径的出口流水线。这里应用了NAT规则。数据包然后进入提供外部连接的localnet逻辑交换机数据路径的入口流水线，然后出口流水线，最后通过提供外部连接的逻辑交换机的localnet端口出去
  

 尽管这可以工作，但当VM流量从计算chassis发送到网关chassi时，它是通过隧道传输的。为了使其正常工作，必须降低localnet逻辑交换机的MTU来考虑隧道封装.

 为连接到逻辑路由器的标记为localnet VLAN的逻辑交换机进行集中路由.

 为了克服前一节中描述的隧道封装问题，OVN支持为标记为localnet VLAN的逻辑交换机启用集中式路由。CMS可以为每个连接到标记为localnet VLAN的逻辑交换机的Logical_Router_Port配置选项选项:reside-on-redirect-chassis为true。这将导致网关chassis(托管分布式网关端口)为这些网络处理所有路由，使其集中。它会回复逻辑路由器端口IPs的ARP请求

 如果逻辑路由器没有一个分布式网关端口连接到提供外部连接的localnet逻辑交换机，那么OVN会忽略这个选项.

 一个虚拟机发送需要被路由的东西流量时，以下情况会发送：

• (1)数据包首先进入源localnet逻辑交换机数据路径的入口流水线，然后进入出口流水线，并通过源localnet逻辑交换机的localnet端口发送出去(而不是将其发送到路由器管道)
• (2)网关chassis通过源localnet逻辑交换机的localnet端口接收数据包，并将其发送到集成桥接。然后数据包进入源localnet逻辑交换机数据路径的入口流水线，然后进入出口流水线。然后逻辑路由器数据路径的入口。
• (3)路由决策
• (4)从路由器数据路径，数据包进入目的localnet逻辑交换机数据路径的入口流水线，然后出口流水线。然后，它通过localnet端口从集成桥接走到提供商桥接(属于目的逻辑交换机)
• (5)目标机箱通过localnet端口接收数据包并将其发送到集成桥接器。数据包进入目的localnet逻辑交换机的入口流水线，然后出口流水线，最后被交付到目的VM端口

 当VM发送需要NATting的外部流量时，会发生以下情况

• (1)数据包首先进入源localnet逻辑交换机数据路径的入口流水线，然后通过源localnet逻辑交换机的localnet端口被发送出去(而不是将其发送到路由器流水线)。
• (2)网关chassis通过源localnet逻辑交换机的localnet端口接收数据包，并将其发送到集成桥接。然后数据包进入源localnet逻辑交换机数据路径的出入流水线，然后进入逻辑路由器datapath的入流水线。
• (3)选择路由并应用NAT规则
• (4)数据包从路由器数据路径进入提供外部连接的localnet逻辑交换机datapath的出入流水线。然后，它通过localnet端口从集成桥接走到提供者桥接(属于提供外部连接的逻辑交换机)

 对于反向外部流量，会发生以下情况

• (1)网关chassis从提供外部连接的逻辑交换机的localnet端口接收数据包。数据包然后进入localnet逻辑交换机(提供外部连接)的入口和出口流水线。然后数据包进入逻辑路由器数据路径的入口流水线
• (2)逻辑路由器数据路径的入口流水线应用非natting规则。数据包然后进入源localnet逻辑交换机的入口流水线和出口流水线。由于源VM不驻留在网关chassis中，因此包通过源逻辑交换机的localnet端口发送出去
• (3)源chassis通过localnet端口接收数据包并将其发送到集成桥接器。包进入源localnet逻辑交换机的入口和出口流水线，最后被交付到源VM端口

2.9 Life Cycle of a VTEP gateway

 网关是一个chassis，它在逻辑网络的ovn管理部分和物理VLAN之间转发通信，将基于隧道的逻辑网络扩展为物理网络。下面的步骤通常引用OVN和VTEP数据库模式的详细信息。请分别查看ovn sb(5)、ovn nb(5)和vtep(5)，了解这些数据库的完整情况.

• (1)VTEP网关的生命周期从管理员将VTEP网关注册为VTEP数据库中的一个Physical_Switch表条目开始。连接到这个vtep数据库的ovn控制器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列在创建时没有填充.ovn-controller-vtep将会在vtep逻辑交换机绑定到一个OVN逻辑网络时，为该列设置合适的值。
• (3)现在，管理员可以使用CMS向OVN逻辑网络添加一个VTEP逻辑交换机。为此，CMS必须首先在OVN_Northbound数据库中创建一个新的Logical_Switch_Port表条目。然后，该条目的type列必须设置为“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控制器vtep将识别event并删除OVN_Southbound数据库中的所有相关配置(chassis表条目和端口绑定)
• (8)当ovn控制器vtep终止时，OVN_Southbound数据库和vtep数据库中的所有相关配置将被清除，包括所有注册的vtep网关及其端口绑定的chassis表项，以及所有Ucast_Macs_Remote表项和Logical_Switch隧道键

3 SECURITY

3.1 Role−Based Access Controls for the Soutbound DB

 为了提供额外的安全性来避免OVN chassis因为允许恶意软件对南向数据库状态进行任意修改被盗用进而破坏了OVN网络。为南向数据库提供了基于角色的访问控制(参见ovsdb−server(1)了解更多细节


 实现基于角色的访问控制(RBAC)需要向OVSDB模式添加两个表:RBAC_Role表(按角色名称建立索引，并将可针对给定角色修改的各种表的名称映射到包含该角色的详细权限信息的权限表中的各个行，以及由包含以下信息的行组成的权限表本身):

• (1)Table Name
  
   关联表的名称。此列主要用于帮助人们读取该表的内容
• (2)Auth Criteria
  
   一组包含列名称的字符串(或列:包含string:string映射的列的键对)。要修改、插入或删除的行中至少一个列:键值的内容必须等于试图对该行进行操作的客户机的ID，这样才能通过授权检查。如果授权标准为空，则禁用授权检查，该角色的所有客户端将被视为已授权
• (3)Insert/Delete
  
   行插入/删除权限;布尔值，指示是否允许对关联表插入和删除行。如果为真，则允许对授权客户端插入和删除行
• (4)Updatable Columns
  
   一组包含列或列名称的字符串:可由授权客户端更新或更改的键对。只有在客户端通过授权检查并且要修改的所有列都包含在这组可修改列中时，才允许对一行中的列进行修改
   OVN南行数据库的RBAC配置由OVN -northd维护。启用RBAC后，只允许对chassis、Encap、Port_Binding和MAC_Binding表进行修改，并按照以下方式进行重新限制:
• (1)Chassis
  • 1)Authorization:客户端ID必须与chassis名称匹配
  • 2)Insert/Delete:允许授权的行插入和删除
  • 3)Update:在获得授权后，可以修改nb_cfg、external_ids、encaps和vtep_logical_switches列
• (2)Encap
  • 1)Authorization:客户端ID必须与chassis名称匹配
  • 2)Insert/Delete:允许授权的行插入和删除
  • 3)Update:在获得授权后，可以修改tyep,options和IP列
• (3)Port_Binding
  • 1)Authorization:禁用(所有客户端都被视为已授权。未来的增强可能会添加列(或向external_ids添加键)，以控制允许哪个chassis绑定每个端口
  • 2)Insert/Delete:不允许插入/删除行(ovn-northd维护这个表中的行
  • 3)Update:只允许修改chassis
• (4)MAC_Binding
  • 1)Authorization:禁用(所有客户端都被认为是经过授权的)
  • 2)Insert/Delete:允许插入/删除行
  • 3)Update:ovn-controller可以修改logical_port、ip、mac和datapath列

 为ovn-controller与南向数据库的连接启用RBAC需要执行以下步骤

• (1)为每个chassis创建SSL证书，将证书CN字段设置为chassis名称(例如，对于具有外部id的chassis: system id=chassis-1，通过命令ovs-pki-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”)

3.2 Encrypt Tunnel Traffic with IPsec

 OVN隧道流量通过物理路由器和交换机。这些物理设备可能是不可信的(公共网络中的设备)，或者可能被破坏。启用对隧道交通的加密可以防止交通数据被监视和操纵

 

 隧道流量使用IPsec加密。CMS在向北的NB_Global表中设置ipsec列来启用或禁用ipsec加密。如果ipsec为真，所有的OVN隧道将被加密。如果ipsec为false，则没有OVN隧道将被加密

 当CMS更新向北的NB_Global表中的ipsec列时，ovn-northd将该值复制到向南的SB_Global表中的ipsec列。每个chassis中的ovn控制器监视向南的数据库，并相应地设置OVS隧道接口的选项。OVS隧道接口选项由OVS监视器ipsec守护进程监视，该守护进程配置IKE守护进程来设置ipsec连接

 chassis通过使用证书相互验证。如果隧道中的另一端提供了一个由受信任CA签名的证书，并且公共名称(CN)与预期的底盘名称匹配，则身份验证成功。在基于角色的访问控制(RBAC)中使用的SSL证书可以在IPsec中使用。或使用ovs pki创建不同的证书。证书要求是x.509版本3，并且CN字段和subjectAltName字段设置为底盘名称
 在启用IPsec之前，需要在每个chassis中安装CA证书、机箱证书和私钥。请参阅ovs vswitch .conf.db(5)来设置基于CA的IPsec认证

4 DESIGN DECISIONS

4.1 Tunnel Encapsulations

 OVN用以下三段元数据注释它从一个hypervisor发送到另一个hypervisor的逻辑网络包，这些元数据以特定于封装的方式进行编码

• (1)24位逻辑数据路径标识符。来自OVN南向Datapath_Binding表中的tunnel_key列
• (2)15位逻辑入口端口标识符。ID 0预留给OVN内部使用。IDs 1到32767(包括在内)可以分配给逻辑端口(请参阅OVN南行Port_Binding表中的tunnel_key列)。
• (3)16位逻辑出口端口标识符。IDs 0到32767与逻辑入口端口具有相同的含义。IDs 32768到65535(包括)可以分配给逻辑多播组(请参阅OVN南向多播组表中的tunnel_key列)。

 对于hypervisor到hypervisor的通信，OVN仅支持Geneve和STT封装，原因如下

(1)只有STT和Geneve支持OVN使用的大量元数据(每个包超过32位)(如上所述)

(2)STT和Geneve使用随机的UDP或TCP源端口，允许在使用ECMP的环境中有效地在多个路径之间分配

(3)网卡可用于卸载STT和Geneve封装和解密

 由于其灵活性，hypervisor之间首选的封装是Geneve。对于Geneve封装.具体封装实现见文档最后一页。