首页 > 其他分享 >实验3:OpenFlow协议分析实践

实验3:OpenFlow协议分析实践

时间:2022-09-26 01:23:08浏览次数:53  
标签:struct uint16 OpenFlow 实践 uint8 header ofp 交换机 实验

实验3:OpenFlow协议分析实践

(一)基本要求

拓扑文件


#!/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', defaultRoute=None)
    h2 = net.addHost('h2', cls=Host, ip='192.168.0.102', defaultRoute=None)
    h3 = net.addHost('h3', cls=Host, ip='192.168.0.103', defaultRoute=None)
    h4 = net.addHost('h4', cls=Host, ip='192.168.0.104', defaultRoute=None)

    info( '*** Add links\n')
    net.addLink(h1, s1)
    net.addLink(h3, s1)
    net.addLink(h2, s2)
    net.addLink(s2, h4)
    net.addLink(s1, 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()

wireshark抓包的结果

OFPT_HELLO

OFPT_HELLO是用于协议协商,内容是本方支持的最高版本的协议,最终使用双方都支持的最低版本协议建立连接。

控制器6633端口(我最高能支持OpenFlow 1.0) ---> 交换机35098端口

交换机35098端口(我最高能支持OpenFlow 1.5) ---> 控制器6633端口

Features Request

控制器向交换机发送Features Request消息查询交换机特性,Features Request消息只包含Openflow Header,
交换机的特性信息包括交换机的ID(DPID),交换机缓冲区数量,交换机端口及端口属性等等

Set Config

控制器6633端口(请按照我给你的flag和max bytes of packet进行配置) --->
交换机35098端口

Port_Status

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

Features Reply

Features Reply消息包括Openflow Header 和Features Reply Message;

交换机35098端口(这是我的特征信息,请查收) ---> 控制器6633端口

Packet_in

产生packet_in的原因主要有以下两种:
OFPR_NO_MATCH:当交换机收到一个数据包后,会查找流表,找出与数据包包头相匹配的条目。如果流表中有匹配条目,则交换机按照流表所指示的action列表处理数据包。如果流表中没有匹配条目,则交换机会将数据包封装在Packet‐in消息中发送给控制器处理。此时数据包会被缓存在交换机中等待处理。
OFPR_ACTION:交换机流表所指示的action列表中包含转发给控制器的动作(Output=CONTROLLER)。此时数据包不会被缓存在交换机中。

交换机35098端口(有数据包进来,请指示)--- 控制器6633端口

Packet_out

控制器6633端口(请按照我给你的action进行处理) ---> 交换机35098端口

Flow_mod

控制器通过6633端口向交换机35098端口、交换机35100端口下发流表项,指导数据的转发处理


OpenFlow协议中交换机与控制器的消息交互过程,画出相关交互图或流程图

交换机与控制器建立通信时是使用TCP协议还是UDP协议?

使用的是TCP协议

(二)进阶要求

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

OFPT_HELLO

OFPT_HELLO是用于协议协商,内容是本方支持的最高版本的协议,最终使用双方都支持的最低版本协议建立连接。

struct ofp_hello {
    struct ofp_header header;
};
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. */
};

OFPT FEATURES REQUEST

控制器向交换机发送Features Request消息查询交换机特性,Features Request消息只包含Openflow Header,
交换机的特性信息包括交换机的ID(DPID),交换机缓冲区数量,交换机端口及端口属性等等

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

OFPT_FEATURES REPLY

Features Reply消息包括Openflow Header 和Features Reply Message;

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. */
};
OFP_ASSERT(sizeof(struct ofp_phy_port) == 48);

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

OFPT_SET_CONFIG

根据收到的flag和max bytes of packet配置

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

OFPT_PORT_STATUS

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

OFPT_FLOW_MOD

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. */
};
/* Flow setup and teardown (controller -> datapath). */
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. */
};

OFPT_PACKET_IN

在控制器获取完交换机的特性之后 , 交换机开始处理数据。

