openflow

一、OpenFlow协议简介

2006年，斯坦福大学Clean Slate计划资助的Ethane项目开始部署，致力于企业网架构的创新，OpenFlow协议的雏形就诞生于这个项目。2008年，Nick McKeown教授的一篇重要论文“OpenFlow：Enabling Innovation in Campus Networks”使得OpenFlow正式进入人们的视野，继而成为了标准化组织ONF（Open Network Foundation，开放网络基金会）主推的南向接口协议。经过多年的发展，OpenFlow现已成为SDN的主流南向接口协议之一。目前，OpenFlow协议还在不断地演进中，本实验采用OpenFlow v1.3协议，并对控制器与OpenFlow交换机之间的交互过程进行深入分析。
OpenFlow主要有3种类型的消息，分别是Controller-to-Switch、Asynchronous和Symmetric，其中每个类型又包含多个子类型。Controller-to-Switch消息由控制器发起，用于管理、查看交换机的状态。Asynchronous消息由交换机发起，向控制器汇报交换机的事件和改变。Symmetric消息由控制器或交换机任一方发起，无需请求直接发起消息。详细信息如下表所示：

消息类型	消息例子	描述
Controller-to-Switch	Packet_out Barrier Switch Configuration Switch Features Multipart	控制器使用这些消息可以添加、修改或删除流表项查询交换机的功能和统计配置交换机配置交换机端口属性将数据包发送出指定交换机端口
Asynchronous（异步）	Error Packet_in Port Status Table Status Controller Role Status	由交换机发起，发送消息给控制器这些消息可以是没有匹配交换机中任意流表项的数据包或数据包头，因此需要发送给控制器进行处理在流状态、端口状态改变，或者产生错误消息时，进行通知
Symmetric（对称）	Hello Echo Experimenter	Hello消息在控制器与交换机建立连接过程中使用 Echo消息用来确定Controller-to-Switch连接的延时，验证连接是否处于活跃状态 Experimenter消息用于未来消息的扩展

二、OpenFlow连接建立交互流程

在OpenFlow1.3协议的情况下，控制器与OpenFlow交换机的消息完整交互流程如下：
1、控制器与OpenFlow交换机通过TCP“三次握手”，建立有效的连接。其中，控制器一端的端口号为6633。
2、控制器与OpenFlow交换机之间相互发送Hello消息，用于协商双方的OpenFlow版本号。在双方支持的最高版本号不一致的情况下，协商的结果将以较低的OpenFlow版本为准。如果双方协商不一致，还会产生Error消息。
3、控制器向OpenFlow交换机发送Features Request消息，请求OpenFlow交换机上传自己的详细参数。OpenFlow交换机收到请求后，向控制器发送Features Reply消息，详细汇报自身参数，包括支持的buffer数目、流表数以及Actions等。
4、控制器通过Set Config消息下发配置参数，然后通过Get config Request消息请求OpenFlow交换机上传修改后的配置信息。OpenFlow交换机通过Get config Reply消息向控制器发送当前的配置信息。
5、控制器与OpenFlow交换机之间发送Packet_out、Packet_in消息，通过Packet_out中内置的LLDP包，进行网络拓扑的探测。
6、控制器与OpenFlow交换机之间通过发送Multipart Request、Mutipart Reply消息，控制器能获取OpenFlow交换机的状态信息，包括流的信息、端口信息等。
7、控制器与OpenFlow交换机之间通过发送Echo Request、Echo Reply消息，保证二者之间存在有效连接，避免失联。
说明：以上为控制器与OpenFlow交换机之间的标准交互流程，在具体实验过程中某些阶段可能会缺失。

实验步骤
一、实验环境检查

步骤1 登录控制器，查看控制器所在主机的IP地址。桌面版镜像可以通过双击桌面上的“Terminal”图标打开命令终端，也可以使用Ctrl+Alt+t快捷方式打开命令终端，如下图所示。

步骤2 登录主机1，查看Mininet所在主机的IP地址，如下图所示。

二、捕获数据包

步骤1 登录Floodlight控制器，启动抓包工具Wireshark，捕获控制器与交换机建立连接过程中的数据包，通过分析这些数据包了解控制器与交换机基于OpenFlow协议进行交互的流程。执行以下命令：
```
$ sudo wireshark
```
步骤2 双击eth0网卡，查看eth0网卡上数据包收发情况，如下图所示。

