OpenFlow协议分析

张梦婕289

于 2024-06-07 21:11:55 发布

阅读量1k

点赞数 24

文章标签：网络

本文链接：https://blog.csdn.net/weixin_74846124/article/details/139535524

版权

OpenFlow协议分析

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

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

配置网段

配置IP地址

保存为Python文件

2.查看抓包结果，分析OpenFlow协议中交换机与控制器的消息交互过程，画出相关交互图或流程图。

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

（1）Hello：当连接启动时交换机和控制器会发送Hello交互。

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

OFPT_HELLO 源端口6633 ------- 目的端口46038，从控制器到交换机

交换机46038端口（OpenFlow 1.5)-------控制器6633端口

OpenFlow交换机与OpenFlow控制器之间通过TCP三次握手过程建立连接，使用的TCP端口号为6633。

TCP连接建立后，交换机和控制器就会互相发送hello报文。Hello报文负责在交换机和控制器之间进行版本协商，该报文中OpenFlow数据头的类型值为0。

于是双方建立连接，并使用OpenFlow 1.0

（2）Features Request:控制器发向交换机的一条OpenFlow 消息，目的是为了获取交换机性能，功能以及一些系统参数。该报文中OpenFlow 数据头的类型值为5。

　连接建立后，控制器向交换机发送一个features Request消息查询交换机的特性，features request消息也只包含of Header，交换机接受到该消息之后会返回一个features reply消息，这个消息就包含Header和Message。如下所示：

控制器6633端口（OpenFlow 1.0)------- 交换机46038端口

（3）Features Reply: 由交换机向控制器发送的功能响应（Feature Reply）报文，描述了OpenFlow交换机的详细细节。控制器获得交换机功能信息后，OpenFlow协议相关的特定操作就可以开始了。

交换机向控制器响应的OFPT_FEATURES_REPLY消息。如下所示

交换机46038端口（openflow 1.0）--- 控制器6633端口

reply消息分析：

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

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

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

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

n_tables：表示交换机支持的流表数量。每个流表可以设置不同的通配符和不同数量的流表项。控制器和交换机第一次通信的时候，控制器会从feature_reply消息中找出交换机支持多少流表，如果控制器还想了解大小、类型和流表查询的顺序，就发送一个ofpst_table stats请求，交换机必须按照数据包遍历流表的顺序把这些流表回复给控制器，并且精确匹配流表排在通配流表前。

auxiliary_id：标识辅助连接。

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

reserved：保留字段。

（4）Packet_in

Packet-in事件在以下两种情况下会被触发：

1.当交换机收到一个数据包后，并未与流表中匹配成功，那么交换机就会将数据封装在Packer-in消息中，发送给控制器处理。此时数据包会被缓存在交换机中等待处理。

2.交换机流表所指示的action列表中包含转发给控制器的动作（Output=Controller），此时数据不会被缓存在控制器中。

交换机向控制器递交OFPT_PACKET_IN消息。如下所示

分析抓取的数据包，可以发现是因为交换机发现此时自己并没有匹配的流表（Reason: No matching flow (table-miss flow entry) (0)），所以要问控制器如何处理

（5）Flow_mod

Flow-Mod消息用于添加、删除、修改openflow交换机的流表项信息；Flow-Mod消息共有5种类型：ADD、DEKETE、DELETE-STRICT、MODIFY、MODIFY_STRICT。

ADD类型消息用来添加一条新的流表项（flow entry）

DELETE类型消息用来删除所有符合一定条件的流表项

DELETE‐STRICT类型消息用来删除某一条指定的流表项

MODIFY类型消息用来修改所有符合一定条件的流表项

MODIFY‐STRICT类型息用来修改某一条指定的流表项

分析抓取的flow_mod数据包，控制器通过6633端口向交换机46038端口、交换机46038端口下发流表项，指导数据的转发处理。如下所示

（6）Packet_out

Packet-out消息的应用场景：

指定某一个数据包的处理方法

让交换机产生一个数据包并按照action流表处理。

典型应用：链路发现

控制器向一个交换机发送packet-out消息，buffer_id=-1，data段为某种特殊数据包，actions为从交换机的某个端口进行转发，如果发出这个数据包的端口另一端也连接一个openflow交换机，对端的交换机会产生一个packet-in消息将这个特殊的数据包包上交给控制器，从而控制器他侧到一条链路的存在（控制器实现链路发现，就是依靠packet-out消息）。

当控制器断电或者交换机与控制器之间的连接断开，则交换机会寻找备用控制器，当无法找到备用控制器时便会进入紧急模式（交换机初始化时也是在这个模式下），在紧急模式下，交换机默认将所有接受到的数据包丢弃。

控制器向交换机下发OFPT_PACKET_OUT消息。如下所示

（7）port_status

当交换机端口发生变化时，告知控制器相应的端口状态。如下所示

(8)、交互图

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

分析wireshark抓包，可以看出交换器与控制器建立通信时使用的是TCP协议。

(二)进阶要求

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

(1)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. */

};

/* OFPT_HELLO. This message has an empty body, but implementations must

* ignore any data included in the body, to allow for future extensions. */

struct

ofp_hello

{

struct

ofp_header

header;

};

(2)Features Request

与Hello中的数据格式相同

(3)Set Conig

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

};

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

];

/* Align to 64-bits. */

struct

ofp_phy_port

desc;

};

(5)Features Reply

/* Description of a physical port */

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

};

/* 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[

];

/* 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[

];

/* Port definitions. The number of ports

is inferred from the length field in

the header. */

};

(6)Packet_in

/* Why is this packet being sent to the controller? */

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[

];

/* 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)Flow_mod

/* Fields to match against flows */

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[

];

/* 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[

];

/* 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[

];

/* The action length is inferred

from the length field in the

header. */

};

(8)Packet_out

/* Action header that is common to all actions. The length includes the

* header and any padding used to make the action 64-bit aligned.

* NB: The length of an action *must* always be a multiple of eight. */

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[

];

};

OFP_ASSERT

sizeof

(

struct

ofp_action_header) ==

);

/* 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[

];

/* 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协议的理解：更加深入地理解了OpenFlow协议的基本原理和工作机制，掌握了报文的格式和字段含义。

在编写控制器应用程序的过程中，我提高了自己的网络编程能力，熟悉了SDN网络编程的基本流程和技巧。

在实验过程中，我遇到了许多问题，但通过查阅资料和不断尝试，我最终解决了这些问题，锻炼了自己的分析问题和解决问题的能力。

张梦婕289

关注

24
点赞
踩
11

收藏

觉得还不错? 一键收藏
0
评论
OpenFlow协议分析

实践成果加深了对OpenFlow协议的理解：更加深入地理解了OpenFlow协议的基本原理和工作机制，掌握了报文的格式和字段含义。在编写控制器应用程序的过程中，我提高了自己的网络编程能力，熟悉了SDN网络编程的基本流程和技巧。在实验过程中，我遇到了许多问题，但通过查阅资料和不断尝试，我最终解决了这些问题，锻炼了自己的分析问题和解决问题的能力。
复制链接

扫一扫