51学通信论坛2017新版

标题: 云数据中心网络虚拟化——大二层技术巡礼之NVo3技术端到端隧道 [打印本页]

---

作者: admin    时间: 2017-9-17 12:34
标题: 云数据中心网络虚拟化——大二层技术巡礼之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设备的控制器负责隧道建立、地址学习等控制逻辑。

[attach]882[/attach]

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的报头。

[attach]883[/attach]

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的通信流程如下例所示。

[attach]884[/attach]

首先，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。

[attach]885[/attach]

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的隧道技术。

[attach]886[/attach]

虽然用到了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。

[attach]887[/attach]

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月过期，估计下一版很快就要出来了，让我们拭目以待，看看未来走势如何。
最后画几张表作为总结吧，方便读者直观地对这几种技术做个对比。

	标准化	隧道 类型	地址学习	VN Context	头端复制	ECMP	精细化 匹配
VxLAN	RFC标准，De facto Standard	MAC inUDP	二层自学习	24位 VNI	不支持	源端口号	不支持
NvGRE	微软提交的草案	MAC inGRE	结合SDN	24位VSID	支持	Outer IP+ VSID+FlowID	8位FlowID
STT	VMware提交的草案	MAC inTCP	结合SDN	64位Context ID	不支持	源端口号	不支持
Geneve	工作组形成的草案	MAC inUDP	结合SDN	24位 VNI	支持	源端口号 +VNI	预计通过TLV支持

	分片Offload	传输质 量保障	OAM	Middle Box	IP Router Aware	网关上的VLAN Trunking
VxLAN	不支持	不支持	不支持	兼容	不支持	支持
NvGRE	不支持	不支持	不支持	基本兼容	建议支持	不支持
STT	原生支持	建议支持	不支持	不兼容	建议支持	支持
Geneve	建议支持	预计支持	支持	兼容	建议支持	可选支持

作者简介：
张晨，北京邮电大学未来网络理论与应用实验室研究生
主要研究方向：SDN、虚拟化、数据中心
个人博客：www.sdnv.xyz
个人邮箱：zhangchen9211@126.com
声明:本文转载自网络。版权归原作者所有,如有侵权请联系删除。

---

欢迎光临 51学通信论坛2017新版 (http://bbs.51xuetongxin.com/)

Powered by Discuz! X3