【博客445】ovs中的一些必备概念

ovs中的一些概念

Packet （数据包）

网络转发的最小数据单元，每个包都来自某个端口，最终会被发往一个或多个目标端口，转发数据包的过程就是网络的唯一功能。

Bridge （网桥）

Open vSwitch中的网桥对应物理交换机，其功能是根据一定流规则，把从端口收到的数据包转发到另一个或多个端口。

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

网桥的fail-mode设置：

standalone：该模式下，没有运行controller的情况下，OVS会自动调整为普通交换机模式，像物理交换机一样，此时可能会有环路产生的问题。如果有controller的情况，OVS会自动变成openflow交换机secure： 该模式下，无论有没有controller，OVS都会作为openflow交换机运行，也就是所有网桥上的端口，等待controller或者用户添加flow到OVS来进行通信。

Port （端口）

端口是收发数据包的单元。Open vSwitch中，每个端口都属于一个特定的网桥。端口收到的数据包会经过流规则的处理，发往其他端口；也会把其他端口来的数据包发送出去。
端口Port与物理交换机的端口概念类似，Port是OVS Bridge上创建的一个虚拟端口，每个Port都隶属于一个Bridge。

Internal类型会自动创建接口(Interface)，而Normal类型是把主机中已有的网卡接口添加到OVS中

Open vSwitch支持的端口有以下几种：

1、Normal Port: 用户可以把操作系统中的网卡绑定到Open vSwitch上，Open vSwitch会生成一个普通端口处理这块网卡进出的数据包。可以把操作系统中已有的网卡(物理网卡em1/eth0,或虚拟机的虚拟网卡tapxxx)挂载到ovs上，
ovs会生成一个同名Port处理这块网卡进出的数据包。此时端口类型为Normal。如下，主机中有一块物理网卡eth1，把其挂载到OVS网桥br-ext上，OVS会自动创建同名Port eth1。
ovs-vsctl add-port br-ext eth1 //Bridge br-ext中出现port “eth1”注意：挂载到OVS上的网卡设备不支持分配IP地址，因此若之前eth1配置有IP地址，
挂载到OVS之后IP地址将不可访问。这里的网卡设备不只包括物理网卡，也包括主机上创建的虚拟网卡。2、Internal Port: 当设置端口类型为internal，Open vSwitch会创建一快虚拟网卡，此端口
收到的所有数据包都会交给这块网卡，网卡发出的包会通过这个端口交给Open vSwitch。
当Open vSwitch创建一个新网桥时，默认会创建一个与网桥同名的Internal Port创建一个网桥br0，并创建一个internal类型的Port p0：
ovs-vsctl add-br br0
ovs-vsctl add-port br0 p0 -- set Interface p0 type=internal查看网桥br0：
ovs-vsctl show br0Bridge "br0"fail_mode:securePort "p0"Interface "p0"type:internalPort "br0"Interface "br0"type:internal结果分析：
可以看到有两个Port。当ovs创建一个新网桥时，默认会创建一个与网桥同名的Internal Port。
在OVS中，只有”internal”类型的设备才支持配置IP地址信息因此我们可以为br0接口配置一个IP地址，当然p0也可以配置IP地址：
ip addr add 192.168.10.11/24 dev br0
ip link set br0 up
//添加默认路由
ip route add default via 192.168.10.1 dev br03、Patch Port: 当机器中有多个Open vSwitch网桥时，可以使用Patch Port把两个网桥连起来。
Patch Port总是成对出现，分别连接在两个网桥上，在两个网桥之间交换数据。Patch Port是机房术语，特指用于切换网线连接的接线卡。
此卡上面网口成对出现，当需要把两台设备连接起来时，只需要把两台设备接入同一对网口即可。当主机中有多个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-ex可以使用ovs-vsctl创建patch设备：
如下创建两个网桥br0,br1，然后使用一对Patch Port连接它们
ovs-vsctl add-br br0
ovs-vsctl add-br br1
ovs-vsctl \
-- add-port br0 patch0 --set interface patch0 type=patch options:peer=patch1 \
-- add-port br1 patch1 --set interface patch1 type=patch options:peer=patch0结果如下：
ovs-vsctl showBridge "br0"Port "br0"Interface "br0"type:internalPort "patch0"Interface "patch0"type:patchoptions:{peer="patch1"}Bridge "br1"Port "br1"Interface "br1"type:internalPort "patch1"Interface "patch1"type:patchoptions:{peer="patch0"}4、Tunnel Port:
隧道端口是一种虚拟端口，支持使用gre或vxlan等隧道技术与位于网络上其他位置的远程端口通讯。OpenStack是多节点结构，同一子网的虚拟机可能被调度到不同计算节点上，
因此需要有隧道技术来保证这些同子网不同节点上的虚拟机能够二层互通，
就像他们连接在同一个交换机上，同时也要保证能与其它子网隔离。OVS在计算和网络节点上建立隧道Port来连接各节点上的网桥br-int，
这样所有网络和计算节点上的br-int互联形成了一个大的虚拟的跨所有节点的逻辑网桥
(内部靠tunnel id或VNI隔离不同子网)，这个逻辑网桥对虚拟机和qrouter是透明的，
它们觉得自己连接到了一个大的br-int上。从某个计算节点虚拟机发出的数据包会
被封装进隧道通过底层网络传输到目的主机然后解封装。使用两台主机测试创建vxlan隧道：
//主机192.168.7.21上
ovs-vsctl add-br br-vxlan
//主机192.168.7.23上
ovs-vsctl add-br br-vxlan
//主机192.168.7.21上添加连接到7.23的Tunnel Port
ovs-vsctl add-port br-vxlan tun0 --set Interface tun0 type=vxlan options:remote_ip=192.168.7.23
//主机192.168.7.23上添加连接到7.21的Tunnel Port
ovs-vsctl add-port br-vxlan tun0 --set Interface tun0 type=vxlan options:remote_ip=192.168.7.21然后，两个主机上桥接到br-vxlan的虚拟机就像连接到同一个交换机一样，
可以实现跨主机的L2连接，同时又完全与物理网络隔离

