实验3：OpenFlow协议分析实践

• 实验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主要消息类型的数据结构，能够直观的认识到不同类型的数据报的组成，以及各字段所代表的意义和作用。