SDN第三次上机实验

SDN第三次上机实验
一、实验目的
1. 能够运用 wireshark 对 OpenFlow 协议数据交互过程进行抓包；
2. 能够借助包解析工具，分析与解释 OpenFlow协议的数据包交互过程与机制。
二、实验要求
任务一
1. 将（一）中导出的拓扑文件存入目录：/home/用户名/学号/lab3/；
2 . 搭建下图所示拓扑，完成相关 IP 配置，并实现主机与主机之间的 IP 通信。用抓包软件获取控制器与交换机之间的通信数据包。

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

hello

Features Request/Set Conig

Port_Status

Features Reply

Packet_in

Flow_mod

Packet_out

  任务二  

回答问题：交换机与控制器建立通信时是使用TCP协议还是UDP协议？

交换机与控制器建立通信时是使用TCP协议
三、进阶任务
将抓包结果对照OpenFlow源码，了解OpenFlow主要消息类型对应的数据结构定义。
1、Hello包定义了一个header，header数据结构如下：

struct ofp_header {
uint8_t version; /* 版本号 /
uint8_t type; / Openflow 协议类型. /
uint16_t length; / Openflow 数据包包头. /
uint32_t xid; / 数据包编号. */
};
};
struct ofp_hello {
struct ofp_header header;
};

                                                                                                                                                      OFPT_ERROR

如果连接失败，会发送一个error包,error类型如下

enum ofp_error_type {
OFPET_HELLO_FAILED, /* Hello protocol failed. /
OFPET_BAD_REQUEST, / Request was not understood. /
OFPET_BAD_ACTION, / Error in action description. /
OFPET_FLOW_MOD_FAILED, / Problem modifying flow entry. /
OFPET_PORT_MOD_FAILED, / Port mod request failed. /
OFPET_QUEUE_OP_FAILED / Queue operation failed. */
};

OFPT_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. */ };

OFPT_PACKET_IN
OFPT_PACKET_IN产生的原因，一种是没匹配到流表，另一种是匹配到动作是转发的控制器，代码如下
enum ofp_packet_in_reason {
OFPR_NO_MATCH, /* No matching flow. / OFPR_ACTION / Action explicitly output to controller. */ };

OFPT_PACKET_IN的数据格式如下：
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. */
};

OFPT_PACKET_OUT
packet_in事件之后，会触发两类事件，packet_out和flow_mod。两者都是指导交换机如何处理数据包，区别是是否下发流表项。packet_out数据结构如下。
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.) */
};

OFPT_FLOW_MOD：控制器收到 Packet‐in 消息后，发送 Flow‐Mod 消息向交换机下发一个流表项。指导交换机转发数据包，数据格式如下：
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);
/ Why was this flow removed? /
enum ofp_flow_removed_reason {
OFPRR_IDLE_TIMEOUT, / Flow idle time exceeded idle_timeout. /
OFPRR_HARD_TIMEOUT, / Time exceeded hard_timeout. /
OFPRR_DELETE / Evicted by a DELETE flow mod. */
};

四、实验心得
本次的实验遇到的问题较多，例如：抓包时找不到hello包，我的解决方法是需要在打开mininet进行pingall之前打开wireshark，之后再进入any界面下找寻找两个hello，不然第一个hello包就会被未捕获丢失掉。因为一个是控制器发给交换机的可以检索openflow_v1找到，另一个hello是交换机发给控制器的。再就是进阶题目的问题较多，虽然是数据结构分析，但还是不太清楚，只能去网上查阅资料和请教同学，最后也只是把主要消息类型的代码理解了一点，还是希望老是可以再次讲解讲解，我可能会理解的更好。

标签：struct,上机,packet,header,ofp,uint16,交换机,SDN,第三次
来源： https://www.cnblogs.com/cwjainilyf1/p/15314082.html