1. 软市首页
  2. 行业观察

OVN架构

• 行业观察

原文地址

OVN架构

1、简介

OVN，即，是一个支持虚拟 络抽象的系统。
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实现中心的位置

  • 一个或更多的（一般来说有很多）（hypervisor）：

    管理程序必须运行Open vSwitch,并实现OVN source tree里文件中所描述的接口。
    我们可以使用任何Open vSwitch支持的虚拟机监控程序平台。

  • 零个或更多的：

    关通过在隧道和物理以太 端口之间双向转发数据包，将基于隧道的逻辑 络扩展到物理 络中。
    这样一来，非虚拟机便可以参与逻辑 络。 关可以是物理主机、虚拟机或者基于ASIC且支持模式的硬件交换机。

    虚拟机管理程序(Hypervisor)和 关(gateway)一起被称为或。

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

下图展示了OVN的主要部分和相关的软件交互:

从图表的最上面开始，主要有：

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

  • OVN/CMS 插件（Plugin）：插件是用作OVN接口的CMS组件。在中，就是一个。
    插件的主要目的就是将CMS的逻辑 络配置概念（以CMS可识别的特定格式存储在CMS的配置数据库中），转换为OVN可以理解的中间格式。

    此组件必须是CMS特定的，因此，需要为每个与OVN集成的CMS开发一个新插件。上图中此组件下面的所有组件都是独立于CMS的。

  • OVN北向数据库（Northbound Database）：接收OVN/CMS插件传递的逻辑 络配置的中间表示。
    数据库模式与CMS中使用的概念，因此它直接支持逻辑交换机、路由器、ACL等概念。详见ovn nb。

    OVN北向数据库有两个客户端：它上面的还有它下面的

  • ovn-northd: 它上连OVN北向数据库，下连OVN南向数据库。
    它将从北向数据库中获得的传统 络概念中的逻辑 络配置，转换为它下面的南向数据库所能理解的（logical datapath flow）。

  • OVN南向数据库（Southbound Database）：这是本系统的中心。
    它的客户端(client)包括其上的ovn-northd，以及其下每个传输节点上的。

    OVN南向数据库包含三种数据：

    • 物理 络(Physical Network (PN))表：指明如何访问hypervisor和其他节点
    • 逻辑 络(Logical Network (LN))表：用来描述逻辑 络，
    • 绑定表：将逻辑 络组件的位置链接到物理 络

    OVN南向数据库的性能必须随着传输节点的变化而变化。这就需要在遇到瓶颈的时候在上进行一些工作。
    可能需要引入集群来提升可用性。

其余组件将被复制到每个虚拟机监控程序（hypervisor）上：

  • ovn-controller ：是每个hypervisor和软件 关上的agent。
    • 北向而言，它连接到南向数据库来获取OVN的配置及状态，并用hypervisor的状态填充绑定表中的PN表和Chassis列。
    • 南向而言，它作为OpenFlow controller连接到 ovs-vswitchd 来控制 络流量 ，
      并连接到本地来监控和控制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更新北向数据库中的配置时，作为同一事务的一部分，它将增加表中的列的值。
      （只有当CMS想知道配置何时实现时，这才是必要的。）

    • 2) 当ovn-northd基于北向数据库的给定快照（snapshot）更新南向数据库时，作为同一事务的一部分，
      它将从北向数据库的复制到南向数据库的表中。
      （这样一来，监视两个数据库的观察者就可以确定南向数据库何时赶上北向数据库。）

    • 3) 在ovn northd从southerbound数据库服务器收到其更改已提交的确认之后，
      它将表中的更新为被已被推到下面的版本。
      （这样一来，CMS或另一个观察者可以确定南向数据库何时被挂起（caught up），而不用与南向数据库连接）。

    • 4) 每个chassis上的ovn-controller控制器进程接收更新后的南向数据库和更新后的。
      该过程也会更新chassis的Open vSwitch实例上安装的物理流（physical flows）。
      当它从Open vSwitch收到物理流已更新的确认信息时，就会在南向数据库中更新自己的Chassis记录中的nb_cfg。

    • 5) ovn-northd 监视所有南向数据库中Chassis记录的nb_cfg列。
      它跟踪所有记录中的最小值，并将其复制到北向表的列中。
      （这样一来，CMS或另一个观察者就可以确定什么时候所有hypervisor都赶上了北向配置。）

