漫谈：软件定义网络的千型百态

晚上好，很高兴认识大家，我来自Canonical，做OpenStack的，之前在IBM干了三年也是做OpenStack的，主要做网络，做纯技术的。

所以我就做一些纯技术方面的分享吧，漫谈一下SDN网络，抛个砖引个玉，说些观点，给出链接，然后大家提问，大家一起沟通探讨认识一下。

IaaS就是为用户提供隔离的操作系统资源，对外可以以虚机、容器、VPC等外在形式表现出来。

OpenStack最初就是一个开源的IaaS平台(当然现在在Heat上又挂了一些PaaS的东西，我们暂且不表)。

操作系统资源主要由计算、存储、网络三大资源组成，所以Neutron的职责应该是为用户提供隔离的网络服务，也即NaaS(Network as a Service)。

所以从这个大的视图上讲，无论是OpenStack还是Neutron的重点应该是提供放之万物而皆准的权威的北向API，同时像Linux内核一样提供插件结构让这领域的不同厂商的不同技术都可以通过写驱动的形式进来玩。

对于网络来说：

二三层一般叫网络拓扑，四到七层叫网络服务(即网络应用，如防火墙，负载均衡，入侵检测系统，入侵防护，深度包检测，数据缓存，广域网加速等)。

网络拓扑可以由两种技术实现，一是Overlay技术，一是新兴的OpenFlow流技术。实现上二者在控制平面/转发平面所做的事情的思想是一样的。我们以Overlay举例来控制平面与转发平面的实现思想。

转发平面，NaaS是为每一个用户提供用户隔离的网络服务，一般使用标签来隔离，如传统的vlan，但它需要修改物理交换机，部署麻烦。于是，后来一般使用overlay技术，如gre, vxlan，nvgre, Geneve, stt，mpls over udp/gre等，同样使用标签segmention id来隔离用户网络流量，即通过自定义二层帧，通过UDP或QUIC或TCP Fast Open或IP或者别的什么上层协议传送到远端，再由远端解析这个自定义帧。这个帧是自定义的，所以格式就五花八门，于是，市场上就出现了众多的SDN产品，但其技术本质都是差不多的。于是，有人就想统一这个帧的格式，于是就有了Geneve。overlay的本质有两个头，一个是外部管理网段的头，一个是内部租户网段的头，这样天然为IPv4实现了NAT之类的网络地址转换。

Overlay网络可以分为两层，一是物理网络，一是构建在物理层上的虚拟overlay网络。

物理网络不需要和用户信息关联，它只是负责提供一个IP矩阵实现所有物理设备之间的单播IP可达性，并提供segmention id功能实现租户隔离。而虚拟overlay网络则会包含租户的信息，即类似于VPN为每一个租户都生成自己的路由信息，也叫转发路由实例(VRF)，例如在MPLS主干网上的流量在IP地址前都会添加一个全局唯一的路由标志符(Route Distinguisher, RD)形成唯一的VPN-IPv4地址来识别不同租户的流量。PE路由器不应该交换全网所有租户的路由，所以通过手工设定路由目标(Route Targe, RT)来设置从CE路由器向PE路由器导入导出哪些路由。只有所带RT标记与VRF表中任意一个Import RT相符的路由才会被导入到VRF表中。RT使得PE路由器只包含和其直接相连的VPN的路由，而不是全网所有VPN的路由，从而节省了PE路由器的资源，提高了网络拓展性。

控制平面，那么导入导出哪些路由完全可以由上层控制平面通过规则来设定，这种通过路由方式将虚机流量导流到底层IP隧道矩阵的做法天然将广播隔离在了一个节点上，可以省略像Neutron DRV ARP responser特性。也可以天然地让计算节点也具备三层功能随意设置局域隔离的网关(fan, opencontrail都是这么干的)。这层还要做地址学习功能。

对于openflow来说，控制平面应该集中全局的VM, PORT, CONTROL, SWITCH的映射拓扑关系，这样便可以计算给不同CONTROL上的不同SWITCH上的不同的PORT上的VM下发合适的流表(dragonflow就是这么干的)。还可以在边缘出口路由器处运行Quagga等动态路由协议通过BGP或iBGP收集到动态路由结合ARP路由通过一些规则转换成流表，如下列是RouteFlow的转换规则：

Route =IP + MASK [Rede]+IP[Gateway]+InterfaceARP= IP[Host]+MAC[Host]+Interface

路由表转换成流表：

Match: DST_MAC + DST_IP + SUBNET_MASKActions:Re-Write [SRC_MAC (Interface)], Re-Write [DST_MAC (Nexthop)]Forward [Port-out(Interface)]

在数据转发平面方面的性能方面，可以采用用户态协议栈，通过DPDK在用户态直接操作硬件网卡，并且构建用户态socket供上层调用。还可以引入Linux 4.x switchdev避免二层交换时引发CPU中断从而为SR-IOV网卡提供交换加速功能。

所有SDN产品的大致思想都脱离不了上面的点。现在对照它，我们可以发现Neutron有很多不足之处：

理想网络我感觉一是无限可伸缩同时适合大小规模部署的网络拓扑，可以在一个局域网的多个跨三层的OpenStack云之间互联，可以互联跨广域网的多个OpenStack云。我感觉第二点应该是在网络拓扑之上的好的网络服务。第三点应该是性能，每个网络节点都应该同时具备至少第三层功能，干净利索地解决东西南北流量问题。

