标签：控制器 OFPT OpenFlow 实践 header ofp 交换机 实验 port

实验3：OpenFlow协议分析实践

一、实验目的

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

二、实验环境

Ubuntu 20.04 Desktop amd64

三、实验要求

（一）基本要求

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

ip和拓扑

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

HELLO

控制器6633端口（我最高能支持OpenFlow 1.0） ---> 交换机56960端口

交换机56960端口（我最高能支持OpenFlow 1.5） ---> 控制器6633端口

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

FEATURES_REQUEST

控制器6633端口（我需要你的特征信息） ---> 交换机56960端口

SET_CONFIG

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

PORT_STATUS

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

FEATURES_REPLY

交换机56960端口（这是我的特征信息，请查收） ---> 控制器6633端口

PACKET_IN

交换机56960端口（有数据包进来，请指示）--->控制器6633端口

PACKET_OUT

控制器6633端口--->交换机56960端口（请按照我给你的action进行处理）

FLOW_MOD

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

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

三次握手建立连接

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

如图所示为（Transmission Control Protocol)TCP协议

（二）进阶要求

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

OpenFlow消息

Openflow消息总共分为三大类：
1、Controller-to-Switch（控制器至交换机消息），此类消息由控制器主动发出

Features 在建立传输层安全会话的时候，控制器发送feature请求(OFPT_FEATURES_REQUEST)消息给交换机，交换机需要应答(OFPT_FEATURES_REPLY)自身支持的功能。
Configuration 控制器设置或查询交换机上的配置信息。交换机仅需要应答查询消息。
Modify-State 控制器管理交换机流表项和端口状态等。
Read-State 用来读取交换机流表、端口状态
Send-Packet 用来通过指定端口发送数据包
Barrier 控制器确保消息依赖满足，或接收完成操作的通知（OFPT_BARRIER_REQUEST、OFPT_BARRIER_REPLY）

     / *交换机配置消息。 * /

     OFPT_FEATURES_REQUEST，

     OFPT_FEATURES_REPLY，

     OFPT_GET_CONFIG_REQUEST，

     OFPT_GET_CONFIG_REPLY，

     OFPT_SET_CONFIG，

     / *控制器命令消息。 * /

     OFPT_PACKET_OUT，

     OFPT_FLOW_MOD，

     OFPT_PORT_MOD，

     / *统计信息。 * /

     OFPT_STATS_REQUEST，

     OFPT_STATS_REPLY，

     / *障碍消息。 * /

     OFPT_BARRIER_REQUEST，

     OFPT_BARRIER_REPLY，

     / *队列配置消息。 * /

     OFPT_QUEUE_GET_CONFIG_REQUEST，

     OFPT_QUEUE_GET_CONFIG_REPLY

2、Asynchronous（异步消息），此类消息由交换机主动发出

Packet-in 用来告知控制器交换机接收到数据包
Flow-Removed用来告知控制器交换机流表被删除>Port-Status用来告知控制器交换机端口状态更新
Error用来告知控制器交换机发生错误

OFPT_PACKET_IN,          
OFPT_FLOW_REMOVED,     
OFPT_PORT_STATUS,
OFPT_ERROR,

3、Symmetric（对称消息），此类消息可以由控制器或交换机主动发起

Hello用来建立Openflow连接
Echo用来确认交换机与控制器之间的连接状态
Vendor厂商自定义消息

OFPT_HELLO,
OFPT_ECHO_REQUEST,  
OFPT_ECHO_REPLY,   
OFPT_VENDOR,        

1、对称消息

建立OpenFlow连接（OFPT_HELLO消息）
控制器与交换机互相发送Hello消息，Hello消息中只包含Openflow Header，Openflow Header中的version字段为发送方所支持的最高版本Openflow协议
双方选取Hello消息中最低版本的协议作为通信协议如果有一方不支持Openflow协议版本，应发送Error消息后断开连接
如果双方Openflow版本可以兼容，则Openflow连接建立成功。

HEADER——ofp_header

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

HELLO

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

获取交换机特性信息（Features消息）

Openflow连接建立后，控制器最需要获得交换机的特性信息，交换机的特性信息包括交
换机的ID（DPID），交换机缓冲区数量，交换机端口及端口属性等等。
控制器向交换机发送Features Request消息查询交换机特性，Features Request消息只包含Openflow Header。
交换机在收到Features Request消息后返回Features Reply消息，Features Reply消息包括Openflow Header 和Features Reply Message

FEATURES_REQUEST

源码参数格式与HELLO的一致

