【重识云原生】第四章云网络4.8.2.3节——OpenFlow运行机制

发布于

3 OpenFlow运行机制

3.1 OpenFlow信道建立

3.1.1 OpenFlow消息类型

        要了解OpenFlow信道的建立过程，首先需要了解OpenFlow协议目前支持的三种报文类型：

1、Controller to Switch消息

        由Controller发起、Switch接收并处理的消息。这些消息主要用于Controller对Switch进行状态查询和修改配置等管理操作，可能不需要交换机响应。

Controller to Switch消息示意图

        Controller to Switch消息主要包含以下几种类型：

  1. Features：用于控制器发送请求来了解交换机的性能，交换机必须回应该报文。
  2. Modify-State：用于管理交换机的状态，如流表项和端口状态。该命令主要用于增加、删除、修改OpenFlow交换机内的流表表项，组表表项以及交换机端口的属性。
  3. Read-State：用于控制器收集交换机各方面的信息，例如当前配置，统计信息等 。
  4. Flow-Mod：Flow-Mod消息用来添加、删除、修改OpenFlow交换机的流表信息。Flow-Mod消息共有五种类型：ADD、DELETE、DELETE-STRICT、MODIFY、MODIFY-STRICT。
  5. Packet-out：用于通过交换机特定端口发送报文 ，这些报文是通过Packet-in消息接收到的。通常Packet-out消息包含整个之前接收到的Packet-in消息所携带的报文或者buffer ID（用于指示存储在交换机内的特定报文）。这个消息需要包含一个动作列表，当OpenFlow交换机收到该动作列表后会对Packet-out消息所携带的报文执行该动作列表。如果动作列表为空，Packet-out消息所携带的报文将被OpenFlow交换机丢弃。
  6. Asynchronous-Configuration：控制器使用该报文设定异步消息过滤器来接收其只希望接收到的异步消息报文，或者向OpenFlow交换机查询该过滤器。该消息通常用于OpenFlow交换机和多个控制器相连的情况。

2、异步（Asynchronous）消息

        由Switch发送给Controller，用来通知Switch上发生的某些异步事件的消息，主要包括Packet-in、Flow-Removed、Port-Status和Error等。例如，当某一条规则因为超时而被删除时，Switch将自动发送一条Flow-Removed消息通知Controller，以方便Controller作出相应的操作，如重新设置相关规则等。

Switch to Controller示意图

        异步消息具体包含以下几种类型：

  1. Packet-in：转移报文的控制权到控制器。对于所有通过匹配流表项或者Table Miss后转发到Controller端口的报文均要通过Packet-in消息送到Controller。也有部分其他流程（如TTL检查等）也需要通过该消息和Controller交互。Packet-in既可以携带整个需要转移控制权的报文，也可以通过在交换机内部设置报文的Buffer来仅携带报文头以及其Buffer ID传输给Controller。Controller在接收到Packet-in消息后会对其接收到的报文或者报文头和Buffer ID进行处理，并发回Packet-out消息通知OpenFlow交换机如何处理该报文。
  2. Flow-Removed：通知控制器将某个流表项从流表的移除。通常该消息在控制器发送删除流表项的消息或者流表项的定时器其超时后产生。
  3. Port-Status：通知控制器端口状态或设置的改变。

3、同步（Symmetric）消息

        顾名思义，同步（Symmetric）消息是双向对称的消息，主要用来建立连接、检测对方是否在线等，是控制器和OpenFlow交换机都会在无请求情况下发送的消息，包括Hello、Echo和Experimenter三种消息，这里我们介绍应用最常见的前两种：

同步消息示意图

  • Hello：当连接启动时交换机和控制器会发送Hello交互。
  • Echo：用于验证控制器与交换机之间连接的存活，控制器和OpenFlow交换机都会发送Echo Request/Reply消息。对于接收到的Echo Request消息必须能返回Echo Reply消息。Echo消息也可用于测量控制器与交换机之间链路的延迟和带宽。