端口的VLAN_MODE几种模式

default：

在默认模式下（VLAN_mode没被设置），如果指定了端口的tag属性，那么这个端口就工作在access模式，并且其trunk属性的值应该保持为空。否则，这个port就工作在trunk模式下，如果trunk被指定，则使用指定的trunk值。

trunk：

trunk模式的端口允许传输所有在其trunk属性中指定的那些VLAN对应的数据包。其他VLAN的数据包就会被丢弃。从trunk模式的端口中进入的数据包其VLAN ID不会发生变化。如果进入的数据包不含有VLAN ID，则该数据包进入交换机后的VLAN为0。从trunk模式的端口出去的数据包，如果VLAN ID不为空，则依然保持该VLAN ID，如果VLAN ID为空，则出去后不再包含802.1Q头部

access：

access模式的端口只允许不带VLAN的数据包进入，不管数据包的VLAN ID是否与其tag相同，只要含有VLAN ID，这个数据包都会被端口drop。数据包进入access端口后会被打上和端口tag相同的VLAN，而再从access端口出去时，数据包的VLAN会被删除，也就是说从access的端口出去的数据包和进来时一样是不带VLAN的

native-tagged：

native-tagged端口类似于trunk端口，它们之间的区别是如果进入native-tagged端口的数据包不含有802.1Q头部，即没有指定VLAN，那么该数据包会被当作native VLAN，其VLAN ID由端口的tag指定。

native-untagged：

native-untagged端口类似于native-tagged端口，不同点是native VLAN中的数据包从native-untagged端口出去时，会被去掉802.1Q头部。

Interface （iface/接口）

接口是Open vSwitch与外部交换数据包的组件。一个接口就是操作系统的一块网卡，这块网卡可能是Open vSwitch生成的虚拟网卡，也可能是物理网卡挂载在Open vSwitch上，也可能是操作系统的虚拟网卡（TUN/TAP）挂载在Open vSwitch上。

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

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

当Open vSwitch创建一个新网桥时，默认会创建一个与网桥同名的Internal Port，同时也创建一个与Port同名的Interface。三位一体，所以操作系统里就多了一块网卡，但是状态是down的。

