欢迎使用CSDN-markdown编辑器

如何看懂Open vSwitch的流表

虚拟化技术快速发展，云平台的使用离不开Open vSwitch,那么如何使用Open vSwitch? 遇到问题如

何查看Open vSwitch的流表呢，这里给大家介绍一下Open vSwitch的流表相关的知识。

什么是Open vSwitch

Open vSwitch (下面简称为 OVS) 是由 Nicira Networks 主导的，运行在虚拟化平台 (例如 KVM，

Xen) 上的虚拟交换机。在虚拟化平台上，OVS 可以为动态变化的端点提供 2 层交换功能，很好的

控制虚拟网络中的访问策略、网络隔离、流量监控等等。OVS 遵循 Apache 2.0 许可证, 能同时支持

多种标准的管理接口和协议。OVS也提供了对OpenFlow协议的支持，用户可以使用任何支持 OpenFlow

协议的控制器对OVS进行远程管理控制。在OVS中, 有几个非常重要的概念:

[root@host-192-168-2-129 ~]# ovs-vsctl show
26dd968c-6026-4b72-b079-e69c478afdd9
Bridge br-int
Port br-int
Interface br-int
type: internal
Port "veth5"
Interface "veth5"
Port "port1"
Interface "port1"
Port "bond1"
Interface "veth0"
Interface "veth1"

Bridge: 代表一个以太网交换机 (Switch)，可以创建一个或者多个Bridge设备。

Port: 端口与物理交换机的端口概念类似，每个Port都隶属于一个 Bridge。可以通过

ovs-vsctl list port xxx 查看, 存储二层信息(vlan, lacp, mac等)。

Interface: 连接到 Port 的网络接口设备。在通常情况下，Port 和 Interface 是一

对一的关系, 只有在配置 Port 为 bond 模式后，Port 和 Interface 是一对多的关系。

流表的类型

OVS中有两种流表，一种是在慢通道上的OpenFlow流表，这种流表是多级流表，有table0, table1,

table2… 分为多个table表，每个table有自己的功能，比如table0 表示协议报文处理逻辑，

table1表示acl相关，table3表示源mac过滤，table4表示目的mac过滤， table5表示ip层过滤等等

另一种是快通道流表，目前OVS使用的是linux的datapath，属于一级流表。

OpenFlow流表

交换机中有多个flow table，当交换机收到某个数据包过后，会交给flow tables进行处理,如图：

-
+----------------------------------------------------------------------+
|                                                                      |
|        +-----+        packet +-----+       +-----+         +-------+ |
Packet|ingress |     |  ingress port |     |       |     |         |Execute| |Packet
in  |   port |Table|      metadata |Table|       |Table|  packet | action| | Out
------+------->|  0  |-------------->|  1  |->...->|  n  |-------->|  set  |-+------>
| action |     |        action |     |       |     |  action |       | |
| set={} +-----+          set  +-----+       +-----+   set   +-------+ |
|                                                                      |
+----------------------------------------------------------------------+

说明：

多个flow tables是依次排列的，序号从0开始，每个flow table中含有多个flow entry。

当该数据包和某个flow table中的流表项的match匹配时，会执行该流表项中的指令。

每个流项中的指令（instruction）可能是：goto table（将该数据包交给指定的table id的

flow table处理 ）、apply actions（执行actions中的处理）、clear actions（清除action

set中所有的action）、write actions（将某个action 放到action set 中去）、write

meta_data/mask等。

如果匹配上的flow entry中的指令不是goto table，则flow tables 的流水线处理就会在该

flow table上停止，并执行该匹配项上的操作，然后将数据包转发。

交换机的flow table中通常默认都会有table miss这个流表项，table miss流表项的优先级最

低，为0且不匹配所有匹配项。table miss流表项的作用是：在某个流表中找不到和该数据包

匹配的流表项时，该数据包由table miss来处理，通常是转发给控制器、drop、或转交给后面

的flow table。

DataPath流表

OVS的datapath是基于linux内核的，它运行在内核态，通过给网卡驱动设置回调钩子，接管驱动收

发报文，通过OVS的datapath进行软件交换，完成vswitch的功能。

DVS的datapath是基于intel的DPDK开发包实现的，它运行在用户态，基于用户态intel的网卡驱动

收发报文，通过DVS的datapath进行软件交换，完成vswitch的功能。由于DVS运行在用户态，去除

了内核的中断以及信号的干扰，性能上较好。

-
+---------------------------------------+
|                                       |
|        +-----+              +-------+ |
Packet|ingress |     |              |Execute| |Packet
in|   port |Table|              | action| |Out
------+------->|     |------------->|    set|-+------>
| action |     |              |       | |
|    set +-----+              +-------+ |
|                                       |
+---------------------------------------+

如何看流表

OVS 基本工作流如下图所示，当报文从port上接收到后，首先在快通道datapath里面查流表，如果

查到流表，则直接根据流表转发出去，如果查不到，则通过miss upcall机制，把报文上送到慢通道

vswitchd上，在vswitchd上匹配openflow流表，根据key匹配多级流表，最终找到需要做的action动

