OpenFlow流表学习

任务目的

1、掌握OpenFlow流表和流表项基础知识。
2、掌握OpenFlow流表匹配规则。
3、掌握OpenFlow流表匹配后执行的动作。。

任务环境

设备名称	软件环境（镜像）	硬件环境
控制器	Ubuntu 14.04桌面版 Floodlight 1.0	CPU：1核 内存：2G 磁盘：20G
交换机	Ubuntu 14.04命令行版 Open vSwitch 2.3.1	CPU：1核 内存：2G 磁盘：20G
主机	Ubuntu 14.04桌面版	CPU：1核 内存：2G 磁盘：20G

注：系统默认的账户为root/root@openlab，openlab/user@openlab。

任务内容

1、学习OpenFlow流表和流表项基础知识。
2、学习OpenFlow流表匹配规则。
3、学习OpenFlow流表匹配后执行的动作。

实验原理

OpenFlow控制器通过部署流表来指导数据平面流量。OpenFlow v1.0中每台OF交换机只有一张流表，这张流表中存储着许多的表项，每一个表项都表征了一个“流”及其对应的处理方法——动作表（Action），一个数据分组进入OF交换机后需要先匹配流表，若符合其中某条表项的特征，则按照相应的动作进行转发，否则封装为Packet-in消息通过安全通道交给控制器，再由控制器决定如何处理。另外，每条流表项都存在一个有效期，过期之后流表会自动删除。
一个流表中包含多个流表项，OpenFlow v1.0中流表项主要由3部分组成，分别是用于数据分组匹配的分组头域（Head Field），用于保存与条目相关统计信息的计数器（Counter），还有匹配表项后需要对数据分组执行的动作表（Action），如图1所示。

图1 OpenFlow v1.0流表项结构

分组头域是数据分组匹配流表项时参照的依据，作用上类似于传统交换机进行二层交换时匹配数据分组的MAC地址，路由器进行三层路由时匹配的IP地址。如图2所示，在OpenFlow v1.0中，流表项的分组头域包括了12个字段，协议称其为12元组（12-Tuple），它提供了1～4层的网络控制信息，详见表1。

图2 OpenFlow v1.0中的12元组

交换机入端口（Ingress Port）属于一层的标识；源MAC地址（Ether source）、目的MAC地址（Ether dst）、以太网类型（EtherType）、VLAN标签（VLAN id）、VLAN优先级（VLAN priority）属于二层标识；源IP（IP src）、目的IP（IP dst）、IP协议字段（IP proto）、IP服务类型（IP ToS bits）属于三层标识；TCP/UDP源端口号（TCP/UDP src port）、TCP/UDP目的端口号（TCP/UDP dst port）属于四层的标识。这些丰富的匹配字段为标识“流”提供了更为精细的粒度。

设备名称	软件环境（镜像）	硬件环境	设备名称
入端口	未规定	所有数据分组	数据分组进入交换机的端口号，从1开始
以太网源地址	6	有效端口收到的数据分组	无
以太网目的地址	6	有效端口收到的数据分组	无
以太网帧类型	2	有效端口收到的数据分组	OF交换机必须支持由IEEE 802.2+SNAP或OUI规定的类型。使用IEEE 802.3而非SNAP的帧类型为0x05FF
VLAN标识	12bit	帧类型为0x8100的数据分组	VLAN ID
VLAN优先级	3bit	帧类型为0x8100的数据分组	VLAN PCP字段
源IP地址	4	ARP与IP数据分组	可划分子网
目的IP地址	4	ARP与IP数据分组	可划分子网
服务类型TOS	6bit	IP数据分组	高6bit为TOS
IP数据分组类型	1	ARP与IP数据分组	对应ARP中opcode字段的低字节
传输层源端口号/ICMP类型	2	TCP/UDP/ICMP分组	当数据分组类型是ICMP时，低8bit用于标识ICMP类型
传输层目的端口号/ICMP 码值	2	TCP/UDP/ICMP分组	当数据分组类型是ICMP时，低8bit用于标识ICMP码值