先说nova-network, 它的multi-host功能可以让每一个计算节点同时具备网络三层功能，我们知道，一个子网是不能出现相同IP的网关的，而多个计算节点是可能出现相同子网的虚机的。所以对于multi-host而言对于同一个子网每一个计算节点上网关的IP都是不一样的，这样简化了设计，但是问题是浪费了IP地址。

Neutron的DVR可以干同样的事情，每一个计算节点上相同子网的网关都是相同的，但是通过流表来确保这个网关局部隔离。缺点是这种设计实现复杂度较高。

kubernetes则是事先假设每一个计算节点使用不重复的子网，这样也就避免了计算节点上出现相同子网网关的问题，简化了设计。

Neutron为二层提供了ML2插件来支持不同厂商的二层设备，在三层没有提供插件只提供了一个L3-agent来支持三层设备，在四到七层提供了高级服务框架来支持不同的网络服务。其缺点有：

北向API层做得太烂，如ACL，如QoS，如VPN等高级服务的API始终做不好或者因为有待商榷的代码评审机制而发展滞后。

分得层数太多，尤其是将二层和三层分开了，这样不利于让所有节点同时具备三层功能。特别对于一些不分层的新兴网络技术如SDN是不适合的。二层和三层插件应该合并适应于SDN技术。

三层没有插件，只有一个l3-agent。应该有插件结构，支持不同厂商的三层设备，特别是一些支持ACL的三层设备，支持跨广域网的三层支持如MPLS VPN等.

四到七层的服务链功能做得不好，同时，它的API只适合传统的基本iptables服务链插入模型，不适合SDN基于流表的服务模型。

SDN的本质是数据转发平面与集中控制平面相分离，数据转发这块主要是基于新兴的openflow流以及基于overlay隧道技术，但其技术本质也是一样的。overlay会对二层数据帧进行自定义，我们可以随心所欲地改写，添加两个包头，一个是内部包头对应虚机网段，一个是外部包头对应管理网段，天然进行内外网的网络地址转换。overlay层只负责通过隧道进行数据转发，另外，其隧道最好是支持segmention id的有利于租户间的隔离。控制平面首先要是集中的，它会记录网络和租户间的对应关系，通过提供一些规则容易通过上面控制底层的流量转发，如虚机出来的流量如何进入隧道，如果是经过路由那可以通过路由将广播只限制在一台物理机上，也可以像VPN一样针对每个用户建立路由转发实例，也可以像DVR一样直接响应需机的ARP请求和地址学习等。

Ubuntu Fan网络的思想和上述一致，问题在于fan网络是flat的即隧道里还不支持segmention id 来隔离租户网络，另外Fan也没有控制平面不能做规则设置。

opencontrail是我认识的最好的SDN，它忠实实现了上述思想，juniper的工程师们非常理解电信网络，在电信世界，现在4G的每一个基站和其他基站都是两两互连的，也就是说基站和openstack里的计算节点一样是需要3层功能的。fan实现的是IPIP隧道，opencontrail实现是mpls over udp/gre隧道可以天然地互联广域网的多个数据中心。另外，opencontrail的服务链功能做得非常完善，如深度包检测(DPI)，入侵检测(IDP)，入侵防护(IPS)，广域网优化和负载均衡等。

Midonet也非常不错，虽然每个计算节点不具备3层功能，但它支持VTEP和MPLS L2 Gateway功能，这样同一tenant的不同子网间的东西向流量并不需要经过Provider Router(Neutron DVR解决的是相同子网的东西向流量不绕道l3-agent的情况), 只有跨tenant的东西向流量和南北流量才需要经过Provder Router。它和没有DVR的neutron的拓扑看起来最像，但是它比l3-agent做得更好也支持BGP与ECMP支持等。另外，neutron是MQ+DB实现的，大量应用了消息，这可能成为性能瓶颈;而Midonet主要基于分布式数据库技术。采用分布式数据库NSDB来作集中的控制平面存储port, node, mac等映射关系。这种搞法和基于openflow流表的SDN实现产品看起来更眼熟，如routeflow等。

Neutron的dragonflow也正在朝这方面努力， 它基于openflow流表同时支持网络二三层，每个虚机出来的流量经过qvb接口进入br-int网桥后都会将seg_id设置到流规则里的metadata里，显然，不同的子网就会有不同的seg_id, 再结合destination ip就可以判断是L2还是L3流量。它和neutron的思想更近，可以代替DVR，比DVR的实现要简单，复杂度要低，更重要的是，它消除了影响neutron性能的veth和namespace这些东西。总之，它非常好，我也非常看好。但问题是它目前还不成熟，目前，DragonFlow仅支持中心化的SNAT与DNAT，还不支持在计算节点上做SNAT与DNAT。

还有一个就是openvswitch的OVN项目，设想地都非常好，问题是现在只是1.0版本，太多的特性没有实现。它将支持提供对L2/L3网络虚拟化的支持(logical switches, distributed logical l3 processing, software and hardware gateway, in-kernel based security groups, and L2/L3/L4 ACLs, tunnel-based[VXLAN, NVGRE, Geneve, STT, IPSec])。