云数据中心网络虚拟化——大二层技术巡礼之NVo3技术端到端隧道

NVo3（Network Virtualization over Layer 3），是IETF 2014年十月份提出的数据中心虚拟化技术框架。NVo3基于IP/MPLS作为传输网，在其上通过隧道连接的方式，构建大规模的二层租户网络。NVo3的技术模型如下所示，PE设备称为NVE（Network Virtualization Element），VN Context作为Tag标识租户网络，P设备即为普通的IP/MPLS路由器。NVo3在设计之初，VxLAN与SDN的联合部署已经成为了数据中心的大趋势，因此NVo3的模型中专门画出了NVA（Network Virtualization Authority）作为NVE设备的控制器负责隧道建立、地址学习等控制逻辑。

NVo3的思想起源于VxLAN，结合NVGRE和STT的发展，目前收敛为Geneve。上述技术都是端到端的隧道，CE为虚拟机或物理服务器，其实单纯地从NVo3的模型角度来看，后面要介绍的OTV/EVN/EVI这些DC间互联的隧道技术都属于NVo3的框架中。本专题将对端到端的NVo3技术进行深入的介绍。

1)VxLAN

VxLAN（Virtual eXtensible LAN，RFC 7348），是Vmware和Cisco联合提出的一种大二层技术，突破了VLAN ID只有4k的限制，允许通过现有的IP网络进行隧道的传输。别看VxLAN名字听起来和VLAN挺像，但是两者技术上可没什么必然联系。VxLAN是一种MACinUDP的隧道，下面是VxLAN的报头。

VxLAN封装的是以太网帧，外层的报头可以为IPv4也可以为IPv6。UDP Src Port是外层UDP的源端口号，它的值通过hash得到，常用来实现ECMP；Dst Port为VxLAN从IANA申请的端口4789；UDP checksum如果不为0，出口VTEP（VxLAN的NVE）必须进行计算，计算结果必须与该字段一致才能进行解封装，不一致则进行丢弃，checksum如果为0，则出口VTEP无条件解封装；VNI是VxLAN的VN Context，长度为24位，支持16 million的租户；后面是CE送出来的Ethernet原始帧，VxLAN GW对其中的VLAN tag有所要求。

NVo3技术中，NVE上的地址学习包括两类：第一类是学习本地VM的MAC与port的映射关系，第二类是学习远端VM的MAC地址与该VM所在NVE的IP地址的映射关系。标准VxLAN的地址学习仍为二层的自学习算法，通过组播在VTEP间泛洪。标准VxLAN的通信流程如下例所示。

首先，VTEP通过IGMP加入VNI 1的组播组，VNI 1中的BUM流量都将通过该组播组传输。虚拟机A与B间通信具体转发流程如下：VM A发送ARP请求，VTEP 1学习VM A的本地连接端口，然后将该ARP请求进行封装，标记好VNI后进行组播，VTEP 2收到后学习VNI 1中A的MAC地址与VTEP 1 的IP地址的映射关系，然后本地泛洪。B收到该ARP请求后进行回复，由于VTEP 2已经完成了自学习，因此VTEP 2封装报头后将向VTEP 1进行单播，同时VTEP 2学习VM B的本地连接端口。同理，VTEP 1收到ARP回复后，学习该VNI中MAC B与VTEP 2 IP地址的映射关系，然后再交给A。之后A和B间的数据流将通过单播在VETP 1和VTEP 2间传输。

上述为单播的过程，二层的组播过程与之类似，只不过外层的目的IP地址被封装为相应VNI的组播地址。可见，标准VxLAN的转发十分依赖于IP的组播（VxLAN不支持头端复制的伪广播），这对底层的IP网提出了相当的要求。而且将二层的ARP泛洪到底层的IP网上也不是很令人满意，因此目前VxLAN常常与SDN控制器配合——控制器集中地学习VM与VTEP的映射关系，以帮助VxLAN建立隧道，减少了绝大部分在IP网络上的组播。

