openflow1.0协议消息wireshark抓包解析

Posted 2022-12-11 Itzel_yuki

Openflow消息类型包括：

enum ofp_type 

/* Immutable messages. */
OFPT_HELLO, /* Symmetric message */
OFPT_ERROR, /* Symmetric message */
OFPT_ECHO_REQUEST, /* Symmetric message */
OFPT_ECHO_REPLY, /* Symmetric message */
OFPT_VENDOR, /* Symmetric message */
/* Switch configuration messages. */
OFPT_FEATURES_REQUEST, /* Controller/switch message */
OFPT_FEATURES_REPLY, /* Controller/switch message */
OFPT_GET_CONFIG_REQUEST, /* Controller/switch message */
OFPT_GET_CONFIG_REPLY, /* Controller/switch message */
OFPT_SET_CONFIG, /* Controller/switch message */
/* Asynchronous messages. */
OFPT_PACKET_IN, /* Async message */
OFPT_FLOW_REMOVED, /* Async message */
OFPT_PORT_STATUS, /* Async message */
/* Controller command messages. */
OFPT_PACKET_OUT, /* Controller/switch message */
OFPT_FLOW_MOD, /* Controller/switch message */
OFPT_PORT_MOD, /* Controller/switch message */
/* Statistics messages. */
OFPT_STATS_REQUEST, /* Controller/switch message */
OFPT_STATS_REPLY, /* Controller/switch message */
/* Barrier messages. */
OFPT_BARRIER_REQUEST, /* Controller/switch message */
OFPT_BARRIER_REPLY, /* Controller/switch message */
/* Queue Configuration messages. */
OFPT_QUEUE_GET_CONFIG_REQUEST, /* Controller/switch message */
OFPT_QUEUE_GET_CONFIG_REPLY /* Controller/switch message */
;

1、Hello消息

        控制器与交换机建立连接时由其中某一方发起Hello消息，双方协调协议版本号。Hello消息只有of包头，没有主体部分。
目的：协议协商。
内容：本方支持的最高版本的协议
成果：使用双方都支持的最低版本协议。
成功：建立连接
失败：OFPT_ERROR (TYPE:OFPT_HELLO_FAILED,CODE =0),终止连接。

（1）sw1向C发送Hello消息

 

（2）C分别向sw1和sw2回应Hello

 
        上面俩张图显示，交换机支持的openflow版本为1，控制器支持的版本为4（1.3），因此，采用openflow1.0。

2、Feature消息

        当sw跟controller完成连接之后，控制器会向交换机下发OFPT_FEATYRES_REQUEST的数据包，目的是请求交换机的信息。
        发送时间：连接建立完成之后
        发送数据：OFPT_FEATURES_REQUEST
        对称数据：OFPT_FEATURES_REPLY
        目的：获取交换机的信息

        OFPT_FEATURES_REQUEST：
        TYPE=5
        Without data（只有包头，没有数据）

（1）C向sw1、sw2发送feature_request消息

 

（2）sw1和sw2分别向C应答，发送feature_replay消息

        OFPT_FEATURES_REPLY：
        TYPE =6
        [0:8]为header（version、type、length、xid）
        [8:32]长度24byte为sw的features，包含如下：
        datapath_id：交换机的标识符，低48位是一个MAC地址，而高16位是自定义的。例如，用高16位代表VLAN ID区别一个物理交换机中的多个虚拟交换机。
        n_buffers：一次最多缓存的数据包数量。
        n_tables：表示交换机支持的流表数量。而每个流表可以设置不同的通配符和不同数量的流表项。控制器和交换机第一次通信的时候，控制器会从feature_reply消息中找出交换机支持多少流表，如果控制器还想了解大小、类型和流表查询的顺序，就发送一个ofpst_table stats请求，交换机必须按照数据包遍历流表的顺序把这些流表回复给控制器，并且精确匹配流表排在通配流表前。
        capabilities：所支持的功能。交换机的一些详细信息的bitmap
        Action：交换机支持的action类型的bitmap
        [32:]长度与端口数成正比,Of_port_desc list,交换机物理端口信息,，存放port的信息。每一个port信息长度为48byte。


 
 

3、Configuration消息

        控制器可以发送OFPT_SET_CONFIG / OFPT_GET_CONFIG_REQUEST消息设置/查询交换机配置参数，交换机只需响应OFPT_GET_CONFIG_REQUEST消息即可。

（1）控制器分别向sw1、sw2发送config消息

        C向sw1发送了set_config+barrier_request+get_config_reauets消息
 

（2）sw1应答，发送barrier_reply消息

           barrier_request/reply：保证在它之前的命令都已经被执行。

（3）sw1应答，发送get_config_reply消息

           Of交换机中需要控制器配置的属性有两个flags和miss_send_len。Flags用来指示交换机如何处理IP分片数据包，上图显示的是OEFC_FRAG_NORMAL,即为当作普通交换机处理；miss_send_len用来只是当一个交换机无法处理数据，将数据上报给控制器时发送的最大字节数。与转发action中的output中定义的max_len字段一致。

4、Stats消息

        数据包是为了某些目的而设计的，如OFPT_STATS_REQUEST && REPLY可以获得统计信息，我们可以利用统计信息做的事情就太多了。如：负载平衡， 流量监控等基于流量的操作。
        OFPT_STATS_REQUEST类型有很多，回复的类型也很多。
        Type：
        0:请求交换机版本信息，制造商家等信息。
        1:单流请求信息
        2:多流请求信息
        3:流表请求信息
        4:端口信息请求
        5:队列请求信息
        6:vendor请求信息，有时候没有定义。

