一：什么是流表

流表类似于交换机的MAC地址表，路由器的路由表，是 OpenvSwitch 指挥流量转发的表。

Openflow是有多个版本的 ovs-ofctl仅启用OpenFlow 1.0.，当使用其他版本OpenFlow时

需要使用ovs-ofctl -O来指定详细的版本，在一体机项目中。我们使用的openflow13 版本，因此查看流表的命令为

ovs-ofctl -Oopenflow13 dump-flows br-int table=0

 cookie=0x0, duration=1541435.636s, table=0, n_packets=4337289, n_bytes=660210111, priority=100 actions=goto_table:10

 

二：常见的流表字段分类

从上面的输出结果能看出一个常见的流表可以分为三类、统计类、标识类、行为类。

统计类：duration 表示该规则自创建以来已经生存的时间（单位为秒）。n_packets 和 n_bytes 分别表示匹配该规则的数据包数和总字节数。

 

标识类：cookie 用来标识一类规则，table 标识表的编号。默认规则都是从table=0开始按priority 优先级逐条匹配的，数字越大优先级越高。

 

行为类：actions对于匹配到的包，如何进行处理。实际生产的流表中，我们可以看到有多个表项的动作为goto_table和set_field。其中，

goto_table用于跳转到指定的表中继续匹配和执行，set_field用于设置指定字段的值

 

三： 详细字段说明

3.1 虚拟机如何获取IP地址。

 cookie=0x0, duration=1542867.268s, table=0, n_packets=4339798, n_bytes=660327009, priority=100 actions=goto_table:10

 cookie=0x0, duration=1542867.196s, table=10, n_packets=0, n_bytes=0, priority=300,udp6,tp_dst=547 actions=CONTROLLER:65535

 cookie=0x0, duration=1542867.172s, table=10, n_packets=137, n_bytes=47185, priority=300,udp,tp_dst=67 actions=CONTROLLER:65535

一个常见的流表项和安全组和防火墙类似，都是匹配到指定规则的包，按指定的行为（action）去处理.

上面第一条没有任何匹配条件，标识所有的包都匹配，go_to_table 表示继续交给table=10的表去处理。（在实际应用中我们可以使用该命令来查看

指定table的条目，而不是一次将所有的流表都输出。）

ovs-ofctl -Oopenflow13 dump-flows br-int table=0  #此时就只看table=0的表

 

上面条是table=10的表项有两条，因为优先级都是300，则默认至上而下的匹配执行。具体含义表示匹配UDPv6协议的数据包，

目的端口为547（DHCPv6协议的默认端口），如果匹配成功，将数据包发送到控制器进行处理（controller：65535）。而第三条的含义是

目标端口是udp 67的端口包，交给控制器来处理。dhcp服务默认端口就是udp 67.因此从该规则我们看出，dhcp的请求包将发送给控制器去处理，

事实上也确实如此，下面我们来抓包来分析。

 

在物理机上抓目标端口为6633端口数据包（6633端口为控制器监听地址），OFPT_PACKET_IN 为openflow向上发给控制器的请求报文。

详细的报文格式如下

打开Openflow 协议的Data 字段可以看到发送dhcp 请求的mac ，目标mac为广播报文。下面我们查看虚拟机接口的mac

发现该mac 确实是虚拟机的接口的mac ,因此确定这个dhcp的请求包为虚拟机发送出来的，其通过openflow协议发送给了控制器。

下面是控制器回复的响应报文 ，包括了dhcp 的响应包，该报文是发送给虚拟机所在的物理机节点上，到达物理机后，由物理机转发给对应的虚拟机。

总结：从上述例子中我们知道在一体机项目中通过20号流表来把虚拟机的dhcp的请求包发送给了控制器，如果流表不正常、控制器不正常、控制器6633端口被防火墙规则所限制等都会造成虚拟机拿不到IP地址。

 

3.2 同网段的虚拟机相互之间通信

原理：相同网络的虚拟机要想通信需要通过arp 报文获取对方的mac地址，接下来我们继续分析流表，看虚拟机是如何发送arp请求和响应的。

