-
实验3:OpenFlow协议分析实践
-
一、实验目的
能够运用 wireshark 对 OpenFlow 协议数据交互过程进行抓包;
能够借助包解析工具,分析与解释 OpenFlow协议的数据包交互过程与机制。 -
二、实验环境
Ubuntu 20.04 Desktop amd64 -
三、实验要求
-
(一)基本要求
-
搭建下图所示拓扑,完成相关 IP 配置,并实现主机与主机之间的 IP 通信。用抓包软件获取控制器与交换机之间的通信数据
-
hello
-
控制器6633端口(我最高能支持OpenFlow 1.0) ---> 交换机42736端口
- 交换机42736端口(我最高能支持OpenFlow 1.5) ---> 控制器6633端口
- Features Request:控制器6633端口(我需要你的特征信息) ---> 交换机42736端口
- Set Conig:控制器6633端口(请按照我给你的flag和max bytes of packet进行配置) ---> 交换机42736端口
- Port_Status:当交换机端口发生变化时,告知控制器相应的端口状态
- Features Reply:交换机42736端口(这是我的特征信息,请查收) ---> 控制器6633端口
- Packet_in
- Packet_out
- Flow_mod:分析抓取的flow_mod数据包,控制器通过6633端口向交换机42736端口、交换机60028端口下发流表项,指导数据的转发处理
- 2、查看抓包结果,分析OpenFlow协议中交换机与控制器的消息交互过程,画出相关交互图或流程图。
-
3、回答问题:交换机与控制器建立通信时是使用TCP协议还是UDP协议?
TCP协议。 -
(二)进阶要求
将抓包基础要求第2步的抓包结果对照OpenFlow源码,了解OpenFlow主要消息类型对应的数据结构定义。 -
openflow数据包头通用格式
/* Header on all OpenFlow packets. */ struct ofp_header { uint8_t version; /* OFP_VERSION. */ uint8_t type; /* One of the OFPT_ constants. */ uint16_t length; /* Length including this ofp_header. */ uint32_t xid; /* Transaction id associated with this packet. Replies use the same id as was in the request to facilitate pairing. */ };
-
1、OFPT_HELLO
`OFP_ASSERT(sizeof(struct ofp_header) == 8);
/* OFPT_HELLO. This message has an empty body, but implementations must
- ignore any data included in the body, to allow for future extensions. */
struct ofp_hello {
struct ofp_header header;
};
`
- 2、OFPT FEATURES REQUES
struct ofp_stats_request { struct ofp_header header; uint16_t type; /* One of the OFPST_* constants. */ uint16_t flags; /* OFPSF_REQ_* flags (none yet defined). */ uint8_t body[0]; /* Body of the request. */ };
- 3、Set Config
/* Switch configuration. */ struct ofp_switch_config { struct ofp_header header; uint16_t flags; /* OFPC_* flags. */ uint16_t miss_send_len; /* Max bytes of new flow that datapath should send to the controller. */ };
- 4、Port_Status
/* A physical port has changed in the datapath */ struct ofp_port_status { struct ofp_header header; uint8_t reason; /* One of OFPPR_*. */ uint8_t pad[7]; /* Align to 64-bits. */ struct ofp_phy_port desc; };
- 5、OFPT_FEATURES REPLY
`struct ofp_stats_reply {
struct ofp_header header;
uint16_t type; /* One of the OFPST_* constants. /
uint16_t flags; / OFPSF_REPLY_* flags. /
uint8_t body[0]; / Body of the reply. */
};
OFP_ASSERT(sizeof(struct ofp_stats_reply) == 12);
define DESC_STR_LEN 256
define SERIAL_NUM_LEN 32
/* Body of reply to OFPST_DESC request. Each entry is a NULL-terminated
- ASCII string. /
struct ofp_desc_stats {
char mfr_desc[DESC_STR_LEN]; / Manufacturer description. /
char hw_desc[DESC_STR_LEN]; / Hardware description. /
char sw_desc[DESC_STR_LEN]; / Software description. /
char serial_num[SERIAL_NUM_LEN]; / Serial number. /
char dp_desc[DESC_STR_LEN]; / Human readable description of datapath. */
};
OFP_ASSERT(sizeof(struct ofp_desc_stats) == 1056);
/* Body for ofp_stats_request of type OFPST_FLOW. /
struct ofp_flow_stats_request {
struct ofp_match match; / Fields to match. /
uint8_t table_id; / ID of table to read (from ofp_table_stats),
0xff for all tables or 0xfe for emergency. /
uint8_t pad; / Align to 32 bits. /
uint16_t out_port; / Require matching entries to include this
as an output port. A value of OFPP_NONE
indicates no restriction. */
};
OFP_ASSERT(sizeof(struct ofp_flow_stats_request) == 44);
`
- 6、Packet_In
`/* Why is this packet being sent to the controller? /
enum ofp_packet_in_reason {
OFPR_NO_MATCH, / No matching flow. /
OFPR_ACTION / Action explicitly output to controller. */
};
/* Packet received on port (datapath -> 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. */
};
OFP_ASSERT(sizeof(struct ofp_packet_in) == 20);
`
-
7、Flow_Mod
`/* Flow setup and teardown (controller -> datapath). /
struct ofp_flow_mod {
struct ofp_header header;
struct ofp_match match; / Fields to match /
uint64_t cookie; / Opaque controller-issued identifier. *//* Flow actions. /
uint16_t command; / One of OFPFC_. /
uint16_t idle_timeout; / Idle time before discarding (seconds). /
uint16_t hard_timeout; / Max time before discarding (seconds). /
uint16_t priority; / Priority level of flow entry. /
uint32_t buffer_id; / Buffered packet to apply to (or -1).
Not meaningful for OFPFC_DELETE. /
uint16_t out_port; / For OFPFC_DELETE* commands, require
matching entries to include this as an
output port. A value of OFPP_NONE
indicates no restriction. /
uint16_t flags; / One of OFPFF_*. /
struct ofp_action_header actions[0]; / The action length is inferred
from the length field in the
header. */
};
OFP_ASSERT(sizeof(struct ofp_flow_mod) == 72);
`
-
(三)实验总结
首先实验过程中要先启动wireshark之后在执行python文件,不然的话hello包一直出不来,我在这个地方卡了很久,问了群里的人才知道要先启动wireshark,然后要执行pingall命令,否则会导致一些包丢失,像flow mod 包就一直找不到,还是得问同学才能找到实验中细节的地方。在进行拓扑实验时要清除之前的拓扑结构,不然运行不了新构建的拓扑。跟着老师的实验报告还是能写出大部分的实验内容。
进阶实验了解OpenFlow协议的数据包交互过程与机制并且通过对照源码,更加了解了OpenFlow主要消息类型的数据结构,能够直观的认识到不同类型的数据报的组成,以及各字段所代表的意义和作用。