3.1.2 信道建立过程解析

        OpenFlow控制器和OpenFlow交换机之间建立信道连接的基本过程，具体步骤如下：

  1. OpenFlow交换机与OpenFlow控制器之间通过TCP三次握手过程建立连接，使用的TCP端口号为6633。
  2. TCP连接建立后，交换机和控制器就会互相发送hello报文。Hello报文负责在交换机和控制器之间进行版本协商，该报文中OpenFlow数据头的类型值为0。
  3. 功能请求（Feature Request）：控制器发向交换机的一条OpenFlow 消息，目的是为了获取交换机性能，功能以及一些系统参数。该报文中OpenFlow 数据头的类型值为5。
  4. 功能响应（Feature Reply）：由交换机向控制器发送的功能响应（Feature Reply）报文，描述了OpenFlow交换机的详细细节。控制器获得交换机功能信息后，OpenFlow协议相关的特定操作就可以开始了。
  5. Echo请求（Echo Request）和Echo响应（EchoReply）属于OpenFlow中的对称型报文，他们通常用于OpenFlow交换机和OpenFlow控制器之间的保活。通常echo请求报文中OpenFlow数据头的类型值为2，echo响应的类型值为3。不同厂商提供的不同实现中，echo请求和响应报文中携带的信息也会有所不同。

3.1.3 信道连接断开模式

        当OpenFlow设备与所有Controller断开连接后，设备进入Fail Open模式。OpenFlow设备存在两种Fail Open模式：

  • Fail Secure mode交换机：在该模式下的OpenFlow交换机，流表项继续生效，直到流表项超时删除。OpenFlow交换机内的流表表项会正常老化。
  • Fail Standalone mode交换机：所有报文都会通过保留端口Normal处理。即此时的OpenFlow交换机变成传统的以太网交换机。Fail Standalone mode只适用于OpenFlow-Hybrid交换机。

        安全通道也有两种模式，不同模式下安全通道重连的机制不同。

  • 并行模式：并行模式下，Switch允许同时与多个Controller建立连接，Switch与每个Controller单独进行保活和重连，互相之间不影响。当且仅当Switch与所有Controller的连接断开后，Switch才进入Fail Open状态。
  • 串行模式：串行模式下，Switch在同一时刻仅允许与一个Controller建立连接。一旦与该Controller连接断开后，Switch并不会进入Fail Open状态，而是立即根据Controller的ID顺序依次尝试与Controller连接。如果与所有Controller都无法建立连接，则等待重连时间后，继续遍历Controller尝试建立连接。在三次尝试后，仍然没有成功建立连接，则Switch进入Fail Open状态。

3.2 OpenFlow消息处理

3.2.1 OpenFlow流表下发与初始流表

        OpenFlow流表下发分为主动和被动两种机制：

  • 主动模式下，Controller将自己收集的流表信息主动下发给网络设备，随后网络设备可以直接根据流表进行转发。
  • 被动模式下，网络设备收到一个报文没有匹配的FlowTable记录时，会将该报文转发给Controller，由后者进行决策该如何转发，并下发相应的流表。被动模式的好处是网络设备无需维护全部的流表，只有当实际的流量产生时才向Controller获取流表记录并存储，当老化定时器超时后可以删除相应的流表，因此可以大大节省交换机芯片空间。

        在实际应用中，通常是主动模式与被动模式结合使用。

        当OpenFlow交换机和Controller建立连接后，Controller需要主动给OpenFlow交换机下发初始流表，否则进入OpenFlow交换机的报文查找不到流表项，就会做丢弃处理。这里的初始流表保证了OpenFlow的未知报文能够上送控制器。而后续正常业务报文的转发流表，则在实际流量产生时，由主动下发的初始流表将业务报文的首包上送给控制器后，触发控制器以被动模式下发。

        这里我们以H3C VCFC控制器给交换机下发的一个初始流表举例。

        前面我们了解到，OpenFlow流表是分级匹配的，通常按0表、1表、2表这样依次匹配过去，每个级别的表中则由优先级高的表项先进行匹配。

