精华内容
下载资源
问答
  • OpenFlow协议通信流程解读 OpenFlow 通信流程 OFPT_HELLO 创建socket之后,sw跟controller会彼此发送hello数据包。 目的:协议协商。 内容:本方支持的最高版本的协议 成果:使用双方都支持的最低版本协议。 成功:...

    这玩意我还是再开一篇
    OpenFlow协议通信流程解读

    OpenFlow 通信流程

    OFPT_HELLO

    创建socket之后,sw跟controller会彼此发送hello数据包。

    目的:协议协商。
    内容:本方支持的最高版本的协议
    成果:使用双方都支持的最低版本协议。
    成功:建立连接
    失败:OFPT_ERROR (TYPE:OFPT_HELLO_FAILED,CODE =0),终止连接。

    OFPT_ERROR

    ofp_error_type = { 0: "OFPET_HELLO_FAILED",
                       1: "OFPET_BAD_REQUEST",
                       2: "OFPET_BAD_ACTION",
                       3: "OFPET_FLOW_MOD_FAILED",
                       4: "OFPET_PORT_MOD_FAILED",
                       5: "OFPET_QUEUE_OP_FAILED"}
    

    OFPT_FEATURES

    当sw跟controller完成连接之后,控制器会向交换机下发OFPT_FEATYRES_REQUEST的数据包,目的是请求交换机的信息。

    发送时间:连接建立完成之后
    发送数据:OFPT_FEATURES_REQUEST
    对称数据:OFPT_FEATURES_REPLY
    目的:获取交换机的信息

    OFPT_FEATURES_REQUEST

    TYPE=5
    Without data

    OFPT_FEATURES_REPLY

    TYPE =6
    [0:8]为header
    [8:32]长度24byte为sw的features
    [32:]长度与端口数成正比,存放port的信息。每一个port信息长度为48byte。

    OFPT_PACKET_IN

    展开全文
  • Openflow协议通信流程解读

    万次阅读 2013-12-30 19:01:50
    现在有时间了,就写一写自己对Openflow协议通信流程的一些理解。 SDN中Switch和controller 在SDN中很重要的两个实体是Switch跟Controller。Controller在网络中相当于上帝,可以知道网络中所有的消息,可以给...

    前言

    接触了这么久的SDN,Openflow协议前前后后也读过好多遍,但是一直没有时间总结一下自己的一些见解。现在有时间了,就写一写自己对Openflow协议通信流程的一些理解。

    SDN中Switch和controller

    在SDN中很重要的两个实体是Switch跟Controller。Controller在网络中相当于上帝,可以知道网络中所有的消息,可以给交换机下发指令。Switch就是一个实现Controller指令的实体,只不过这个交换机跟传统的交换机不一样,他的转发规则由流表指定,而流表由控制器发送。

    switch组成与传统交换机的差异

    switch组成

    switch由一个Secure Channel和一个flow table组成,of1.3之后table变成多级流表,有256级。而of1.0中table只在table0中。

    • Secure Channel是与控制器通信的模块,switch和controller之间的连接时通过socket连接实现。
    • Flow table里面存放这数据的转发规则,是switch的交换转发模块。数据进入switch之后,在table中寻找对应的flow进行匹配,并执行相应的action,若无匹配的flow则产生packet_in(后面有讲)

    of中sw与传统交换机的差异

    • 匹配层次高达4层,可以匹配到端口,而传统交换机只是2层的设备。
    • 运行of协议,实现许多路由器的功能,比如组播。
    • 求补充!!(如果你知道,请告诉我,非常感谢!)

    openflow的switch可以从以下方式获得

    • 实体of交换机,目前市场上有一些厂商已经制造出of交换机,但是普遍反映价格较贵!性能最好。
    • 在实体机上安装OVS,OVS可以使计算机变成一个openflow交换机。性能相对稳定。
    • 使用mininet模拟环境。可以搭建许多交换机,任意拓扑,搭建拓扑具体教程本博客有一篇。性能依赖虚拟机的性能。

    controller组成

    控制器有许多种,不同的语言,如python写的pox,ryu,如java写的floodlight等等。从功能层面controller分为以下几个模块:

    • 底层通信模块:openflow中目前controller与switch之间使用的是socket连接,所以控制器底层的通信是socket。
    • openflow协议。socket收到的数据的处理规则需按照openflow协议去处理。
    • 上层应用:根据openflow协议处理后的数据,开发上层应用,比如pox中就l2_learning,l3_learning等应用。更多的应用需要用户自己去开发。

    Openflow通信流程

    以下教程环境为:mininet+自编简单控制器

    建立连接

    首先启动mininet,mininet会自行启动一个default拓扑,你也可以自己建立你的拓扑。sw建立完成之后,会像controllerIP:controllerport发送数据。

    controller启动之后,监听指定端口,默认6633,但是好像以后的都改了,因为该端口被其他协议占用。

    3次握手之后,建立连接,这个是底层的通信,是整一套系统的基础设施。

    OFPT_HELLO

    创建socket之后,sw跟controller会彼此发送hello数据包。

    • 目的:协议协商。
    • 内容:本方支持的最高版本的协议
    • 成果:使用双方都支持的最低版本协议。
    • 成功:建立连接
    • 失败:OFPT_ERROR (TYPE:OFPT_HELLO_FAILED,CODE =0),终止连接。

    OFPT_ERROR

    说到OFPT_ERROR,我们不妨先了解一下。

    ofp_error_type = { 0: "OFPET_HELLO_FAILED",
                       1: "OFPET_BAD_REQUEST",
                       2: "OFPET_BAD_ACTION",
                       3: "OFPET_FLOW_MOD_FAILED",
                       4: "OFPET_PORT_MOD_FAILED",
                       5: "OFPET_QUEUE_OP_FAILED"}
    

    错误类型如上所示。对应的type还会有对应的code.所以报错的格式为:

    OFPT_ERROR
    TYPE: 
    CODE:
    [PAYLOAD]具体的错误信息。
    

    如 TYPE:0 CODE:0为:*OFPHFC_INCOMPATIBLE*

    具体对应的关系,请自行查看OF协议。

    OFPT_ECHO

    • 分类:对称信息 OFPT_ECHO_REQUEST, OFPT_ECHO_REPLY
    • 作用:查询连接状态,确保通信通畅。

    当没有其他的数据包进行交换时,controller会定期循环给sw发送OFPT_ECHO_REQUEST。

    OFPT_FEATURES

    当sw跟controller完成连接之后,控制器会向交换机下发OFPT_FEATYRES_REQUEST的数据包,目的是请求交换机的信息。

    • 发送时间:连接建立完成之后
    • 发送数据:OFPT_FEATURES_REQUEST
    • 对称数据:OFPT_FEATURES_REPLY
    • 目的:获取交换机的信息

    OFPT_FEATURES_REQUEST

    • TYPE=5
    • Without data

    OFPT_FEATURES_REPLY

    • TYPE =6
    • [0:8]为header
    • [8:32]长度24byte为sw的features
    • [32:]长度与端口数成正比,存放port的信息。每一个port信息长度为48byte。

      class ofp_features_reply(Packet):
          name = "OpenFlow Switch Features Reply"
          fields_desc=[ BitFieldLenField('datapath_id', None, 64, length_of='varfield'),
                        BitFieldLenField('n_buffers', None, 32, length_of='varfield'),
                        XByteField("n_tables", 0),
                        X3BytesField("pad", 0),
                        #features
                        BitField("NOT DEFINED", 0, 24),
                        BitField("OFPC_ARP_MATCH_IP", 0, 1),  #1<<7 Match IP address in ARP packets
                        BitField("OFPC_QUEUE_STATS", 0, 1),   #1<<6 Queue statistics
                        BitField("OFPC_IP_STREAM", 0, 1),     #1<<5 Can reassemble IP fragments
                        BitField("OFPC_RESERVED", 0, 1),      #1<<4 Reserved, must be zero
                        BitField("OFPC_STP", 0, 1),           #1<<3 802.1d spanning tree
                        BitField("OFPC_PORT_STATS", 0, 1),    #1<<2 Port statistics
                        BitField("OFPC_TABLE_STATS", 0, 1),   #1<<1 Table statistics
                        BitField("OFPC_FLOW_STATS", 0, 1),    #1<<0 Flow statistics
                        BitFieldLenField('actions', None, 32, length_of='varfield'),
                      ]
      bind_layers( ofp_header, ofp_features_reply, type=6 )
      

    以上的结构是交换机的features,紧跟在后面的是端口的结构:

    class ofp_phy_port(Packet):
        name = "OpenFlow Port"
        fields_desc=[ ShortEnumField("port_no", 0, ofp_port),
                      MACField("hw_addr", "00:00:00:00:00:00"),
                      StrFixedLenField("port_name", None, length=16),
                      BitField("not_defined", 0, 25),
                      BitField("OFPPC_NO_PACKET_IN", 0, 1),
                      BitField("OFPPC_NO_FWD", 0, 1),
                      BitField("OFPPC_NO_FLOOD", 0, 1),
                      BitField("OFPPC_NO_RECV_STP",0, 1),
                      BitField("OFPPC_NO_RECV", 0, 1),
                      BitField("OFPPC_NO_STP", 0, 1),
                      BitField("OFPPC_PORT_DOWN", 0, 1),
    
                      #uint32_t for state
                      BitField("else", 0, 31),
                      BitField("OFPPS_LINK_DOWN", 0, 1),
    
                      #uint32_t for Current features
                      BitField("not_defined", 0, 20),
                      BitField("OFPPF_PAUSE_ASYM", 0, 1),
                      BitField("OFPPF_PAUSE", 0, 1),
                      BitField("OFPPF_AUTONEG", 0, 1),
                      BitField("OFPPF_FIBER", 0, 1),
                      BitField("OFPPF_COPPER", 0, 1),
                      BitField("OFPPF_10GB_FD", 0, 1),
                      BitField("OFPPF_1GB_FD", 0, 1),
                      BitField("OFPPF_1GB_HD", 0, 1),
                      BitField("OFPPF_100MB_FD", 0, 1),
                      BitField("OFPPF_100MB_HD", 0, 1),
                      BitField("OFPPF_10MB_FD", 0, 1),
                      BitField("OFPPF_10MB_HD", 0, 1),
    
                      #uint32_t for features being advised by the port
                      BitField("advertised", 0, 32),
    
                      #uint32_t for features supported by the port
                      BitField("supported", 0, 32),
    
                      #uint32_t for features advertised by peer
                      BitField("peer", 0, 32)]
    

    交换机和端口的配置信息在整一个通信过程起着至关的作用,因为所有关于的操作都需要从features里面提取相关的信息,如dpid,port_no,等在整个通信过程中多次被用到的重要数据。所以,对这两个数据结构了然于心,对于研究openflow来说,至关重要。每一次交换机连到控制器,都会收到控制器的features_request,当sw将自己的features回复给控制器之后,控制器就对交换机有了一个全面的了解,从而为后面的控制提供的控制信息。

    OFPT_PACKET_IN

    在控制器获取完交换机的特性之后,交换机开始处理数据。

    对于进入交换机而没有匹配流表,不知道如何操作的数据包,交换机会将其封装在packet_in中发给controller。包含在packet_in中的数据可能是很多种类型,arp和icmp是最常见的类型。

    当然产生packet_in的原因不止一种,产生packet_in的原因主要有一下两种:

    • OFPR_NO_MATCH
    • OFPR_ACTION

    无法匹配的数据包会产生packet_in,action也可以指定将数据包发给packet_in,也就是说我们可以利用这一点,将需要的数据包发给控制器。

    packet_in事件之后,一般会触发两类事件:

    • packet_out
    • flow_mod

    如果是广播包,如arp,控制器一般会将其包装起来,封装成packet_out数据包,将其发给交换机,让其flood,flood操作是将数据包往除去in_port以外的所有端口发送数据包。

    OFPT_PACKET_OUT

    很多人不是特别了解packet_out的作用。

    • 作用:通过控制器发送交换机希望发送的数据
    • 例子:arp在广播的时候,在ofsw中不能直接将arp广播,而是,将其封装在packet_out里面,交换机泛洪的是packet_out。

    我个人观点,这个数据包,是一个兼容性之的数据包,为了实现信令,不得不处理arp,但是arp又不能直接处理,所以将其封装在packet_out,从而能够在of的sw中传播,从而在openflow里实现arp等IP网的功能。

    OFPT_FLOW_MOD

    OFPT_FLOW_MOD是整一个Openflow协议中最重要的数据结构,没有之一。

    OFPT_FLOW_MOD由header+match+flow_mod+action[]组成。为了操作简单,以下的结构是将wildcards和match分开的形式,形成两个结构,在编程的时候能更方便一些。由于这个数据包很重要,所以,我将把这个数据包仔细拆分解读。

    flow_mod = of.ofp_header(type=14,length=72)/of.ofp_flow_wildcards(OFPFW_NW_TOS=1,
                                      OFPFW_DL_VLAN_PCP=1,
                                      OFPFW_NW_DST_MASK=0,
                                      OFPFW_NW_SRC_MASK=0,
                                      OFPFW_TP_DST=1,
                                      OFPFW_TP_SRC=1,
                                      OFPFW_NW_PROTO=1,
                                      OFPFW_DL_TYPE=1,
                                      OFPFW_DL_VLAN=1,
                                      OFPFW_IN_PORT=1,
                                      OFPFW_DL_DST=1,
                                      OFPFW_DL_SRC=1)\
               /of.ofp_match(in_port=msg.payload.payload.payload.in_port,
                             dl_src=pkt_parsed.src,
                             dl_dst=pkt_parsed.dst,
                             dl_type=pkt_parsed.type,
                             dl_vlan=pkt_parsed.payload.vlan,
                             nw_tos=pkt_parsed.payload.tos,
                             nw_proto=pkt_parsed.payload.proto,
                             nw_src=pkt_parsed.payload.src,
                             nw_dst=pkt_parsed.payload.dst,
                             tp_src = 0,
                             tp_dst = 0)\
               /of.ofp_flow_mod(cookie=0,
                                command=0,
                                idle_timeout=10,
                                hard_timeout=30,
                                out_port=msg.payload.payload.payload.payload.port,
                                buffer_id=buffer_id,
                                flags=1)
    

    OFP_HEADER

    header是所有数据包的报头,有三个参数:

    • type:类型
    • length:整个数据包的长度
    • xid:数据包的编号

    比如ofp_flow_mod的type就是14,具体的哪一种数据的类型将在文章最后给出。length最基本长度为72,每一个action长度为8。所以长度必定为8的倍数才是一个正确的数据长度。

    WILDCARDS

    这是从match域提取出来的前32bit。

    在of1.0中这里的0,1意义跟我们平时接触的如子网掩码等意义相反,如OFPFW_NW_DST_MASK=0则表示全匹配目标IP。如果为63,则表示不匹配IP。为什么拿这个举例?原因就在于,他的长度是6bit,最大是63,需要将数值转变成对应2进制数值才是我们想要的匹配规则,且注意,1是忽略,0是匹配。如果wildcards全0,则表示由match精确指定,即所有12元组都匹配。

    当然高兴的是,在1.3的时候,这个逻辑改成了正常的与逻辑。即1为使能匹配,0为默认不匹配。

    MATCH

    这个数据结构会出现在机会所有重要的数据包中,因为他存的就是控制信息。

    如有packet_in引发的下发流表,则match部分应对应填上对应的数据,这样下发的流表才是正确的。

    但是在下发的时候还需要注意许多细节,比如:

    • 并不是所有的数据包都有vlan_tag。如0x0800就是纯IP,并没有携带vlan_tag,所以填充式应根据packet_in的具体情况填充。
    • 并不是所有的数据都有四层端口,所以四层的源端口,目的端口都不是任何时候都能由packet_in去填充的。不去管就好了,默认的会填充一个默认值,匹配的时候不去匹配4层端口就没有问题。

    FLOW_MOD

    这里面的信息也是至关重要的。

    class ofp_flow_mod(Packet):
        name = "OpenFlow Flow Modify"
        fields_desc=[ BitField("cookie", 0, 64), #Opaque controller-issued identifier
                      ShortEnumField("command", 0, ofp_flow_mod_command),
                      ShortField("idle_timeout", 60),
                      ShortField("hard_timeout", 0),
                      ShortField("priority", 0),
                      IntField("buffer_id", 0),
                      ShortField("out_port", 0),
                      #flags are important, the 1<<0 bit is OFPFF_SEND_FLOW_REM, send OFPT_FLOW_REMOVED
                      #1<<1 bit is OFPFF_CHECK_OVERLAP, checking if the entries' field overlaps(among same priority)  
                      #1<<2 bit is OFPFF_EMERG, used only switch disconnected with controller) 
                      ShortField("flags", 0)]
    

    command里面的类型决定了flow_mod的操作是添加,修改还是删除等。类型如下

    ofp_flow_mod_command = { 0: "OFPFC_ADD",            # New flow
                             1: "OFPFC_MODIFY",         # Modify all matching flows
                             2: "OFPFC_MODIFY_STRICT",  # Modify entry strictly matching wildcards
                             3: "OFPFC_DELETE",         # Delete all matching flows
                             4: "OFPFC_DELETE_STRICT"}  # Strictly match wildcards and priority
    

    例如:如果要添加一条新流,command=0。

    两个时间参数idle_timeout & idle_timeout:

    • idle_timeout:如值为10,则某条流在10秒之内没有被匹配,则删除,可以称之为活跃时间吧。
    • hard_timeout:如值为30,则30秒到达的时候,一定删除这条流,即使他还活跃,即被匹配。

    priority

    priority是流的优先级的字段,字数越大则优先级越高,存放在号数越小的table中

    buffer_id

    由交换机指定的buffei_id,准确的说是由dpid指定的。如果是手动下发的流,buffer_id应填-1,即0xffff,告诉交换机这个数据包并没有缓存在队列中。

    out_port

    指定流的出口,但是这个出口并不是直接指导流转发的,至少我是这么觉得,指导流转发的出口会在action里面添加,这个端口是为了在flow_removed的时候查询,并返回控制器的作用。(求纠正!)

    有一些端口是很特殊的,如flood,local等。具体分类如下:

    ofp_port = { 0xff00: "OFPP_MAX",
                 0xfff8: "OFPP_IN_PORT",
                 0xfff9: "OFPP_TABLE",
                 0xfffa: "OFPP_NORMAL",
                 0xfffb: "OFPP_FLOOD",
                 0xfffc: "OFPP_ALL",
                 0xfffd: "OFPP_CONTROLLER",
                 0xfffe: "OFPP_LOCAL",
                 0xffff: "OFPP_NONE"}
    

    如果你不知道端口是多少,最好填flood,也就是0xfffb。

    flags

    在上面的注释中也说得比较清楚了。如果没有特殊用处,请将他置1,因为这样能让交换机在删除一条流的时候给交换机上报flow_removed信息。

    ACTION

    action是openflow里面最重要的结构。对,他也是最重要的。每一条流都必须指定必要的action,不然匹配上之后,没有指定action,交换机会默认执行drop操作。

    action有2种类型:

    • 必备行动: Forward and Drop

    • 选择行动:FLOOD,NALMAL 等

    如添加output就是一个必须要添加的action.每一个action最好有一个action_header(),然后再接一个实体。如:

    ofp_action_header(type=0)/ofp_action_output(type =0, port =oxfffb,len =8)
    

    具体的action类型如下:

    ofp_action_type = { 0: "OFPAT_OUTPUT",
                        1: "OFPAT_SET_VLAN_VID",
                        2: "OFPAT_SET_VLAN_PCP",
                        3: "OFPAT_STRIP_VLAN",
                        4: "OFPAT_SET_DL_SRC",
                        5: "OFPAT_SET_DL_DST",
                        6: "OFPAT_SET_NW_SRC",
                        7: "OFPAT_SET_NW_DST",
                        8: "OFPAT_SET_NW_TOS",
                        9: "OFPAT_SET_TP_SRC",
                        10: "OFPAT_SET_TP_DST",
                        11: "OFPAT_ENQUEUE"
                        }
    

    action不仅仅会出现在flow_mod中,也会出现在如stats_reply中。

    OFPT_BARRIER_REQUEST && REPLY

    这个数据包可以的作用很简单,交换机在收到OFPT_BARRIER_REQUEST的时候,会回复控制器一个OFPT_BARRIER_REPLY。我们默认数据下发的顺序不会在传输中发生变化,在进入消息队列之后处理也是按照FIFO进行的,那么只要在flow_mod之后发送这个数据,当收到reply之后,交换机默认flow已经写成功。也许你会问他只是保证了flow_mod命令执行了,写入的结果如何并没有保证,如何确定确实写入流表了呢?

    • 如果非逻辑错误,那么交换机在处理flow_mod的时候会报错。所以我们会知道写入结果。
    • 如果是逻辑错误,那么会写进去,但是逻辑错误应该是人的问题,所以barrier还是有他的功能的。

    OFPT_FLOW_REMOVED

    如果flow_mod的flags填成1,则该流在失效之后会回复控制器一条OFPT_FLOW_REMOVED信息。

    • 结构:header()/wildcards()/match()/flow_removed()
    • 作用:在流失效的时候回复控制器,并携带若干统计数据。

      class ofp_flow_removed(Packet):
        name = "Openflow flow removed"
        fields_desc = [ BitField("cookie", 0, 64),
                        BitField("priority", 0,16),
                        BitField("reason", 0, 8),
                        ByteField("pad", None),
                        BitField("duration_sec", 0, 32),
                        BitField("duration_nsec", 0, 32),
                        BitField("idle_timeout", 0, 16),
                        ByteField("pad", 0),
                        ByteField("pad", 0),
                        BitField("packet_count", 0, 64),
                        BitField("byte_count", 0, 64)
                      ]
      

    其实的duration_sec是流存在的时间,单位为秒,duration_nsec单位为纳秒。

    OFPT_STATS_REQUEST && REPLY

    以上的数据都是通信过程中必须的部分。还有一些数据包是为了某些目的而设计的,如OFPT_STATS_REQUEST && REPLY可以获得统计信息,我们可以利用统计信息做的事情就太多了。如:负载平衡, 流量监控等基于流量的操作。

    OFPT_STATS_REQUEST

    OFPT_STATS_REQUEST类型有很多,回复的类型也很多。

    class ofp_stats_request(Packet):
        name = "OpenFlow Stats Request"
        fields_desc=[ ShortEnumField("type", 0, ofp_stats_types),
                      ShortField("flag", 0)]
    

    Type

    • 0:请求交换机版本信息,制造商家等信息。
    • 1:单流请求信息
    • 2:多流请求信息
    • 3:流表请求信息
    • 4:端口信息请求
    • 5:队列请求信息
    • 6:vendor请求信息,有时候没有定义。

         msg = { 0: of.ofp_header(type = 16, length = 12)/of.ofp_stats_request(type = 0),                            #Type of  OFPST_DESC (0) 
                  1: of.ofp_header(type = 16, length = 56)/of.ofp_stats_request(type =1)/ofp_flow_wildcards/ofp_match/of.ofp_flow_stats_request(out_port = ofp_flow_mod.out_port),                  #flow stats
                  2: of.ofp_header(type = 16, length =56)/of.ofp_stats_request(type = 2)/ofp_flow_wildcards/of.ofp_match/of.ofp_aggregate_stats_request(),                                  # aggregate stats request
                  3: of.ofp_header(type = 16, length = 12)/of.ofp_stats_request(type = 3),                            #Type of  OFPST_TABLE (0) 
                  4: of.ofp_header(type = 16, length =20)/of.ofp_stats_request(type = 4)/of.ofp_port_stats_request(port_no = port),   # port stats request    
                  5: of.ofp_header(type = 16, length =20)/of.ofp_stats_request(type =5)/of.ofp_queue_stats_request(), #queue request
                  6: of.ofp_header(type = 16, length = 12)/of.ofp_stats_request(type = 0xffff)                        #vendor request
              }
      

    OFPT_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,如流量监控,负载均衡等等。

    值得注意的是,在这些数据之后,其实还有一些action,但是目前我还没有查看这些action到底是干什么用的。

    后续

    写到这里,我使用到的数据包都写了一遍,其他的报文其实道理也是一样的。如OFPT_GET_CONFIG_REQUEST和REPLY,道理应该和stats一样,只是数据结构不一样罢了。不再多说。

    最后把我们用的一些比较多的信息帖出来让大家更好的学习。

    ERROR

    在调试的过程中遇到错误是再所难免的,前面也提到了error的结构。这里就贴一下type跟code吧。

    Type

    ofp_error_type = { 0: "OFPET_HELLO_FAILED",
                       1: "OFPET_BAD_REQUEST",
                       2: "OFPET_BAD_ACTION",
                       3: "OFPET_FLOW_MOD_FAILED",
                       4: "OFPET_PORT_MOD_FAILED",
                       5: "OFPET_QUEUE_OP_FAILED"}
    

    Code:

    ofp_hello_failed_code = { 0: "OFPHFC_INCOMPATIBLE",
                              1: "OFPHFC_EPERM"}
    
    ofp_bad_request_code = { 0: "OFPBRC_BAD_VERSION",
                             1: "OFPBRC_BAD_TYPE",
                             2: "OFPBRC_BAD_STAT",
                             3: "OFPBRC_BAD_VENDOR",
                             4: "OFPBRC_BAD_SUBTYPE",
                             5: "OFPBRC_EPERM",
                             6: "OFPBRC_BAD_LEN",
                             7: "OFPBRC_BUFFER_EMPTY",
                             8: "OFPBRC_BUFFER_UNKNOWN"}
    
    ofp_bad_action_code = { 0: "OFPBAC_BAD_TYPE",
                            1: "OFPBAC_BAD_LEN",
                            2: "OFPBAC_BAD_VENDOR",
                            3: "OFPBAC_BAD_VENDOR_TYPE",
                            4: "OFPBAC_BAD_OUT_PORT",
                            6: "OFPBAC_BAD_ARGUMENT",
                            7: "OFPBAC_EPERM",          #permissions error
                            8: "OFPBAC_TOOMANY",
                            9: "OFPBAC_BAD_QUEUE"}
    
    ofp_flow_mod_failed_code = { 0: "OFPFMFC_ALL_TABLES_FULL",
                                 1: "OFPFMFC_OVERLAP",
                                 2: "OFPFMFC_EPERM",
                                 3: "OFPFMFC_BAD_EMERG_TIMEOUT",
                                 4: "OFPFMFC_BAD_COMMAND",
                                 5: "OFPFMFC_UNSUPPORT"}
    
    ofp_port_mod_failed_code = { 0: "OFPPMFC_BAD_PORT",
                                 1: "OFPPFMC_BAD_HW_ADDR"}
    
    ofp_queue_op_failed_code = { 0: "OFPQOFC_BAD_PORT",
                                 1: "OFPQOFC_BAD_QUEUE"}
    

    谢谢Richardzhao,kimi带我走进Openflow的世界。

    展开全文
  • openflow协议

    2020-09-21 10:39:07
    Open Networking Foundation openflow标准协议,版本为1.5版本,为SDN网络架构下的南北向通信协议,用于控制器和交换机之间的通信,控制器向交换机下发表项,用于交换机转发数据报文
  • OpenFlow协议

    2015-01-29 13:38:57
    OpenFlow协议标准解读,对协议标准的解读,通信过程的详解。
  • Openflow协议

    2018-06-08 16:08:58
    控制器与网络设备间需要一种协议才能互相通信,即为Openflow协议Openflow交换机中的转发表称为流表,流表中包含了:数据包匹配特征,数据包处理方法Openflow消息分为三种:1.Controller-to-Switch,由控制器主动发出...

    控制器与网络设备间需要一种协议才能互相通信,即为Openflow协议

    Openflow交换机中的转发表称为流表,流表中包含了:数据包匹配特征,数据包处理方法

    Openflow消息分为三种:1.Controller-to-Switch,由控制器主动发出,2,Asynchronous:异步消息,交换机主动发出,3.Symmetric对称消息,控制器或交换机主动发出

    控制器与交换机通过Openflow协议建立连接(通过三次握手完成socket连接)后,最先需要关心的要获取交换机的信息(switch的ID,switch缓冲数量,switch端口及端口属性)

    Controller  Features Request__>> switch

                     <<Features Reply

    Feature Reply中包含了Openflow Header和Features Reply Message


    展开全文
  • to-switch消息2.2 asynchronous信息(异步)2.3 symmtric消息(对称)3 Openflow消息格式3.1 OpenFlow头部3.2 OpenFlow消息体4 OpenFlow协议的主要通信流程5 OpenFlow通信流程详解 1 OpenFlow协议概述 OpenFlow...

    1 OpenFlow协议概述

    OpenFlow协议为控制器与交换机之间的通信,提供了一种开放标准的方式。OpenFlow交换机通过安全通道与控制器进行信息交互。

    2 OpenFlow消息类型

    在这里插入图片描述

    2.1 controller-to-switch消息

    由控制器发起,可能会要求交换机回复对应的消息
    在这里插入图片描述

    • Features消息:在建立传输安全会话时,控制器主动向交换机发Feature_Request消息,请求交换机的特性信息,交换机通过Feature_Reply消息回复所支持的功能特性
    • Modify-state消息:修改状态消息主要用于增加、修改、删除交换机的流表项、组表项及端口状态
    • Send-packet消息:一般用于响应Packet-in消息的处理,Packet-out信息必须携带一个Buffer_id,来定位缓存在交换机上的数据包
    • Barrier消息:用于告知控制器该报文之前的动作均已执行

    2.2 asynchronous信息(异步)

    用于告知控制器新数据包的到达和交换机状态的改变
    这类消息的触发不是由控制器触发,而是有交换机主动发起的,用于告知控制器新数据包的到达,和交换机状态的改变

    在这里插入图片描述

    2.3 symmtric消息(对称)

    由控制器或交换机任意一方发送,无需对方的许可或请求
    在这里插入图片描述

    3 Openflow消息格式

    3.1 OpenFlow头部

    Openflow协议数据包:Openflow Header和Openflow Message组成
    在这里插入图片描述
    在这里插入图片描述

    3.2 OpenFlow消息体

    与具体的消息类型有关,消息类型是一种枚举类型,每种消息类型被定义为一个常数
    在这里插入图片描述

    4 OpenFlow协议的主要通信流程

    1. 控制器和交换机连接的建立
      在这里插入图片描述
    2. 双方建立TLS隧道后,方法发送hello消息进行版本协商,如果协议版本协商成功,则连接建立。否则发送Error消息描述协商失败原因,并终止连接
      在这里插入图片描述
    3. 协商完成后,控制器和交换机之间发送Features消息,获取交换机参数,参数包括支持的buffer数目、流表数、Actions等
      在这里插入图片描述
    4. 控制器发送SET_CONFIG消息向交换机发送配置参数
      在这里插入图片描述
    5. 通过GET_CONFIG消息得到交换机修改后的配置信息
      在这里插入图片描述
    6. 制器与OpenFlow交换机之间,发送PACKET_OUT和PACKET_IN消息,通过PACKET_OUT中内置的LLDP包进行网络拓扑的探测
    7. 控制器通过FLOW_MOD向控制器下发流表操作
      在这里插入图片描述
      举例:
      在这里插入图片描述

    5 OpenFlow通信流程详解

    在这里插入图片描述

    展开全文
  • OpenFlow交换机 之 OpenFlow协议

    万次阅读 2014-04-30 13:21:18
    OpenFlow协议是用来描述控制器和OpenFlow交换机之间交互所用的信息的接口标准,其核心是OpenFlow协议信息的集合。OpenFlow协议支持三种消息类型:controller-to-switch、asynchronous(异步)和symmetric(对称),...
  • (三)OpenFlow协议

    千次阅读 2017-09-19 00:21:35
    在OpenFlow引入了“流”的概念之后,控制器可以根据某次通信中“流”的第一个数据分组的特征,使用OpenFlow协议提供的接口对数据平面设备部署策略——流表,而这次通信的后续流量则按照相应流表在硬件层次上进行匹配...
  • OpenFlow:简述对OpenFlow协议的认识

    千次阅读 2019-03-25 15:36:25
    OpenFlow:简述对OpenFlow协议的认识 一、OpenFlow协议的背景 转发和控制分离是SDN网络的本质特点之一 。在SDN网络架构中,控制平面与转发平面分离,网络的管理和状态在逻辑上集中到一起,底层的网络基础从应用中...
  • OpenFlow协议简介-ielab

    2019-08-21 14:06:58
    OpenFlow协议背景: 转发和控制分离是SDN网络的本质特点之一 。在SDN网络架构中,控制平面与转发平面分离,网络的管理和状态在逻辑上集中到一起,底层的网络基础从应用中独立出来,由此,网络获得前所未有的可编程、...
  • OpenFlow协议是什么

    千次阅读 2020-05-01 13:12:06
    为什么学习OpenFlow? 实践SDN的首选 主流南向接口协议 P4和PISA的前身 OpenFlow起源 ...一种网络通信协议,属于数据链路层,能够控制网上交换器或路由器的转发平面(forwarding plane),借此改变网络数...
  • OpenFlow通信流程解读

    2019-07-13 09:32:00
    现在有时间了,就写一写自己对OpenFlow协议通信流程的一些理解。 2SDN中Switch和controller 在SDN中很重要的两个实体是Switch跟Controller。Controller在网络中相当于上帝,可以知道网络中所有的消息,可以给...
  • OpenFlow协议分析

    千次阅读 2017-05-09 11:16:10
    学习SDN相关的学习也已经有快半年了,期间从一无所知到懵懵懂懂,再到现在的有所熟悉,经历了许多,也走了不少弯路,其中,最为忌讳的便是,我在学习过程中,尚未搞明白OpenFlow协议的情况下,便开始对SDN进行相关...
  • OpenFlow 协议详解(干货)

    万次阅读 2019-05-03 15:45:16
    自2009年底发布1.0版本后,OpenFlow协议又经历了1.1、1.2、1.3及1.4版本的演进过程,目前使用和支持最多的是1.0和1.3版本。OpenFlow1.3在1.0版的基础上进一步优化及升级,其中添加了很多新的特性及消息,如支持多个...
  • OpenFlow协议之殇?

    2017-09-01 10:51:00
    在过去,OpenFlow一度是SDN的代名词,只要是SDN出现的地方就不得...这个曾经的唯一选择究竟遇到了什么,难道这是OpenFlow协议之殇? 下面我们好好分析一下这个问题。这里首先得提到的就是ONF,OpenFlow协议标准的发...
  • SDN网络技术:OpenFlow协议(1)

    千次阅读 2019-09-07 15:11:39
    本文首发于我的公众号码农之屋(id:Spider1818),专注于干货分享,包含但不限于Java编程、网络技术、Linux内核...通过OpenFlow协议,SDN控制器与数据转发层之间建立了一个标准的通信接口。本文将对其背景及组件进行...
  • Openflow协议详解

    千次阅读 2018-12-14 16:25:00
    1 OpenFlow背景 转发和控制分离是SDN网络的本质特点之一 。在SDN网络架构中,控制平面与转发平面分离,网络的管理和状态在逻辑上集中到一起,底层的网络基础从应用中独立出来,由此,网络获得前所未有的可编程、可...
  • 先从大的概念开始介绍 OpenFlow网络 分为以下三个部分 OpenFlow交换机:主要实现... 安全通道是连接OpenFlow交换机和控制器通信的接口。控制器通过这个接口来控制和管理OF交换机,同时OF交换机通过这个接口将事...
  • OpenFlow协议及其简单仿真

    千次阅读 2015-01-20 22:20:11
     OpenFlow协议及其简单仿真 在讲述本文的主旨之前,先来说一说SDN的三大要素:  1. 转发与控制分离,这使得网络交换机的数据转发变得更加简单、快速;同时,控制变成了网络操作系统中一个相对集中的逻辑功能。  ...
  • SDN软件定义网络之南向协议——OpenFlow协议 三种消息类型 1.controller to switch 2.asynchronous 告知控制器新数据包的到达和交换机状态的改变 3.symmetric 由控制器或交换机任意一方发送,无需对方的许可或请求...
  • SDN原理 OpenFlow协议 -1

    2016-09-05 09:41:00
    本文基于SDN原理视频而成:SDN原理 OpenFlow OpenFlow 协议 和 传统的...但是OpenFlow协议的流表,却什么都有。 OpenFlow 相比传统路由协议来说,更大更广泛;是一种推倒重来的做法。 功能 OpenFlow 1.0 ...
  • Openflow switch介绍,结构,操作,实现
  • OpenFlow协议发展到现在已经经过了1.0、1.3、1.4等版本。其中1.0和1.3版本使用的是最为广泛的。 本篇博文主要分析1.0版本和1.3版本OpenFLow协议在控制器和交换机之间的交互流程。 OpenFlow1.0协议交互 ...
  • Openflow协议读书笔记

    2019-12-02 17:08:16
    版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,611
精华内容 1,044
关键字:

openflow协议通信