3、Chassis 设置

OVN部署中的每个Chassis都必须配置一个专门用于ovn的Open vSwitch 桥，称为。
如果需要，系统启动脚本可以在启动OVN控制器之前创建此 桥。
当OVN控制器启动时此 桥不存在的话，就将使用下面建议的默认配置来自动创建它。

集成 桥上的端口包括：

  • 任何机箱上，OVN用来保持逻辑 络连接的隧道（tunnel）端口:

    OVN控制器将添加、更新和删除这些隧道端口。

  • 在hypervisor中，任何要连接到逻辑 络的VIF:
    hypervisor本身，或者vSwitch和hypervisor之间的集成（在integrationguide.rst中描述）会负责处理这个问题。

这不是OVN的一部分，也不是OVN的新内容；这些都是预存在的集成工作，早已经在支持OVS的 hypervisor上实现了。

  • 在 关上，用于逻辑 络连接的物理端口：
    系统启动脚本在启动ovn控制器之前将此端口添加到 桥。
    在更复杂的设置中，也可能是是另一个 桥的补丁端口（patch port），而不是物理端口。

其他端口不应连接到集成 桥上。
尤其是，附加到底层 络（underlay network）的物理端口（与附加到逻辑 络物理端口的 关端口相反）不能连接到集成 桥。
底层物理端口应该连接到单独的Open vSwitch 桥（事实上，它们根本不需要连接到任何 桥）。

集成 桥应该按照下面描述的方式配置。每个配置的效果都记录在中：

集成桥的惯用名称是，但可以使用另一个名称。

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）。
      本地端口一般来说只生成目标指向本地目的地的通信，通常是对其接收到请求的响应。
      其中一个用例便是：如何使用Localport端口为每个hyperviso上的VM提供元数据（metadata）服务。
      元数据代理进程连接到每个主机（host）上的此端口，同一个 络中的所有VM都将通过相同的IP/MAC地址来访问它，
      所有流量都不通过隧道发送。想了解更多可以查看链接

5、VIF的生命周期

单独呈现表（Table）和其模式的话会很难理解。这里有一个例子。

虚拟机监控程序（hypervisor）上的VIF是一个虚拟 络接口，他们要么连接到VM上要么连接到容器
上（容器直接在该hypervisor上运行）。这与在VM中运行的容器的接口不同:

