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

实验3:OpenFlow协议分析实践

时间:2022-10-07 16:55:07浏览次数:49  
标签:控制器 struct OpenFlow 实践 header ofp 交换机 实验 net

(三)实验报告

3.1 请用Markdown排版;

3.2 基础要求只需要提交导入到/home/用户名/学号/lab3/目录下的拓扑文件,wireshark抓包的结果截图和对应的文字说明;

3.2.1 搭建所示拓扑,完成相关 IP 配置,并实现主机与主机之间的 IP 通信。用抓包软件获取控制器与交换机之间的通信数据。

  • 根据拓扑图创建python脚本,并在脚本文件中完成主机ip配置
#!/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='10.0.0.0/8')
 
    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(s1, s2)
    net.addLink(s2, h2)
    net.addLink(s2, h4)
 
    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()

  • 实现主机之间pingall通信效果

3.2.2 查看抓包结果,分析OpenFlow协议中交换机与控制器的消息交互过程,画出相关交互图或流程图。【交换机s1与控制器c0的通信为例】

  • hello
    • 控制器6633端口(我需要你的特征信息)---> 交换机42628端口
    • 交换机42628端口(我最高能支持OpenFlow 1.5)---> 控制器6633端口
  • Features Request / Set Conig
    • 控制器6633端口(我需要你的特征信息)---> 交换机42628端口
    • 控制器6633端口(请按照我给你的flag和max bytes of packet进行配置)---> 交换机42628端口
  • Port_Status
  • Features Reply
    • 交换机42628端口(这是我的特征信息,请查收) ---> 控制器6633端口
  • Packet-in
    • 交换机42628端口(有数据包进来,请指示)--> 控制器6633端口
  • Flow_mod
    • 控制器通过6633端口向交换机42628端口下发流表项,指导数据的转发处理

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

3.2.3 交换机与控制器的交互流程图

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

答:交换机与控制器建立通信时是使用TCP协议
原因:根据抓包的结果上可以看出,控制器与交换机进行了TCP协议的三次握手行为来建立通信

3.3 进阶要求为选做,有完成的同学请提交相关截图对应的OpenFlow代码,加以注释说明,有完成比未完成的上机分数更高。

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

  • hello
struct ofp_hello {
    struct ofp_header header;
};
  • Features Request / Set Conig

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

3.4 个人总结,包括但不限于实验难度、实验过程遇到的困难及解决办法,个人感想,不少于200字。

3.4.1 交换机与控制器在互相发送HELLO报文时,根据抓包的结果发现双方协商的OpenFlow版本不同

  • 控制器使用1.0版本
  • 交换机使用1.5版本

    通过在多方网络资料查询后得知,OFPT_HELLO报文内显示的内容时双方支持的最高OpenFLow版本,而通信实现的结果是采用双方能够使用的最低OpenFlow结果,即在本次抓包中控制器与交换机实际采用OpenFLow1.0版本进行通信

标签:控制器,struct,OpenFlow,实践,header,ofp,交换机,实验,net
From: https://www.cnblogs.com/lyf5446/p/16757506.html

相关文章

  • 实验5:开源控制器实践——POX
    一、实验目的1.能够理解POX控制器的工作原理;2.通过验证POX的forwarding.hub和forwarding.l2_learning模块,初步掌握POX控制器的使用方法;3.能够运用POX控制器编写自定义......
  • 干货实践 | Anchor优化后在目标检测提升这么明显
    “计算机视觉研究院”计算机视觉研究院专栏作者:Edison_G目标检测发展已经到了一个瓶颈,但是依然有很多优秀的产出,比如最近比较火热的“Anchor—Free”,貌似在该机制下精度有一......
  • 实验3:OpenFlow协议分析实践
    (一)基本要求1.搭建下图所示拓扑,完成相关IP配置,并实现主机与主机之间的IP通信。用抓包软件获取控制器与交换机之间的通信数据。主机 IP地址h1 192.168.0.101/24h2 1......
  • Mongodb学习实践文档
    2020年12月目 录1MongoDB简介12Mongodb与传统关系型数据库对比13Mongodb基础运维23.1Mongodb安装33.1.1创建用户33.1.2创建目录33.1.3安装33.1.4mongod......
  • 网络字节序与主机字节序的转换函数实践
    网络字节序与主机字节序的转换函数实践1、什么是字节序?字节序,顾名思义,就是字节组织的顺序分为两种,一种是以IBM、Oracle公司为代表的大端序(bigendian),一种是以Intel公司......
  • 代码实践 | CVPR2020——AdderNet(加法网络)迁移到检测网络(代码分享)
    公众号 :计算机视觉战队扫码回复:加法网络,获取源码论文链接记得前段时间“计算机视觉研究院”推送了一篇关于CVPR2020最佳分类的文献(链接:​​CVPR2020最佳目标检测|Adder......
  • 实验3:OpenFlow协议分析实践
    实验3:OpenFlow协议分析实践一、实验目的能够运用wireshark对OpenFlow协议数据交互过程进行抓包;能够借助包解析工具,分析与解释OpenFlow协议的数据包交互过程与机制......
  • nginx proxy webservie 问题&实践
    webservice具有特殊性,因为wsdl文件是服务器端生成的(大部分,而且是动态的),所以我们直接使用nginx进行proxy会有问题实际上此问题比较常见,而且网上也有人碰到,可能因为时间......
  • 网络字节序与主机字节序的转换函数实践
    网络字节序与主机字节序的相互转换常用系统调用Linuxsocket网络编程中,经常会使用下面四个C标准库函数进行字节序间的转换。#include<arpa/inet.h>uint32_thtonl(ui......
  • 网络字节序与主机字节序的转换函数实践
    首先我们要对于网络字节序和主机字节序有一个初步的概念。字节序:字节在内存中储存的顺序字节序的种类:(1):大端字节序,数值高位储存在内存的低地址,低位储存在内存的高地址,在 ......