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

实验3:OpenFlow协议分析实践

时间:2022-09-25 21:44:07浏览次数:44  
标签:OFPT struct OpenFlow 端口 实践 header ofp uint16 实验

实验3:OpenFlow协议分析实践

实验目的

  • 能够运用 wireshark 对 OpenFlow 协议数据交互过程进行抓包;
  • 能够借助包解析工具,分析与解释 OpenFlow协议的数据包交互过程与机制。

实验环境

Ubuntu 20.04 Desktop amd64

实验要求

(一)基本要求

  1. 搭建如下拓扑


命令行拓扑完整性测试

  1. 查看抓包结果
    OFPT_HELLO:
    从控制器6633端口到交换机53956端口,使用OpenFlow1.0协议:

从控制器53956端口到交换机6633端口,使用OpenFlow1.5协议:

OFPT_HELLO后,双方协商使用openflow1.0协议

OFPT_FEATURES_REQUEST:
从控制器6633端口到交换机53956端口,请求特征信息

OFPT_SET_CONFIG:

OFPT_PORT_STATUS:
从交换机53956端口到控制器6633端口当交换机端口发生变化时,告知控制器相应的端口状态

OFPT_FEATURES_REPLY:
交换机53956端口到控制器6633端口,回复特征信息

OFPT_PACKET_IN:
分析抓取的数据包(交换机53956端口(有数据包进来,请指示)--->控制器6633端口)

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

OFPT_FLOW_MOD
分析抓取的flow_mod数据包,控制器通过6633端口向交换机53954端口、交换机53956端口下发流表项,指导数据的转发处理

  1. 相关交互图或流程图。

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

    所以(Transmission Control Protocol)TCP协议

(二)进阶要求

将抓包基础要求第2步的抓包结果对照OpenFlow源码,了解OpenFlow主要消息类型对应的数据结构定义。

  1. OFPT_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. */
};
  1. OFPT_FEATURES_REQUEST
/* Header on all OpenFlow packets. */
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. */
};
  1. OFPT_SET_CONFIG
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. */
};
  1. OFPT_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;
};
  1. OFPT_FEATURES_REPLY
/* 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. */
};
  1. OFPT_PACKET_IN
    两种情况:
    1. 交换机查找流表,发现没有匹配条目,但是这种包没有抓到过
enum ofp_packet_in_reason {
    OFPR_NO_MATCH,          /* No matching flow. */
    OFPR_ACTION             /* Action explicitly output to controller. */
};
2. 有匹配条目,对应的action是OUTPUT=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. */
};

7.OFPT_PACKET_OUT

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

(三)个人总结

1.本次实验刚开始时,建立拓扑输入命令时,没加上sudo,所以出现了报错,通过查找上一次实验的报告改了过来
2.本次实验还学会了行用过滤器进行过滤,因为版本的不同,在过滤openflow_v4时找不到结果,通过查询发现可以用openflow_v6进行过滤
3.因为未详细阅读需要注意的事项,所以先建立拓扑再抓包了,所以出现的抓包结果一直找不到,再重复阅读实验手册才发现要先开启抓包再构建拓扑。还有就是在抓包之前要先pingall一次,才能找到FLOW_MOD
4.总体来说本次实验不是很难,但是要非常的仔细,不然一不小心就会出现一些不必要错误

标签:OFPT,struct,OpenFlow,端口,实践,header,ofp,uint16,实验
From: https://www.cnblogs.com/hjy03/p/16729059.html

相关文章

  • 实验2:Open vSwitch虚拟交换机实践
    一、实验目的能够对OpenvSwitch进行基本操作;能够通过命令行终端使用OVS命令操作OpenvSwitch交换机,管理流表;能够通过Mininet的Python代码运行OVS命令,控制网络拓扑中的......
  • SDN第一次实验报告(第1、2次合并)
    第一次实验报告一、实验目的能够使用源码安装Mininet;能够使用Mininet的可视化工具生成拓扑;能够使用Mininet的命令行生成特定拓扑;能够使用Mininet交互界面管理SDN拓......
  • 实验2:Open vSwitch虚拟交换机实践
    (一)基本要求a)/home/用户名/学号/lab2/目录下执行ovs-vsctlshow命令、以及p0和p1连通性测试的执行结果截图;b)/home/用户名/学号/lab2/目录下开启MininetCLI并执行pi......
  • 实验2:Open vSwitch虚拟交换机实践
    三、实验报告3.1基础要求提交a)/home/用户名/学号/lab2/目录下执行ovs-vsctlshow命令、以及p0和p1连通性测试的执行结果截图;b)/home/用户名/学号/lab2/目录下开启M......
  • 实验3:OpenFlow协议分析实践
    基础要求代码#!/usr/bin/envpythonfrommininet.netimportMininetfrommininet.nodeimportController,RemoteController,OVSControllerfrommininet.nodeimp......
  • 实验一 SDN拓扑实践
    (一)基本要求1.使用Mininet可视化工具,生成下图所示的拓扑,并保存拓扑文件名为学号.py。2.使用Mininet的命令行生成如下拓扑:a)3台交换机,每个交换机连接1台主机,3台交换机连......
  • 一线架构师实践指南 pdf
    高清扫描版下载链接:https://pan.baidu.com/s/11lqzpndTtybOdLkZQJKcVg点击这里获取提取码 ......
  • 实验1:SDN拓扑实践
    一、实验目的能够使用源码安装Mininet;能够使用Mininet的可视化工具生成拓扑;能够使用Mininet的命令行生成特定拓扑;能够使用Mininet交互界面管理SDN拓扑;能够使用Python......
  • 实验3:OpenFlow协议分析实践
    实验3:OpenFlow协议分析实践(一)基本要求1.搭建拓扑,完成相关IP配置。2-1.查看抓包结果①HELLO控制器6633端口(我最高能支持OpenFlow1.0)--->交换机60806端口交......
  • Mesh实战:基于Linkerd和Kubernetes的微服务实践 pdf
    高清扫描版下载链接:https://pan.baidu.com/s/1q78WP_OyGzsmCNjdFk_nbA点击这里获取提取码 ......