cookie=0x0, duration=8729580.116s, table=20, n_packets=25135358, n_bytes=4688159427, priority=200,ip,in_port="tap4432d19a-eb"

actions=load:0x7->NXM_NX_REG5[],load:0x7->NXM_NX_REG6[],set_field:0x23->tun_id,goto_table:21

 

cookie=0x0, duration=8729580.115s, table=20, n_packets=249587, n_bytes=10482654, priority=200,arp,in_port="tap4432d19a-eb" actions=load:0x7->NXM_NX_REG5[],load:0x7->NXM_NX_REG6[],set_field:0x23->tun_id,goto_table:21

 

cookie=0x0, duration=7607595.333s, table=20, n_packets=6775179, n_bytes=804658123, priority=200,ip,in_port="tap41e48bdc-5b" actions=load:0x8->NXM_NX_REG5[],load:0x11->NXM_NX_REG6[],set_field:0x47->tun_id,goto_table:21

 

cookie=0x0, duration=7607595.332s, table=20, n_packets=206073, n_bytes=8655066, priority=200,arp,in_port="tap41e48bdc-5b" actions=load:0x8->NXM_NX_REG5[],load:0x11->NXM_NX_REG6[],set_field:0x47->tun_id,goto_table:21

Ip,in_port=tap4432d19a-eb 表示其协议是IP协议，流量是从tap4432d19a-eb 发出来的，将执行的操作 load:0x7->MXM_NX_REG5[]，load:0x->MXM_NX_REG6

Set_field: 0x23->tun_id 。

上述的操作看上去复杂，其实就做了一件事打标记，只不过其标记是存放在对应的寄存器中，reg5的标记表示虚拟机port的来源的标记，reg6标记则表示同一个subnet的标记，而tun_id 从字面意思上可以看出是隧道标记。

因为上述环境为vxlan 网络，因此每个不同的vpc 对应一个不同的tun_id,通过不同tun_id 来隔离不同vpc的租户流量。

同样的第二条也是打标记，只不过其标识的协议是来自arp协议的数据包。分别对比1 2条数据和3 4 条数据可以确定tap4432d19a-eb 和tap41e48bdc-5b的两个port 分别输入两个完全不同的subnet 。因为reg6 标记不一样，待会我们会验证这一点。

 

 cookie=0x0, duration=8825531.760s, table=21, n_packets=92159712, n_bytes=12528380058, priority=100 actions=goto_table:22

 cookie=0x0, duration=8825531.760s, table=22, n_packets=92159712, n_bytes=12528380058, priority=100 actions=goto_table:30

上述这两条规则只是做跳转，将流量引入了30号流表。

 

 cookie=0x0, duration=8729580.113s, table=30, n_packets=20, n_bytes=840, priority=300,arp,reg6=0x7,arp_tpa=10.100.255.5,arp_op=1 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:fa:16:3e:31:cc:e5->eth_src,set_field:2->arp_op,move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],set_field:fa:16:3e:31:cc:e5->arp_sha,move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],set_field:10.100.255.5->arp_spa,IN_PORT

上述流表要想看明白需要对arp 的报文有一定的了解，因此我们说下arp报文的格式

我们先看华为官网的例子中arp报文的部分格式如下

从上面看出一个arp 报文有发送mac地址 发送者IP地址 和目标mac地址和目标IP地址。 Opcode: 1 表示是arp 请求的报文， 2 则表示是arp 的响应的报文。

了解上述信息后我们在看报文就豁然开朗了，arp_tpa=10.100.255.5,arp_op=1，表示如果是arp请求的目标IP是10.100.255.5，则

 

move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[] set_field:fa:16:3e:31:cc:e5->eth_src  ，将源mac修改为目标mac ，而将指定的fa:16:3e:31:cc:e5 ，写进源mac, 而set_field:2->arp_op，表示将arp 的请求包改为arp 的应答包。

 

上述是修改了2层以太网的封装包，而下面则是将arp的封装包也进行了修改，ARP_SHA 表示 Ethernet Address of Sender，发送方的以太网地址，

ARP_THA 表示 Ethernet Address of Destination 接受方的以太网地址，ARP_SPA 表示 发送方的IP地址 ARP_TPA 则表示接受方的IP 地址。