表1 OpenFlow v1.0中12元组详细信息
流表项中的计数器用来统计相关“流”的一些信息，例如查找次数、收发分组数、生存时间等。另外，OpenFlow针对每张表、每个流表项、每个端口、每个队列也都会维护它们相应的计数器。
动作表指定了OF交换机处理相应“流”的行为。动作可以分为两种类型：必选动作（Required Action）和可选动作（Optional Action）。必选动作是默认支持的，而交换机需要通知控制器它支持的可选动作。另外，当流表项中存在OF交换机不支持的动作时将向控制器返回错误消息。
OpenFlow v1.3中流表项主要由6部分组成，分别是：匹配字段（match fields）、优先级（priority）、计数器（counters）、指令（instructions）、超时（timeouts）、cookie，如图3所示。从OpenFlow1.0发展至OpenFlow1.3，匹配字段已经从12元组扩展成39个字段。

图3 OpenFlow v1.3流表项结构

与OpenFlow v1.0不同的是，OpenFlow v1.3协议中一台OF交换机会有多张流表。具体匹配流程与图4所示，首先交换机解析进入设备的数据分组，然后从table 0开始匹配，按照优先级高低依次匹配该流表中的流表项，一个数据分组在一个流表中只会匹配上一条流表项。通常根据数据分组的类型，分组头的字段例如源MAC地址、目的MAC地址、源IP地址、目的IP地址等进行匹配，大部分匹配还支持掩码进行更精确、灵活的匹配。也可以通过数据分组的入端口或元数据信息来进行数据分组的匹配，一个流表项中可以同时存在多个匹配项，一个数据分组需要同时匹配流表项中所有匹配项才能匹配该流表项。数据分组匹配按照现有的数据分组字段进行，比如前一个流表通过apply actions改变了该数据分组的某个字段，则下一个表项按修改后的字段进行匹配。如果匹配成功，则按照指令集里的动作更新动作集，或更新数据分组/匹配集字段，或更新元数据和计数器。根据指令是否继续前往下一个流表，不继续则终止匹配流程执行动作集，如果指令要求继续前往下一个流表则继续匹配，下一个流表的ID需要比当前流表ID大。当数据分组匹配失败了，如果存在无匹配流表项（table miss）就按照该表项执行指令，一般是将数据分组转发给控制器、丢弃或转发给其他流表。如果没有table miss表项则默认丢弃该数据分组。

图4 OpenFlow v1.3中流表的匹配流程

实验步骤

一、实验环境检查

步骤1 查看操作实验拓扑，如下图所示。

步骤2 使用root用户登录交换机，查看网络连通性。如下图所示，is_connected为true表明控制器与交换机连接成功，如下图所示。

步骤3 登录主机，查看主机IP地址，如下图所示。

主机1：

主机2：

主机3：

二、下发流表

步骤1 Floodlight控制器与交换机建立连接后会自动下发一些流表项，登录交换机，查看控制器下发的流表项。Floodlight下发了254条流表项，table id依次从0到253，这些流表项的优先级（priority）都为0，动作都是转发给控制器。执行以下命令：

ovs-ofctl dump-flows br-sw

步骤2 登录主机1，ping主机主机2，交换机收到数据包后匹配当前的流表项，将数据包转发给控制器，触发packet_in消息。控制器发送flow_mod消息作为响应，并下发与该数据包相关的流表项，指导交换机进行转发。不过这些流表项的生命周期都比较短，如下图所示。

步骤3 登录交换机，使用命令ovs-ofctl dump-flows br-sw|more查看控制器下发的流表项。接收端口为port1，从主机1发往主机2的数据包从port2转发出去。接收端口为port2，从主机2发往主机1的数据包从port1转发出去，如下图所示。

步骤4 下发一条流表项，将主机1发给主机2的数据包丢弃。匹配字段包括：dl_type、nw_src、nw_dst，优先级priority设为27，table id为0，即将该流表项下发到table 0中。执行如下命令：

ovs-ofctl add-flow br-sw dl_type=0x0800,nw_src=10.0.0.4,nw_dst=10.0.0.5,priority=27,table=0,actions=drop

步骤5 查看流表，可以看见新添加的流表项，以及之前控制器下发的流表项。

ovs-ofctl dump-flow br-sw |more

步骤6 登录主机1，ping主机主机2，发现新增的流表项生效，主机1与主机2不通，如下图所示。