步骤3 登录Mininet虚拟机，启动Mininet。通过“--controller”参数设置Mininet连接远程控制器，并指定控制器的IP和端口号。
```
$ sudo mn --controller=remote,ip=30.0.1.3,port=6633 --switch=ovsk,protocols=OpenFlow13
```
步骤4 登录Floodlight控制器，停止Wireshark，观察数据包列表，可以看出控制器与交换机的基本交互流程。

三、OpenFlow1.3交互流程分析

步骤1 交换机连接控制器的6633端口，经过3次握手后双方建立TCP连接。查看捕获到的数据包，分析交换机与控制器建立TCP连接的流程。分析TCP连接建立过程，需要先了解TCP的状态位，主要包括SYN、FIN、ACK、PSH、RST和URG。SYN表示建立连接，FIN表示关闭连接，ACK表示响应，PSH表示有DATA数据传输，RST表示连接重置。可以看出交换机与控制器经历一次连接重置后，成功完成三次握手，建立TCP连接，如下图所示。

步骤2 当控制器与交换机建立TCP连接后，由其中某一方发起Hello消息，双方协调协OpenFlow议版本号。控制器和交换机都会向对方发送一条Hello消息，消息中附上自己支持的OpenFlow的最高版本。接收到对方Hello消息后，判断自己能否支持对方发送的版本，能支持则版本协商成功，不能支持则回复一条OFPT_ERROR消息。查看Hello消息详情，本实验中由于交换机和控制器都能支持OpenFlow1.3版本，所以版本协商为1.3，如下图所示。

步骤3 OpenFlow版本协商完成后，控制器发送一条features_request消息获取交换机的特性信息，包括交换机的ID（DPID）、缓冲区数量、端口及端口属性等等。相应的，交换机回复features_reply消息，如下图所示。

查看数据包详情，ofpt_feature_request消息只有包头，如下图所示。

ofpt_feature_reply数据包详情如下，交换机的DPID是数据通道独一无二的标识符，低48位是一个MAC地址，高16位是自定义的。本实验中交换机缓冲区数量（n_buffers）为256，交换机支持的流表数量（n_tables）为254，交换机所支持的功能，如下图所示。

步骤4 OpenFlow1.0协议中feature_reply消息还包含交换机端口信息，OpenFlow 1.3协议将‘stats’框架更名为‘multipart’框架，并且将端口描述移植到multipart消息中。其中OPPT_PORT_DESC类型的multipart消息就是用于获取交换机端口信息的。

查看OPPT_PORT_DESC类型multipart_reply消息，消息中列出了交换机的端口以及每个端口的详细信息，包括端口名称和mac地址等，如下图所示。

步骤5 OFPMP_DESC类型的multipart_reply消息包含了交换机的其他信息，包括交换机厂商名称、交换机名称以及交换机版本等。本实验中使用的是Mininet仿真软件中自带的开源交换机Open vSwitch(2.0.2)，而Open vSwitch是由Nicira Networks主导开发的，如下图所示。

步骤6 在连接过程中，控制器不断的发送echo_request消息给交换机，确认交换机与控制器之间的连接状态。相应的，交换机会回复echo_reply消息，如下图所示。

OpenFlow1.3协议基于Mininet部署与验证

实验描述: OpenFlow1.3协议基于Mininet部署与验证

一级分类: SDN

二级分类: OpenFlow系列实验

难易级别: 基础

实验课时: 2.0

任务目的

1．Mininet通过配置支持OpenFlow1.3协议。
2．验证通过配置后Mininet对OpenFlow1.3的支持。

任务环境

设备名称	软件环境	硬件环境
控制器	Ubuntu 14.04桌面版 OpenDaylight Carbon	CPU：2核内存：4G 磁盘：20G
主机	Ubuntu 14.04桌面版 Mininet 2.2.0	CPU：1核内存：2G 磁盘：20G

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

任务内容

创建一个Ubuntu虚拟机，在Ubuntu环境下安装并验证支持OpenFlow1.3协议的Mininet。
实验原理