作，形成最终的流表，下发到datapath中去，后面的报文就可以查找到快通道的流表直接走掉。

慢通道的时候，如果匹配openflow流表失败，那么会下一条drop流表到datapath中去。使用了SDN

控制器，那么有些协议报文(arp,lldp等)，会上送控制器，同时也会下发一条快通道流表表明某些

协议报文要上送SDN控制器。没有使用SDN控制器，那么会有一条NORMAL流表，匹配上这个NORMAL流

表的话，那么OVS的交换原则是遵循传统交换机的，OVS会学习mac-port表，会根据mac-port表进行

报文转发。

-
+-------------------------------------+
|        vswitchd (slow flows)        |
|        +-------------------+        |
|        |                   |        |
|        |    match flow     |        |
|        |   ---------->     |        |
|        +---|---------|-----+        |
|            ^         |synchornize   |
|            |miss     |              |
|            |upcall   v              |
Packet|        +---+---------------+        |Packet
in|        |                   |        |Out
------+------->|   ---------->     |--------+------>
|        |    match flow     |        |
|        +-------------------+        |
|        datapath (fast flows)        |
+-------------------------------------+

搞清楚了流表查找原理后，那么问题来了，怎样看懂这些流表呢？因为OVS分快通道和慢通道，所以

我们先看快通道的流表。

datapath 流表

可以通过ovs-dpctl dump-flows查看：

[root@host-192-168-2-129 ori_ovs]# ovs-dpctl dump-flows
recirc_id(0),in_port(11),eth(src=06:9e:e9:4b:6b:4e,dst=ce:9c:65:ae:10:4a),eth_type(0x0800),ipv4(frag=no), packets:22, bytes:2156, used:0.337s, actions:12
recirc_id(0),in_port(12),eth(src=ce:9c:65:ae:10:4a,dst=06:9e:e9:4b:6b:4e),eth_type(0x0800),ipv4(frag=no), packets:22, bytes:2156, used:0.337s, actions:11
[root@host-192-168-2-129 ori_ovs]#

可以看到快通道datapath有两条流表，我们来分析一下这两条流表

入向口是11的报文，以太网源目的mac是xxx的，type是0800，动作actions是12

入向口是12的报文，以太网源目的mac是xxx的，type是0800， 动作actions是11

很明显，11是端口号，12 也是端口号，到底是什么端口呢，我们通过ovs-dpctl show查看一下：

[root@host-192-168-2-129 ori_ovs]# ovs-dpctl show
system@ovs-system:
lookups: hit:17857085 missed:108586 lost:11
flows: 10
masks: hit:42308134 total:7 hit/pkt:2.35
port 0: ovs-system (internal)
port 6: veth1
port 9: veth0
port 11: br-int (internal)
port 12: veth5
port 15: port1

我们看到11是br-int端口，12是veth5端口，也就是说一个ipv4报文从br-int端口进来，要转发到

veth5这个端口上，那么veth5进来报文，要转发到br-int上，很简单，就是这样，我们的业务模型

是在br-int上配置了一个ip，然后ping另一个ip，而另一个ip正好是能通过veth5访问到。

openflow 流表

通常使用ovs-ofctl dump-flows br-int -OOpenFlow13命令查看流表，我们可以看到openflow流表

包含了一些关键字段:

table：表示是第几张表

priority：表示这条openflow流表的优先级，优先级越高，则优先匹配

in_port: 表示入向端口

tun_id：表示隧道id

actions：表示匹配上后要做的动作，CONTROLLER:65535 表示上送控制器

dl_dst: 目的mac

output:24 从24号端口发出去

…

这个和datapath流表内容都差不多，区别是openflow流表中分多个table，每个table做一个事情，

比如过滤源mac，又或者是路由的table等，当一张table匹配到后，会goto到下一张table去，再

进行过滤，直到找到最终的动作，执行。

所以，当有报文的时候，跟这openflow流表一条一条查看，就知道报文如何走的。这和我们做协议

栈类似，报文来了，需要查哪些表，然后根据表里面的内容做相应的动作。