SET_CONFIG

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

物理接口描述——ofp_phy_port

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

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

2、异步消息

PACKET_IN

Packet-in消息触发情况1：
当交换机收到一个数据包后，会查找流表，找出与数据包包头相匹配的条目。
如果流表中有匹配条目，则交换机按照流表所指示的action列表处理数据包。
如果流表中没有匹配条目，则交换机会将数据包封装在Packet-in消息中发送给控制器处理。此时数据包会被缓存在交换机中等待处理。

Packet-in消息触发情况2：

交换机流表所指示的action列表中包含转发给控制器的动作（Output=CONTROLLER）。
此时数据包不会被缓存在交换机中。
本次实验中：交换机发现没有匹配的流表(Reason: No matching flow (table-miss flow entry) (0) )

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

3、控制器-交换机消息

1、控制器配置流表（Flow-Mod消息）

FLOW_MOD

用Flow-Mod消息响应Packet-in消息

当交换机收到一个数据包并且交换机中没有与该数据包匹配的流表项时，交换机将此数据包封装到Packet-in消息中发送给控制器，并且交换机会将该数据包缓存。
控制器收到Packet-in消息后，可以发送Flow-Mod消息向交换机写一个流表项。并且将Flow-Mod消息中的buffer_id字段设置为Packet-in消息中的buffer_id值。从而控制器向交换机写入了一条与数据包相关的流表项，并且指定该数据包按照此流表项的aciton列表处理。

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

2、交换机转发数据包（Packet-Out消息）

PACKET_OUT

并不是所有的数据包都需要向交换机中添加一条流表项来匹配处理，网络中还存在多种数据包，它出现的数量很少（如ARP、IGMP等），以至于没有必要通过流表项来指定这一类数据包的处理方法。
此时，控制器可以使用PacketOut消息，告诉交换机某一个数据包如何处理。

/* 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.) */
};
/* 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[4];
};
/* 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. */
enum ofp_action_type {
    OFPAT_OUTPUT,           /* Output to switch port. */
    OFPAT_SET_VLAN_VID,     /* Set the 802.1q VLAN id. */
    OFPAT_SET_VLAN_PCP,     /* Set the 802.1q priority. */
    OFPAT_STRIP_VLAN,       /* Strip the 802.1q header. */
    OFPAT_SET_DL_SRC,       /* Ethernet source address. */
    OFPAT_SET_DL_DST,       /* Ethernet destination address. */
    OFPAT_SET_NW_SRC,       /* IP source address. */
    OFPAT_SET_NW_DST,       /* IP destination address. */
    OFPAT_SET_NW_TOS,       /* IP ToS (DSCP field, 6 bits). */
    OFPAT_SET_TP_SRC,       /* TCP/UDP source port. */
    OFPAT_SET_TP_DST,       /* TCP/UDP destination port. */
    OFPAT_ENQUEUE,          /* Output to queue.  */
    OFPAT_VENDOR = 0xffff
};
/* Action structure for OFPAT_OUTPUT, which sends packets out 'port'.
 * When the 'port' is the OFPP_CONTROLLER, 'max_len' indicates the max
 * number of bytes to send.  A 'max_len' of zero means no bytes of the
 * packet should be sent.*/
struct ofp_action_output {
    uint16_t type;                  /* OFPAT_OUTPUT. */
    uint16_t len;                   /* Length is 8. */
    uint16_t port;                  /* Output port. */
    uint16_t max_len;               /* Max length to send to controller. */
};

四、个人总结

1、本次实验中通过wireshark工具了解了OpenFlow 协议数据交互过程，交互过程中各种信息的往来，及相对应的含义

2、本次实验学会通过滤器输入“openflow_v1”或“openflow_v4”等进行数据包过滤，运用 wireshark 对 OpenFlow 协议数据交互过程进行抓包；借助包解析工具，分析与解释 OpenFlow协议的数据包交互过程与机制；将抓包结果对照OpenFlow源码，和上网查阅资料知晓OpenFlow 消息的类型和具体含义

3、在实验过程中第一次使用wireshark时并没有考虑另一个hello协议的交互并不一定基于openflow 1.0，事实也证明了另一项hello的协议基于openflow 1.5，因此在第一次直接通过通过滤器输入“openflow_v1”或“openflow_v4”等进行数据包过滤，会出现一次hello的情况（无目的地址向源地址发送hello的数据报）。

标签：控制器,OFPT,OpenFlow,实践,header,ofp,交换机,实验,port
From： https://www.cnblogs.com/soya-hzy/p/16728596.html