Mininet可以用一个命令在一台主机上（虚拟机、云或者本地）以秒级创建一个虚拟网络，并在上面运行真正的内核、交换机和应用程序代码。之前已有实验介绍过Mininet的安装使用，但是有的Mininet版本并不支持或需要修改相应配置文件才能支持OpenFlow1.3协议，这给用户在使用过程中增加了不必要的麻烦。但在Mininet2.1.0p1及以后的版本可以原生支持OpenFlow1.3！但是这些新版本暂时还不能通过apt-get（Ubuntu环境下）命令获取到，本实验将介绍如何安装并验证支持OpenFlow1.3协议的Mininet。
实验步骤
一、实验环境检查

步骤1 选择控制器，单击终端图标，打开终端，执行ifconfig命令查看控制器IP，如下所示。

步骤2 执行netstat -an|grep 6633查看控制器的进程端口是否在监听状态，如下所示。

说明：OpenDaylight端口启动较慢，需等待1分钟左右。

步骤3 选择Mininet主机，单击终端图标，打开终端，执行ifconfig命令查看Mininet的IP地址，如下所示。

步骤4 执行mn --version查看Mininet的版本号，如下所示。

二、OpenFlow1.3通信验证

步骤1 执行以下命令，设置Mininet连接支持OpenFlow1.3的控制器：
```
$ sudo mn --switch ovs,protocols=OpenFlow13 --controller=remote,ip=[controller ip],port=6633
```
说明：该版本已不像之前2.1.0修改版本一样能在启动打印日志上看到所用的协议版本，因此后续我们要验证其南向接口是否用了OpenFlow1.3协议。

步骤2 执行pingall命令使得默认生成的两台主机互ping一下。

步骤3 在Mininet主机上打开一个新的终端窗口，执行sudo ovs-ofctl dump-flows -O openflow13 s1命令查看交换机中的流表是否是OpenFlow1.3版本的。

步骤4 在控制器主机上，执行命令sudo wireshark打开Wireshark，单击菜单“Capture>Options”。

步骤5 选中eth0网卡，单击“Start”按钮查看eth0网卡上数据包收发情况，如图所示，通过Wireshark查看抓包也可以看出使用的通信协议及版本号

实验描述: 学习OpenFlow Flow-Mod消息

一级分类: SDN

二级分类: OpenFlow

难易级别: 基础

实验课时: 2.0

任务目的

1、初步了解OpenFlow协议的三大消息类型，并着重学习Flow-Mod消息。
2、进一步巩固抓包工具Wireshark的使用方法，通过抓包详细分析Flow-Mod消息。

任务环境

设备名称	软件环境（镜像）	硬件环境
控制器	Ubuntu 14.04桌面版 Floodlight 1.0	CPU：1核内存：2G 磁盘：20G
主机	Ubuntu 14.04桌面版 Mininet 2.2.0	CPU：1核内存：2G 磁盘：20G

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

任务内容

1、通过Flow-Mod消息对流表进行添加、删除、变更设置等操作。
2、使用Wireshark工具捕获OpenFlow数据包，了解、学习Flow-Mod消息。
实验原理

OpenFlow 协议支持3种消息类型：Controller-to-Switch（控制器—交换机）、Asynchronous（异步）和Symmetric（对称），每一类消息又有多个子消息类型。
1、 Controller-Switch（控制器—交换机）消息，这类消息由控制器发起，包括Features、Configuration、Modify-State、Read-State、Send-Packet、Barrier等几类消息，用于对OF交换机的管理。
2、 Asynchronous（异步）消息，这类消息用来将网络事件或交换机状态的变化更新到控制器。主要包括4种子类型：Packet-in、Flow-Removed、Port-status和Error消息。
3、 Symmetric（同步）消息与前两类消息有所不同，Symmetric类的消息可由控制器或者OF交换机中的任意一侧发起，这类消息包括以下3种类型：Hello、Echo和Vendor。
Modify-State消息是OpenFlow消息中最为重要的消息类型，控制器通过Port-mod消息用来管理端口状态，通过Flow-mod消息增删交换机的流表项，考虑到流表在OpenFlow的重要意义，在此针对Flow-mod消息进行详尽分析。
图1是Flow-mod消息的具体格式，前4个字段是OpenFlow消息的通用报头。wildcard表示匹配时12元组的掩码位，被掩盖掉的元组不参加匹配。中间部分从in_port到tp_dst字段说明了流表项12元组的信息，其中的pad负责对齐占位，不代表任何意义。cookie字段在处理数据分组时不会用到，控制器通过cookie来过滤流的统计信息。command字段表示对流表的操作，包括增加（Add）、删除（Delete）、修改（Modify）等。idle_time和hard_time给出了该流表项的生存时间，其中idle_time表示当这条流表项在这段时间内没有匹配到数据分组，则该流表项失效，hard_time表示自流表项下发后只要过了这段时间即刻失效；两者同时设置时，以先到的生存时间为准；两者同时为0时，流表项不会自动失效。priority（优先级）字段的设置参考流表匹配那一小节，原则上优先级越高，所属的Table号就越小。buffer_id表示对应Packet-in消息的buffer_id。out_port仅在command为Delete或者Delete Strict时有效，表明当某表项不仅匹配了Flow-mod中给出的12元组，且转发动作中指定端口等于该out_port的动作时才予以删除，即对删除操作的一种额外限制。flags字段为标志位，OpenFlow v1.0中包括3项：OFPFF_SEND_FLOW_REM（流表失效时是否向控制器发送Flow-removed消息），OFPFF_CHECK_OVERLAP（交换机是否检测流表冲突），OFPFF_EMERG（该流表项将被存于Emergency Flow Cache中，仅在交换机处于紧急模式时生效）。消息中最后的actions数组是对动作表的描述actions[0]即代表其中第一个动作。