[root@host-10-47-205-44 ~]# ovs-ofctl dump-flows br-int -OOpenFlow13
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x2, duration=281304.906s, table=0, n_packets=1169, n_bytes=303166, priority=0 actions=goto_table:1
cookie=0x1, duration=281304.906s, table=0, n_packets=561789, n_bytes=21347982, priority=251,dl_type=0x88cc actions=CONTROLLER:65535
cookie=0x2b, duration=281304.905s, table=0, n_packets=0, n_bytes=0, priority=241,dl_type=0x8940 actions=CONTROLLER:65535
cookie=0x27, duration=281304.905s, table=0, n_packets=652985, n_bytes=27425370, priority=241,arp actions=CONTROLLER:65535
cookie=0x29, duration=281304.905s, table=0, n_packets=107, n_bytes=37619, priority=244,udp,tp_src=68,tp_dst=67 actions=CONTROLLER:65535
cookie=0x3, duration=281304.906s, table=1, n_packets=0, n_bytes=0, priority=0 actions=CONTROLLER:65535
cookie=0xa0, duration=195555.056s, table=1, n_packets=0, n_bytes=0, priority=222,in_port=3 actions=goto_table:3
cookie=0x59, duration=281298.676s, table=1, n_packets=0, n_bytes=0, priority=221,in_port=18 actions=write_metadata:0x300000021,goto_table:4
cookie=0xa6, duration=195547.091s, table=1, n_packets=0, n_bytes=0, priority=222,in_port=4 actions=goto_table:3
cookie=0x5a, duration=281298.658s, table=1, n_packets=0, n_bytes=0, priority=221,in_port=23 actions=write_metadata:0x80000003d,goto_table:4
cookie=0x4, duration=281304.907s, table=2, n_packets=0, n_bytes=0, priority=0 actions=goto_table:5
cookie=0x12, duration=281304.906s, table=3, n_packets=0, n_bytes=0, priority=181,tun_id=0xe01 actions=write_metadata:0x300000e01,goto_table:5
cookie=0x15, duration=281304.906s, table=3, n_packets=0, n_bytes=0, priority=181,tun_id=0x1f actions=write_metadata:0x30000001f,goto_table:5
cookie=0x5, duration=281304.907s, table=3, n_packets=0, n_bytes=0, priority=0 actions=goto_table:5
cookie=0x6, duration=281304.907s, table=4, n_packets=1, n_bytes=243, priority=0 actions=CONTROLLER:65535
cookie=0x79, duration=261988.738s, table=4, n_packets=0, n_bytes=0, priority=161,dl_src=fa:11:00:e6:07:e3 actions=write_metadata:0x4000000d5,goto_table:5
cookie=0x68, duration=280856.745s, table=4, n_packets=862, n_bytes=198213, priority=161,dl_src=fa:11:00:51:2d:69 actions=write_metadata:0x20000003c,goto_table:5
cookie=0x7, duration=281304.907s, table=5, n_packets=153, n_bytes=50380, priority=0 actions=goto_table:7
cookie=0x4200000005, duration=281299.876s, table=5, n_packets=0, n_bytes=0, priority=100,ip,metadata=0x300000000/0xffffffff00000000,in_port=5 actions=goto_table:7
cookie=0x4100000005, duration=281299.927s, table=5, n_packets=0, n_bytes=0, priority=10,ip,metadata=0x300000000/0xffffffff00000000,in_port=5 actions=clear_actions
cookie=0x590000001e, duration=9453.576s, table=5, n_packets=0, n_bytes=0, priority=10,ip,metadata=0x300000000/0xffffffff00000000,in_port=30 actions=clear_actions
cookie=0x8, duration=281304.906s, table=7, n_packets=862, n_bytes=198213, priority=0 actions=CONTROLLER:65535
cookie=0x7d, duration=261988.738s, table=7, n_packets=0, n_bytes=0, priority=102,metadata=0xd5/0xffffff,dl_dst=fa:11:00:e6:07:e3 actions=write_actions(output:43),write_metadata:0x4000000d5/0xffffffff00ffffff,goto_table:10
cookie=0x77, duration=263806.682s, table=7, n_packets=0, n_bytes=0, priority=102,metadata=0x21/0xffffff,dl_dst=fa:11:00:7a:13:51 actions=write_actions(output:18),write_metadata:0x300000021/0xffffffff00ffffff,goto_table:10
cookie=0x5e, duration=281294.541s, table=7, n_packets=0, n_bytes=0, priority=102,metadata=0x44/0xffffff,dl_dst=fa:11:00:0d:e2:d7 actions=write_actions(output:44),write_metadata:0x200000044/0xffffffff00ffffff,goto_table:10
cookie=0x66, duration=281162.707s, table=7, n_packets=0, n_bytes=0, priority=102,metadata=0x3c/0xffffff,dl_dst=fa:11:00:54:1b:06 actions=write_actions(output:26),write_metadata:0x20000003c/0xffffffff00ffffff,goto_table:10
cookie=0x52, duration=281300.465s, table=7, n_packets=0, n_bytes=0, priority=102,metadata=0x3d/0xffffff,dl_dst=fa:01:01:01:01:3a actions=write_actions(output:23),write_metadata:0x80000003d/0xffffffff00ffffff,goto_table:10
cookie=0x6b, duration=280856.745s, table=7, n_packets=0, n_bytes=0, priority=102,metadata=0x3c/0xffffff,dl_dst=fa:11:00:51:2d:69 actions=write_actions(output:24),write_metadata:0x20000003c/0xffffffff00ffffff,goto_table:10

DVS的流表与OVS的类似，唯一不同的是查找的命令不同，DVS的datapath流表和端口号查找的命令

查看datapath端口号

iovs-dpctl -c 0x1 --proc-type=secondary -- -s show dpdk@br-int

查看datapath流表

iovs-dpctl -c 0x1 --proc-type=secondary -- -s dump-flows dpdk@br-int

查看openflow端口号

iovs-vsctl list interface |grep -1aw ofport

查看openflow流表

iovs-ofctl dump-flows br-int -OOpenFlow13