本例中的步骤通常涉及到OVN和OVN Northbound database模式的详细信息。想了解这些数据库的完整信息，
请分别参阅和。

  • 1、当CMS管理员使用CMS用户界面或API创建新的VIF，并将其添加到交换机（由OVN作为逻辑交换机实现）时，VIF的生命周期开始。
    CMS更新自身配置，主要包括：将VIF唯一的持久标识符和以太 地址mac相关联。

  • 2、CMS插件通过向表添加一行来更新OVN北向数据库以囊括新的VIF信息。
    新行之中，名称是，mac是mac，交换机指向OVN逻辑交换机的Logical_Switch记录，其他列则被适当地初始化。

  • 3、ovn-northd收到OVN北向数据库的更新。相应的，它做出响应，在南向数据库的表的添加新行，以映射新的端口。比如：添加一个流来识别发往给新端口的MAC地址的数据包，并且更新传递广播和多播数据包的流以囊括新的端口。它还在“绑定”表中创建一条记录，并填充用于识别chassis的列之外的所有列。

  • 4、每个hypervisor上的都会接收上一步ovn-northd在Logical_Flow表所做的更新。
    但如果持有VIF的虚拟机关机，ovn-controller就无能为力了。
    例如，它不能发送数据包或从VIF接收数据包，因为VIF实际上并不存在了。

  • 5、最终，用户启动拥有该VIF的VM。在VM启动的hypervisor上，
    hypervisor与Open vSwitch（IntegrationGuide.rst中所描述的）之间的集成，是通过将VIF添加到OVN集成 桥上实现的，
    此外还需要在中存储，以指示该接口是新VIF的实例。

    这些代码在并不是OVN的新功能；在支持OVS的虚拟机管理程序上就已经预先集成了。

  • 6、在启动VM的hypervisor上，ovn-controller在新的接口中注意到。
    作为响应，在OVN南向数据库中，它将更新绑定表的chassis列中的相应行，这些行链接逻辑端口到hypervisor。
    之后，ovn-controller更新本地虚拟机hypervisor的OpenFlow表，以便正确处理进出VIF的数据包。

  • 7、一些CMS系统，包括OpenStack，只有在 络准备就绪的情况下才能完全启动虚拟机。
    为了支持这个功能，ovn-northd一旦发现Binding表中的chassis列的某行更新了，
    则通过更新OVN北向数据库的表中的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通过将写在数据库中的信息，转换成每个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不同的容器编制系统所创建。
    无论创建容器的实体是谁，它需要知道与虚拟机的 络接口关联的，容器接口的 络流量将通过该 络接口来流通。
    创建容器接口的实体也需要在该虚拟机内部选择一个未使用的VLAN。

  • 2、创建容器的实体（直接或间接通过CMS管理底层基础结构）通过向表添加一行来更新OVN南向数据库以囊括新的CIF。
    在新行中，是任何唯一的标识符，是CIF 络流量预计要经过的VM的vif-id，是标识该CIF 络流量的VLAN标记。

  • 3、ovn-northd收到OVN北向数据库的更新。反过来，它通过添加相应行到OVN南向数据库的表来反映新的端口，
    并通过在Binding表中创建一个新行(填充除了标识列以外的所有列)，来相应地更新OVN南向数据库的chassis。

  • 4、在每个hypervisor上，ovn-controller订阅绑定表中的更改。
    当由ovn-northd创建的新行中包含Binding表的parent_port列中的值时，
    拥有与中的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接收在上一步中表的更新。
    ovn-controller会更新本地的表以反映更新。

7、数据包的物理处理生命周期

本节介绍数据包如何通过OVN从一个虚拟机或容器传输到另一个。

这个描述着重于数据包的物理处理。有关数据包逻辑生命周期的描述，请参考ovn-sb中的Logical_Flow表。

为了清楚起见，本节提到了一些数据和元数据字段，总结如下：

7.1、涉及的数据和元数据字段

  • 隧道密钥。当OVN在Geneve或其他隧道中封装数据包时，会附加额外的数据，以使接收的OVN实例正确处理。
    取决于特定的封装形式，会采取不同的形式，但在每种情况下，我们都将其称为“隧道密钥”。
    请参阅文末的“隧道封装”以了解详细信息。

  • 逻辑数据路径字段。表示数据包正在被处理的逻辑数据路径的字段。
    OVN使用简单地（且容易混淆地）调用“元数据”来存储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中存储的区域信息，
    在Open vSwitch扩展寄存器12中存储的区域信息。

  • 逻辑流标志。逻辑标志旨在处理保持流表之间的上下文以便确定后续表中的哪些规则匹配。
    该值只在本地有意义，跨chassis之间是没有意义的。OVN将逻辑标志存储在Open vSwitch扩展寄存器10中。

  • VLAN ID。VLAN ID用作OVN和嵌套在VM内的容器之间的接口（有关更多信息，请参阅上面VM内容器接口的生命周期）。

7.2、详细的生命周期

首先，hypervisor上的VM或容器通过连接到OVN集成 桥的端口上,来发送数据包。详细的生命周期如下：

  • 1、OpenFlow流表0执行物理到逻辑的转换。它匹配数据包的入口（ingress）端口。
    其通过设置 字段以标识数据包正在穿越的逻辑数据路径，并设置字段来标识入口端口，
    从而实现用逻辑元数据标注数据包。然后重新提交到表8进入逻辑入口管道。

