标签：OVS OpenFlow 网络 flows 4.8 重识云 3.1 Port 第四章

1 Open vSwitch诞生背景

1.1 虚拟化催生vSwitch技术

在过去十几年中，虚拟化已经改变了应用、数据、服务的实现部署方式。服务器的虚拟化给数据中心网络带来了根本性的变化。在传统的数据中心网络架构基础上，出现了一个新的、位于物理服务器内的接入层。这个新的接入层包含的设备是运行在x86服务器中的vSwitch，而这些vSwitch连接着一个服务器内的多个workload（包括容器和虚机）。

vSwitch的早期代表是Linuxbridge，它在设计之初就是为了提供基本的网络连接，因此它只是模拟了ToR交换机的行为，并将自己接入到现有的物理网络中。这样实现的优点是，现有物理网络的理论和协议可以直接套用，不需要重复设计。缺点就是，作为物理网络的延伸，使得虚拟workload的网络与物理网络紧耦合，影响了虚拟化本身带来的诸如灵活，快速上线的优势。

随着网络虚拟化（network virtualization）技术的出现，为连接虚拟workload的网络提供了另一种可能。物理网络仍然由物理网络设备管理，虚拟workload的网络，单独由vSwitch管理，并且在现有物理网络（underlay）基础之上，再定义一个独立的overlay网络（例如VxLAN）。这个overlay网络不受物理网络设备控制，完全由vSwitch控制。

OpenvSwitch就是基于这个设计思想实现的。OpenVSwitch是一个多层的、开源虚拟交换机。不过到目前为止，LinuxBridge也支持了VxLAN，OpenVSwitch也能够支持对应于物理网络的VLAN、FLAT网络。

1.2 OpenFlow技术的驱动

除了基于overlay网络的思想设计以外，OpenVSwitch的另一大特点就是基于OpenFlow。

传统的交换机，不论是硬件的，还是软件的，所具备的功能都是预先内置的，需要使用某个功能的时候，需要提前进行相应的配置。而Open vSwitch通过OpenFlow实现了交换机的可编程性。OpenFlow可以定义网络包在交换机中的处理流程（pipeline），因此支持OpenFlow的交换机，其功能不再是固定的，通过OpenFlow可以软件定义OpenVSwitch所具备的功能。

OpenFlow以多个Table串行工作的方式来处理网络数据包，如下图所示。

OpenFlow的灵活性是实现SDN必不可少的一部分，但是在一些实际场景中，因为涉及的功能多且复杂，相应的OpenFlow pipeline会变得很长。直观上来看，pipeline越长，处理一个网络包需要的时间也越长。这是OpenFlow从理论到实际的一个问题，Open vSwitch为此尝试过很多优化。

对于一个Linux系统来说，可以分为用户空间（user space）和内核空间（kernel space），网络设备接入到内核空间。如果需要将数据传输到用户程序则需要通过内核空间将数据上送到用户空间，如果需要在网络设备之间转发数据，直接在内核空间就可以完成。

作为运行在x86服务器中的软件交换机，直观上来看，应该在内核空间来实现转发。因此，Open vSwitch在最早期的时候，是在Linux内核模块实现了所有的OpenFlow的处理。当时的OpenvSwitch内核模块处理流程是接收网络数据包，根据OpenFlow规则一步步的Match，并根据Action修改网络数据包，最后从某个网络设备送出。

但是这种方式很快就被认为是不能实际应用的。首先，虽然在内核实现可以缩短网络数据包在操作系统的路径，但是在内核进行程序开发和更新也更加困难，以OpenvSwitch的更新速度，完全在内核实现将变得不切实际。其次，完全按照OpenFlow pipeline去处理网络包，势必要消耗大量CPU，进而降低网络性能。

因此，最新版本（2.x版本）的OpenVSwitch采用了一种很不一样的方式来避免这些问题。

1.3 Open vSwitch（OVS）简介

Open vSwitch（下文简称 OvS）就是一个开源的虚拟交换机实现。广泛应用在云计算行业，为网络管理员提供虚拟云主机之间和之内的流量可见性与可控性。Open vSwitch 旨在用虚拟化方案解决网络问题，与控制器软件一起实现分布式的虚拟交换技术。这意味着，交换机和控制器软件能够在多个服务器之间创建集群网络配置，从而不需要在每一台云主机和物理主机上单独配置网络。这个交换机还支持 VLAN 中继，通过 NetFlow、sFlow 和 RSPAN 实现可见性，通过 OpenFlow 协议进行管理。它还有其他一些特性：严格流量控制，它由 OpenFlow 交换协议实现；远程管理功能，它能通过网络策略实现更多控制；支持多种虚拟化平台（Xen,KVM, Proxmox VE and VirtualBox）和交换机芯片。支持多种虚拟化管理平台（ OpenStack,openQRM, OpenNebula and oVirt）。

