实验3：OpenFlow协议分析实践

一、实验目的

• 能够运用 wireshark 对 OpenFlow 协议数据交互过程进行抓包；
• 能够借助包解析工具，分析与解释 OpenFlow协议的数据包交互过程与机制。

二、实验环境

• 下载虚拟机软件Oracle VisualBox；
• 在虚拟机中安装Ubuntu 20.04 Desktop amd64，并完整安装Mininet；

三、实验要求

（一）基本要求

• 搭建下图所示拓扑，完成相关 IP 配置，并实现主机与主机之间的 IP 通信。用抓包软件获取控制器与交换机之间的通信数据包。
  
  • 执行导出的拓扑结构并进行连通性测试
    
• 查看抓包结果，分析OpenFlow协议中交换机与控制器的消息交互过程，画出相关交互图或流程图。
  • hello报文抓包结果
    • 控制器6633端口给交换机43790端口，并告诉对方最高支持OpenFlow 1.0
      
    • 交换机43790端口给控制器6633端口，并告诉对方最高支持OpenFlow 1.3
      
    • 双方顺利建立连接，并使用OpenFlow 1.0
  • Features Request报文抓包结果
    • 控制器6633端口给交换机43790端口，并告诉对方需要对方的特征信息
      
  • Features Reply报文抓包结果
    • 交换机43790端口给控制器6633端口，并告诉对方自己的特征信息
      
  • Set Config报文抓包结果
    • 控制器6633端口给交换机43790端口，并告诉对方按照我给你的flag和max bytes of packet进行配置
      
  • Port_Status报文抓包结果
    • 交换机43790端口给控制器6633端口，并告速对方相应的端口状态
      
  • Packet_in报文抓包结果
    • 交换机43790端口给控制器6633端口，并询问对方如何处理，从reason上看是因为交换机发现此时自己并没有匹配的流表
      
  • Packet_out报文抓包结果
    • 控制器6633端口给交换机43790端口, 并告诉对方输出到交换机的65531端口
      
  • Flow_mod报文抓包结果
    • 控制器6633端口向交换机43788端口、43790端口下发流表项，指导数据的转发处理
      
      
  • 交互图
    
• 回答问题：交换机与控制器建立通信时是使用TCP协议还是UDP协议？
  从wireshark的抓包结果可知，交换机与控制器建立通信时使用TCP协议

（二）进阶要求

将抓包结果对照OpenFlow源码，了解OpenFlow主要消息类型对应的数据结构定义。

• hello
  • 源码中定义了一个header,对照抓包结果可看出包括版本号，类型，长度以及ID

         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;
         };

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

• Set config
  • 源码中定义了flags及miss_send_len，用来指示交换机如何处理 IP 分片数以及向控制器发送如何处理的最大字节数据包

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

• PACKET_IN
  • 源码中reason指明产生缘由一种是没匹配到流表，二是是匹配到了，但action 列表中包含转发给控制器的动作

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

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

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

三、个人总结

• 实验难度
  这次试验有之前两次实验打基础做下来还是比较顺畅的，老师的pdf基本上解决了大部分问题
• 实验困难及解决办法
  • 最开始做的时候没有注意到老师pdf中先抓包再建拓扑的重要提示，导致建完拓扑抓包没抓到什么东西，重新阅读要求后按步骤来解决了这个问题
  • 阅读互联网上经验博客时发现在建立拓扑时IP可以设置基准值，方便了配置操作
  • 阅读源码还是有困难的，也是参照互联网上的经验博客来一步步地对照消息类型对应的数据结构
• 个人感想
  这次试验进一步锻炼了使用wireshark的能力，能做到设置过滤条件并分析数据包内容，同时对openflow的机制了解比之前更深入一点，了解了该协议数据包交互过程与机制，还是非常有收获的