实验3：OpenFlow协议分析实践

实验3：OpenFlow协议分析实践

搭建并配置拓扑

miniedit导出的python文件：

#!/usr/bin/env python

from mininet.net import Mininet
from mininet.node import Controller, RemoteController, OVSController
from mininet.node import CPULimitedHost, Host, Node
from mininet.node import OVSKernelSwitch, UserSwitch
from mininet.node import IVSSwitch
from mininet.cli import CLI
from mininet.log import setLogLevel, info
from mininet.link import TCLink, Intf
from subprocess import call

def myNetwork():

    net = Mininet( topo=None,
                   build=False,
                   ipBase='192.168.0.0/24')

    info( '*** Adding controller\n' )
    c0=net.addController(name='c0',
                      controller=Controller,
                      protocol='tcp',
                      port=6633)

    info( '*** Add switches\n')
    s1 = net.addSwitch('s1', cls=OVSKernelSwitch)
    s2 = net.addSwitch('s2', cls=OVSKernelSwitch)

    info( '*** Add hosts\n')
    h1 = net.addHost('h1', cls=Host, ip='192.168.0.101/24', defaultRoute=None)
    h2 = net.addHost('h2', cls=Host, ip='192.168.0.102/24', defaultRoute=None)
    h3 = net.addHost('h3', cls=Host, ip='192.168.0.103/24', defaultRoute=None)
    h4 = net.addHost('h4', cls=Host, ip='192.168.0.104/24', defaultRoute=None)

    info( '*** Add links\n')
    net.addLink(h1, s1)
    net.addLink(s1, s2)
    net.addLink(s2, h2)
    net.addLink(s2, h4)
    net.addLink(s1, h3)

    info( '*** Starting network\n')
    net.build()
    info( '*** Starting controllers\n')
    for controller in net.controllers:
        controller.start()

    info( '*** Starting switches\n')
    net.get('s1').start([c0])
    net.get('s2').start([c0])

    info( '*** Post configure switches and hosts\n')

    CLI(net)
    net.stop()

if __name__ == '__main__':
    setLogLevel( 'info' )
    myNetwork()

抓取OpenFlow1.0数据包

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

HELLO

首先控制器和交换机互相发送HELLO报文，可以看到控制器openflow版本为1.0，交换机openflow为1.5，按照规定选择二者间较小的版本，故双方确定版本为1.0

控制器向交换价发送HELLO

交换机向控制器发送HELLO报文

FEATURES_REQUEST/FEATURES_REPLY

控制器向交换机发送FEATURES_REQUEST询问交换机信息

交换机收到FEATURES_REQUEST之后随即发送FEATURES_REPLY，将自己的信息发送至控制器

SET_CONFIG

控制器向交换机发送发送SET_CONFIG消息以发送设置信息，也可能发送GET_CONFIG请求消息以查询OpenFlow交换机的设置状态

PORT_STATUS

当交换机端口发生变化时，告知控制器相应的端口状态。

PACKET_IN

使用PACKET_IN消息的目的是为了将到达交换机的数据包发送至控制器，以下两种情况即可发送PACK_IN消息。

• 不存在与流表项一直的项目时
• 匹配到流表项为记载的行动是“发送至控制器”时

如图为交换机向控制器发送数据包，数据部分包含包的一些信息

PACKET_OUT

PACKET_OUT是从控制器向交换机发送的消息，包含数据包发送命令的消息

FLOW_MOD

控制器通过向交换机发送FLOW_MOD，来对交换机进行流表的添加、删除、变更等设置操作。

采用协议

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

很显然，从截图中可以看到运输层采用的协议是TCP（Transmission Control Protocol）

进阶要求

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

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

可以看到对应了HELLO报文的四个参数

FEATURES_REQUEST

可以看到格式与上述ofp_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. */
};
/* 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. */
};

可以看到与图中信息一一对应，包括交换机物理端口的信息

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

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

PACKET_IN

源码：

前面提到packetin分两种情况，一种是没有匹配，但是这种包没有抓到过

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. */
};
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协议在交换机和控制器间的交互过程，但是在实验过程中遇到了两个问题：

• miniedit导出的拓扑代码，再次运行时无法指定openflow的协议，因为不影响后续实验，所以暂时不深究
• OVS交换机采用的openflow协议版本为1.5，所以起初以为没有抓到交换机应答的HELLO包

此外，这次的进阶要求，要求查看源码，所以也是一个对源码阅读的挑战。当然，可以很快的找到关键源码在openflow安装目录中的openflow/include/openflow/openflow.h头文件里，通过不断比对源码中定义的结构体和抓到的包的报文结构，学习到openflow协议在代码上是如何体现的。但是由于有些报文类型如PACKET_IN的两种触发形式，对于这类报文，没有抓取到。今后，还需要了解其触发机制，抓取报文下来进行查看。