众所周知，OpenvSwitch 以其丰富的功能和不错的性能，已经成为 Openstack 部署中最受欢迎的虚拟交换机。由于 Openstack Neutron 的架构引入了一些性能问题，比如 neutron-server 要与非常多的 agent 通信，RPC 就是一个性能瓶颈，还有 neutron 里面用到非常多的 namespace，namespace 资源有限而且系统开销比较大，这也是一个性能瓶颈。OVS 社区觉得从长远来看，Neutron 应该让一个其它的项目来做虚拟网络的控制平面，Neutron 只需要提供 API 的处理，于是 OVS 社区推出了 OVN（Open Virtual Switch）这个项目，OVN 是 OVS 的控制平面，它给 OVS 增加了对虚拟网络的原生支持，大大提高了 OVS 在实际应用环境中的性能和规模。

OVN 的功能

虽然 OVN 是 OVS 社区在 2015 年 1 月份才宣布的一个子项目，但是到目前为止 OVN 已经支持了很多功能，

• Logical switches：逻辑交换机，用来做二层转发。
• L2/L3/L4 ACLs：二到四层的 ACL，可以根据报文的 MAC 地址，IP 地址，端口号来做访问控制。
• Logical routers：逻辑路由器，分布式的，用来做三层转发。
• Multiple tunnel overlays：支持多种隧道封装技术，有 Geneve，STT 和 VXLAN。
• TOR switch or software logical switch gateways：支持使用硬件 TOR switch 或者软件逻辑 switch 当作网关来连接物理网络和虚拟网络。

OVN 对于运行平台没有额外的要求，只要能够运行 OVS，就可以运行 OVN，所以 OVN 可以和 Linux，Docker，DPDK 还有 Hyper-V 兼容，从 OVS 升级到 OVN 是非常容易的。

另外 OVN 可以和很多 CMS（Cloud Management System）集成到一起，比如 Openstack neutron，这些 CMS 只需要添加一个 plugin 来配置 OVN 即可。

OVN 架构

图 1. OVN 架构图

图 1 是 OVN 架构概览，最上面 Openstack/CMS plugin 是 CMS 和 OVN 的接口，它把 CMS 的配置转化成 OVN 的格式写到 Nnorthbound DB 里面。

Northbound DB 里面存的都是一些逻辑的数据，大部分和物理网络没有关系，比如 logical switch，logical router，ACL，logical port，和传统网络设备概念一致。

OVN-northd 类似于一个集中的控制器，它把 Northbound DB 里面的数据翻译一下，写到 Southbound DB 里面。

Southbound DB 里面存的数据和 Northbound DB 语义完全不一样，主要包含 3 类数据，一是物理网络数据，比如 HV（hypervisor）的 IP 地址，HV 的 tunnel 封装格式；二是逻辑网络数据，比如报文如何在逻辑网络里面转发；三是物理网络和逻辑网络的绑定关系，比如逻辑端口关联到哪个 HV 上面。

ovn-controller 是 OVN 里面的 agent，类似于 neutron 里面的 ovs-agent，它也是运行在每个 HV 上面，北向，ovn-controller 会把物理网络的信息写到 Southbound DB 里面，南向，它会把 Southbound DB 里面存的一些数据转化成 Openflow flow 配到本地的 OVS table 里面，来实现报文的转发。

ovs-vswitchd 和 ovsdb-server 是 OVS 的两个进程。

OVN 对 Neutron 的改变

从 OVN 的架构可以看出，OVN 里面数据的读写都是通过 OVSDB 协议来做的，取代了 neutron 里面的消息队列机制，所以有了 OVN 之后，neutron 里面所有的 agent 都不需要了，neutron 变成了一个 API server 来处理用户的 REST 请求，其他的功能都交给 OVN 来做，只需要在 neutron 里面加一个 plugin 来调用配置 OVN。