move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],set_field:fa:16:3e:31:cc:e5->arp_sha,move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],set_field:10.100.255.5->arp_spa,IN_PORT

上述的报文就是将ARP的发送方的以太网地址和IP地址，都修改为了接收方的以太网地址和IP地址。而将发送方的IP修改为 10.100.255.5

发送方的mac 修改为fa:16:3e:31:cc:e5 。下面我们来查询该mac对应的接口，则发现就是之前的tap4432d19a-eb 。

virsh domiflist 51

 Interface        Type     Source   Model    MAC

----------------------------------------------------------------

 tap4432d19a-eb   bridge   br-int   virtio   fa:16:3e:31:cc:e5

同时将2层以太网封装的mac 和2层arp报文的封装修改后，将目标改成源，其整体上就做了一件事，arp 地址代答，也就是说 如果arp 请求查询10.100.255.5的IP对应的mac 时，将tap4432d19a-eb对应接口mac 来作为arp的响应的报文发送出去。此时也验证了该mac地址对应的IP是10.100.255.5.

cookie=0x0, duration=8729580.113s, table=30, n_packets=6292, n_bytes=264264,

priority=200,arp,tun_id=0x23,in_port=vxlan1,arp_tpa=10.100.255.5 actions=output:"tap4432d19a-eb"

此流表表示如果tun_id是 0x23 流量是从vxlan1 进入来的 且arp 的接收的方IP是10.100.255.5 从 tap4432d19a-eb 发送出去。经过上述几天流表，无论是相同网段（相同tun_id ）的虚拟机都可以通过arp的报文来拿到通信双方的mac 地址了。

 

解决了mac地址的问题，则同subnet的虚拟机既可以完成2层封装，如果想要进行IP通信，还需要将IP流量引入指定虚拟机的tap口，接下来我们具体分析。

cookie=0x0, duration=8729580.112s, table=40, n_packets=23418345, n_bytes=3836008358, priority=200,ip,in_port=vxlan1,dl_dst=fa:16:3e:31:cc:e5 actions=load:0x7->NXM_NX_REG5[],load:0x7->NXM_NX_REG6[],goto_table:81

根据前面的理解，这条报文的意思是 如果是IP协议，从vxlan1 进来的 目标mac地址是 fa:16:3e:31:cc:e5也就是10.100.255.5 其tap口为 tap4432d19a-eb的流量包，跳转到81号流表。

cookie=0x0, duration=8728669.421s, table=81, n_packets=158, n_bytes=13828, priority=200,icmp,reg5=0x7 actions=ct(commit,table=83)

cookie=0x0, duration=8728268.791s, table=81, n_packets=3567, n_bytes=499779, priority=200,tcp,reg5=0x7,tp_dst=3389 actions=ct(commit,table=83)

cookie=0x0, duration=7976525.032s, table=81, n_packets=55623, n_bytes=5723897, priority=200,tcp,reg5=0x7,tp_dst=9098 actions=ct(commit,table=83)

上述三条的意思是如果其reg5=0x7 ，上述曾说明过其就代表的tap4432d19a-eb 的tap口，并且协议是icmp 或 tcp协议目标端口是3389 或目标端口是9098的流量，其追踪后重新提交到83号流表。

 cookie=0x0, duration=8825531.759s, table=83, n_packets=38664553, n_bytes=5163764381, priority=100 actions=goto_table:84

 cookie=0x0, duration=8825531.758s, table=84, n_packets=38664553, n_bytes=5163764381, priority=100 actions=goto_table:85

 cookie=0x0, duration=8729580.111s, table=85, n_packets=23415882, n_bytes=3835853296, priority=200,reg5=0x7 actions=output:"tap4432d19a-eb"

标记为0x7的tap4432d19a-eb ，经过84 85好流表都发送到了tap4432d19a-eb的接口，这样就完成了与tap4432d19a-eb的流量的引导。

 

总结：从arp地址应到、到流量引导，可以看到整个流量的过程都是在流表中进行的，而流表的下发和更新都是由控制器来动态更新和生成的。