實驗3：OpenFlow協議分析實踐

本文轉載自查看原文 2021-09-22 23:44 105 SDN

一、實驗目的

能夠運用 wireshark 對 OpenFlow 協議數據交互過程進行抓包

能夠借助包解析工具，分析與解釋 OpenFlow協議的數據包交互過程與機制

二、實驗環境

下載虛擬機軟件Oracle VisualBox

在虛擬機中安裝Ubuntu 20.04 Desktop amd64，並完整安裝Mininet

三、實驗要求

3.1 基本要求

3.1.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

在Mininet可視化工具中搭建目標拓撲，並保存為py文件

代碼如下：

#!/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(h3, s1)
    net.addLink(s1, s2)
    net.addLink(s2, h4)
    net.addLink(h2, s2)

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

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

Hello
- 控制器6633端口（我最高能支持OpenFlow 1.0）---> 交換機44026端口
- 交換機44026端口（我最高能支持OpenFlow 1.5) ---> 控制器6633端口
- 於是雙方建立連接，並使用OpenFlow 1.0

Features Request

控制器6633端口（我需要你的特征信息） ---> 交換機44026端口
控制器6633端口（請按照我給你的 flag 和 max bytes of packet 進行配置） --->
交換機44026端口
- flag：指示交換機如何處理 IP 分片數據包
- max bytes of packet：當交換機無法處理到達的數據包時，向控制器發送如何處理的最大字節數，本實驗中控制器發送的值是0x0080，即128字節。

Port_Status

當交換機端口發生變化時，告知控制器相應的端口狀態

Features Reply

交換機44026端口（這是我的特征信息，請查收）--- 控制器6633端口

Packet_in

有兩種情況：
- 交換機查找流表，發現沒有匹配條目時
- 有匹配條目但是對應的action是OUTPUT=CONTROLLER時
交換機44026端口（有數據包進來，請指示）--- 控制器6633端口
分析抓取的數據包，可以發現是因為交換機發現此時自己並沒有匹配的流表（Reason: No matching flow (table-miss flow entry) (0)），所以要問控制器如何處理

Flow_mod

分析抓取的flow_mod數據包，控制器通過6633端口向交換機44026端口、交換機44028端口下發流表項，指導數據的轉發處理

Packet_out

控制器6633端口（請按照我給你的action進行處理） ---> 交換機44026端口
告訴輸出到交換機的65531端口

流程圖

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

答：在wireshark的抓包工具中，可以看到交換器與控制器建立通信時是使用TCP協議。

3.2 進階要求

3.2.1 將抓包結果對照OpenFlow源碼，了解OpenFlow主要消息類型對應的數據結構定義。

相關數據結構可在openflow安裝目錄openflow/include/openflow當中的openflow.h頭文件中查詢到。

Hello

OpenFlow源碼：

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

可以看到結構體中的四個參數對應上圖中的四個數據
version：OFP協議版本，type：OFPT的常數之一，length：OFP頭的長度，xid：與此包相關的交互ID。回復時使用與請求中相同的ID，以方便配對。
FEATURES_REQUEST
- 可以看到與Hello中的數據格式相同
Set Conig
- OpenFlow源碼：

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

flag：指示交換機如何處理 IP 分片數據包，max bytes of packet：當交換機無法處理到達的數據包時，向控制器發送如何處理的最大字節數，本實驗中控制器發送的值是0x0080，即128字節。
Port_Status
- OpenFlow源碼：

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

Features Reply
- OpenFlow源碼：

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

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

datapath_id：唯一標識符，n_buffers：交換機緩沖區可以緩存的最大數據包個數，n_tables：流表數量，pad：可以理解為填充值，capabilities：支持的特殊功能，actions：支持的動作，port data：物理端口描述列表。
Packet_in
- OpenFlow源碼：

#沒有匹配到
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. */
};

Flow_mod
- OpenFlow源碼：

struct ofp_match {
    uint32_t wildcards;        /* Wildcard fields. */
    uint16_t in_port;          /* Input switch port. */
    uint8_t dl_src[OFP_ETH_ALEN]; /* Ethernet source address. */
    uint8_t dl_dst[OFP_ETH_ALEN]; /* Ethernet destination address. */
    uint16_t dl_vlan;          /* Input VLAN id. */
    uint8_t dl_vlan_pcp;       /* Input VLAN priority. */
    uint8_t pad1[1];           /* Align to 64-bits */
    uint16_t dl_type;          /* Ethernet frame type. */
    uint8_t nw_tos;            /* IP ToS (actually DSCP field, 6 bits). */
    uint8_t nw_proto;          /* IP protocol or lower 8 bits of
                                * ARP opcode. */
    uint8_t pad2[2];           /* Align to 64-bits */
    uint32_t nw_src;           /* IP source address. */
    uint32_t nw_dst;           /* IP destination address. */
    uint16_t tp_src;           /* TCP/UDP source port. */
    uint16_t tp_dst;           /* TCP/UDP destination port. */
};

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

Packet_out
- OpenFlow源碼：

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

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

四、總結

實驗難度：適中

實驗過程遇到的困難及解決辦法：

在進行基本要求中的查看抓包結果，分析OpenFlow協議中交換機與控制器的消息交互過程時，忘了先開啟抓包再運行拓撲，弄好后發現根本找不到flow_mod信號，於是發現要先ping一下主機，才能看到flow_mod。
剛開始找不到交換機對控制器發送的Hello信號，后來發現它支持最高的版本為OpenFlow 1.5，於是要用openflow_v6來過濾。
在完成進階要求的時候，1000行的源碼看的真的很辛苦，找的很累，后來就直接把源碼復制到word，用word的查找功能，效率就快了很多！

個人感想：
- OpenFlow的源碼看的真累，有的還是看不懂，但看代碼的話能確實能更加直觀的理解OpenFlow協議。

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 實驗3：OpenFlow協議分析實踐實驗3：OpenFlow協議分析實踐 SDN實驗三 OpenFlow協議分析 OpenFlow協議分析 SDN學習之OpenFlow協議分析利用Wireshark抓取並分析OpenFlow協議報文 OpenFlow協議【SDN】利用Wireshark抓取並分析OpenFlow協議報文網絡協議分析-實驗 OpenFlow1.3協議wireshark抓包分析