图1 OpenFlow v1.0中的Flow-mod消息格式
实验步骤
一、实验环境检查

步骤1 登录控制器，查看控制器IP。桌面版镜像可以通过双击桌面上的“Terminal”图标打开命令终端，也可以使用Ctrl+Alt+t快捷方式打开命令终端，如下图所示。

步骤2 登录Mininet所在主机，查看Mininet的IP，如下图所示。

二、Flow-Mod消息解析
- 场景一控制器自动下发流表
步骤1 登录Floodlight控制器，启动抓包工具Wireshark，捕获控制器与交换机建立连接后，控制器自动发送给交换机的flow_mod消息。执行以下命令：
```
$ sudo wireshark
```
步骤2 双击eth0网卡，查看eth0网卡上数据包收发情况，如下图所示。

步骤3 登录Mininet虚拟机，执行以下命令启动Mininet。

通过“—controller”参数设置Mininet连接远程控制器，并指定控制器的IP和端口号。
```
$ sudo mn --controller=remote,ip=30.0.1.3,port=6633 --switch=ovsk,protocols=OpenFlow13
```
步骤4 登录Floodlight控制器，停止Wireshark，观察数据包列表。

可以看出控制器发送的第一条flow_mod消息就是删除交换机中的流表项。这条flow_mod消息中table-id设为OFPTT_ALL，表明匹配的流表项将都会被删除。Commend显示为DELETE，Commend表示对流表进行的操作，具体包括五种操作类型：ADD、DELETE、DELETE‐STRICT、MODIFY、MODIFY‐STRICT，当Commend为DELETE就代表删除所有符合一定条件的流表项，如下图所示。

步骤5 发送完DELETE类型的消息后，控制器会发送ADD类型的flow_mod消息来添加新的流表项。

ADD消息可以分为三部分：openflow主体部分、match部分、instruction部分，其中instruction部分可以省略。match部分是匹配条件，instruction部分是指令，当一个数据包满足匹配条件就会执行instruction中的指令。控制器发送的add消息中action为output，而output的端口是controller，也就是说让交换机将符合匹配要求的数据包都转发给控制器，如下图所示。
- 场景二手动下发流表
步骤1 登录Floodlight控制器，启动Wireshark。

说明：控制器自动发送的flow_mod消息通常就是以上两种，为了进一步了解flow_mod消息，可以通过手动添加、删除流表项触发flow_mod消息。

步骤2 在控制器中再打开一个Terminal，输入以下命令获取交换机DPID。

其中：127.0.0.1是控制器所在的IP，8080是floodlightRest Api的端口。
```
$ curl http://127.0.0.1:8080/wm/core/controller/switches/json
```
说明：Floodlight控制器将自己的API通过Rest Api的形式向外暴露，用户可以通过Floodlight的Rest Api来向Floodlight请求交换机信息，添加、删除、查看流表项等。

步骤3 执行以下命令添加流表项。

