首页 > 其他分享 >实验3:OpenFlow协议分析实践

实验3:OpenFlow协议分析实践

时间:2022-10-09 13:47:28浏览次数:56  
标签:OFPT struct OpenFlow 实践 header ofp 交换机 实验 message

一、实验目的
能够运用 wireshark 对 OpenFlow 协议数据交互过程进行抓包;
能够借助包解析工具,分析与解释 OpenFlow协议的数据包交互过程与机制。
二、实验环境
Ubuntu 20.04 Desktop amd64
三、实验要求
(一)基本要求
1.搭建下图所示拓扑,完成相关 IP 配置,并实现主机与主机之间的 IP 通信。用抓包软件获取控制器与交换机之间的通信数据。

2.查看抓包结果,分析OpenFlow协议中交换机与控制器的消息交互过程,画出相关交互图或流程图
控制器6633端口(我最高能支持OpenFlow 1.0) ---> 交换机50846端口

交换机50846端口(我最高能支持OpenFlow 1.5) ---> 控制器6633端口

双方建立连接,使用OpenFlow1.0
Features Request:控制器向将交换机发送Featrues Request消息,获取交换机特征信息
控制器6633端口---> 交换机50846端口

Set Conig:控制器告诉交换机如何配置
控制器6633端口---> 交换机50846端口

Port_Status:当交换机端口发生变化时,告知控制器相应的端口状态
交换机50846端口--->控制器6633端口
第一次抓包未出现port,做完之后重新抓了一次,所以端口号发生了变化

Features Reply:Featrues Request的回复的交换机的特征信息
交换机50846端口---> 控制器6633端口

Packet_in:交换机收到数据包后问控制器如何处理
有两种情况会触发交换机向控制器发送 Packet-in 消息:
1.当交换机收到一个数据包后,查找流表。如果流表中有匹配条目,则交换机按照流表所指示的 action 列表处理数据包。如果没有,则交换机将数据包封装在 Packet-in 消息中发送给控制器处理,注意这时候数据包仍然会被放进缓冲区等待处理而不是被丢弃。
2.数据包在流表中有匹配的条目,但是其中所指示的 action 列表中包含转发给控制器的动作(Output = CONTROLLER),注意这时候数据包不会被放进缓冲区。

Flow_mod:分析抓取的flow_mod数据包,控制器向交换机下发流表项,指导数据的转发


因为第一遍的时候并没有执行PINGALL所以没有mod的信息,从新抓了一次所以端口号发生了变化。
Packet_out:告诉交换机将数据输出到交换机的哪个端口
控制器6633端口---> 交换机50846端口

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

流程图

二(进阶要求)
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. */
};
OFP_ASSERT(sizeof(struct ofp_header) == 8);

消息类型

enum ofp_type {
    /* Immutable messages. */
    OFPT_HELLO,               /* Symmetric message */
    OFPT_ERROR,               /* Symmetric message */
    OFPT_ECHO_REQUEST,        /* Symmetric message */
    OFPT_ECHO_REPLY,          /* Symmetric message */
    OFPT_VENDOR,              /* Symmetric message */

    /* Switch configuration messages. */
    OFPT_FEATURES_REQUEST,    /* Controller/switch message */
    OFPT_FEATURES_REPLY,      /* Controller/switch message */
    OFPT_GET_CONFIG_REQUEST,  /* Controller/switch message */
    OFPT_GET_CONFIG_REPLY,    /* Controller/switch message */
    OFPT_SET_CONFIG,          /* Controller/switch message */

    /* Asynchronous messages. */
    OFPT_PACKET_IN,           /* Async message */
    OFPT_FLOW_REMOVED,        /* Async message */
    OFPT_PORT_STATUS,         /* Async message */

    /* Controller command messages. */
    OFPT_PACKET_OUT,          /* Controller/switch message */
    OFPT_FLOW_MOD,            /* Controller/switch message */
    OFPT_PORT_MOD,            /* Controller/switch message */

    /* Statistics messages. */
    OFPT_STATS_REQUEST,       /* Controller/switch message */
    OFPT_STATS_REPLY,         /* Controller/switch message */

