首页 > 其他 > 详细

OpenFlow协议分析实践

时间:2021-09-20 23:13:33      阅读:7      评论:0      收藏:0      [点我收藏+]

实验3:OpenFlow协议分析实践

一、实验目的

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

二、实验环境

  1. 下载虚拟机软件Oracle VisualBox;
  2. 在虚拟机中安装Ubuntu 20.04 Desktop amd64,并完整安装Mininet;

三、实验要求

(一)基本要求

  1. 搭建下图所示拓扑,完成相关 IP 配置,并实现主机与主机之间的 IP 通信。用抓包软件获取控制器与交换机之间的通信数据包。
    技术分享图片
主机IP地址
h1 192.168.0.101/24
h2 192.168.0.102/24
h3 192.168.0.103/24
h4 192.168.0.104/24

技术分享图片

 

 

    1. 任务二:
    2. 查看抓包结果,分析OpenFlow协议中交换机与控制器的消息交互过程,画出相关交互图或流程图。
    3. 交互图
    4. 技术分享图片
    5. Hello:

      首先,控制器与交互及互相发送 Hello 消息技术分享图片

       

       

      Features Request:

      其次,OpenFlow 连接建立之后,控制器向交换机发送 Features Request 消息查询交换机特性技术分享图片

       

       

      Features Reply

      交换机在收到控制器发出的 Features Request 消息后,将自己的特性告诉给控制器,返回 Features Request 消息技术分享图片

       

       

      Set config

      知道了交换机的特性之后就要配置交换机了技术分享图片

       

      Packet-in

      • 1.数据包在交换机中匹配不到流表,则向controller发送Packet_in消息
      • 2.数据包在流表中有匹配的条目,但是其中所指示的 action 列表中包含转发给控制器的动作(Output = CONTROLLER)技术分享图片

         

         

        Flow-Mod / Packet-out

        当控制器收到 Packet-in 消息时有两种响应的方式:
            1.Flow-Mod:控制器收到 Packet‐in 消息后,可以发送 Flow‐Mod 消息向交换机下发一个流表项
            2.Packet-out:与Flow-Mod不同的是,控制器不会下发流表,而是直接告诉交换机该如何做技术分享图片

         

         

       

      1. 回答问题:交换机与控制器建立通信时是使用TCP协议还是UDP协议?     答:tcp协议!  

        进阶任务

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

          OFPT_Hello

          Hello包定义了一个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

          OFPT_FEATURES 主要是请求交换机的特性
          交换机的特性数据结构定义:

        2. 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产生的原因有两种,一种是没匹配到流表,另一种是匹配到了,动作是转发的控制器
          代码

        3. :enum ofp_packet_in_reason {
              OFPR_NO_MATCH,          /* No matching flow. */
              OFPR_ACTION             /* Action explicitly output to controller. */
          };数据格式

        4. :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. */

        5. OFPT_PACKET_OUT

          packet_in事件之后,一般会触发两类事件,packet_out和flow_mod。两者都是指导交换机如何处理数据包,区别是是否下发流表项
          数据结构

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

        7. 实验总结:本次实验难度相对较小,但是对于刚刚开始实验的时候对于wireshark中找不到hello是相当的难受,经过对同学博客上的有相同问题的解决办法还是有一定的帮助,但是还是找不到hello,最后还是陈诗文同学的帮助下,才成功的找到需要的截图,本次实验自我有很好的掌握了wireshark,懂得一些基础的分析,懂得了一些东西,同时对于进阶实验的东西多少有些了解,参考了有书写进阶任务的同学的资料,还是学到了一些东西。谢谢老师同学的材料

OpenFlow协议分析实践

原文:https://www.cnblogs.com/chenqing123/p/15309053.html

(0)
(0)
   
举报
评论 一句话评论(0
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!