其中switch的值就是上面获取到的DPID，name是流表项的名称，需要注意name的值必须是唯一的。priority是流表项的优先级，默认值是32767，最大值也是32767。以第二条命令为例，可以理解为“将交换机port1端口接收到的数据包都从port2转发出去”。
```
$ curl -X POST -d '{"switch":"00:00:00:00:00:00:00:01", "name":"ovs1", "cookie":"0", "priority":"34","in_port":"2","active":"true","actions":"output=1"}' http://127.0.0.1:8080/wm/staticflowpusher/json
$ curl -X POST -d '{"switch":"00:00:00:00:00:00:00:01", "name":"ovs2", "cookie":"0", "priority":"35","in_port":"1","active":"true","actions":"output=2"}' http://127.0.0.1:8080/wm/staticflowpusher/json
```
步骤4 查看flow_mod消息，从priority可以看出这个第二条流表项，Commend为ADD。匹配条件是in_port为1，对应的动作是output到端口2，如下图所示。

步骤5 执行以下命令删除流表项“ovs1”。
```
$ curl -X DELETE -d '{"name":"ovs1"}' http://127.0.0.1:8080/wm/staticflowpusher/json
```
步骤6 查看对应的flow_mod消息，Commend是DELETE_STRICT，DELETE_STRICT类型消息表示删除某一条指定的流表项。该消息表明删除的流表项的priority是34，匹配条件是in_port为2，如下图所示。

步骤7 执行以下命令修改流表项“ovs2”。

如果修改名称、优先级、匹配条件等字段，就会被认为是添加新的流表项。如果只是修改actions，则是修改流表项。
```
$ curl -X POST -d '{"switch":"00:00:00:00:00:00:00:01", "name":"ovs2", "cookie":"0", "priority":"35","in_port":"1","active":"true","actions":"output=3"}' http://127.0.0.1:8080/wm/staticflowpusher/json
```
步骤8 查看对应的flow_mod消息，Commend是MODIFY_STRICT，MODIFY_STRICT类型息用来修改某一条指定的流表项。从消息可以看出被修改的流表项的priority是35，匹配条件是in_port为1，如下图所示。

实验描述: 学习OpenFlow流表下发方式

一级分类: SDN

二级分类: OpenFlow

难易级别: 基础

实验课时: 2.0

任务目的

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 登录控制器，查看控制器IP

步骤2 使用root用户登录交换机，连接控制器和交换机，其中30.0.1.36是控制器的IP地址。如下图所示，is_connected为true表明控制器与交换机连接成功。
```
 ovs-vsctl set-controller br-sw tcp:30.0.1.36:6633
```
步骤3 登录主机1，为主机1的数据口配置IP，如下图所示。
```
sudo ifconfig eth1 10.0.0.4/24
```
主机1：

步骤4 登录主机2，为主机2的数据口配置IP，如下图所示。
```
sudo ifconfig eth1 10.0.0.5/24
```
主机2：

二、下发流表

步骤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不通，如下图所示。

posted on 2025-04-05 21:46 vanness_205 阅读(283) 评论(0) 收藏举报

openflow

一、OpenFlow协议简介

二、OpenFlow连接建立交互流程

实验步骤

一、实验环境检查

步骤1 登录控制器，查看控制器所在主机的IP地址。桌面版镜像可以通过双击桌面上的“Terminal”图标打开命令终端，也可以使用Ctrl+Alt+t快捷方式打开命令终端，如下图所示。

步骤2 登录主机1，查看Mininet所在主机的IP地址，如下图所示。

二、捕获数据包

步骤1 登录Floodlight控制器，启动抓包工具Wireshark，捕获控制器与交换机建立连接过程中的数据包，通过分析这些数据包了解控制器与交换机基于OpenFlow协议进行交互的流程。执行以下命令：

步骤2 双击eth0网卡，查看eth0网卡上数据包收发情况，如下图所示。

步骤3 登录Mininet虚拟机，启动Mininet。通过“--controller”参数设置Mininet连接远程控制器，并指定控制器的IP和端口号。

步骤4 登录Floodlight控制器，停止Wireshark，观察数据包列表，可以看出控制器与交换机的基本交互流程。

三、OpenFlow1.3交互流程分析

步骤3 OpenFlow版本协商完成后，控制器发送一条features_request消息获取交换机的特性信息，包括交换机的ID（DPID）、缓冲区数量、端口及端口属性等等。相应的，交换机回复features_reply消息，如下图所示。

