Open Flow协议分析实践

一、实验目的

1.能够运用 wireshark 对 OpenFlow 协议数据交互过程进行抓包；

2.能够借助包解析工具，分析与解释 OpenFlow协议的数据包交互过程与机制。

二、实验环境

1.下载虚拟机软件Oracle VisualBox；

2.在虚拟机中安装Ubuntu 20.04 Desktop amd64，并完整安装Mininet；

三、实验要求

（一）基本要求

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

1.在终端输入sudo ./../mininet/examples/miniedit.py搭建拓扑

2.配置网段

3.配置ip地址

4.保存拓扑为python文件

5.运行sudo wireshark命令，并选择any模式进行抓包，开启另一个终端，命令行运行topo.py文件，运行pingall

6.查看抓包结果，分析OpenFlow协议中交换机与控制器的消息交互过程

（1）OFPT_HELLO 

当交换机连接到控制器时，交换机与控制器会相互发送hello包，而hello消息中只包含of Header，of Header中的version字段为发送方支持的最高版本的of协议版本。如果两者协议版本兼容，则建立of连接，否则发送error消息，断开连接。

（注：如果抓不到hello包需要先打开wireshark抓包再运行python文件）

• 源端口6633 -> 目的端口35188，从控制器到交换机,控制器与交换机建立连接，并使用OpenFlow 1.0

• 源端口35188 -> 目的端口6633，即交换机到控制器的另一个包，此处协议为openflow1.5

（2）OFPT_FEATURES_REQUEST 

• 源端口6633 -> 目的端口35188，从控制器到交换机，协议为openflow1.0
• 控制器请求交换器的特征信息

（3）OFPT_SET_CONFIG 

• 源端口6633 -> 目的端口35188，从控制器到交换机，协议为openflow1.0
  • flag：指示交换机如何处理IP分片数据包
  1. max bytes of packet：当交换机无法处理到达的数据包时，向控制器发送如何处理的最大字节数，本实验中控制器发送的值是0x0080，即128字节
• 控制器要求交换机按照所给出的信息进行配置

（4）OFPT_PORT_STATUS 

• 源端口35188 -> 目的端口6633，从交换机到控制器，协议为openflow1.0
• 当交换机端口发生变化时，交换机告知控制器相应的端口状态

（5）OFPT_FEATURES_REPLY 

• 源端口35188 -> 目的端口6633，从交换机到控制器，协议为openflow1.0

• 交换机告知控制器它的特征信息

reply消息分析：

[0:8]为header(version、type、length、xid)

[8:32]长度24byte为sw的features，包含如下：

datapath_id：交换机的标识符，低48位是一个MAC地址，高16位是自定义的。

n_buffers：一次最多缓存的数据包数量。

n_tables：表示交换机支持的流表数量。

auxiliary_id：标识辅助连接。

capabilities：所支持的功能。交换机的一些详细信息。

reserved：保留字段。

（6）OFPT_PACKET_IN 

• 源端口35198 -> 目的端口6633，从交换机到控制器，交换机告知控制器有数据包进来，请求控制器指示

• 有两种情况：
  • 交换机查找流表，发现没有匹配条目
  • 有匹配条目但是对应的action是OUTPUT=CONTROLLER，固定收到向控制器发送包

协议解释：

　　 buffer_id是packet-in消息所携带的数据包在交换机中的缓存ID
        Total_len为data段的长度
        In_port数据包进入交换机的入端口号
        Reason为packet-in事件的产生原因
        同时，从reason的消息格式也可以看出触发packet-in的两种情况：OFPR_NO_MATCH和OFPR_ACTION。

（7）OFPT_PACKET_OUT 

• 源端口6633 -> 目的端口35198，从控制器到交换机
• 控制器要求交换机按照所给出的action进行处理

（8）OFPT_FLOW_MOD 

• 源端口6633 -> 目的端口35198，从控制器到交换机下发流表项，指导数据的转发处理
• 控制器对交换机进行流表的添加、删除、变更等操作

消息解释：

  Cookie为控制器定义流表项标识符

  Command是flow-mod的类型，可以是ADD、DELETE、DELETE-STRICT、MODIFY、MODIFY-STRCT；

   Ldle_timeout是流表项的空闲超时时间；

   Hard_timeout是流表项的最大生存时间；

   Priority为流表项的优先级，交换机优先匹配高优先级的流表项；

   Buffer_id为交换机中的缓冲区ID，flow-mod消息可以指定一个缓冲区的ID，该缓冲区的数据包会按照此flow-mod消息的action列处理。如果是手动下发的流，buffer_id应填-1，即0xffff,告诉交换机这个数据包并没有缓存在队列中。

　　 Out_port为删除流表的flow_mod消息提供的额外的匹配参数。

        Flags为flow-mod命令的一些标志位，可以用来指示流表删除后是否发送flow-removed消息，添加流表时是否检查流表重复项，添加的流表项是否为应急流表项。

        当OFPFF_SEND_FLOW_REM 被设置的时候，表项超时删除会触发一条表项删除的信息。

        当OFPFF_CHECK_OVERLAP 被设置的时候，交换机必须检查同优先级的表项之间是否有匹配范围的冲突。

        当OFPFF_EMERG_被设置的时候，交换机将表项当作紧急表项，只有当与控制器连接断的时候才启用。

7.画出交互图或流程图

 

（二）进阶要求

将抓包结果对照OpenFlow源码，了解OpenFlow主要消息类型对应的数据结构定义

（1）OFPT_HELLO 

（2）OFPT_FEATURES_REQUEST 

• 源码参数格式与HELLO相同

（3）OFPT_SET_CONFIG 

（4）OFPT_PORT_STATUS 

（5）OFPT_FEATURES_REPLY 

（6）OFPT_PACKET_IN 

（7）OFPT_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.) */

};

（8）OFPT_FLOW_MOD 

（三）个人心得

个人总结

1.本次实验的难度不是特别大，是验证性的实验,只要实验步骤正确，一般是可以得到正确的结果的，当然细心还是很重要的。

2.在实验过程中我遇到的困难并不多，就是刚开始的时候没抓到flow_mod的数据包，后来经过反复地尝试，将拓扑运行，主机通信等一系列过程都进行抓包，很快就找到flow_mod的数据包。

3.能够借助包解析工具，分析与解释 OpenFlow协议的数据包交互过程与机制。借助包解析工具，分析与解释 OpenFlow协议的数据包交互过程与机制；将抓包结果对照OpenFlow源码，让我们能够了解OpenFlow主要消息类型对应的数据结构定义。