Open Flow协议分析实验

一、实验目的

1.能够运用 wireshark 对 OpenFlow 协议数据交互过程进行抓包；

2.能够借助包解析工具，分析与解释 OpenFlow协议的数据包交互过程与机制。

二、实验环境

1.下载虚拟机软件Oracle VisualBox；

2.在虚拟机中安装Ubuntu 20.04 Desktop amd64，并完整安装Mininet；

三、实验要求

（一）基本要求

1.搭建下图所示拓扑，完成相关 IP 配置，并实现主机与主机之间的 IP 通信。用抓包软件获取控制器与交换机之间的通信数据包。

主机	IP地址
h1	192.168.0.101/24
h2	192.168.0.102/24
h3	192.168.0.103/24
h4	192.168.0.104/24

• 在终端输入sudo ./../mininet/examples/miniedit.py搭建拓扑

• 配置网段

• 配置IP地址

• 保存为Python文件

2.查看抓包结果，分析OpenFlow协议中交换机与控制器的消息交互过程，画出相关交互图或流程图。

运行sudo wireshark命令，并选择any模式进行抓包，开启另一个终端，命令行运行topo.py文件，运行pingall

（1）Hello：当连接启动时交换机和控制器会发送Hello交互。

　当交换机连接到控制器时，交换机与控制器会相互发送hello包，而hello消息中只包含of Header，of Header中的version字段为发送方支持的最高版本的of协议版本。如果两者协议版本兼容，则建立of连接，否则发送error消息，断开连接。交换机向控制器发送的Hello消息如下所示：

OFPT_HELLO 源端口6633 ------- 目的端口46038，从控制器到交换机

• 交换机46038端口（OpenFlow 1.5)-------控制器6633端口

• OpenFlow交换机与OpenFlow控制器之间通过TCP三次握手过程建立连接，使用的TCP端口号为6633。
• TCP连接建立后，交换机和控制器就会互相发送hello报文。Hello报文负责在交换机和控制器之间进行版本协商，该报文中OpenFlow数据头的类型值为0。
• 于是双方建立连接，并使用OpenFlow 1.0

 （2）Features Request:控制器发向交换机的一条OpenFlow 消息，目的是为了获取交换机性能，功能以及一些系统参数。该报文中OpenFlow 数据头的类型值为5。

　连接建立后，控制器向交换机发送一个features Request消息查询交换机的特性，features request消息也只包含of Header，交换机接受到该消息之后会返回一个features reply消息，这个消息就包含Header和Message。如下所示：

• 控制器6633端口（OpenFlow 1.0)------- 交换机46038端口

 （3）Features Reply: 由交换机向控制器发送的功能响应（Feature Reply）报文，描述了OpenFlow交换机的详细细节。控制器获得交换机功能信息后，OpenFlow协议相关的特定操作就可以开始了。

交换机向控制器响应的OFPT_FEATURES_REPLY消息。如下所示

• 交换机46038端口（openflow 1.0）--- 控制器6633端口

 

reply消息分析：

[0:8]为header(version、type、length、xid)

[8:32]长度24byte为sw的features，包含如下：

datapath_id：交换机的标识符，低48位是一个MAC地址，高16位是自定义的。

n_buffers：一次最多缓存的数据包数量。

n_tables：表示交换机支持的流表数量。每个流表可以设置不同的通配符和不同数量的流表项。控制器和交换机第一次通信的时候，控制器会从feature_reply消息中找出交换机支持多少流表，如果控制器还想了解大小、类型和流表查询的顺序，就发送一个ofpst_table stats请求，交换机必须按照数据包遍历流表的顺序把这些流表回复给控制器，并且精确匹配流表排在通配流表前。

auxiliary_id：标识辅助连接。

capabilities：所支持的功能。交换机的一些详细信息。

reserved：保留字段。

（4）Packet_in

Packet-in事件在以下两种情况下会被触发：
        1.当交换机收到一个数据包后，并未与流表中匹配成功，那么交换机就会将数据封装在Packer-in消息中，发送给控制器处理。此时数据包会被缓存在交换机中等待处理。
        2.交换机流表所指示的action列表中包含转发给控制器的动作（Output=Controller），此时数据不会被缓存在控制器中。

交换机向控制器递交OFPT_PACKET_IN消息。如下所示

• 分析抓取的数据包，可以发现是因为交换机发现此时自己并没有匹配的流表（Reason: No matching flow (table-miss flow entry) (0)），所以要问控制器如何处理

 （5）Flow_mod

Flow-Mod消息用于添加、删除、修改openflow交换机的流表项信息；Flow-Mod消息共有5种类型：ADD、DEKETE、DELETE-STRICT、MODIFY、MODIFY_STRICT。
        ADD类型消息用来添加一条新的流表项（flow entry）
        DELETE类型消息用来删除所有符合一定条件的流表项
        DELETE‐STRICT类型消息用来删除某一条指定的流表项
        MODIFY类型消息用来修改所有符合一定条件的流表项
        MODIFY‐STRICT类型息用来修改某一条指定的流表项

• 分析抓取的flow_mod数据包，控制器通过6633端口向交换机46038端口、交换机46038端口下发流表项，指导数据的转发处理。如下所示

 

（6）Packet_out

Packet-out消息的应用场景：
        指定某一个数据包的处理方法
        让交换机产生一个数据包并按照action流表处理。
        典型应用：链路发现
        控制器向一个交换机发送packet-out消息，buffer_id=-1，data段为某种特殊数据包，actions为从交换机的某个端口进行转发，如果发出这个数据包的端口另一端也连接一个openflow交换机，对端的交换机会产生一个packet-in消息将这个特殊的数据包包上交给控制器，从而控制器他侧到一条链路的存在（控制器实现链路发现，就是依靠packet-out消息）。
        当控制器断电或者交换机与控制器之间的连接断开，则交换机会寻找备用控制器，当无法找到备用控制器时便会进入紧急模式（交换机初始化时也是在这个模式下），在紧急模式下，交换机默认将所有接受到的数据包丢弃。

控制器向交换机下发OFPT_PACKET_OUT消息。如下所示

（7）port_status

 当交换机端口发生变化时，告知控制器相应的端口状态。如下所示

四、个人总结

本次实验学习分析openflow协议，基本上了解学习了openflow协议的工作方式以及发包流程，并且学习了这些协议的源代码数据结构，进一步加强了对openflow协议工作方式以及工作流程的理解了，了解了在这个协议之下交换机以及控制器进行交流分享数据的方式，对数据交互有了更深的理解。
同时，在刚开始使用wireshark抓包时发现无法看到hello协议的包，才了解到hello在构建拓扑结构的时候才会发出。之后又找不到flow_mod的包，了解到flow_mod在下发流表的时候才会发出，对发到的顺序以及控制器与交换机之间的沟通顺序有了更深刻的理解。