步骤4 OpenFlow1.0协议中feature_reply消息还包含交换机端口信息，OpenFlow 1.3协议将‘stats’框架更名为‘multipart’框架，并且将端口描述移植到multipart消息中。其中OPPT_PORT_DESC类型的multipart消息就是用于获取交换机端口信息的。

步骤6 在连接过程中，控制器不断的发送echo_request消息给交换机，确认交换机与控制器之间的连接状态。相应的，交换机会回复echo_reply消息，如下图所示。

OpenFlow1.3协议基于Mininet部署与验证

任务目的

任务环境

任务内容

实验原理

实验步骤

一、实验环境检查

步骤1 选择控制器，单击终端图标，打开终端，执行ifconfig命令查看控制器IP，如下所示。

步骤2 执行netstat -an|grep 6633查看控制器的进程端口是否在监听状态，如下所示。

步骤3 选择Mininet主机，单击终端图标，打开终端，执行ifconfig命令查看Mininet的IP地址，如下所示。

步骤4 执行mn --version查看Mininet的版本号，如下所示。

二、OpenFlow1.3通信验证

步骤1 执行以下命令，设置Mininet连接支持OpenFlow1.3的控制器：

步骤2 执行pingall命令使得默认生成的两台主机互ping一下。

步骤3 在Mininet主机上打开一个新的终端窗口，执行sudo ovs-ofctl dump-flows -O openflow13 s1命令查看交换机中的流表是否是OpenFlow1.3版本的。

步骤4 在控制器主机上，执行命令sudo wireshark打开Wireshark，单击菜单“Capture>Options”。

步骤5 选中eth0网卡，单击“Start”按钮查看eth0网卡上数据包收发情况，如图所示，通过Wireshark查看抓包也可以看出使用的通信协议及版本号

任务目的

任务环境

任务内容

实验原理

实验步骤

一、实验环境检查

步骤1 登录控制器，查看控制器IP。桌面版镜像可以通过双击桌面上的“Terminal”图标打开命令终端，也可以使用Ctrl+Alt+t快捷方式打开命令终端，如下图所示。

步骤2 登录Mininet所在主机，查看Mininet的IP，如下图所示。

二、Flow-Mod消息解析

步骤1 登录Floodlight控制器，启动抓包工具Wireshark，捕获控制器与交换机建立连接后，控制器自动发送给交换机的flow_mod消息。执行以下命令：

步骤2 双击eth0网卡，查看eth0网卡上数据包收发情况，如下图所示。

步骤3 登录Mininet虚拟机，执行以下命令启动Mininet。

步骤4 登录Floodlight控制器，停止Wireshark，观察数据包列表。

步骤5 发送完DELETE类型的消息后，控制器会发送ADD类型的flow_mod消息来添加新的流表项。

步骤1 登录Floodlight控制器，启动Wireshark。

步骤2 在控制器中再打开一个Terminal，输入以下命令获取交换机DPID。

步骤3 执行以下命令添加流表项。

步骤4 查看flow_mod消息，从priority可以看出这个第二条流表项，Commend为ADD。匹配条件是in_port为1，对应的动作是output到端口2，如下图所示。

步骤5 执行以下命令删除流表项“ovs1”。

步骤6 查看对应的flow_mod消息，Commend是DELETE_STRICT，DELETE_STRICT类型消息表示删除某一条指定的流表项。该消息表明删除的流表项的priority是34，匹配条件是in_port为2，如下图所示。

步骤7 执行以下命令修改流表项“ovs2”。

步骤8 查看对应的flow_mod消息，Commend是MODIFY_STRICT，MODIFY_STRICT类型息用来修改某一条指定的流表项。从消息可以看出被修改的流表项的priority是35，匹配条件是in_port为1，如下图所示。

任务目的

任务环境

任务内容

实验原理

实验步骤

一、实验环境检查

步骤1 登录控制器，查看控制器IP

步骤2 使用root用户登录交换机，连接控制器和交换机，其中30.0.1.36是控制器的IP地址。如下图所示，is_connected为true表明控制器与交换机连接成功。

步骤3 登录主机1，为主机1的数据口配置IP，如下图所示。

步骤4 登录主机2，为主机2的数据口配置IP，如下图所示。

二、下发流表

步骤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中。执行如下命令：

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

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