OVS流表分析方法总结（超实用）

1、基本流表介绍

在实际应用中，其中查看最多的是0、17、51、220。

2、使用odl_l2和原生l3的流表走势图

odl_l2和原生l3的流表走势图

3、具体流表阅读方法

流表的阅读可以分为两个部分：匹配和动作。匹配是指在一堆流表中找到包所走的那条流表，动作是指这个包接下来的操作。

匹配涉及到的字段：priority、in_port、metadata、dl_dst、reg6等

动作涉及到的字段：write_metadata、goto_table、drop、output、load等

上述字段中metadata和write_metadata是最重要的匹配字段，在匹配操作中进行精确匹配，在动作操作中进行写更新。metadata具体形式为字节码/掩码的形式，在操作过程中，掩码位为1的字节段决定匹配段和写入段。

例如metadata=0x170000000000/0xffffff0000000001，掩码与后，得到前面的0x17和末尾的0。前面的0x17是指与网络相关的基本信息，这部分可以很长，通过掩码截取后，主要可以分为网络段（reg7记录）、端口段（reg1/reg6记录），这样划分可以在某些table中便于查看，例如table51以网络段匹配为主，table220以端口段匹配为主等。末尾的0是指，在table0中，包从该端口出，如果是1，就指包从该端口进。（0出1进）

下面就具体的流表进行分析。

cookie=0x8000000, duration=3853.011s, table=0, n_packets=142, n_bytes=13430, priority=10,in_port="br-vlan-patch",dl_vlan=723 actions=pop_vlan,write_metadata:0x4d0000000001/0xffffff0000000001,goto_table:17

关注标红的部分。匹配部分主要有四个字段：table、priority、in_port、dl_vlan。具体内容是，该流表位于起始流表table0，优先级为10，属于vlan的patch口（注意in_port的值有时候是数字，需要查看show-port脚本对应的端口名称），对应的vlan id为723。也就是说，只有属于723的vlan网络的中的报文才会从该host的vlan patch口进入。动作部分主要有三个字段：pop_vlan、write_metadata、goto_table。具体内容是，弹出vlan id，然后按照规则写metadata，最后跳转到table17。

cookie=0x8040000, duration=5547.489s, table=17, n_packets=7, n_bytes=1284, priority=10,metadata=0xb000550000000000/0xffffff0000000000 actions=load:0x55->NXM_NX_REG10..19,load:0x1395->NXM_NX_REG70..15,write_metadata:0xc000551395000000/0xfffffffffffffffe,goto_table:43

关注标红的部分。匹配部分主要有table、priority、metadata。具体内容是，该流表位于table17，匹配0xb00055。动作部分主要有：load、write_metadata、goto_table。具体内容是端口段写入reg1，网络段写入reg7，然后写metadata，最后跳转到table43。

cookie=0x8031393, duration=5594.128s, table=51, n_packets=51, n_bytes=6276, priority=20,metadata=0x1393000000/0xffff000000,dl_dst=fa:16:3e:43:bd:5e actions=load:0x4d00->NXM_NX_REG6[],resubmit(,220)

关注标红的部分。匹配部分主要有table、priority、metadata、dl_dst。具体内容是，该流表位于table51，匹配metadata对于网络段为0x1393（table51的metadata主要就是匹配网络用的），但是匹配网络段为0x1393的流表会有很多，此时再匹配dl_dst目的mac地址，就可以过滤出所走的流表。动作部分主要有：load、resubmit。具体内容是，将目标端口段写入reg6，然后跳转到table220。

cookie=0x8000007, duration=82764.893s, table=220, n_packets=0, n_bytes=0, priority=9,reg6=0x1400 actions=output:tun723446dd7af

关注标红的部分。匹配部分主要是table和reg6。具体内容是，table220的一条流表，匹配端口段为0x1400。动作部分主要是output，从tun723446dd7af口出去。

group_id=210018,type=all,bucket=actions=group:210017,bucket=actions=load:0x3d00->NXM_NX_REG6[],resubmit(,220)

关注标红的部分。这条流表是group的流表，入口一般在flow里的table52，其功能是进行广播。可以看到它的匹配字段是group_id。动作字段则是几个actions，跳转到group:210017，写reg6后跳转到table220。

实际流表还有更多其他的形态，字段和内容也会有较大的变化，但是基本的构造——匹配和动作是不会改变的，只是具体的操作上有所差别，望举一反三。

4、实战操作

这里给出一个示例流程，说明报文是如何通过流表从table0转到table220出去的。

cookie=0x8000000, duration=258.784s, table=0, n_packets=222, n_bytes=21866, priority=10,in_port=6,dl_vlan=233 actions=pop_vlan,write_metadata:0x5e0000000001/0xffffff0000000001,goto_table:17

报文从vlan的patch口进来，写入medata为0x5e0000000001，跳转到table17。

cookie=0x8040000, duration=354.054s, table=17, n_packets=331, n_bytes=32718, priority=10,metadata=0x5e0000000000/0xffffff0000000000 actions=load:0x5e->NXM_NX_REG10..19,load:0x1397->NXM_NX_REG70..15,write_metadata:0xc0005e1397000000/0xfffffffffffffffe,goto_table:43

匹配中流表后，继续写metadata，跳转到43。

流表43到流表51的过程忽略，自行查看。

cookie=0x8031397, duration=448.037s, table=51, n_packets=391, n_bytes=40081, priority=20,metadata=0x1397000000/0xffff000000,dl_dst=fa:16:3e:0f:6c:19 actions=load:0x5f00->NXM_NX_REG6[],resubmit(,220)

匹配metadata发现，有多条匹配。分析该报文的属性可以知道，该报文是一个reply报文，会回到发起ping包的虚机端口。因此找到虚机的端口mac，匹配中。写reg6，跳转到220。

cookie=0x6900000, duration=479.333s, table=220, n_packets=457, n_bytes=46325, priority=6,reg6=0x5f00 actions=load:0x90005f00->NXM_NX_REG6[],write_metadata:0/0xfffffffffe,goto_table:239

匹配中reg6，继续写reg6，跳转端table239，进行端口安全的过滤。

端口安全内的流表跳转忽略，顺利通过，回到table220。

cookie=0x8000007, duration=484.570s, table=220, n_packets=453, n_bytes=44073, priority=9,reg6=0x90005f00 actions=output:"tapd9fd9aa5-d1"

匹配中reg6，从虚机端口出去。

对于复杂的场景，一般来说，在查看流表的过程中，还需要结合抓包进行分析。