一个VxLAN网络连接的主机都在一个网段中，如果租户需要多个网段则需要开通多个VxLAN网络，每个VxLAN网络都有自己的VNI。这些网端间的3层互通依赖于VxLAN GW，VxLAN GW作为网关将终结源主机所在的VxLAN然后进入目的主机的VxLAN。另外VxLAN网关还负责VxLAN与VLAN网络的连接，数据包从VxLAN网络进入VLAN网络时，VxLAN网关去掉VxLAN头并根据VNI标记原始帧中的VLAN，反之同理。

VxLAN核心的东西就这么多了。值得注意的是，VxLAN不允许VTEP接收IP分片，因此如果ingress VTEP封装隧道后超过了IP Router的MTU就会被分片，Egress VTEP收到分片后将直接丢弃，而VxLAN本身并没有MTU探测机制。

VxLAN用来建立虚拟机间端到端的隧道，常常被部署在物理服务器的HyperVisor中。考虑到软件性能的=问题，现在也有一些硬件交换机也可以支持VxLAN了。这几年VxLAN基本上已经成为了新一代数据中心技术的代名词，再配合SDN的集中式控制，VxLAN当下当仁不让地扛起了网络虚拟化的大旗。从目前来看，VxLAN在数据中心已经取得了对其他技术的压倒性优势，很多厂商都在担心会被VxLAN锁定，迫切地寻找着其他的替代方案。

大炮一响，黄金万两，NvGRE和STT相继登场。

2)NvGRE

NvGRE（Network virtualization GRE，RFC draft）是微软搞出来的数据中心虚拟化技术，是一种MACinGRE隧道。它对传统的GRE报头进行了改造，增加了24位的VSID字段标识租户，而FlowID可用来做ECMP。由于去掉了GRE报头中的Checksum字段，因此NvGRE不支持校验和检验。NvGRE封装以太网帧，外层的报头可以为IPv4也可以为IPv6。

NvGRE与VxLAN并没有什么核心的区别。虽然是在VxLAN之后提出的技术，但NvGRE变得更简单了，完全没有规定什么地址学习机制，就是靠NVA来指挥，看来是铁了心站到SDN这一队了。细节上NvGRE与VxLAN还是有一定区别的，比如：不支持与VLAN网络的互通；使用Outer SRC IP+VSID+FlowID做ECMP，不过这要求IP Router的硬件支持；支持头端复制的伪广播；同样不支持IP Router上的分片，但在RFC中探讨了MTU发现机制，等等。

微软又不是专门做网络的，有必要包装一个Vmware搞一个基本一样的技术吗？有，原因很简单，因为微软的Hyper-V跟Vmware 的vCloud可是死对头，有了VxLAN人家Vmware计算、存储、网络的虚拟化可都齐活儿了，微软要卖Hyper-V，总不可能拿死对头现成的技术过来吧，这样就有了NvGRE。

3)STT

STT（Stateless Transport Tunnel，RFC draft）是Nicira提出的数据中心虚拟化技术，是一种MACinTCP的隧道。之所以设计STT，是因为希望利用网卡的TSO（TCP Segment Offload）功能在隧道两端进行分片以支持巨型帧的传输，提高端到端的通信效率。Nicira被VMware收购后STT技术也自然易主，被用在NSX中做HyperVisor to HyperVisor的隧道技术。

虽然用到了TCP头，但是STT修改了里面的Seq字段和Ack字段的含义，不再用于重传和滑动窗口，是一种无状态的隧道。准确地说，STT使用的是一种TCP like的包头，只是为了伪装成TCP段来进行TSO。Src Port可用来做ECMP，DST Port为7471（正在向IANA申请）；Ack用来标识STT frame，Seq的upper 16 bits用于标识STT frame的长度，lower 16 bits用于标识current frame的偏移量。STT frame被分片后，各片的Ack和Seq的upper 16 bits均相同，而Seq的lower 16 bits各不相同，隧道出口设备上的网卡用之进行分片重组；TCP Flag和Urgent Pointer都不再具有意义；Version现为0；Flags标识了内层数据的类型与相关信息；L4 Offset标识了STT frame的末位到内层数据Layer 4（TCP/UDP）的偏移量；MSS为最大的分片长度；PCP为传输优先级；VLAN ID用于与VLAN网络互通；Context ID为64位的VN Context。STT的外层的报头可以为IPv4或者IPv6。