（1）controller分别向sw1、sw2发送stats_request消息（stats_type=0）

 

（2）sw1应答，发送stats_reply消息

 

（3）aggregate_stats_request（stats_type=2）

 

（4）aggregate_stats_reply

           每一种请求信息都会对应一种回复信息。我们只介绍最重要的flow_stats_reply。
        结构：header(type=17)/reply_header()/flow_stats/wildcards/match/ flow_stats_data
        作用：携带流的统计信息，如通过的数据包个数，字节数。
        ofp_flow_stats(body[4:8])里面会有的table_id字段表明该流存放在哪一个流表里。
        flow_stats_data里面有packet_count和byte_count是最有价值的字段，流量统计就是由这两个字段提供的信息。
        如想统计某条流的速率：前后两个reply的字节数相减除以duration_time只差就可以求得速率，由速率我们可以做很多基于流量的app，如流量监控，负载均衡等等。
      

5、echo消息

        分类：对称信息 OFPT_ECHO_REQUEST, OFPT_ECHO_REPLY
        作用：查询连接状态，确保通信通畅。
        当没有其他的数据包进行交换时，controller会定期循环给sw发送OFPT_ECHO_REQUEST。

（1）echo_request

 

（2）echo_reply

 

6、Packet_out、Packet_in和flow_mod

注：其中的in和out针对控制器来说的

（1）Sw1向c发送packet_in消息

        Packet-in事件在以下两种情况下会被触发：
        1.当交换机收到一个数据包后，并未与流表中匹配成功，那么交换机就会将数据封装在Packer-in消息中，发送给控制器处理。此时数据包会被缓存在交换机中等待处理。
        2.交换机流表所指示的action列表中包含转发给控制器的动作（Output=Controller），此时数据不会被缓存在控制器中。
            其中：
        buffer_id是packet-in消息所携带的数据包在交换机中的缓存ID
        Total_len为data段的长度
        In_port数据包进入交换机的入端口号
        Reason为packet-in事件的产生原因
        同时，从reason的消息格式也可以看出触发packet-in的两种情况：OFPR_NO_MATCH和OFPR_ACTION。
  
 

（2）C向sw1发送flow_mod(add_flow)消息

        Flow-Mod消息用开添加、删除、修改openflow交换机的消息；Flow-Mod消息共有5种类型：ADD、DEKETE、DELETE-STRICT、MODIFY、MODIFY_STRICT。
        ADD类型消息用来添加一条新的流表项（flow entry）
        DELETE类型消息用来删除所有符合一定条件的流表项
        DELETE‐STRICT类型消息用来删除某一条指定的流表项
        MODIFY类型消息用来修改所有符合一定条件的流表项
        MODIFY‐STRICT类型息用来修改某一条指定的流表项
        *注意，Flow-Mod消息对应修改的是流表中的流表项（flow entry）而不是整个流表（flow table）。Of1.0协议中并不支持多级流表操作。
            上图中：
        Match为流表的match域，也就是上文所说的匹配过程中的of_match。
        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_被设置的时候，交换机将表项当作紧急表项，只有当与控制器连接断的时候才启用。

        Actions为action的列表。

        当packet-in消息发送的控制器后，控制器可以做出多种响应，其中就有flow-mod消息作为响应：交换机接收到数据包->交换机中没有该数据包的匹配流表项->交换机将数据包封装到packet-in消息中发往控制器并将该数据包缓存在本地->控制器接收到packet-in消息->发送flow-mod消息并将flow-mod中的buffer_id改为packetin中的buffer_id->控制器已向交换机写入一条与该数据包相关的流表项，并指定该数据包按照流表项做的action列表进行处理。

（3）C向sw1发送packet_out消息，命令sw1将包发送出去。

        除了flow-mod消息可以作为packet-in消息的响应，packet-out也可以作为packet-in消息的响应。在网络中还存在多种数据包，有些类型的数据包出现的数量非常少（如：ARP，ICMP），对于这种出现频率较低的数据包，并没有必要都向交换机添加一条流表项来匹配处理。此时，控制器可以使用packet-out消息，告诉交换机某一个数据包该如何处理。
        Packet-out的消息格式：
            上图中：
        buffer_id为交换机中缓存数据的buffer_id（同flow-mod）；特别注意的是当buffer_id为”-1”的时候，指定的缓冲区为packet-out消息的data段。
        In_port为packet-out消息提供额外的匹配信息，当packet-out的buffer_id=-1，并且action流表中指定了output=TABLE的动作，in_port将作为data段数据包的额外匹配信息进行流表查询。
        action_len指定了action列表的长度，用来区分actions和data段Data为一个缓冲区，可以存储一个以太网帧。




 
         Packet-out消息的应用场景：
        指定某一个数据包的处理方法
        让交换机产生一个数据包并按照action流表处理。
        典型应用：链路发现
        控制器向一个交换机发送packet-out消息，buffer_id=-1，data段为某种特殊数据包，actions为从交换机的某个端口进行转发，如果发出这个数据包的端口另一端也连接一个openflow交换机，对端的交换机会产生一个packet-in消息将这个特殊的数据包包上交给控制器，从而控制器他侧到一条链路的存在（控制器实现链路发现，就是依靠packet-out消息）。


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

参考：http://blog.csdn.net/sherkyoung/article/details/39159601