2019 SDN上机第3次作业

1. 利用Mininet仿真平台构建如下图所示的网络拓扑，配置主机h1和h2的IP地址（h1:10.0.0.1，h2:10.0.0.2），测试两台主机之间的网络连通性

- 网络拓扑： - 测试主机连通性：

2. 利用Wireshark工具，捕获拓扑中交换机与控制器之间的通信数据，对OpenFlow协议类型的各类报文（hello, features_request, features_reply, set_config, packet_in, packet_out等）进行分析，对照wireshark截图写出你的分析内容。

需要先运行抓包工具然后选择any后再进行拓扑连接

• Hello：
  控制器与交换机建立连接时由其中某一方发起Hello消息，双方协调协议版本号。
  控制器6633端口 ---> 交换机50120端口
  
  交换机50120端口 ---> 控制器6633端口
  
  于是双方建立连接，并使用OpenFlow 1.0

• Features Request
  OpenFlow 连接建立之后，控制器就会向交换机发送一个ofpt_feature_request消息。
  控制器6633端口（我需要你的特征信息） ---> 交换机50120端口
  

• Set Config
  控制器让交换机按自己设置的flag和 max bytes of packet进行配置。
  控制器6633端口（请按照我给你的flag和max bytes of packet进行配置） ---> 交换机50120端口
  

• Features Reply
  交换机50120端口（这是我的特征信息，请查收）--- 控制器6633端口
  
  Features 消息包括 OpenFlow Header 和 Features Reply Message
  对照Features Reply Message结构

struct ofp_switch_features{
    struct ofp_header header;
    uint64_t datapath_id; /*唯一标识 id 号*/
    uint32_t n_buffers; /*交缓冲区可以缓存的最大数据包个数*/
    uint8_t n_tables; /*流表数量*/
    uint8_t pad[3]; /*align to 64 bits*/
    uint32_t capabilities; /*支持的特殊功能，具体见 ofp_capabilities*/
    uint32_t actions; /*支持的动作，具体见 ofp_actions_type*/
    struct ofp_phy_port ports[0]; /*物理端口描述列表，具体见 ofp_phy_port*/
};

对应到抓取到的报文，逐项查看报文内容

• Packet_in:
  当交换机碰到新数据包不知道如何处理，或者action要求发送给控制器，那么交换机就会用packet_in消息发送给控制器。
  交换机50134端口（有数据包进来，请指示）--- 控制器6633端口
  
  结合Packet_in的结构

struct ofp_packet_in {
    struct ofp_header header;
    uint32_t buffer_id; /*Packet-in消息所携带的数据包在交换机缓存区中的ID*/
    uint16_t total_len; /*data字段的长度*/
    uint16_t in_port; /*数据包进入交换机时的端口号*/
    uint8_t reason; /*发送Packet-in消息的原因，具体见 ofp_packet_in_reason*/
    uint8_t pad;
    uint8_t data[0]; /*携带的数据包*/
};

分析抓取的数据包，可以发现是因为交换机发现此时自己并没有匹配的流表（Reason: No matching flow (table-miss flow entry) (0)），所以要问控制器如何处理

• Packet_out
  当控制器希望交换机发送某个数据包或指定一个数据包的处理方法时，就使用packet_out。
  控制器6633端口（请按照我给你的action进行处理） ---> 交换机50134端口
  
  结合Packet_out的结构

struct ofp_packet_out {
    struct ofp_header header;
    uint32_t buffer_id; /*交换机缓存区id，如果为-1则指定的为packet-out消息携带的data字段*/
    uint16_t in_port; /*如果buffer_id为‐1，并且action列表中指定了Output=TABLE的动作,in_port将作为data段数据包的额外匹配信息进行流表查询*/
    uint16_t actions_len; /*action列表的长度，可以用来区分actions和data段*/
    struct ofp_action_header actions[0]; /*动作列表*/
    uint8_t data[0]; /*数据缓存区，可以存储一个以太网帧，可选*/
}

告诉输出到交换机的65531端口

h1 ping h2

• packet_in
  

• flow_mod
  结合flow_mod结构

struct ofp_flow_mod {
    struct ofp_header header;
    struct ofp_match match; /*流表的匹配域*/ 
    uint64_t cookie; /*流表项标识符*/
    uint16_t command; /*可以是ADD,DELETE,DELETE-STRICT,MODIFY,MODIFY-STRICT*/
    uint16_t idle_timeout; /*空闲超时时间*/
    uint16_t hard_timeout; /*最大生存时间*/
    uint16_t priority; /*优先级，优先级高的流表项优先匹配*/
    uint32_t buffer_id; /*缓存区ID ,用于指定缓存区中的一个数据包按这个消息的action列表处理*/  
    uint16_t out_port; /*如果这条消息是用于删除流表则需要提供额外的匹配参数*/
    uint16_t flags; /*标志位，可以用来指示流表删除后是否发送flow‐removed消息，添加流表时是否检查流表重复项，添加的流表项是否为应急流表项。*/
    struct ofp_action_header actions[0]; /*action列表*/
};

分析抓取的flow_mod数据包，控制器通过6633端口向交换机50120端口、交换机50134端口下发流表项，指导数据的转发处理

PS.把控制器从openflow reference改成ovs controller

最后协商以1.3的openflow来进行通信