Neutron 里面的子项目 networking-ovn 就是实现 OVN 的 plugin。Plugin 使用 OVSDB 协议来把用户的配置写在 Northbound DB 里面，ovn-northd 监听到 Northbound DB 配置发生改变，然后把配置翻译到 Southbound DB 里面，ovn-controller 注意到 Southbound DB 数据的变化，然后更新本地的流表。

OVN 里面报文的处理都是通过 OVS OpenFlow 流表来实现的，而在 Neutron 里面二层报文处理是通过 OVS OpenFlow 流表来实现，三层报文处理是通过 Linux TCP/IP 协议栈来实现。

OVN security group 对比 Neutron security group

图 2. Neutron security group

Neutron 里面的 security group 是作用在 VM 对应的 neutron port 上面，因为 OVS internal port 不能经过 Linux 协议栈，所以不能直接通过 iptables 来做 security group，加上 OVS 2.4.0 以前都不支持 conntrack（Linux kernel netfiler 的一个功能，可以记录连接状态，是有状态访问控制和 NAT 的必备条件），如果单独通过匹配报文字段来做，有些访问控制实现不了并且性能会受到影响，所以 neutron 给每个应用了 security group 的 port 创建一个 linux bridge，neutron tap port 连到 linux bridge，然后创建一对 veth pair，一端连接 linux bridge，另一端连接 OVS bridge（默认是 br-int），如图 2 所示。Security group 里面的 rule 通过 iptables 配到 netfilter 里面，作用在 neutron tap port 上面，创建 linux bridge 的目的就是为了利用 iptables 来做 security group。

图 3. OVN security group

如图 3 所示，OVN 的 security group 每创建一个 neutron port，只需要把 tap port 连到 OVS bridge（默认是 br-int），不用像现在 Neutron 那样创建那么多 network device，大大减少了跳数。更重要的是，OVN 的 security group 是用到了 OVS 的 conntrack 功能，可以直接根据连接状态进行匹配，而不是匹配报文的字段，提高了流表的查找效率，还可以做有状态的防火墙和 NAT。

OVS 的 conntrack 是用 Linux kernel 的 netfilter 来做的，他调用 netfiler userspace netlink API 把来报文送给 Linux kernel 的 netfiler connection tracker 模块进行处理，这个模块给每个连接维护一个连接状态表，记录这个连接的状态，OVS 获取连接状态，Openflow flow 可以 match 这些连接状态。

OVS 官方也提供了一些测试数据，使用 OVS 的 conntrack 做 security group 比用 Linux bridge+iptables 做 security group 对 CPU 消耗要少，尤其是在 rule 越多的时候性能提升越明显。

OVN L3 对比 Neutron L3

Neutron 的三层功能主要有路由，SNAT 和 Floating IP（也叫 DNAT），它是通过 Linux kernel 的 namespace 来实现的，每个路由器对应一个 namespace，利用 Linux TCP/IP 协议栈来做路由转发。

在支持 DVR（分布式虚拟路由器，在 Juno 版本增加的一个功能）之前，Neutron 的三层功能是在网络节点做的，所有东西向跨网段的流量都需要经过网络节点做路由，这使得网络节点成为瓶颈。有了 DVR 之后，路由变成了分布式，每个计算节点上面都可以做路由，东西向流量直接通过计算节点路由而不需要经过网络节点，Floating IP 也是在计算节点上面实现的，对于有 floating IP 的 VM 访问公网，直接走计算节点上面的路由器出去，对于没有 floating IP 的 VM 访问公网才会从网络节点的路由器 SNAT 出去。DVR 减轻了网络节点的负担，但是也引入了一些问题，DVR 需要每个计算节点占用 2 个公网 IP，并且 DVR 还不能和 FWaaS，VPNaaS 和 LBaaS 集成起来。

OVN 支持原生的三层功能，不需要借助 Linux TCP/IP stack，用 OpenFlow 流表来实现路由查找，ARP 查找，TTL 和 MAC 地址的更改。OVN 的路由也是分布式的，路由器在每个计算节点上都有实例，和 DVR 一样。有了 OVN 之后，不需要 neutron l3 agent 了。

