引言
随着软件定义网络（SDN）技术的快速发展，OpenFlow作为SDN架构中的核心协议之一，其重要性不言而喻。本次实践，我深入了解了OpenFlow协议的基本原理、报文结构和应用场景，并通过实际的分析和实验，加深了对该协议的理解。
一、实验目的
1.能够运用 wireshark 对 OpenFlow 协议数据交互过程进行抓包；
2.能够借助包解析工具，分析与解释 OpenFlow协议的数据包交互过程与机制。
二、实验环境
1.下载虚拟机软件Oracle VisualBox；
2.在虚拟机中安装Ubuntu 20.04 Desktop amd64，并完整安装Mininet；
三、实验要求
理论学习：我首先阅读了OpenFlow协议的官方文档和相关资料，了解了OpenFlow协议的基本原理、报文结构、工作流程等。
环境搭建：为了进行实践分析，我搭建了一个基于OpenFlow的SDN网络环境，包括控制器（如OpenDaylight或Ryu）、交换机（如Open vSwitch）和终端设备。
报文分析：我使用网络抓包工具（如Wireshark）对OpenFlow协议报文进行了捕获和分析。通过观察报文的格式、字段和交互过程，我更加深入地理解了OpenFlow协议的工作原理
（一）基本要求
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地址
2.查看抓包结果，分析OpenFlow协议中交换机与控制器的消息交互过程，画出相关交互图或流程图。
（1）Hello
- 控制器6633端口（我最高能支持OpenFlow 1.0） ---> 交换机39280端口
- 交换机39286端口（我最高能支持OpenFlow 1.5）--- 控制器6633端口
- 于是双方建立连接，并使用OpenFlow 1.0
（2）Features Request / Set Conig
- 控制器6633端口（我需要你的特征信息） ---> 交换机39280端口
- 控制器6633端口（请按照我给你的flag和max bytes of packet进行配置） ---> 交换机39280端口
- flag：指示交换机如何处理 IP 分片数据包
- max bytes of packet：当交换机无法处理到达的数据包时，向控制器发送如何处理的最大字节数，本实验中控制器发送的值是0x0080，即128字节。
（3）Port_Status
- 当交换机端口发生变化时，告知控制器相应的端口状态。
（4）Features Reply
- 交换机39280端口（这是我的特征信息，请查收）--- 控制器6633端口
（5）Packet_in
- 有两种情况：
- 交换机查找流表，发现没有匹配条目时
- 有匹配条目但是对应的action是OUTPUT=CONTROLLER时
- 交换机56346端口（有数据包进来，请指示）--- 控制器6633端口
- 分析抓取的数据包，可以发现是因为交换机发现此时自己并没有匹配的流表（Reason: No matching flow (table-miss flow entry) (0)），所以要问控制器如何处理
（6）Flow_mod
- 分析抓取的flow_mod数据包，控制器通过6633端口向交换机56354端口、交换机56346端口下发流表项，指导数据的转发处理
- 分析抓取的flow_mod数据包，控制器通过6633端口向交换机56354端口、交换机56346端口下发流表项，指导数据的转发处理
（7）Packet_out
- 控制器6633端口（请按照我给你的action进行处理） ---> 交换机56346端口
（8）交互图
3.回答问题：交换机与控制器建立通信时是使用TCP协议还是UDP协议？
分析wireshark抓包，可以看出交换器与控制器建立通信时使用的是TCP协议。
(二)进阶要求
1.将抓包结果对照OpenFlow源码，了解OpenFlow主要消息类型对应的数据结构定义。
(1)Hello
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. */
};/* 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)Features Request
- 与Hello中的数据格式相同
(3)Set Conig
/* 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)Features Reply
/* Description of a physical port */
struct ofp_phy_port {
uint16_t port_no; uint8_t hw_addr[OFP_ETH_ALEN]; char name[OFP_MAX_PORT_NAME_LEN]; /* Null-terminated */ uint32_t config; /* Bitmap of OFPPC_* flags. */ uint32_t state; /* Bitmap of OFPPS_* flags. */ /* Bitmaps of OFPPF_* that describe features. All bits zeroed if * unsupported or unavailable. */
uint32_t curr; /* Current features. */ uint32_t advertised; /* Features being advertised by the port. */ uint32_t supported; /* Features supported by the port. */ uint32_t peer; /* Features advertised by peer. */};/* Switch features. */
struct ofp_switch_features {
struct ofp_header header; uint64_t datapath_id; /* Datapath unique ID. The lower 48-bits are for a MAC address, while the upper 16-bits are
implementer-defined. */
uint32_t n_buffers; /* Max packets buffered at once. */ uint8_t n_tables; /* Number of tables supported by datapath. */ uint8_t pad[3]; /* Align to 64-bits. */ /* Features. */ uint32_t capabilities; /* Bitmap of support "ofp_capabilities". */ uint32_t actions; /* Bitmap of supported "ofp_action_type"s. */ /* Port info.*/ struct ofp_phy_port ports[0]; /* Port definitions. The number of ports is inferred from the length field in
the header. */
};- 对应
(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. */
};- 对应
(7)Flow_mod
/* Fields to match against flows */
struct ofp_match {
uint32_t wildcards; /* Wildcard fields. */ uint16_t in_port; /* Input switch port. */ uint8_t dl_src[OFP_ETH_ALEN]; /* Ethernet source address. */ uint8_t dl_dst[OFP_ETH_ALEN]; /* Ethernet destination address. */ uint16_t dl_vlan; /* Input VLAN id. */ uint8_t dl_vlan_pcp; /* Input VLAN priority. */ uint8_t pad1[1]; /* Align to 64-bits */ uint16_t dl_type; /* Ethernet frame type. */ uint8_t nw_tos; /* IP ToS (actually DSCP field, 6 bits). */ uint8_t nw_proto; /* IP protocol or lower 8 bits of * ARP opcode. */
uint8_t pad2[2]; /* Align to 64-bits */ uint32_t nw_src; /* IP source address. */ uint32_t nw_dst; /* IP destination address. */ uint16_t tp_src; /* TCP/UDP source port. */ uint16_t tp_dst; /* TCP/UDP destination port. */};/* 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. */
};- 对应
(8)Packet_out
/* Action header that is common to all actions. The length includes the
* header and any padding used to make the action 64-bit aligned.
* NB: The length of an action *must* always be a multiple of eight. */
struct ofp_action_header {
uint16_t type; /* One of OFPAT_*. */ uint16_t len; /* Length of action, including this header. This is the length of action,
including any padding to make it
64-bit aligned. */
uint8_t pad[4];};OFP_ASSERT(sizeof(struct ofp_action_header) == 8);
/* Send packet (controller -> datapath). */
struct ofp_packet_out {
struct ofp_header header; uint32_t buffer_id; /* ID assigned by datapath (-1 if none). */ uint16_t in_port; /* Packet's input port (OFPP_NONE if none). */ uint16_t actions_len; /* Size of action array in bytes. */ struct ofp_action_header actions[0]; /* Actions. */ /* uint8_t data[0]; */ /* Packet data. The length is inferred from the length field in the header.
(Only meaningful if buffer_id == -1.) */
};- 对应
四、个人总结
实践成果
加深了对OpenFlow协议的理解：通过实践分析，我更加深入地理解了OpenFlow协议的基本原理和工作机制，掌握了报文的格式和字段含义。
提高了网络编程能力：在编写控制器应用程序的过程中，我提高了自己的网络编程能力，熟悉了SDN网络编程的基本流程和技巧。
锻炼了分析问题和解决问题的能力：在实验过程中，我遇到了许多问题，但通过查阅资料和不断尝试，我最终解决了这些问题，锻炼了自己的分析问题和解决问题的能力。
体会与感悟
通过这次实践，我深刻体会到了OpenFlow协议在SDN技术中的重要作用和广泛应用前景。同时，我也认识到网络编程的复杂性和挑战性，需要不断学习和实践才能不断提高自己的能力。
未来展望
未来，我将继续关注SDN技术和OpenFlow协议的发展动态，不断学习和探索新的技术和应用。同时，我也将积极参与相关的科研和工程项目，为网络技术的发展贡献自己的力量。
扫一扫
1309
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
