SDN第三次上机实验

2021-09-20 13:03:47 阅读：180 来源： 互联网

标签：struct 上机 packet header ofp uint16 交换机 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

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

SDN第三次上机实验