不过目前 OVN 三层功能只能做东西向路由，Floating IP 的设计和 DVR 一样，方案还在 review 过程中，SNAT 的实现方法还没有确定。所以如果需要所有的三层功能，暂时还是要使用 neutron l3 agent。

OVN VTEP 网关

图 4. OVN VTEP 网关连接物理网络和逻辑网络

OVN 可以通过 VTEP 网关把物理网络和逻辑网络连接起来，VTEP 网关可以是 TOR（Top of Rack）switch，目前很多硬件厂商都支持，比如 Arista，Juniper，HP 等等；也可以是软件做的逻辑 switch，OVS 社区就做了一个简单的VTEP 模拟器。VTEP网关需要遵守 VTEP OVSDB schema，它里面定义了 VTEP 网关需要支持的数据表项和内容，VTEP 通过 OVSDB 协议与 OVN 通信，通信的流程 OVN 也有相关标准，VTEP 上需要一个 ovn-controller-vtep 来做 ovn-controller 所做的事情。VTEP 网关和 HV 之间常用 VXLAN 封装技术。

如图 4 所示，PH1 和 PH2 是连在物理网络里面的 2 个服务器，VM1 到 VM3 是 OVN 里面的 3 个虚拟机，通过 VTEP 网关把物理网络和逻辑网络连接起来，从逻辑上看，PH1，PH2，VM1-VM3 就像在一个物理网络里面，彼此之间可以互通。

虽然 VTEP OVSDB schema 里面定义了三层的表项，但是目前没有硬件厂商支持，VTEP 模拟器也不支持，所以 VTEP 网络只支持二层的功能，也就是说只能连接物理网络的 VLAN 到逻辑网络的 VXLAN，如果 VTEP 上不同 VLAN 之间要做路由，需要 OVN 里面的路由器来做。

OVN Chassis

Chassis 是 OVN 新增的概念，OVS 里面没有这个概念，Chassis 可以是 HV，也可以是 VTEP 网关。

Chassis 的信息保存在 Southbound DB 里面，由 ovn-controller/ovn-controller-vtep 来维护。以 ovn-controller 为例，当 ovn-controller 启动的时候，它去本地的数据库 Open_vSwitch 表里面读取external_ids:system_id，external_ids:ovn-remote，external_ids:ovn-encap-ip 和external_ids:ovn-encap-type的值，然后它把这些值写到 Southbound DB 里面的表 Chassis 和表 Encap 里面。external_ids:system_id表示 Chassis 名字。external_ids:ovn-remote表示 Sounthbound DB 的 IP 地址。external_ids:ovn-encap-ip表示 tunnel endpoint IP 地址，可以是 HV 的某个接口的 IP 地址。external_ids:ovn-encap-type表示 tunnel 封装类型，可以是 VXLAN/Geneve/STT。external_ids:ovn-encap-ip和external_ids:ovn-encap-type是一对，每个 tunnel IP 地址对应一个 tunnel 封装类型，如果 HV 有多个接口可以建立 tunnel，可以在 ovn-controller 启动之前，把每对值填在 table Open_vSwitch 里面。

安装 networking-ovn 后，您会发现 tunnel type 默认是 Geneve，而且 tunnel IP 是配置在 local.conf 里面的 HOST_IP，这是因为networking-ovn的 devstack 安装脚本里面配置好了，如果需要改这些值，修改 networking-ovn/devstack/plugin.sh 即可。

OVN tunnel

OVN 支持的 tunnel 类型有三种，分别是 Geneve，STT 和 VXLAN。HV 与 HV 之间的流量，只能用 Geneve 和 STT 两种，HV 和 VTEP 网关之间的流量除了用 Geneve 和 STT 外，还能用 VXLAN，这是为了兼容硬件 VTEP 网关，因为大部分硬件 VTEP 网关只支持 VXLAN。