Flow （流）

流定义了端口之间数据包的交换规则。每条流分为匹配和动作两部分，匹配部分选择哪些数据包需要可以通过这条流处理，动作决定这些匹配到的数据包如何转发。流描述了一个网桥上，端口到端口的转发规则。比如我可以定义这样一条流：

当数据包来自端口A，则发往端口B匹配部分：来自端口A
动作部分：发往端口B 

流的定义可能非常复杂，比如：

当数据包来自端口A，并且其源MAC是aa:aa:aa:aa:aa:aa，并且其拥有vlan tag为a，
并且其源IP是a.a.a.a，并且其协议是TCP，其TCP源端口号为a，
则修改其源IP为b.b.b.b，发往端口B

OVS中的各种流(flows)：

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

OVS中有多种flows存在，用于不同目的：

OpenFlow flows

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

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连接能够正常建立。

hidden flows优先级高于OpenFlow flows，它们不需要手动设置。
可以使用ovs-appctl查看这些flows，比如：输出内容包括OpenFlow flows,hidden flows

ovs-appctl bridge/dump-flows br-name

datapath flows

datapath flows是datapath内核模块维护的flows，由内核模块维护意味着我们并不需要去修改管理它。与OpenFlow flows不同的是，它不支持优先级，并且只有一个表，这些特点使它非常适合做缓存。与OpenFlow一样的是它支持通配符，也支持指令集(多个action)
datapath flows可以来自用户空间ovs-vswitchd缓存，也可以是datapath内核模块进行MAC地址学习到的flows，这取决与OVS是作为SDN交换机，还是像Linux Bridge那样只是一个简单基于MAC地址学习的二层交换机

管理flows的命令行工具

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

面三种flows管理工具：

ovs-ofctl dump-flows br-name：

打印指定网桥内的所有OpenFlow flows，可以存在多个流表(flow tables)，按表顺序显示。不包括”hidden” flows。这是最常用的查看flows命令，当然这条命令对所有OpenFlow交换机都有效，不单单是OVS

ovs-appctl bridge/dump-flows br-name：

打印指定网桥内所有OpenFlow flows，包括”hidden” flows，in-band control模式下排错可以用到

ovs-dpctl dump-flows [dp]：

打印内核模块中datapath flows，[dp]可以省略，默认主机中只有一个datapath system@ovs-system，注意ovs-ofctl管理的是OpenFlow flows

Datapath

由于流可能非常复杂，对每个进来的数据包都去尝试匹配所有流，效率会非常低，所以有了datapath这个东西。Datapath是流的一个缓存，会把流的执行结果保存起来，当下次遇到匹配到同一条流的数据包，直接通过datapath处理。考虑到转发效率，datapath完全是在内核态实现的，并且默认的超时时间非常短，大概只有3秒左右。

datapath处理原理：

用户空间ovs-vswitchd和内核模块datapath决定了数据包的转发，首先，datapath内核模块收到进入数据包(物理网卡或虚拟网卡)，然后查找其缓存(datapath flows)，当有一个匹配的flow时它执行对应的操作，否则datapath会把该数据包送入用户空间由ovs-vswitchd负责在其OpenFlow flows中查询(图1中的First Packet)，ovs-vswitchd查询后把匹配的actions返回给datapath并设置一条datapath flows到datapath中，这样后续进入的同类型的数据包(图1中的Subsequent Packets)因为缓存匹配会被datapath直接处理，不用再次进入用户空间。

datapath专注于数据交换，它不需要知道OpenFlow的存在。与OpenFlow打交道的是ovs-vswitchd，ovs-vswitchd存储所有Flow规则供datapath查询或缓存.

虽然有ovs-dpctl管理工具的存在，但我们没必要去手动管理datapath，这是用户空间ovs-vswitchd的工作

Controller

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

整体实现

收到数据包后，会交给datapath内核模块处理，当匹配到对应的datapath会直接输出，如果没有匹配到，会交给用户态的ovs-vswitchd查询flow，用户态处理后，会把处理完的数据包输出到正确的端口，并且设置新的datapath规则，后续数据包可以通过新的datapath规则实现快速转发。