源自嵌套在虚拟机内的容器的数据包有稍微不同的方式处理。
可以根据VIF特定的来区分始发容器，因此物理到逻辑的转换流程将在字段上需要匹配，
且在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使用逻辑流的的前32位作为OpenFlow流的cookie。
    （这不一定是唯一的，因为逻辑流的UUID的前32位不一定是唯一的。）

    一些逻辑流程可以映射到Open vSwitch扩展（参见ovs-field部分文档）。
    流连接操作使用的为0，因为它们可以对应多个逻辑流。
    关于OpenFlow流的连接匹配包含上的匹配。

    如果某个逻辑流无法在该hypervisor上使用，则某些逻辑流可能无法在给定的hypervisor中的OpenFlow流表中表示。
    例如，如果逻辑交换机中没有VIF驻留在给定的hypervisor上，并且该hypervisor上的其他逻辑交换机不可访问
    （例如，从hypervisor上的VIF开始的逻辑交换机和路由器的一系列跳跃），那么逻辑流就可能不可以在那里表示。

    大多数OVN操作在OpenFlow中具有相当明显的实现（具有OVS扩展），
    例如，实现为; 至于，下面有一些更详细地描述：

    • 通过将数据包重新提交给表32来实现。如果pipeline执行多于一个的输出动作，则将每个动作单独地重新提交给表32。
      这可以用于将数据包的多个副本发送到多个端口。
      （如果数据包在输出操作之间未被修改，并且某些拷贝被指定给相同的hypervisor，
      那么使用逻辑多播输出端口将节省hypervisor之间的带宽。）

    • 通过将参数存储在OpenFlow字段中来实现，然后重新提交到表66，
      ovn-controller使用OVN南向数据库中的表生成的此66流表。
      如果表66中存在匹配项，则其会将绑定的MAC存储在以太 目的地地址字段中。

    OpenFlow操作保存并恢复用于上述参数的OpenFlow字段，OVN操作不必知道这个临时用途。

    • 通过将参数存储在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还包括：

    • 根据标志匹配从VXLAN隧道接收到的数据包的高优先级的规则，然后将这些数据包重新提交给表33进行本地传递。
      从VXLAN隧道收到的数据包由于缺少隧道密钥中的逻辑输出端口字段而到达此处，因此需要将这些数据包提交到表8以确定输出端口。

    • 根据逻辑输入端口匹配从localport类型的端口接收到的数据包并将这些数据包重新提交到表33以进行本地传送的较高优先级规则。
      每个 hypervisor都存在localport类型的端口，根据定义，它们的流量不应该通过隧道出去。

    • 如果没有其他匹配，则重新提交到流表33的备用流。

    对于驻留在本地而不是远程的逻辑端口，表33中的流表类似于表32中的流表。对于本地hypervisor中的单播逻辑输出端口，操作只是重新提交给表34。
    对于在本地hypervisor中包括一个或多个逻辑端口的多播输出端口，对于每个这样的逻辑端口，操作将逻辑输出端口改变为 ，然后重新提交到表34。

    一个特殊情况是，当数据路径上存在localnet端口时，会通过切换到localnet端口来连接远程端口。
    在这种情况下，不是在表32中增加一个到达远程端口的流，而是在表33中增加一个流以将逻辑输出端口切换到localnet端口，
    并重新提交到表33，好像它被单播到本地hypervisor的逻辑端口上一样。

    表34匹配并丢弃逻辑输入和输出端口相同并且标志未被设置的数据包。它重新提交其他数据包到表40。

  • 4、OpenFlow表40至63执行OVN Southbound数据库中的Logical_Flow表的逻辑出口流程。
    出口管道可以在分组交付之前执行验证的最后阶段。
    最终，它可以执行一个输出动作，ovn-controller通过重新提交到

    声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！

上一篇 2019年8月21日
下一篇 2019年8月21日

相关推荐

首页
软件超市
企服市场
会员中心