虽然 VXLAN 是数据中心常用的 tunnel 技术，但是 VXLAN header 是固定的，只能传递一个 VNID（VXLAN network identifier），如果想在 tunnel 里面传递更多的信息，VXLAN 实现不了。所以 OVN 选择了 Geneve 和 STT，Geneve 的头部有个 option 字段，支持 TLV 格式，用户可以根据自己的需要进行扩展，而 STT 的头部可以传递 64-bit 的数据，比 VXLAN 的 24-bit 大很多。

OVN tunnel 封装时使用了三种数据，

• Logical datapath identifier（逻辑的数据通道标识符）：datapath 是 OVS 里面的概念，报文需要送到 datapath 进行处理，一个 datapath 对应一个 OVN 里面的逻辑交换机或者逻辑路由器，类似于 tunnel ID。这个标识符有 24-bit，由 ovn-northd 分配的，全局唯一，保存在 Southbound DB 里面的表 Datapath_Binding 的列 tunnel_key 里。
• Logical input port identifier（逻辑的入端口标识符）：进入 logical datapath 的端口标识符，15-bit 长，由 ovn-northd 分配的，在每个 datapath 里面唯一。它可用范围是 1-32767，0 预留给内部使用。保存在 Southbound DB 里面的表 Port_Binding 的列 tunnel_key 里。
• Logical output port identifier（逻辑的出端口标识符）：出 logical datapath 的端口标识符，16-bit 长，范围 0-32767 和 logical input port identifier 含义一样，范围 32768-65535 给组播组使用。对于每个 logical port，input port identifier 和 output port identifier 相同。

如果 tunnel 类型是 Geneve，Geneve header 里面的 VNI 字段填 logical datapath identifier，Option 字段填 logical input port identifier 和 logical output port identifier，TLV 的 class 为 0xffff，type 为 0，value 为 1-bit 0 + 15-bit logical input port identifier + 16-bit logical output port identifier。

如果 tunnel 类型是 STT，上面三个值填在 Context ID 字段，格式为 9-bit 0 + 15-bit logical input port identifier + 16-bit logical output port identifier + 24-bit logical datapath identifier。

OVS 的 tunnel 封装是由 Openflow 流表来做的，所以 ovn-controller 需要把这三个标识符写到本地 HV 的 Openflow flow table 里面，对于每个进入 br-int 的报文，都会有这三个属性，logical datapath identifier 和 logical input port identifier 在入口方向被赋值，分别存在 openflow metadata 字段和 Nicira 扩展寄存器 reg6 里面。报文经过 OVS 的 pipeline 处理后，如果需要从指定端口发出去，只需要把 Logical output port identifier 写在 Nicira 扩展寄存器 reg7 里面。

OVN tunnel 里面所携带的 logical input port identifier 和 logical output port identifier 可以提高流表的查找效率，OVS 流表可以通过这两个值来处理报文，不需要解析报文的字段。

从上一章节可以看到，OVN 里面的 tunnel 类型是由 HV 上面的 ovn-controller 来设置的，并不是由 CMS 指定的，并且 OVN 里面的 tunnel ID 又由 OVN 自己分配的，所以用 neutron 创建 network 时指定 tunnel 类型和 tunnel ID（比如 vnid）是无用的，OVN 不做处理。

OVN Northbound DB

Northbound DB 是 OVN 和 CMS 之间的接口，Northbound DB 里面的几乎所有的内容都是由 CMS 产生的，ovn-northd 监听这个数据库的内容变化，然后翻译，保存到 Southbound DB 里面。

Northbound DB 里面主要有如下几张表：

