實驗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的兩種觸發形式，對於這類報文，沒有抓取到。今后，還需要了解其觸發機制，抓取報文下來進行查看。