enum ofp_packet_in_reason {
    OFPR_NO_MATCH,          /* No matching flow. */
    OFPR_ACTION             /* Action explicitly output to controller. */
};

/* Packet received on port (datapath -> 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. */
};

OFPT_PACKET_OUT

控制器可以使用PacketOut消息,告诉交换机某一个数据包如何处理。

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];
};
OFP_ASSERT(sizeof(struct ofp_action_header) == 8);

/* Send packet (controller -> datapath). */
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.) */
};

个人总结

1.本次实验的难度不是特别大,是验证性的实验,只要实验步骤正确,一般是可以得到正确的结果的,当然细心还是很重要的。
2.在实验过程中我遇到的困难并不多,就是刚开始的时候没抓到flow_mod的数据包,后来经过反复地尝试,将拓扑运行,主机通信等一系列过程都进行抓包,很快就找到 flow_mod的数据包。还有后来在画交互图时稍微卡了一下,因为不知道各种包的发送顺序,经过反复对抓取的数据包的分析,以及上网查找资料,最终画出了一张个人觉得正确的交互图。
3. 经过这一次的实验,学会了利用过滤器对抓取的数据包进行过滤以此更迅速地找到所需要的数据包。同时在抓包结果与openflow源码对照学习中更了解openflow主要消息类型对应的数据结构定义,了解了整个拓扑结构工作的流程,对于sdn也有了更多地了解。

标签:struct,uint16,OpenFlow,实践,uint8,header,ofp,交换机,实验
From: https://www.cnblogs.com/daimon-/p/16729353.html

相关文章

  • 实验3:OpenFlow协议分析实践
    实验报告(一)基本要求1.导入到/home/用户名/学号/lab3/目录下的拓扑文件2.Wireshark抓包结果OFPT_HELLO控制器6633端口(我最高能支持OpenFlow1.0)--->交换机3892......
  • 实验1:SDN拓扑实践
    实验1:SDN拓扑实践(一)基本要求1.使用Mininet可视化工具,生成下图所示的拓扑,并保存拓扑文件名为学号.py。2.使用Mininet的命令行生成如下拓扑:a)3台交换机,每个......
  • sdn拓扑实验一
     ......
  • 实验2:Open vSwitch虚拟交换机实践
    实验2:OpenvSwitch虚拟交换机实践一、实验目的能够对OpenvSwitch进行基本操作;能够通过命令行终端使用OVS命令操作OpenvSwitch交换机,管理流表;能够通过Mininet的Pytho......
  • SDN第三次实验
    实验3:OpenFlow协议分析实践实验目的能够运用wireshark对OpenFlow协议数据交互过程进行抓包;能够借助包解析工具,分析与解释OpenFlow协议的数据包交互过程与机制。......
  • 实验3:OpenFlow协议分析实践
    一、基本要求1.搭建下图所示拓扑,完成相关IP配置,并实现主机与主机之间的IP通信。用抓包软件获取控制器与交换机之间的通信数据。控制器6633端口(我最高能支持OpenFlo......
  • 第一次sdn实验
    mininet运行结果a结果图、b结果图修改个人心得:在提前预习ppt的情况下,大部分代码都能正确的输入并且执行;但在完成过程中依旧有一些地方输入代码后没有达到预期效果,发......
  • 实验一
           个人总结:这次实验要求我们理解掌握如何创建网络拓扑,根据老师的指导,实验过程比较顺利,不过后期还是遇到了测试链路带宽出不来结果的问题......
  • 实验3:OpenFlow协议分析实践
    实验3:OpenFlow协议分析实践一、实验目的1.能够运用wireshark对OpenFlow协议数据交互过程进行抓包;2.能够借助包解析工具,分析与解释OpenFlow协议的数据包交互过程与......
  • 实验1:SDN拓扑实践
    一、实验目的能够使用源码安装Mininet;能够使用Mininet的可视化工具生成拓扑;能够使用Mininet的命令行生成特定拓扑;能够使用Mininet交互界面管理SDN拓扑;能够使用Python......