实验3：OpenFlow协议分析实践

一、实验目的

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

二、实验环境

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

三、实验要求

（一）基本要求

搭建下图所示拓扑，完成相关 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

构建上图拓扑，并按要求配置IP
导出拓扑文件，存入/home/ubuntu/031902102/lab3/中
文件目录
目录下拓扑文件

查看抓包结果，分析OpenFlow协议中交换机与控制器的消息交互过程，画出相关交互图或流程图。

根据抓包结果，可以得出交换机与控制器在本实验中是如以下过程进行消息交互的

OFPT_HELLO, 源端口6633 -> 目的端口36424，从控制器到交换机

也有源端口36424 -> 目的端口6633的，即交换机到控制器的另一个包，此处协议为openflow1.3

OFPT_FEATURES_REQUEST, 源端口6633 -> 目的端口36424，从控制器到交换机
OFPT_SET_CONFIG, 源端口6633 -> 目的端口36424，从控制器到交换机
OFPT_PORT_STATUS, 源端口36424 -> 目的端口6633，从交换机到控制器
OFPT_FEATURES_REPLY, 源端口36424 -> 目的端口6633，从交换机到控制器
OFPT_PACKET_IN, 源端口36424 -> 目的端口6633，从交换机到控制器
OFPT_PACKET_OUT, 源端口6633 -> 目的端口36424，从控制器到交换机
OFPT_FLOW_MOD, 源端口6633 -> 目的端口36424，从控制器到交换机

同时，上述6、7、8三种消息报文的交互会频繁多次出现在交换机和控制器之间

综上可知，本实验中交换机和控制器之间消息交互过程，大致如下图所示：

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

答：根据图上红框内容可知，交换机与控制器建立通信时是使用TCP（Transmission Control Protocol）协议。

（二）进阶要求

将抓包结果对照OpenFlow源码，了解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

源码参数格式与HELLO相同，将抓包截图与之对比

3. SET_CONFIG

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

将抓包截图与之对比

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

将抓包截图与之对比

5. FEATUERS_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;
    uint8_t hw_addr[OFP_ETH_ALEN];
    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. */
};

将抓包截图与之对比

6. PORT_IN

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

将抓包截图与之对比

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;           /* 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. */
};
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协议中数据包交换机制，所以实验本身偏向于理论学习。同时，也因为这次理论课和实践课进度存在不同，所以进行实验前和实验过程中，需要查阅一些相关资料，也使得实验难度进一步提升。

实验中遇到的困难

Q1. （一）基础要求中要求修改h1 - h4的IP地址，但一开始修改完拓扑却无法正确连通
解决方法：使用Miniedit构建的拓扑默认网段是10.0.0.0/8，但实验要求IP地址在192.168.0.0/24网段中，故需要在设置中将拓扑网段修改成192.168.0.0/24
Q2&方法. （二）进阶要求中，要求了解并对照OpenFlow源码，着实是一项不轻松的任务，几乎这次实验中三分之二的时间都花在阅读和了解源码上，之后哪怕在阅读相关解析博客之后也还有部分参数内容无法消化。

实验心得

本次实验通过wireshark包分析工具，分析与学习了 OpenFlow协议的数据包交互过程与机制。同时，这次实验内容相对之前两次实验更加偏重理论知识的学习。这就出现了实质实验操作没啥问题，但是理论体系层面不可名状的问题和疑问一大堆。~~（也许我太菜吧）~~但这次实验中，通过查找大量关于OpenFlow协议的相关代码和参数对应关系，也使我对OpenFlow协议有了更深刻形象的认识，提升了自主学习能力。而且同时对wireshark包解析工具的使用更加熟练，也大致了解了switch与controller之间消息交互的方式。而实验中反映出的问题，也将会是下一步学习的方向

posted @ 2021-09-22 21:49 Excalibur_Morgan 阅读(370) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

Excalibur_Morgan

实验3：OpenFlow协议分析实践

实验3：OpenFlow协议分析实践

一、实验目的

二、实验环境

三、实验要求

（一）基本要求

（二）进阶要求

1. HELLO

2. FEATURES_REQUEST

3. SET_CONFIG

4. PORT_STATUS

5. FEATUERS_REPLY

6. PORT_IN

7. PORT_OUT

8. FLOW_MOD

个人总结

实验三难度

实验中遇到的困难

实验心得

公告