OpenFlow流表举例示意图

        如上图所示，0表优先级最高为65535的两条流表匹配到的是端口号为67、68的UDP报文，也就是DHCP报文，匹配动作为goto_table 1，剩下的其他所有报文也命中优先级最低为0的表项后goto_table 1。而在表1中，优先级最低的表项对应的动作为output controller，这保证了虚拟机的DHCP请求可以发送给控制器，由控制器作为网络中的DHCP Server，避免DHCP请求泛洪，同时还保证了交换机上所有未知的无流表匹配的报文都可以上送控制器，触发控制器被动下发流表给交换机指导转发。这里，我们把表1里优先级最低为0，匹配所有未知报文的表项叫做table-miss表项。

        我们在OpenFlow交换机上同样可以观察到初始流表，这里以H3C S6800交换机上的一个初始流表举例。上图中的这条表项匹配报文类型为以太网报文，UDP端口67、68说明匹配DHCP请求报文，动作为上送控制器：

OpenFlow交换机上流表举例图

3.2.2 OpenFlow报文上送控制器

        OpenFlow报文上送控制器详细过程如下：

OpenFlow报文上送控制器过程图

  1. 控制器和交换机建立连接事件是Packet-in事件发生的前提。
  2. 当OpenFlow交换机收到数据包后，如果明细流表中与数据包没有任何匹配条目，就会命中table-miss表项，触发Packet-in事件，交换机会将这个数据包封装在OpenFlow协议报文中发送至控制器。
  3. 一旦交换机触发了Packet-in事件，Packet-in报文就将发送至控制器。

        Packet-in数据头包括了：

  • 缓冲ID
  • 数据包长度
  • 输入端口
  • Packet-in的原因，分两种：
    • 0: 无匹配
    • 1: 流表中明确提到将数据包发送至控制器

3.2.3 控制器回应OpenFlow报文

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

        Controller根据报文的特征信息（如IP、mac等）下发一条新的流表项到OpenFlow交换机或者做其他处理之后下,发Packet-out消息动作为output到table，具体过程如下所示：

控制器回应OpenFlow报文过程图

  1. 控制器和交换机之间建立连接事件是Packet-out事件发生的前提；
  2. 控制器要发送数据包至交换机时，就会触发Packet-out事件将数据包发送至交换机。这一事件的触发可以看做是控制器主动通知交换机发送一些数据报文的操作。通常，当控制器想对交换机的某一端口进行操作时，就会使用Packet-out报文。
  3. 该数据包由控制器发往交换机，内部信息使用Packet-out，并由OpenFlow数据头封装。OpenFlow Packet-out信息包括：
  4. 缓冲ID
  5. 入口端口编号
  6. 动作明细（添加为动作描述符）
  7. 输出动作描述符
  8. VLAN VID动作描述符
  9. VLAN PCP动作描述符
  10. 提取VLAN标签动作描述符
  11. 以太网地址动作描述符
  12. IPv4地址动作描述符
  13. IPv4 DSCP动作描述符
  14. TCP/UDP端口动作描述
  15. 队列动作描述符
  16. 各厂商动作描述符

3.3 OpenFlow交换机转发

3.3.1 单播报文转发流程

        当OpenFlow交换机接收到Flow-Mod消息，生成流表后，就可以按照流表转发接收到的Packet-out报文了，过程举例如下：

单播报文转发流表

        在本例中，OpenFlow 交换机需要转发一个从7.7.7.1到9.9.9.1的流量。当流量上送到OpenFlow交换机后，流量的第一个包会先进行Packet-in、Flow-Mod、Packet out的过程，之后同流量的报文就能匹配控制器已经下发的流表进行转发了。