STT也没有规定地址学习机制，同样要配合SDN控制器完成转发。不过相比于NvGRE，STT还算比较有特色，起码首创地支持了分片的机制，不过STT也没有内生的MTU发现机制。另外，STT不支持伪广播；RFC建议支持DSCP和ECN；支持与VLAN网络的互通。

从某种角度来讲，STT的分片机制能够在一定程度上提高通信的效率，不过STT有一个致命的缺陷——它的TCP是无连接的，不会进行三次握手，也没有状态维护。虽然网卡做TSO时不关心这个问题，但防火墙、负载均衡器这些Middle Box可就不买账了。因此STT在实际部署时受到了很大的限制，在NSX中只被用来做Hyper-Hyper的隧道，想穿越过物理网络还得看VxLAN。STT的RFC也明确地提到了这个问题，希望将来Middle Box能做到STT aware——谈何容易啊！

4)Geneve

Geneve（Generic Network Virtualization Encapsulation，RFC Draft）是NVo3工作组总结VxLAN、NvGRE和STT提出的一种网络虚拟化技术，希望形成一种通用的封装格式，以便支持数据中心中隧道机制的后续演化。Geneve是今年5月份提出的，目前还处于草案阶段，不过从它的内容来看，确实是博采众长，未来具备相当的潜力。

Geneve采用了VxLAN的思路，是一种MACinUDP的隧道。之所以没用MACinGRE或者MACinTCP，作者估计是工作组考虑到GRE头部的可扩展性比较差，不具备可演进的能力。而用TCP头的话，如果仍保持TCP的特性，则维护有连接的隧道开销过大，如果像STT一样处理为无状态的，那么又会存在Middle Box的穿越问题。相比之下，UDP头就没有那么多问题，Geneve作为一种应用层协议不存在可扩展性的问题，而UDP本身的无连接特性又不会带来开销和兼容的问题。至于分片，Geneve建议使用Path MTU Discovery(RFC 1191)来探测传输路径上的MTU。

Geneve封装的是以太网帧，外层的报头可以为IPv4也可以为IPv6。UDP Src Port常通过hash获得，可用于ECMP，Dst Port为IANA分配给Geneve的6081；对于UDP Checksum，Geneve与VxLAN的处理办法相同，并建议使用NIC去Offload；Geneve头部采用了TLV格式，以支持隧道机制的演化，Opt Len为TLV的长度；O位为OAM标识，当O位置1的时候Geneve携带的为控制信令而非Ethernet payload；VNI为24位的VN Context；TLV的具体内容，目前Geneve还在制定草案；对Inner VLAN的处理，Geneve可选地支持VLAN Trunking与VLAN混合组网。

下面再来谈谈一些Geneve草案中除了封装格式以外的内容，借以简单地分析一下端到端NVo3隧道的演化思路。Geneve希望IP Router可选地支持对Geneve的理解，也就是说希望底层IP Fabric的传输能够考虑到隧道传输的需求，这在NvGRE和STT的草案中也都提到过，换句话说为了保障端到端的传输质量，隧道应该放开一些字段给传输网络去参考，而不是死守着透明的原则不放，其实Outer IP的DSCP和ECN字段就很适合做QoS，预计未来会有专门的机制去在NVE上做映射；Geneve参考了NvGRE的设计，希望可以将VNI作为ECMP的一个参考字段，未来估计TLV中的一些Option也会被用来标识细粒度的业务流，以支持精细化的虚网定制；Geneve可采用头端复制的伪广播，不再要求IP Fabric具备组播的能力，降低要求的同时简化了网管的配置工作；Geneve专门讨论了分片的NIC Offload问题，以降低新增隧道包头对传输性能造成的影响；Geneve也没有规定地址学习机制，说明端到端隧道+SDN已经成为当下业界的共识。

目前Geneve只提交了一版草案，到今年的11月过期，估计下一版很快就要出来了，让我们拭目以待，看看未来走势如何。

最后画几张表作为总结吧，方便读者直观地对这几种技术做个对比。