我们平时接触到的SDN技术实现中有三个重要概念，分别是控制协议、虚拟交换机、控制器。其中以控制协议OpenFlow和虚拟交换OpenvSwitch的组合使用最为典型，笔者接下来将分别就其基本结构和使用方法进行介绍，有兴趣的读者也可以使用Mininet虚拟机模拟操作。
1.OpenFlow
OpenFlow是一种开源的网络控制器协议，它起源于斯坦福大学，并在开放网络基金会（Open Networking Foundation，简称ONF，致力于SDN的实现和推广）的帮助下成为SDN架构中控制层与数据层之间的第一个通信标准。对于支持OpenFlow的物理或者虚拟网络设备比如交换机、路由器，我们可以对其中的包转发路径与规则直接进行控制，从而制造出一系列软件定义的网络设备以简化基础设施，这些软件定义的网络设备包括防火墙、交换机、路由器、中继、流量控制器、网桥等。如果它结合硬件支持较为广泛的sFlow/NetFlow监视协议，则可一定程度上提高整体网络的动态性能。国外厂商中生产支持OpenFlow协议设备的有Cisco、Juniper、Brocade等，国内则有Pica8、华为等，社区中也有一些基于FPGA的开源交换机项目，比如MagicLabFast、NetFPGA、ONetSwitch等。
□协议结构
OpenFlow是一个控制器协议，它定义了OpenFlow交换机中数据路径（datapath）的行为规则，笔者。OpenFlow 1.5版本定义的交换机中通常含有一个或多个流表flow table（类似路由表，用以决定封包转发路径）、组表（group table）以及控制通道（control channel），多个流表又可以组成一个管道线（pipeline，类似单向链表），每一个流表又可被测量表（meter table）指定的规则进行QoS操作。通过流表中定义的规则我们可以对封包进行查询、转发等操作，控制通道则负责交换机与外部控制器的通信，如图6-13所示。
图6-13 OpenFlow控制器与交换机通信简图
每个流表中都含有多个流表条目（flow entry，类似路由条目）组成，流表条目中通常有匹配域（match fields）、计数器（counter）、指令（instructions）等。
当封包进入交换机以后，它就会从第一个流表中的第一个流表条目开始匹配。如果封包匹配成功，则开始按照预先配置好的指令进行动作（actions），否则继续前进至下一个流表条目。如果封包未能与第一个流表中的任一流表条目匹配，则交换机会根据组表或者管道线对其进行处理，比如丢弃、转发至控制器或者下一流表。
转发的目标也可以是一个端口（port，多数场景中等同于接口），其形式可以是物理或虚拟交换机上的接口。这些接口通常预定义了一系列转发动作，比如转发至控制器、进行泛洪（flooding，封包被转发至交换机上除本身来源接口外的所有接口，用于于交换机学习规则），或者其他非OpenFlow交换机的包含汇聚信息的端口中。
管道线指令负责将封包传递至下一流表进行处理，流表之间依靠元数据信息（metadata，通常是一组寄存器掩码）进行通信。
组表中同样包含多个组条目（group entry），会对封包进行额外处理，比如泛洪和规则比较复杂的转发。组条目中的指令可将多个流中的封包传递至同一标识符（比如将路由中的IP包转发至下一跳），这样便对多个流进行统一处理而提高转发效率。
□使用示例
接下来笔者将利用OpenFlow和OpenvSwitch创建一个具有VLAN功能且可进行MAC地址学习的虚拟4口交换机，读者需要参考下一节的OpenvSwitch简单编译方法，获取最新源码并安装编译环境所需依赖包。整个过程将在OpenvSwitch提供的sandbox隔离环境中进行，所有命令脚本存在于sandbox子目录中。期间主要涉及的关键字有流表条目的匹配域与流表动作，OpenFlow（1.5）中的常用流表条目匹配域字段与流表动作分别如表6-1和表6-2所示，前缀dl和nw分别代表数据链路层和网络层，详细内容可参考“man ovs-ofctl”。
表6-1 流表条目匹配域字段及其含义
表6-2 流表动作及其含义
了解以上基本关键字后我们开始建立sandbox环境。
首先创建一个缺省配置的网桥br0，添加如下端口：p1为允许所有VLAN通过的Trunk端口，p2为VLAN 20的Access端口；p3、p4为VLAN 30的Access端口。
接下来创建具有4个流表的管道线，每个流表的功能如下所示。
流表0：输入端口的来源控制；
流表1：输入端口的VLAN数据包处理；
流表2：输入端口的源MAC地址和VLAN学习；
流表3：在已学习的端口上查找目的MAC地址和VLAN；
流表4：输出处理。
流表0是所有数据包处理的第一步，我们可以在它上面制定一些普通交换机所具有的基本规则，比如丢弃来自MAC广播源的数据包、禁止STP或者慢速协议等由保留MAC地址定义的协议。
流表1将继续处理来自流表0的数据包，它将来自不同端口的数据包分别打上不同的标签，然后交由流表2处理，如果端口p2、p3、p4的数据包具有不匹配的VLAN标签，则会被丢弃。
流表2会指定流表10为MAC学习表，每一个数据包都会在表中更新对应字段，将来源端口写入寄存器reg0，然后传递至流表3。它用到了OpenvSwitch的learn扩展功能，其中NXM＿OF＿VLAN＿TCI、NXM＿OF＿ETH＿DST、NXM＿OF＿ETH＿SRC、NXM＿OF＿IN＿PORT、NXM＿NX＿REG0为要记录的学习表字段。
流表3会使数据包在传递过程中查找并更新学习表以更新寄存器reg0的值，目的为广播地址的数据包不进行学习。
流表4会根据寄存器reg0的值决定数据包的下一步操作，其值表示数据包的期望输出端口，0表示所有端口（泛洪）。
接下来我们用ovs-appctl ofproto/trace命令模拟发包，查看期间的流表和数据路径的变化。
2.OpenvSw itch
OpenvSwitch作为EVB的典型开源实现，在私有云SDN架构中拥有十分重要的地位。它的首要目的是提供一个完全由软件实现并且支持多种协议与特性的虚拟交换机（Open Virtual Switch，以下简称OVS），同时可以结合各种插件（比如Neutron子项目networkingovn）为云平台构建二层以及三层虚拟网络（Open Virtual Networking，以下简称OVN）的完整解决方案。目前它作为一款非常活跃的开源云平台的网络虚拟化实现工具，不论在厂商还是社区中都获得了很好的第三方支持。
它通过Linux内核模块openvswitch.ko（2009年并入Linux主分支）能够相对高效地支持这些功能，包括802.1q VLAN、网口Bonding、sFlow/NetFlow/IPFIX/IPFIX/SPAN监视协议、QoS控制、Geneve/GRE/VXLAN/LISP通道、OpenFlow等。
首先我们在Fedora 23系统中编译并运行最新版本OpenvSwitch（本书成文时版本号为2.5.90），查看其提供的功能组件（编译后也会在源码目录中出现一些额外工具，比如utilities下的ovs-pcap、ovs-sim等）。
然后为了有助于读者理解OpenvSwitch组件，笔者将这些命令按照操作对象划分为OVS、OVN两大类，每一类中又可按照不同的功能进一步划分。
□OVS
OVS的主要功能命令有这几方面，包括设置（ovs-vsctl、ovs-appctl、ovs-dpctl、ovs-dpctltop、ovs-ofctl）、数据库OVSDB（ovsdb-client、ovsdb-server、ovsdb-tool）、服务进程（ovsvswitchd），杂项则包括虚拟通道网关VTEP（vtep-ctl）、密钥管理（ovs-pki）、Docker网络工具（ovs-docker）、错误收集（ovs-bugtool）、测试工具（ovs-l3ping、ovs-test、ovs、ovs-vlan-test）等，各主要组件关系如图6-14所示。
图6-14 OVS主要功能命令关系简图
其中，OVS服务进程ovs-vswitchd的配置都会被保存在数据库中，ovs-vsctl、ovs-client命令可直接操作数据库而改变OVS配置；外部控制器则通过OpenFlow等流控协议对OVS进行管理，ovs-ofctl只能管理OpenFlow协议的OVS；ovs-dpctl可直接操作内核空间中OVS的数据路径（DP）；ovs-appctl则可以看做OVS、OVSDB的通用调用方法，它相对拥有更具体的选项与参数。
接下来笔者将给出每个命令的简单用法，在Bash命令行环境中使用时可以按两次Tab补全选项或参数，更详细的内容可查看相关手册（形似“man ovs-vsctl”）或者OpenvSwitch源码中的部分文档。
●ovsdb-client、ovsdb-server、ovsdb-tool
ovsdb-server是读写OVSDB的服务进程，它以UNIX套接字（/var/run/openvswitch/db.sock）或者TCP/IP（端口监听，形如“--remote＝ptcp：192.168.0.141：1234”）的形式将本地数据库暴露（OVS默认为/etc/openvswitch/conf.db，JSON文本）出以供外部调用，且所有调用请求与返回的数据格式默认为JSON，关于OVSDB的详细内容可参考“man ovs-vswitchd.conf.db”。在Fedora 23中它的默认选项与参数如下所示：
ovsdb-client和ovsdb-tool是用来操作OVS数据库的命令行工具，前者可对数据库表内容进行查看、修改、添加、删除等，后者可对数据库进行初始化、转化等操作，下面以创建VTEP数据库为例：
●ovs-vswitchd
ovs-vswitchd服务进程负责与控制器和OVSDB的通信，从而使得控制器或者其他命令能够操作本地的OVS以及DP，默认参数如下。
其中，/var/run/openvswitch/db.sock是本地ovsdb-server进程暴露的UNIX套接字，我们同样可以将其改为远程ovsdb-server提供的地址与端口（形如“--db＝tcp：192.168.0.141：1234”）。
●ovs-vsctl
ovs-vsctl是操作ovs-vswitchd的主要命令，它通过修改OVSDB以达到控制OVS的目的。默认情况下它会与本地的ovsdb-server通信，可对OVSDB中的Bridge（OVS网桥，即虚拟交换机）、Port（隶属于OVS的端口，可看作交换机的网口）、Interface（与端口相连的设备接口，默认情况下与端口是一对一的关系，如果端口上配置了bond则此时多个接口属于一个端口）、Controller（可为多个）等数据表内容进行创建、删除、修改操作，同时也可对ovsdb-server服务进程进行配置（Manager表，主要内容是连接信息），使用示例如下。
●ovs-dpctl、ovs-dpctl-top(www.xing528.com)
DP一般与设备端口相关，它是流表作用的直接对象。ovs-dpctl直接管理在内核空间中的OVS的数据路径和流（功能上与ovs-ofctl有一定重复），如果要管理用户空间（比如netdev）中的数据路径，则需要使用ovs-appctl dpctl子命令；ovs-dpctl-top则可对通过ovsdpctl导出的DP数据进行（实时）查看，使用方法如下。
●ovs-ofctl
除了在外部控制器中，我们也可以使用ovs-ofctl命令对其进行控制，可控制的部分包括流表、组表、测量表等。另外ovs-appctl ofctl也提供了较为实用的数据包测试（trace）命令。
●vtep-ctl
在组建基于VXLAN的通道网络时，我们可能会用到软件或硬件实现的VTEP组件以对其中的协议进行封装与解封。而在OVS中添加VTEP之前，首先需要按照本节上文的OVSDB操作以添加独立的VTEP数据库。根据不同的VTEP类型，VTEP配置会被保存在不同的数据库中。如果VTEP是一个hypervisor，则配置保存在Open＿vSwitch中，如果是单独的VTEP设备，则会被保存在hardware＿vtep中。
●ovs-pki
ovs是一个独立的证书管理工具，生成的证书、密钥等可用于OVS、OVSDB中的通信加密，证书链默认存放位置为/var/lib/openvswitch/pki。
●ovs-docker
OpenvSwitch 2.5.0以后的版本中集成了针对Docker网络的命令行工具，以替代之前的第三方脚本。ovs-docker命令可以在容器上进行网络的添加、删除、设置VLAN操作，其使用方法如下所示：
●ovs-bugtool
ovs-bugtool是OVS运行环境日志收集工具，我们可以使用它收集的日志进行排错或者向社区提交bug等。
●ovs-l3ping、ovs-vlan-test
在编译时会生成一些诸如vlan-test、ping、ovstest的测试工具，使用它们可以方便我们的排错工作。
□OVN
OVN是OpenvSwitch社区在2015年1月发布的项目，目前其社区非常活跃。它的目的是为了帮助CMS（Cloud Management System，云平台管理系统）实现网络服务的发布与管理。它支持虚拟二层、三层网络以及安全组，并且借助于集成插件（比如OpenStack的neutron-ovn）可作为CMS平台的独立网络服务提供商。
虽然OVN现在并不是主流CMS的首选网络服务，但是其架构总结并优化了原有产品和项目的实现，是帮助我们理解与设计云平台网络的有力工具。
OVN引入了一些新的概念和表示方法，比如Northbound（北向）、Southbound（南向）、chassis（hypervisor与网关的组合）等，整体架构如图6-15所示。
图6-15 OVN整体架构图
接下来本书以OVN中的最基本元素——虚拟接口（VIF）为例，介绍它在OVN的整个生命周期（见表6-3）以有助于读者理解OVN的架构与工作原理。这里的VIF是指位于hypervisor中的虚拟网络接口，它与虚拟机或者容器的网口相连以使得后者能够通过VIF访问外部网络。
表6-3 OVN中虚拟接口的生命周期
续表
以上即是OVN云平台的虚拟接口的完整生命周期，对于运行于虚拟化之上的容器接口而言基本类似。由于性能以及管理（hypervisor的集成桥与容器接口没有直接连接）等方面因素的考虑，容器网络接口会使用带有标签的CIF（container interface，容器网络接口）以复用VIF而不是每个容器网口都使用一个VIF，关于OVN与docker的详细集成步骤可参考OpenvSwitch的ISTALL.Docker.md。
接下来笔者仍然使用sandbox环境进行操作，分别在两个虚拟机中创建容器网络接口，用VLAN标签区别，其中cport1和cport2位于虚拟机内部交换br-vmport1且分别属于VLAN 42、43，cport3位于br-vmport2属于VLAN 43，整体逻辑如图6-16所示。
图6-16 OVN网络逻辑图
然后在逻辑网络和集成桥中添加端口。
然后我们分别查看Northbound、Southbound，以及本地OVS的配置状态以及数据库内容。
在进行发包测试之前，我们需要查看每个OVS的OpenFlow端口编号以确定数据路径的变化，可使用命令形似“ovs-ofctl dump-flows br-int”以及“ovn-sbctl dump-flows”查看流表条目。
进行发包测试，首先尝试从cport1发送至cport2。
然后尝试从cport3发送至cport2。
3.控制器与监视器
□基本介绍
SDN的精髓之一就在于控制层与数据层的分离。控制层在逻辑上是集中的，控制器通过协议将指令发予数据层的执行元件，又由于SDN本身的可编程性，从而使得控制层更加智能、数据层更加高效。
目前OpenFlow作为控制器协议中的业界标准，是开源云平台SDN控制层协议的首选，虽然较新的版本中添加了测量与QoS功能，但在可视化层面相对sFlow/NetFlow/IPFIX/SPAN等协议而言仍有一定差距，所以笔者也将稍后对后者进行介绍。
□OpenFlow控制器
第一款OpenFlow控制器是由Nicira Networks（已被VMWare收购）使用C语言开发的NOX，现在看来它比较像一款原型产品，虽然其社区已不再活跃但是它的编程架构为以后的控制器提供了很好的范例。后来Nicira与NTT和Google合作开发了闭源的ONIX，据传它是Google的SDN广域网控制器。
与NOX同时期的开源控制器还有POX（Python）、Beacon（Java）等，它们与NOX的实现比较类似，但因为具有语言上的优势使其相对更容易学习。在2012年后，Ryu（Python）、Floodlight（Java）、Trema（Ruby）等控制器相继出现。
Ryu是由NTT公司开发的开源控制器，由于其架构清晰、文档齐全而被广泛关注。Floodlight来源于Beacon，它遵守Apache 2.0协议，是早期商业控制器模型的重要组件（最早的商业控制器是由NEC完全自主开发的ProgrammableFlow Controller）。
后来控制器的发展趋势日益明朗，其中以OpenDayLight和ONOS为典型代表。它们一定程度上已经不再是传统的SDN控制器，而是属于网络运营商级别的分布式SDN控制平台。包括Cisco、Juniper、华为在内的各大厂商均参与OpenDayLight社区维护，目前Cisco为主要贡献者。ONOS相对OpenDayLight而言面世时间较晚，但其支持者中也有惠普、微软等重量级厂商。
接下来笔者以较为经典的FloodLight控制器举例，介绍它在OVS中的使用方法，详细文档可参阅官方网站与源码。
然后使用ovs-vsctl命令添加OVS的控制器（可以是多个），如下所示。
访问http：//192.168.0.140：8080/ui/index.html即可看到其Web UI，如图6-17所示。
图6-17 Floodlight 1.2版本界面
界面可以实时反映OVS中添加的主机、流表、端口等信息，并且拥有友好的拓扑图显示。接下来我们使用它提供的REST API进行添加、查看流表等基本操作，完整REST API手册可以参考其官方网站（https：//floodlight.atlassian.net/wiki/display/floodlightcontroller/Floodlight＋REST＋API）。
□sFlow/NetFlow监视器
市场上存在很多sFlow/NetFlow协议的开源或闭源监视器，比如InMon、SolarWinds等，所有支持这两种协议的交换机都可以使用其进行流量的监控、分析。
如果要在OVS中使用sFlow/NetFlow，我们需要在OVSDB的sFlow表中添加对应字段，如下所示。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