在虚拟交换机的 Flow 控制器或管理工具方面，OvS 需要借助第三方控制器或管理工具实现复杂的转发策略。例如 OvS 支持 OpenFlow 协议，我们就可以使用任何支持 OpenFlow 协议的控制器来对 OvS 进行远程管理。但这并不意味着 OvS 必须要有一个控制器才能工作。在不连接外部控制器情况下，OvS 自身可以依靠 MAC 地址学习实现二层数据包转发功能，就像 Linux Bridge。

Open vSwitch 的特性清单：

支持通过 NetFlow、sFlow、IPFIX、SPAN、RSPAN 和 GRE-tunneled 镜像使虚拟机内部通讯可以被监控；
支持 LACP（IEEE 802.1AX-2008，多端口绑定）协议；
支持标准的 802.1Q VLAN 模型以及 Trunk 模式；
支持 BFD 和 802.1ag 链路状态监测；
支持 STP（IEEE 802.1D-1998）；
支持细粒度的 Qos；
支持 HFSC 系统级别的流量控制队列；
支持每虚拟机网卡的流量的流量控制策略；
支持基于源 MAC 负载均衡模式、主备模式、L4 哈希模式的多端口绑定；
支持 OpenFlow 协议（包括许多虚拟化的增强特性）；
支持IPV6
支持多种隧道协议（GRE, VXLAN, IPsec, GRE and VXLAN over IPsec）
支持通过 C 或者 Python 接口远程配置；
支持内核态和用户态的转发引擎设置；
支持多列表转发的发送缓存引擎；
支持转发层抽象以容易的定向到新的软件或者硬件平台；

1.4 OVS概念

以使用OpenStack neutron+vxlan部署模式下网络节点OVS网桥作为例子

1.4.1 Bridge

Bridge代表一个以太网交换机(Switch)，一个主机中可以创建一个或者多个Bridge。Bridge的功能是根据一定规则，把从端口收到的数据包转发到另一个或多个端口，上面例子中有三个Bridge，br-tun，br-int，br-ext

添加一个网桥br0

1.4.2 Port

端口Port与物理交换机的端口概念类似，Port是OVS Bridge上创建的一个虚拟端口，每个Port都隶属于一个Bridge。Port有以下几种类型：

Normal

可以把操作系统中已有的网卡(物理网卡em1/eth0,或虚拟机的虚拟网卡tapxxx)挂载到ovs上，ovs会生成一个同名Port处理这块网卡进出的数据包。此时端口类型为Normal。

如下，主机中有一块物理网卡eth1，把其挂载到OVS网桥br-ext上，OVS会自动创建同名Port eth1。

有一点要注意的是，挂载到OVS上的网卡设备不支持分配IP地址，因此若之前eth1配置有IP地址，挂载到OVS之后IP地址将不可访问。这里的网卡设备不只包括物理网卡，也包括主机上创建的虚拟网卡。

Internal

Internal类型是OVS内部创建的虚拟网卡接口，每创建一个Port，OVS会自动创建一个同名接口(Interface)挂载到新创建的Port上。接口的概念下面会提到。

下面创建一个网桥br0，并创建一个Internal类型的Port p0。

可以看到有两个Port。当ovs创建一个新网桥时，默认会创建一个与网桥同名的Internal Port。在OVS中，只有”internal”类型的设备才支持配置IP地址信息，因此我们可以为br0接口配置一个IP地址，当然p0也可以配置IP地址。

上面两种Port类型区别在于，Internal类型会自动创建接口(Interface)，而Normal类型是把主机中已有的网卡接口添加到OVS中。

Patch

当主机中有多个ovs网桥时，可以使用Patch Port把两个网桥连起来。Patch Port总是成对出现，分别连接在两个网桥上，从一个Patch Port收到的数据包会被转发到另一个Patch Port，类似于Linux系统中的veth。使用Patch连接的两个网桥跟一个网桥没什么区别，OpenStack Neutron中使用到了Patch Port。上面网桥br-ext中的Port phy-br-ext与br-int中的Port int-br-ext是一对Patch Port。

可以使用ovs-vsctl创建patch设备，如下创建两个网桥br0,br1，然后使用一对Patch Port连接它们。

连接两个网桥不止上面一种方法，linux中支持创建Veth设备对，我们可以首先创建一对Veth设备对，然后把这两个Veth分别添加到两个网桥上，其效果跟OVS中创建Patch Port一样，只是性能会有差别。

Tunnel

OVS中支持添加隧道(Tunnel)端口，常见隧道技术有两种gre或vxlan。隧道技术是在现有的物理网络之上构建一层虚拟网络，上层应用只与虚拟网络相关，以此实现的虚拟网络比物理网络配置更加灵活，并能够实现跨主机的L2通信以及必要的租户隔离。不同隧道技术其大体思路均是将以太网报文使用隧道协议封装，然后使用底层IP网络转发封装后的数据包，其差异性在于选择和构造隧道的协议不同。Tunnel在OpenStack中用作实现大二层网络以及租户隔离，以应对公有云大规模，多租户的复杂网络环境。

OpenStack是多节点结构，同一子网的虚拟机可能被调度到不同计算节点上，因此需要有隧道技术来保证这些同子网不同节点上的虚拟机能够二层互通，就像他们连接在同一个交换机上，同时也要保证能与其它子网隔离。