3.3.2 组播报文转发

        当终端发出的组播报文到达OpenFlow交换机后，OpenFlow交换机Packet-in给控制器，控制器会为网络下发指导查询组表的流表，并进行流表与组表关联。交换机参考流表，引用组表进行转发。举例如下：

        组播报文转发所使用的流表：

组播报文转发流表

        上条流表的动作为引用组表4096，组表4096详细内容如下：

组表详细内容示意图

参考链接

Openflow协议详解-新华三集团-H3C

SDN学习之OpenFlow协议分析 - 守功 - 博客园

OpenFlow 协议详解（干货）_WenjieDai的博客-CSDN博客_openflow协议

OpenFlow_百度百科

 《重识云原生系列》专题索引： 

  1. 第一章——不谋全局不足以谋一域
  2. 第二章计算第1节——计算虚拟化技术总述
  3. 第三章云存储第1节——分布式云存储总述
  4. 第四章云网络第一节——云网络技术发展简述
  5. 第四章云网络4.2节——相关基础知识准备
  6. 第四章云网络4.3节——重要网络协议
  7. 第四章云网络4.3.1节——路由技术简述
  8. 第四章云网络4.3.2节——VLAN技术
  9. 第四章云网络4.3.3节——RIP协议
  10. 第四章云网络4.3.4节——OSPF协议
  11. 第四章云网络4.3.5节——EIGRP协议
  12. 第四章云网络4.3.6节——IS-IS协议
  13. 第四章云网络4.3.7节——BGP协议
  14. 第四章云网络4.3.7.2节——BGP协议概述
  15. 第四章云网络4.3.7.3节——BGP协议实现原理
  16. 第四章云网络4.3.7.4节——高级特性
  17. 第四章云网络4.3.7.5节——实操
  18. 第四章云网络4.3.7.6节——MP-BGP协议
  19. 第四章云网络4.3.8节——策略路由
  20. 第四章云网络4.3.9节——Graceful Restart(平滑重启)技术
  21. 第四章云网络4.3.10节——VXLAN技术
  22. 第四章云网络4.3.10.2节——VXLAN Overlay网络方案设计
  23. 第四章云网络4.3.10.3节——VXLAN隧道机制
  24. 第四章云网络4.3.10.4节——VXLAN报文转发过程
  25. 第四章云网络4.3.10.5节——VXlan组网架构
  26. 第四章云网络4.3.10.6节——VXLAN应用部署方案
  27. 第四章云网络4.4节——Spine-Leaf网络架构
  28. 第四章云网络4.5节——大二层网络
  29. 第四章云网络4.6节——Underlay 和 Overlay概念
  30. 第四章云网络4.7.1节——网络虚拟化与卸载加速技术的演进简述
  31. 第四章云网络4.7.2节——virtio网络半虚拟化简介
  32. 第四章云网络4.7.3节——Vhost-net方案
  33. 第四章云网络4.7.4节vhost-user方案——virtio的DPDK卸载方案
  34. 第四章云网络4.7.5节vDPA方案——virtio的半硬件虚拟化实现
  35. 第四章云网络4.7.6节——virtio-blk存储虚拟化方案
  36. 第四章云网络4.7.8节——SR-IOV方案
  37. 第四章云网络4.7.9节——NFV
  38. 第四章云网络4.8.1节——SDN总述
  39. 第四章云网络4.8.2.1节——OpenFlow概述
  40. 第四章云网络4.8.2.2节——OpenFlow协议详解
  41. 第四章云网络4.8.2.3节——OpenFlow运行机制
  42. 第四章云网络4.8.3.1节——Open vSwitch简介
  43. 第四章云网络4.8.3.2节——Open vSwitch工作原理详解
  44. 第四章云网络4.8.4节——OpenStack与SDN的集成
  45. 第四章云网络4.8.5节——OpenDayLight
  46. 第四章云网络4.8.6节——Dragonflow
#sdn#packet#table#交换机