    /* Barrier messages. */
    OFPT_BARRIER_REQUEST,     /* Controller/switch message */
    OFPT_BARRIER_REPLY,       /* Controller/switch message */

    /* Queue Configuration messages. */
    OFPT_QUEUE_GET_CONFIG_REQUEST,  /* Controller/switch message */
    OFPT_QUEUE_GET_CONFIG_REPLY     /* Controller/switch message */

};

hello和features request


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

features reply

/* Switch features. */
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. */
};
OFP_ASSERT(sizeof(struct ofp_switch_features) == 32);

set config

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

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

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.) */
};
OFP_ASSERT(sizeof(struct ofp_packet_out) == 16);

flow_mod

enum ofp_flow_mod_flags {
    OFPFF_SEND_FLOW_REM = 1 << 0,  /* Send flow removed message when flow
                                    * expires or is deleted. */
    OFPFF_CHECK_OVERLAP = 1 << 1,  /* Check for overlapping entries first. */
    OFPFF_EMERG         = 1 << 2   /* Remark this is for emergency. */
};

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

port_status

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

标签:OFPT,struct,OpenFlow,实践,header,ofp,交换机,实验,message
From: https://www.cnblogs.com/ningjiaoyufei/p/16757225.html

相关文章

  • 实验5:开源控制器实践——POX
    这个作业属于哪个课程https://edu.cnblogs.com/campus/fzzcxy/FZUZCSDN202201这个作业要求在哪里https://edu.cnblogs.com/campus/fzu/FZUSDN2022/homework/12765这个......
  • 网络字节序与主机字节序的转换函数实践
        CPU向内存保存数据的方式有2种,这意味着CPU解析数据的方式也分为2种:        ♦ 大端序(bigendian):高位字节存放到低位地址;      ......
  • 关于TCP和UDP的联系与区别以及网络字节序和主机字节序的转换函数实践
    1.TCP和UDP的相同点:TCP和UDP都是在网络层,都是传输层协议,都能都是保护网络层的传输,双方的通信都需要开放端口。2.TCP和UDP的不同点:TCP传输协议,是一种面向连接的、可靠的......
  • 网络字节序与主机字节序的转换函数(实践)
    什么是字节序?字节序,顾名思义,指字节在内存中存储的顺序。(1)小端字节序,数值低位存储在内存的低地址,高位存储在内存的高地址;(2)大端字节序,数值高位存储在内存的低......
  • 网络字节序与主机字节序的转换函数实践
     在Linux网络编程中,经常会遇见网络字节序喝主机字节序的相互转换,要了解他们,首先要知道什么是字节序。字节序,顾名思义,指字节在内存中存储的顺序。比如一个int32_t类型的......
  • 网络字节序与主机字节序的转换函数实践
    1.网络字节序与主机字节序在Linux网络编程中,经常碰到网络字节序与主机字节序的相互转换。说到网络字节序与主机字节序需要清晰了解以下几个概念。字节序,顾名思义,指字节在......
  • 实验4:开源控制器实践——OpenDaylight
    一、实验目的1能够独立完成OpenDaylight控制器的安装配置;2能够使用Postman工具调用OpenDaylightAPI接口下发流表。二、实验环境1下载虚拟机软件OracleVisualBox或......
  • 对账业务系统实践
     在做对账系统的业务,虽然我只是一个CRUD工程师,但是还是希望能有自己的想法,在摸着石头过河的过程中,自己也是谷歌了对账的方案。 对于对账系统的完整设计方案,其实谷歌出来......
  • 网络字节序与主机字节序的转换函数实践
    .什么是字节序字节序是处理器架构特性,用于指示像整数这样的大数据类型内部的字节如何排序。简单来说,就是指超过一个字节的数据类型在内存中的存储的顺序。那么很明显,像char......
  • 网络字节序与主机字节序的转换函数实践
    主机字节序 在不同的CPU处理器下,有不同的字节序类型,而字节序是指整数在内存中存储的顺序叫做主机序。最常见的主机序有两种:大端存储(Bigendian):最高有效位存于最低内存地......