OVS在计算和网络节点上建立隧道Port来连接各节点上的网桥br-int，这样所有网络和计算节点上的br-int互联形成了一个大的虚拟的跨所有节点的逻辑网桥(内部靠tunnel id或VNI隔离不同子网)，这个逻辑网桥对虚拟机和qrouter是透明的，它们觉得自己连接到了一个大的br-int上。从某个计算节点虚拟机发出的数据包会被封装进隧道通过底层网络传输到目的主机然后解封装。

上面网桥br-tun中Port "vxlan-080058ca"就是一个vxlan类型tunnel端口。下面使用两台主机测试创建vxlan隧道。

然后，两个主机上桥接到br-vxlan的虚拟机就像连接到同一个交换机一样，可以实现跨主机的L2连接，同时又完全与物理网络隔离。

1.4.3 Interface

Interface是连接到Port的网络接口设备，是OVS与外部交换数据包的组件，在通常情况下，Port和Interface是一对一的关系，只有在配置Port为 bond模式后，Port和Interface是一对多的关系。这个网络接口设备可能是创建Internal类型Port时OVS自动生成的虚拟网卡，也可能是系统的物理网卡或虚拟网卡(TUN/TAP)挂载在ovs上。 OVS中只有”Internal”类型的网卡接口才支持配置IP地址。

Interface是一块网络接口设备，负责接收或发送数据包，Port是OVS网桥上建立的一个虚拟端口，Interface挂载在Port上。

1.4.4 Controller

OpenFlow控制器。OVS可以同时接受一个或者多个OpenFlow控制器的管理。主要作用是下发流表(Flow Tables)到OVS，控制OVS数据包转发规则。控制器与OVS通过网络连接，不一定要在同一主机上。

可以看到上面实例中三个网桥br-int,br-ext,br-tun都连接到控制器Controller "tcp:127.0.0.1:6633上。

1.4.5 datapath

OVS内核模块，负责执行数据交换。其内部有作为缓存使用的flows，上面已经介绍过。

1.5 OVS中的各种流(flows)

flows是OVS进行数据转发策略控制的核心数据结构，区别于Linux Bridge是个单纯基于MAC地址学习的二层交换机，flows的存在使OVS作为一款SDN交换机成为云平台网络虚拟机化主要组件

OVS中有多种flows存在，用于不同目的，但最主要的还是OpenFlow flows这种，文中未明确说明的flows都是指OpenFlow flows

1.5.1 OpenFlow flows

OVS中最重要的一种flows，Controller控制器下发的就是这种flows。

1.5.2 “hidden” flows

OVS在使用OpenFlow flow时，需要与OpenFlow控制器建立TCP连接，若此TCP连接不依赖OVS，即没有OVS依然可以建立连接，此时就是out-of-band control模式，这种模式下不需要”hidden” flows。

但是在in-band control模式下，TCP连接的建立依赖OVS控制的网络，但此时OVS依赖OpenFLow控制器下发的flows才能正常工作，没法建立TCP连接也就无法下发flows，这就产生矛盾了，因此需要存在一些”hidden” flows，这些”hidden” flows保证了TCP连接能够正常建立。关于in-band control详细介绍，参考OVS官方文档Design Decisions In Open vSwitch 中In-Band Control部分。

“hidden” flows优先级高于OpenFlow flows，它们不需要手动设置。可以使用ovs-appctl查看这些flows，下面命令输出内容包括OpenFlow flows,"hidden" flows。

1.5.3 datapath flows

datapath flows是datapath内核模块维护的flows，由内核模块维护意味着我们并不需要去修改管理它。与OpenFlow flows不同的是，它不支持优先级，并且只有一个表，这些特点使它非常适合做缓存。与OpenFlow一样的是它支持通配符，也支持指令集(多个action)

datapath flows可以来自用户空间ovs-vswitchd缓存，也可以是datapath内核模块进行MAC地址学习到的flows，这取决与OVS是作为SDN交换机，还是像Linux Bridge那样只是一个简单基于MAC地址学习的二层交换机

1.6 管理flows的命令行工具

我们可以修改和配置的是OpenFlow flows。datapath flow和”hidden” flows由OVS自身管理，我们不必去修改它。当然，调试场景下还是可以使用工具修改的。

介绍下上面三种flows管理工具，不具体说明，具体使用可以查看相关man手册。

ovs-ofctl dump-flows
打印指定网桥内的所有OpenFlow flows，可以存在多个流表(flow tables)，按表顺序显示。不包括”hidden” flows。这是最常用的查看flows命令，当然这条命令对所有OpenFlow交换机都有效，不单单是OVS；
ovs-appctl bridge/dump-flows
打印指定网桥内所有OpenFlow flows，包括”hidden” flows，in-band control模式下排错可以用到；
ovs-dpctl dump-flows [dp] 打印内核模块中datapath flows，[dp]可以省略，默认主机中只有一个datapath system@ovs-systemman手册可以找到非常详细的用法说明，注意ovs-ofctl管理的是OpenFlow flows；