实验3:OpenFlow协议分析实践
实验3:OpenFlow协议分析实践
一、实验目的
- 能够运用 wireshark 对 OpenFlow 协议数据交互过程进行抓包;
- 能够借助包解析工具,分析与解释 OpenFlow协议的数据包交互过程与机制。
二、实验环境
- 下载虚拟机软件Oracle VisualBox;
- 在虚拟机中安装Ubuntu 20.04 Desktop amd64,并完整安装Mininet;
三、实验要求
(一)基本要求
- 搭建下图所示拓扑,完成相关 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 |
- 导入拓扑文件
- 查看抓包结果,分析OpenFlow协议中交换机与控制器的消息交互过程,画出相关交互图或流程图。
-
hello
-
6633->60146
-
60146->6633
-
Features Request
-
Set config
-
Port_Status
-
Features Reply
-
Packet_in
-
Flow_mod
-
Packet_out
-
消息交互图
- 回答问题:交换机与控制器建立通信时是使用TCP协议还是UDP协议?
交换机与控制器建立通信时使用TCP协议,从抓取得全部报文中可以看出。
(二)进阶要求
- 将抓包结果对照OpenFlow源码,了解OpenFlow主要消息类型对应的数据结构定义。
-
header
-
hello(结构体内只有一个header元素,header结构体格式↑,为版本号、消息类型、长度、ID)
-
Features Request(Features Request的结构同hello)
-
Set config(除header外增加了两个属性)
-
flags用来指示交换机如何处理 IP 分片数据包
-
miss_send_len用来指示当一个交换机无法处理的数据包到达时,将数据包发给控制器的最大字节数
-
Port_Status(在OpenFlow交换机中添加、删除或修改物理端口时,需要发送Port-Status 消息来通知OpenFlow 控制器)
-
Features Reply(除了header还包括唯一ID号、缓冲区可以缓存的最大数据包个数、流表数量、功能、动作、端口等)
-
Packet_in(发送该消息的原因有二:一、交换机流表中无匹配条目;二、有匹配的条目,但是其中所指示的 action 列表中包含转发给控制器的动作)
-
结构体中数据包括该数据包位于交换机缓冲区的ID、长度、进入端口号、数据包等
-
Flow_mod(包括流表项标志符cookie,command代表五种操作,对应值分别为0-4,优先级等)
-
Packet_out(包括动作列表、缓冲区ID等)
-
Flow-Mod 是指定一类数据包的处理方法(改的是流表项),而 Packet-Out 则是指定某一个数据包的处理方法
(三)个人总结
- 这次实验比前几次来的简单一点,按照PPT坐下来还是挺顺利的。但要是真的要把每一类消息的结构都查出来看一遍工作量也是不小,而且还有很多消息是实验没有提到的。有几个细节还是要注意的,比如先开wireshark、还有拓扑搭建的时候IP地址等。
- 在用wireshark抓包的时候如果按PPT上的用过滤器看OpenFlowv1.0的包的话是看不出用了TCP的,我也是想了好一会才反应过来,找了好久没找到一个用了TCP协议的。
- 进阶实验主要是通过看网上前辈们的博客了解的,对我来说一直对着全英文的文件看还是比较困难的,但有些地方总会有点错误,也需要对比筛查。
OpenFlow协议详解