实验3：OpenFlow协议分析实践

实验基础要求：
a) 基础要求只需要提交导入到/home/用户名/学号/lab3/目录下的拓扑文件；

b) wireshark抓包的结果截图和对应的文字说明；
1.hello
控制器6633端口 (hello报文)<---> 交换机45262端口（hello报文），双方建立连接，并使用OpenFlow 1.0

2.Features Request
控制器6633端口 (Features Request报文)---> 交换机45262端口，请求对方特征信息

3.Features Reply
控制器6633端口 <--- 交换机45262端口 (Features Reply报文)，交换机回应控制器Features Request报文，发送自己的特征信息

4.Set Conig
控制器6633端口 (Set Conig报文)---> 交换机45262端口，提示对方按照报文的config flag和max bytes of packet进行配置

5.Port_Status
控制器6633端口 <--- 交换机45262端口 (Port_Status报文)，交换机告知控制器发生变化的端口状态

6.Packet_in
有两种情况：
交换机查找流表，发现没有匹配条目时
有匹配条目但是对应的action是OUTPUT=CONTROLLER时
控制器6633端口 <--- 交换机45262端口 (Packet_in报文)，交换机向控制器询问如何处理没有匹配自身流表信息的数据包

7.Packet_out
控制器6633端口(Packet_out报文) ---> 交换机45262端口 ，控制器回应交换机Packet_in报文，按照我给你的action信息进行处理

8.Flow_mod
控制器6633端口(Flow_mod报文) ---> 交换机45262端口 ，控制器给交换机下发流表项，指导数据的转发处理

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

使用TCP协议

d) 相关交互图

进阶要求：

有完成的同学请提交相关截图对应的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. */
};
struct ofp_hello {
struct ofp_header header;
};

2.Features Request

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

3.Features Reply

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. /
};
/ Description of a physical port /
struct ofp_phy_port {
uint16_t port_no;//标明绑定到物理接口的datapath值
uint8_t hw_addr[OFP_ETH_ALEN];//该物理接口的mac 地址
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. */
};

4.Set Conig

enum ofp_config_flags {
/* Handling of IP fragments. /
OFPC_FRAG_NORMAL = 0, / No special handling for fragments. /
OFPC_FRAG_DROP = 1, / Drop fragments. /
OFPC_FRAG_REASM = 2, / Reassemble (only if OFPC_IP_REASM set). */
OFPC_FRAG_MASK = 3
};

/* Switch configuration. /
struct ofp_switch_config {
struct ofp_header header;
uint16_t flags; / OFPC_* flags. / //flag不同的值代表不同的处理方式
uint16_t miss_send_len; / Max bytes of new flow that datapath should
send to the controller. */
};
OFP_ASSERT(sizeof(struct ofp_switch_config) == 12);

5.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;
};
OFP_ASSERT(sizeof(struct ofp_port_status) == 64); //发生变化，则需发送port status来告知

6.Packet_in
a）交换机查找流表，发现没有匹配条目时
b）有匹配条目但是对应的action是OUTPUT=CONTROLLER时

enum ofp_packet_in_reason {
OFPR_NO_MATCH, /* No matching flow. /
OFPR_ACTION / Action explicitly output to 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.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; / action列表长度Size of action array in bytes. /
struct ofp_action_header actions[0]; / action列表Actions. /
/ uint8_t data[0]; / / Packet data. The length is inferred
from the length field in the header.
(Only meaningful if buffer_id == -1.) */
};

8.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; / 标识缓存中的数据包IDBuffered 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]; / action列表The action length is inferred
from the length field in the
header. /
};
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];
};

（三）个人总结
在做的过程中由于不大熟悉命令有所卡顿，这个实验主要是抓包分析OpenFlow通讯过程数据包。对wireshark工具使用更加熟练，通过抓包的结果进行观察与学习，了解OpenFlow主要消息类型对应的数据结构定义。当流表中没有关于新到达流的数据包或者即使有关于新到达流的流规则但其行为是发往控制器的时候，交换机向控制器发送Packet In消息。抓不到Hello包、Port-status包或Set-config包，可能是先运行了拓扑，然后才开WireShark抓的包。因为这几个包只在控制器和交换机刚建立链接的时候发送，因此先完设备还没开Wirshark抓包时，设备就已经建立了连接。