• Logical_Switch：每一行代表一个逻辑交换机，逻辑交换机有两种，一种是 overlay logical switches，对应于 neutron network，每创建一个 neutron network，networking-ovn 会在这张表里增加一行；另一种是 bridged logical switch，连接物理网络和逻辑网络，被 VTEP gateway 使用。Logical_Switch 里面保存了它包含的 logical port（指向 Logical_Port table）和应用在它上面的 ACL（指向 ACL table）。
• Logical_Port：每一行代表一个逻辑端口，每创建一个 neutron port，networking-ovn 会在这张表里增加一行，每行保存的信息有端口的类型，比如 patch port，localnet port，端口的 IP 和 MAC 地址，端口的状态 UP/Down。
• ACL：每一行代表一个应用到逻辑交换机上的 ACL 规则，如果逻辑交换机上面的所有端口都没有配置 security group，那么这个逻辑交换机上不应用 ACL。每条 ACL 规则包含匹配的内容，方向，还有动作。
• Logical_Router：每一行代表一个逻辑路由器，每创建一个 neutron router，networking-ovn 会在这张表里增加一行，每行保存了它包含的逻辑的路由器端口。
• Logical_Router_Port：每一行代表一个逻辑路由器端口，每创建一个 router interface，networking-ovn 会在这张表里加一行，它主要保存了路由器端口的 IP 和 MAC。

OVN Southbound DB

从图 1 可以看出 Southbound DB 处在 OVN 架构的中心，它是 OVN 中非常重要的一部分，它跟 OVN 的其他组件都有交互。

Southbound DB 里面有如下几张表：

• Chassis：每一行表示一个 HV 或者 VTEP 网关，由 ovn-controller/ovn-controller-vtep 填写，包含 chassis 的名字和 chassis 支持的封装的配置（指向表 Encap），如果 chassis 是 VTEP 网关，VTEP 网关上和 OVN 关联的逻辑交换机也保存在这张表里。
• Encap：保存着 tunnel 的类型和 tunnel endpoint IP 地址。
• Logical_Flow：每一行表示一个逻辑的流表，这张表是 ovn-northd 根据 Nourthbound DB 里面二三层拓扑信息和 ACL 信息转换而来的，ovn-controller 把这个表里面的流表转换成 OVS 流表，配到 HV 上的 OVS table。流表主要包含匹配的规则，匹配的方向，优先级，table ID 和执行的动作。
• Multicast_Group：每一行代表一个组播组，组播报文和广播报文的转发由这张表决定，它保存了组播组所属的 datapath，组播组包含的端口，还有代表 logical egress port 的 tunnel_key。
• Datapath_Binding：每一行代表一个 datapath 和物理网络的绑定关系，每个 logical switch 和 logical router 对应一行。它主要保存了 OVN 给 datapath 分配的代表 logical datapath identifier 的 tunnel_key。
• Port_Binding：这张表主要用来确定 logical port 处在哪个 chassis 上面。每一行包含的内容主要有 logical port 的 MAC 和 IP 地址，端口类型，端口属于哪个 datapath binding，代表 logical input/output port identifier 的 tunnel_key, 以及端口处在哪个 chassis。端口所处的 chassis 由 ovn-controller/ovn-controller 设置，其余的值由 ovn-northd 设置。

表 Chassis 和表 Encap 包含的是物理网络的数据，表 Logical_Flow 和表 Multicast_Group 包含的是逻辑网络的数据，表 Datapath_Binding 和表 Port_Binding 包含的是逻辑网络和物理网络绑定关系的数据。

小结

OVN 这种分布式的网络架构，提高了 OVS 在应用环境中的效率。它通过分布式数据库技术，提高了网络的扩展性和容错性；它增加了 tunnel 头部携带的信息，提高了流表的查找效率；它充分利用了 OVS 的功能来提高网络性能。总而言之，OVN 是一个非常值得研究和使用的开源项目。

相关主题

• OVN Architecture，详细介绍了 OVN 的架构。
• OVN Northbound DB schema，详细介绍了 OVN Northbound DB 里面的表。
• OVN Southbound DB schema，详细介绍了 OVN Southbound DB 里面的表。
• OVS github，OVN 的代码是在 OVS 代码下的一个子目录里面，里面有 OVN 的很多资料。
• OVS 文档，OVS 所有资料的一个索引。
• OVN 

https://www.ibm.com/developerworks/cn/cloud/library/1603-ovn-ovs-openvswitch/index.html?ca=drs-&utm_source=tuicool&utm_medium=referral

OVN 路由功能详解

https://www.ibm.com/developerworks/cn/cloud/library/1605-ovn-introduction/index.html