openvswitch实践（二）--架构与实现

OVS架构

先看下OVS整体架构，用户空间主要组件有数据库服务ovsdb-server和守护进程ovs-vswitchd。kernel中是datapath内核模块。最上面的Controller表示OpenFlow控制器，控制器与OVS是通过OpenFlow协议进行连接，控制器不一定位于OVS主机上，下面分别介绍图中各组件

为了说明datapath，来看一张更详细的架构图，图中的大部分组件上面都有提到

用户空间ovs-vswitchd和内核模块datapath决定了数据包的转发，首先，datapath内核模块收到进入数据包(物理网卡或虚拟网卡)，然后查找其缓存(datapath flows)，当有一个匹配的flow时它执行对应的操作，否则datapath会把该数据包送入用户空间由ovs-vswitchd负责在其OpenFlow flows中查询(图1中的First Packet)，ovs-vswitchd查询后把匹配的actions返回给datapath并设置一条datapath flows到datapath中，这样后续进入的同类型的数据包(图1中的Subsequent Packets)因为缓存匹配会被datapath直接处理，不用再次进入用户空间。

datapath专注于数据交换，它不需要知道OpenFlow的存在。与OpenFlow打交道的是ovs-vswitchd，ovs-vswitchd存储所有Flow规则供datapath查询或缓存.

虽然有ovs-dpctl管理工具的存在，但我们没必要去手动管理datapath，这是用户空间ovs-vswitchd的工作

Open vswitch实现方式

与老牌的Linux bridge不同，OVS是由Openflow祖师爷的公司创建的，其通过流表（flow table）的方式实现数据层面的转发和操作。控制器直接将数据包转发的规则以流表的方式发送给交换机，流表包含了详细的匹配信息——什么样的数据包（包类型、源mac地址、目的mac地址、源IP地址、端口等等，1.5版本中已经支持最多45个匹配域），执行什么样的操作（转发、丢弃、修改其中某些字段，匹配其他流表），如果遇到流表无法匹配的数据包，默认也会转发给控制器，由控制器生成新的流表。以下是流表中一个条目包含的字段。

 

以下太长了懒得看系列：每条 Openflow 流条目包含了匹配条件和执行的操作。匹配到的数据包会按照操作进行转发或者丢弃等。

 

Openflow 条目

• 匹配字段：用来匹配需要处理的数据包，可根据数据包的入接口、包头字段、和上一流表定义的元数据字段等等来匹配。最新的1.5.1支持45个匹配域，包括了：入接口、源mac地址、目的mac地址、以太网帧类型、vlan id、vlan priority、ip DSCP、ip ECN、ip源地址、ip目的地址、源端口、目的端口、arp opcode、icmp code、MPLS 标签、流表之间传递的元数据等等。
• 优先级：流条目匹配的优先级。优先级高的条目先匹配。
• 计数器：匹配成功后计数器会+1。
• 说明：用来指定对于匹配成功的数据执行的操作。
• 超时：流的过期时间。
• cookie：自定义字段，用于实控制器的一些自定义操作，例如批量地删除或修改cookie值为XXXXX/16 的流条目（这些流条目可能是用于对某一类业务或者某一个租户的数据包进行处理的）。cookie不会对于数据包的转发和匹配造成影响。
• Flag：flag用于标识流条目的管理方式。比如当flag包含 OFPFF_SEND_FLOW_REM ，则当交换机因为流条目超时或者流条目空间不足而删除条目时，都会触发交换机发送流删除的消息给控制器。

（相信对于很多人来说都会发现流表其实与传统交换机上的ACL、route-map等策略路由的处理方式是有点类似的）

 

 

 

Openflow v1.5 数据包处理流程

 

以下太长了懒得看系列：Openflow 交换机对数据包的处理可以看成两条管道对数据流进行过滤，流表和流条目就是滤网，将筛选出来的数据转发出去或者丢弃。

 

Openflow 在1.5版本后有一个非常大的功能改动，那就是引入了出端处理流程（Egress processing）。过去版本中数据包进入交换机后直接只需经过一次处理，确定出口后即被转发出去。1.5版本后，数据包匹配完，确定出接口后，会再进入出端的匹配流程。例如：

1. 数据包的进入Openflow的交换机后，首先进入入端处理流程（Ingress porcessing）逐条匹配入流表中的流条目；
2. 数据包 match 到的优先级最高的条目，流条目对应动作集也将执行，并更新流条目相关的计数器。
3. 根据动作，数据包有可能被传递（Goto-Table）到另一个流表，然后重新按顺序匹配。也有可能直接丢弃（drop），或者最终匹配到优先级最低的条目。
4. 如果匹配正常，确定的了数据包的出接口，则开始出接口处理流程（egress processing），出流表与入流表在功能上时类似的，不同的是入流程和出流程之间不能通过（Goto-Table）传递数据包。出流程无法重新指定数据包的出接口。
5. 每个流表都必须支持一个 Table-miss 条目，Table-miss 条目优先级最低，为 0。并且匹配域全部匹配。可以看成是一条全为 0 的ACL条目，用来处理那些还没有建立转发规则的数据流。对于这一类的流量，可以选择转发给其他表、或者转发给控制器用于生成新的流表、以及直接丢弃。从流表的设计优化的角度来说，table 0 内的table-miss条目会将数据包转发给控制器，而不是任由无法识别的流量向下持续匹配。

 

一次流表操作示例

所以基于此，我们完全可以制定出这样的流表：

Ingress processing：

table=0 , priority=1 , ARP类型的数据包（ETH TYPE=0x0806） , 交给 table(10)处理  resubmit(10)  -通过匹配域识别出arp类型的流量，并交由指定的流表处理。

table=10 , priority=1 , ARP请求的目标ip为 192.168.1.0/24 (OXM_OF_ARP_TPA=192.168.1.0/24) , action 修改请求中的源mac地址为网关的mac（0xa0a0a0a）。修改请求中的源IP为用户请求的IP（192.168.1.x）。修改包的类型为arp 回复  ——(arp代理的实现)用网关的ip来回应原主机

将原请求中的 源mac 和 源ip 移动到 目的mac 和 目的ip ，返回给源端口(OXM_OF_IN_PORT)。 ——构建arp返回包

进入出处理流程

Egress processing：

table=233，priority=100，修改以太网帧的源mac地址，目的mac地址，转发出接口。——重新封装二层帧

 

（实际中不一定包含 egress processing ，相应的流条目可以放在入处理流程内，实际现有arp代理功能并没用到egress processing ，此例仅为演示效果。）

交换机收到目标IP为192.168.1.100的ARP请求，交换机用自身的mac地址来代替远程主机的mac，并修改数据包类型为ARP回应后，从源端口发送出去。

由此可以看出，SDN交换机可以在完全不懂arp协议是什么的情况下，仅仅通过匹配和操作即实现了传统交换机的 arp代理功能。同理如果需要增加新的功能，只要制定流表就可以，当然前提是交换机上Openflow协议支持对应的匹配域和动作。