实验3:OpenFlow协议分析实践
一、实验目的
- 能够运用 wireshark 对 OpenFlow 协议数据交互过程进行抓包;
- 能够借助包解析工具,分析与解释 OpenFlow协议的数据包交互过程与机制。
二、实验环境
Ubuntu 20.04 Desktop amd64
三、实验要求
(一)基本要求
- 搭建下图所示拓扑,完成相关 IP 配置,并实现主机与主机之间的 IP 通信。用抓包软件获取控制器与交换机之间的通信数据。
- 建立topo图
![]()
- 设置ip
![]()
- 查看抓包结果,分析OpenFlow协议中交换机与控制器的消息交互过程,画出相关交互图或流程图。
-
Hello 控制器6633端口(支持Open Flow1.0) ---> 交换机54892端口
![]()
-
交换机54892端口(支持Open Flow1.5)---> 控制器6633端口
![]()
OFPT_HELLO后,双方建立连接使用openflow1.0协议,HELLO就是使用来协商控制器和交换机之间openflow协议的版本号的消
息。
-
FEATURES_REQUEST 从控制器6633端口到交换机54892端口,请求特征信息,如交换机ID,缓冲区数量,端口及端口属性等。
![]()
-
FEATURES_REPLY 交换机54892端口到控制器6633端口,回复特征信息
![]()
-
SET_CONFIG 控制器6633端口到交换机54892端口,配置交换机的 MTU,报文分片处理等。
![]()
-
PORT_STATUS 从交换机54892端口到控制器6633端口当交换机端口发生变化时,告知控制器相应的端口状态
![]()
-
PACKET_IN 交换机54892端口到控制器6633端口(有数据包进来,请指示)。当交换机遇到不知道如何转发的报文时,使用 Packet_IN 消息将无法处理的报文封装起来发送给控制器,交给控制器去判断处理。并且交换机会将该数据包缓存。
![]()
-
PACKET_OUT 控制器6633端口到交换机54892端口(请按照我给你的action进行处理),告诉交换机某一个数据包如何处理。
![]()
-
FLOW_MOD 分析抓取的flow_mod数据包,控制器通过6633端口向交换机54892端口、交换机54892端口下发流表项,指导数据的转发处理,对流表有添加、删除、变更设置等操作。
![]()
-
交互图
![]()
3.回答问题:交换机与控制器建立通信时是使用TCP协议还是UDP协议?
是TCP协议
(二)进阶要求
- 将抓包基础要求第2步的抓包结果对照OpenFlow源码,了解OpenFlow主要消息类型对应的数据结构定义。
-
hello
![]()
![]()
0x01代表版本1,即 openflow1.0。Type类型为 HELLO,表示为0。
可以看到对应了HELLO报文的四个参数与之一一对应 -
FEATURES_REQUEST
![]()
Type类型为 FEATURE_REQUEST,标识为5,Length 代表消息长度,除去消息报头。
源码参数格式与HELLO相同,与上述ofp_header结构体中数据相同 -
SET_CONFIG
![]()
![]()
4.PORT_STATUS


5.FEATURES_REPLY


Datapath id 数据通道标识符,用来表示交换机的身份。在每一个控制器中独一无二。n_buffers 一次最多缓存的数据包数量,即交换机自己的缓存能力。
n_tables 表示交换机支持的流表数量。actions 该bitmask表示交换机所支持的 actions,有转发和修改包头两种。
-
PACKET_IN
Reason表示packet-in事件的产生原因,分为两种:OFPR_NO_MATCH和OFPR_ACTION。
1.交换机查找流表,发现没有匹配条目,但是这种包没有抓到过
2.有匹配条目,对应的action是OUTPUT=CONTROLLER,固定收到向控制器发送包
struct ofp_packet_in { struct ofp_header header; uint32_t buffer_id; /* ID assigned by datapath. */ uint16_t total_len; /* Full length of frame. */ uint16_t in_port; /* Port on which frame was received. */ uint8_t reason; /* Reason packet is being sent (one of OFPR_*) */ uint8_t pad; uint8_t data[0]; /* Ethernet frame, halfway through 32-bit word, so the IP header is 32-bit aligned. The amount of data is inferred from the length field in the header. Because of padding, offsetof(struct ofp_packet_in, data) == sizeof(struct ofp_packet_in) - 2. */ };
![]()
-
PACKET_OUT
![]()
![]()
In port 数据包进入交换机的入端口号。Actions length 动作信息的长度。 -
FLOW_MOD
![]()
![]()
Command 表示flow-mod消息的动作。一共五种,实现对流表的增、删、改操作。
(三)个人总结
1.实验收获
本次实验比较简单。通过这次实验,可以学会了如何使用wireshark、如何进行数据包过滤、怎么查看并分析数据包的的流动过程,并且可以了解在pingall的过程中有哪些包产生并且如何传递。在进阶实验中,查看openflow源码并与抓包结果进行比对的过程中,同时了解在openflow中主要消息类型对应的数据结构定义。
2.实验中途遇到的问题
- 先开wireshark进行抓包,结果收不到hello的消息。后来重新看pdf才知道要先建立topo再抓包。
- 找不到54892端口发给6633的hello报文,通过将过滤条件设置为openflow_v6得以解决。
3.实验总结
通过本次实验,综合锻炼了耐心和阅读能力,同时对openflow的运行机制有了更好的理解。




















浙公网安备 33010602011771号