實驗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

• 構建上圖拓撲，並按要求配置IP
  
  
  
  

• 導出拓撲文件，存入/home/ubuntu/031902102/lab3/中

• 文件目錄
  

• 目錄下拓撲文件
  

2. 查看抓包結果，分析OpenFlow協議中交換機與控制器的消息交互過程，畫出相關交互圖或流程圖。

• 根據抓包結果，可以得出交換機與控制器在本實驗中是如以下過程進行消息交互的

1. OFPT_HELLO, 源端口6633 -> 目的端口36424，從控制器到交換機
   

也有源端口36424 -> 目的端口6633的，即交換機到控制器的另一個包，此處協議為openflow1.3

2. OFPT_FEATURES_REQUEST, 源端口6633 -> 目的端口36424，從控制器到交換機
   

3. OFPT_SET_CONFIG, 源端口6633 -> 目的端口36424，從控制器到交換機
   

4. OFPT_PORT_STATUS, 源端口36424 -> 目的端口6633，從交換機到控制器
   

5. OFPT_FEATURES_REPLY, 源端口36424 -> 目的端口6633，從交換機到控制器
   

6. OFPT_PACKET_IN, 源端口36424 -> 目的端口6633，從交換機到控制器
   

7. OFPT_PACKET_OUT, 源端口6633 -> 目的端口36424，從控制器到交換機
   

8. OFPT_FLOW_MOD, 源端口6633 -> 目的端口36424，從控制器到交換機
   

同時，上述6、7、8三種消息報文的交互會頻繁多次出現在交換機和控制器之間

• 綜上可知，本實驗中交換機和控制器之間消息交互過程，大致如下圖所示：
  

3. 回答問題：交換機與控制器建立通信時是使用TCP協議還是UDP協議？
   

• 答：根據圖上紅框內容可知，交換機與控制器建立通信時是使用TCP（Transmission Control Protocol）協議。

（二）進階要求

1. 將抓包結果對照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之間消息交互的方式。而實驗中反映出的問題，也將會是下一步學習的方向