虚拟扩展局域网:关于三层网络上实现虚拟重叠二层网络的架构「RFC7348翻译」

Posted by SingChia Blog on December 1, 2017

序言

  • 单独提交
  • 编号7348
  • 类别:信息类
  • ISSN:2070-1721
  • 相关人员:
    • M. Mahalingam@Storvisor
    • D. Dutt@Cumulus Networks
    • K. Duda@Arista
    • P. Agarwal@Broadcom
    • L. Kreeger@Cisco
    • T. Sridhar@VMware
    • M. Bursell@Intel
    • C.Wright@RedHat文档
  • 时间:2014.08

摘要

本文档描述了VXLAN,VXLAN用来满足多租户使用的数据中心重叠网络的需求。 该框架和相关协议可以用于云服务提供商以及企业级数据中心。 本文档也描述了部署VXLAN对于互联网社区的优势。

文档状态

本文档并不是互联网标准跟踪文档;而是用来公布协议信息。

本文档归属RFC系列,独立与其他RFC分支。 RFC的编辑们认为该文档不涉及实施和部署且具有一定严谨性,因此可以公布。 所有RFC文档不作为任何互联网候选标准,详情见RFC5741第2节。

本文档的现状、勘误以及反馈可以从此处获取。

版权说明

作者为序言相关人员,版权属于2014 IEIF Trust,保留所有权利。

本文档是BCP 78的子项并且IETF信托相关法律影响了本文档的发布时间. 请仔细阅读本文档,本文档描述了读者的权利以及限制。

目录

  1. 介绍
    • 1.1. 缩写和定义
  2. 习惯用法
  3. VXLAN问题陈述
    • 3.1. 最小生成树协议和vlan数目范围带来的限制
    • 3.2. 多租户环境
    • 3.3. 接入交换机mac表耗尽
  4. VXLAN
    • 4.1. 虚拟机间单播
    • 4.2. 映射到多播的广播
    • 4.3. 物理设施要求
  5. VXLAN帧格式
  6. VXLAN部署场景
    • 6.1. 内层vlan标签处理
  7. 安全意见
  8. IANA意见
  9. 引用
    • 9.1. 规范引用
    • 9.2. 信息引用
  10. 致谢

1. 介绍

在物理设施上服务虚拟化的需求越来越重要。 一台物理服务器上的虚拟机可以有自己的mac地址。 大量虚拟机之间的通信以及与交换机之间的连接会消耗以太网上交换机大量的mac地址映射。

如果数据中心的虚拟机放到各自的vlan中,vlan的数量也会大大增加,甚至需要好几千个,当前的vlan数量限制为4096,肯定是不足的。

数据中心又要求服务多租户,每一个都要求隔离网络,使用物理设施隔离太烧钱,所以网络管理员可以想办法在共享网络上隔离出虚拟网络来。 在这个场景下,普遍会遇到mac地址和vlan id之间的绑定多用户之间是冲突的。

对于2层物理网络的虚拟环境来说,一个重要的需求是数据中心甚至跨数据中心的二层网络可扩展,以便于计算、网络和存储资源的分配。 这样的网络下,传统的生成树协议下的回环拓扑结构会导致大量的不可用连接。

最后一个场景是网络操作者更喜欢用IP协议来做物理设备之间的连接(比如,为了防止大量物理链路被忽略,使用Equal-Cost Multipath(ECMP)来实现多路径扩展)。 即使在这种情况下,二层网络模型在内部虚拟机交流上仍是需要保留的。

以上场景引起了重叠网络的需求,VXLAN 重叠网络将虚拟机之间的数据封装进mac流量内,以构建逻辑上的通道。

本文档详细说明了VXLAN以适用上述需求,也说明了互联网社区部署VXLAN的优势。

1.1. 缩写和定义

缩写 定义
ACL Access Control List, 访问控制列表
ECMP Equal-Cost Multipath, 等价多路径
IGMP Internet Group Management Protocol, 互联网组播管理协议
IHL Internet Header Length, 互联网头部长度
MTU Maximum Transmission Unit, 最大传输单元
PIM Protocol Independent Multicast, 协议无关组播?
SPB Shortest Path Bridging, 最短路径桥接
STP Spanning Tree Protocol, 生成树协议
ToR Top of Rack,柜顶 ToR Switch一般指接入交换机
TRILL Transparent Interconnection of Lots of Links, 大量链路的透明连接?
VLAN Virtual Local Area Network, 虚拟局域网
VM Virtual Machine 虚拟机、虚机
VNI VXLAN Network Identifier, VXLAN网络标识
VETP VXLAN Tunnel End Point, 发起或者结束VXLAN通道的实体
VXLAN Virtual eXtensible Local Area Network, 虚拟扩展局域网
VXLAN Segment 虚拟机交流的VXLAN二层重叠网络
VXLAN Gateway VXLAN之间发送流量的实体

2. 习惯用法

关键词”MUST必须”, “MUST NOT必须不能”, “REQUIRED要求”, “SHALL最好要”, “SHALL NOT最好不要”, “SHOULD 应该”, “SHOULD NOT不应该”, “RECOMMENDED建议”, “MAY可能”以及”OPTIONAL可选”这些词汇,描述在文档(RFC2119)中。

3. VXLAN问题陈述

本节提供更多关于VXLAN方面的细节,关注点在数据中心的网络设施和相关问题上。

3.1. 生成树导致的限制和VLAN的范围

当前二层网络使用IEEE 802.1D生成树协议(STP)去避免可选多路径引起的网络回环。STP会放弃使用某些链路来避免数据帧的重复拷贝和回环。一些网络中心操作员会觉得在使用STP的情况下设备空闲是一种资源浪费。而且STP引起的部分链路不可用还会影响故障恢复。不过最近有一些新进展,比如TRILL协议(RFC6325)和SPB被提出,用来规避STP引起的一些问题。此外STP还可以用服务器配置来解决,同一个机架上的服务器处于同一个子网,不同的机架不同的子网,不过这个方法跟虚拟机二层网络通信模型有冲突。最后一段译者存在疑惑。

数据中心二层网络的一个关键特性是使用虚拟局域网来隔绝广播域,以太帧中12比特的VLAN ID用来将二层网络隔离为多个广播域。即使最多只能有4096个,VLAN事实上已经服务了很多的数据中心。随着虚拟化的增长,这个限制已经快不能满足需求了。此外,STP的存在也限制了VLAN可用数。虚拟化基础上的多租户环境加速了更大数量VLAN的需求,详见3.3节

3.2. 多租户环境

云计算给多租户环境提供了按需弹性资源供给。最典型的案例就是云服务商在一套物理设施上给多客户或多用户提供弹性服务。

一个租户网络流量的独立性可以通过二层或者三层网络来解决。对于二层网络有VLANs来隔离流量 – 比如一个租户直接由VLAN来区分。不过因为租户的数量太多,4094个VLAN常常不够用。而且还有每个租户需要多个VLAN的情况。

另一个相关问题就是跨仓(cross-pod)扩展,一个仓一般包括一到多个附带着网络和存储的服务器。租客可能开始只用一个仓,随着扩展,可能开始需要其他仓,尤其是其他仓根本没有被充分使用。这个场景就需要可以动态扩展的二层网络了。

三层网络来隔绝多租户流量也不复杂。两个租户在各自的环境可能会用到相同的ip地址,这样就需要云服务提供商来用一些其他的形式来隔绝地址了。进一层约定,要求所有租户内部虚机通信是使用ip而不是直接依赖2层协议或者其他非ip三层协议。

3.3. 接入交换机mac表耗尽

目前虚拟化环境对连接服务器的接入交换机的mac地址表也有要求。多租户环境下不再是一个mac地址对应一个服务器了,接入交换机会学习大量虚机的mac地址(每个服务器上可能有数百个)。这是因为虚机到物理网路上的流量是复用服务器跟交换机之间链路的。一个典型的接入交换机连接服务器端口的数目为24或者48个。数据中心责可能由多个接入交换机组成,每个交换机需要维持一份地址表以提供跨物理服务器的虚机通信。虚拟化环境对地址表大小需求远大于非虚拟化环境。

如果接入交换机的mac地址表满了,交换机可能会停止学习新地址直到有地址项过期,这样会导致超出mac地址表的帧大量洪泛。

4. VXLAN

VXLAN(虚拟扩展局域网)用来处理上述多租户多虚机环境下2,3层网络的需求。VXLAN跑在现有的网络设备上并虚拟出一个更大的2层网络。也就是,VXLAN是一个在3层网络上构建的重叠网络。每个重叠网络都被称为VXLAN段。只有在同一个VXLAN段的虚机之间才能够通信。每个VXLAN段都使用一个24比特段ID来标识,术语为”VXLAN Network Identifier(VNI)”。24比特的ID使得有1600万+的VXLAN段能同时存在同一个管理网络中。

VNI同时也决定了内部虚机的mac帧的范围。因此不同的VXLAN段之间可以有相同的mac地址,却不会有流量互串的情况。VNI作为头部封装了来自虚机的mac帧。下面的章节中,VXLAN段VXLAN重叠网络是相同的意思。

因为有封装,VXLAN也可以称为隧道方法,这个隧道是构建在3层网络上的重叠2层网络。这些通道是无状态的,因此每个帧是按照一系列规则来封装的。下面章节讨论的隧道终端(VXLAN隧道终端或者叫VTEP)是位于虚机宿主服务器上的。此处有hypervisor,在实际的几种vxlan实现中很少见有hypervisor,因此译者省略。因此VXLAN协议里的VNI、隧道以及外层头部封装只有VTEP才知道,虚机是看不到封装的(见图1)。注意VTEP也可以以硬件交换机的形式存在,在第六节的VXLAN部署场景中有相关讨论。

下面的章节讨论了VXLAN环境的典型流量场景,该VXLAN环境的控制方法是通过学习数据平面的来达成的。虚机的mac地址和VTEP的IP地址的映射关系会因为源地址学习被记录下来。而未知目的地址、广播、多播帧则会使用多播协议来承载。

除了基于学习的控制平面,也有其他方法来让虚机mac地址和VETP的IP地址映射信息分发下去。可能的方法包括VETP来查找鉴权中心或者目录中心,以及鉴权中心主动分发这些信息导VETP上。有时候这两种方法也被称为推送和拉取模型。本文档主要关注在VXLAN中学习数据平面信息作为控制平面的方法。

4.1. 虚机间单播

如果一个虚机是在VXLAN重叠网络中,那这个虚机感知不到VXLAN存在的。如果这个虚机要跟不同宿主机上的虚机通信,只需要跟非虚拟环境一样发送一个到目标的mac帧。宿主机上的VETP来查找目的虚机相关联的VNI。这个决定了两个虚机是否处于同一个VXLAN段,如果相同再看是否有虚机mac地址对应的VTEP的IP地址。如果有,则外层mac地址、外ip头部和VXLAN头部一起作为头部追加到虚机产生的mac帧上,这个封装好的包被发往目的VTEP。对端的VTEP拿到包后验证VNI合法性并检查是否有内部虚机能匹配上VNI和mac地址。如果匹配上则拿掉这个封装的头部并发送给目的虚拟机。目的虚拟机不会知道VNI以及帧是从VXLAN封装发送过来的。

除了把包发送到目的虚机,远程VTEP还会学习源mac地址和外层源IP地址的映射关系。这个映射关系被存储在表里,随后目标虚机发送返回包的时候就可以查到该映射信息,就不会有返回包目的地址未知导致洪泛的情况发生。

除了4.2节描述的广播情况外,单播与非VXLAN环境相同,目标虚机的mac地址是在发送前就决定好的。广播帧被封装在多播包里,具体见4.2节。

4.2. 映射到多播的广播

如果有一个虚机想要使用IP协议来与目的虚机通信并且两个虚机在同一个子网,虚机会发送一个地址解析协议(ARP)广播包。 在非VXLAN环境下,这个帧会经过交换机发送到同一VLAN的主机。

在VXLAN环境下,VNI和IP头部和UDP头部一起插入在包首。不过这个包被发往这个VNI重叠 网络所在的IP多播组中。

为了更高效,我们需要有一个VNI和IP多播组的映射。这个映射在管理层通过管理通道已经提供给各VTEP了。使用这个映射,VTEP就可以提供给多播交换机或路由器IGMP成员报告,就可以实现VXLAN对应的多播组的加入和离开。使用特定的多播地址来确定主机上某个成员是否可用来达到剪枝的目的(见RFC4541译者存疑。此外,多播路由协议的使用可以提供高效的三层多播树,比如PIM-SM(见RFC4601)。

VTEP发送组播信息(*,G)来加入一个组播。随着虚机在不同宿主机上的启停,大量VXLAN隧道主机会改变,需要组播信息来更新组。另外,因为每个VTEP可以同时是多播包的源和目的,BIDIR-PIM(RFC5015)等类似的双向协议会让组播协议更高效。

目的虚机会返回一个标准ARP回复。这个帧会被VTEP使用VXLAN封装好以IP单播发送回去,因为ARP请求来的时候相关的mac地址、VTEP的IP地址已经学习过了。
需要注意的是除了广播帧外,多播帧和目的mac地址未确定的帧也会使用多播协议来发送。

4.3. 物理设施需求

如果基础网络设施上IP多播被使用,那网络內每个交换机和路由器都可以使用多播路由协议如PIM-SM。这些协议可以建立更高效的多播树使多播包只发送到需要接收的主机上。

类似一点,虚机间真实网络连接并不一定需要三层网络:VXLAN也可以工作在二层网络。不管什么情况,二层网络中更高效的多播复制可以通过IGMP窥探来实现。

VTEP绝对不可以对VXLAN包进行分段。中间路由器可能会对VXLAN封装比较大的包进行分段。目的VTEP可以默默丢弃这样的VXLAN分段。为了保证流量传递中不发生分段,建议物理网络的MTUs设置成可以容纳更大帧的大小。有些技术比如路径MTU发现(见RFC1191RFC1981)可以用来满足这样的需求。

5. VXLAN帧格式

下面是VXLAN帧格式。从里往外解析 – 在外层帧校验序列上面,有内层mac帧,帧內包括有负载和帧头部,头部包括原始VLAN信息、以太类型、源和目的mac地址。更多关于内层VLAN标签处理见第6节。

内层mac帧被下面四个头部给封装(同样从里往外):
VXLAN头部:一个8字节字段:

  • 标志(8比特):合法的VNI的I标志必须设置为1。其他7比特(R标志)是保留并设置为0的。对端接收忽略这个标志。
  • VNI:24比特指定了单个VXLAN重叠网络,也就是虚机所在的VXLAN网络。不通VXLAN重叠网络的虚机不能互相通信。
  • 保留字段(24比特和8比特):必须传输时设置为0,接收时忽略。

外层UDP头部:外层UDP头部包括VTEP提供的源端口和已知的UDP目的端口。

  • 目的端口:IANA已经给VXLAN分配了4789端口,协议实现者应该使用这个端口作为默认端口。早起的VXLAN实现可能用过其他的目的端口。为了让不同实现的互操作性,目的端口应该是可以配置的。
  • 源端口:建议源端口是由内层包的某些字段做哈希得到的 – 比如使用内层以太帧头部来做哈希。这是为了允许虚机间等价多路径/负载均衡的熵级别。用这个方法计算UDP源端口号的时候,建议这个值在49152-65535这个动态/私有端口范围内(见RFC6335)。
  • UDP校验和:应该以0来传输。当一个包接收时的UDP校验和为0,必须解封装。可选的是,如果封装终端在此字段写入一个非0的UDP校验和,那这个值必须是对IP头、UDP头、VXLAN头和封装的mac帧正确的计算结果。对端收到这个包发现是非0的校验和,可以自行选择去验证这个校验和。如果验证失败那么这个包必须被丢弃。如果对端不去验证或者验证正确,那这个包必须被解封装。

外层IP头部:源IP地址就是虚机(内层mac地址的虚机)相连的VTEP的IP地址。目的IP地址可能是单播或者多播地址(见4.1和4.2节)。如果是单播地址,就是内层目的mac地址关联的VTEP的IP地址。如果是多播地址,见4.2节中的场景。

外层以太头部(示例):图1是外层以太帧+IP+UDP+VXLAN+内层以太帧的示例。外层mac地址可能是VTEP的mac地址,或者是一个3层路由的mac地址。外层VXLAN标签是可选项,如果有值是用来表示LAN上的VXLAN流量。

图1:带有外层IPv4头部的VXLAN帧格式

上面图1的帧格式展示了使用IPv4作为传输的以太帧隧道。IPv6的VXLAN详情在下图显示。

图2:带有外层IPv6头部的VXLAN帧格式 由于译者不熟悉IPv6,直接以原文档显示

6. VXLAN部署场景

典型情况下,VXLAN部署于可能分布在不同接入交换机的可虚拟化主机上。每个交换机既可能是不同的3层网络也可能在一个2层网络上。VXLAN段或者说重叠网络在2层或者3层网络上重叠。

图3中显示了三层网络环境下的两个可虚拟化服务器。两个服务器是同一交换交换机下还是不同还是跨机房都是不一定的。下面环境中有4个VXLAN段,VNI分别是22,34,74和98。假设服务器1上的VM1-1和服务器2上的VM2-4在环境VNI 22上。虚机发出的包是经过封装和解封装并且是服务器1和服务器2上的VTEP完成的,不过虚机感知不到这些。服务器1上的VM1-2和服务器2上的VM2-1在VNI 34上;服务器1上VM1-3和服务器2上VM2-2在环境VNI 74;服务器1上VM1-4和服务器2上VM2-3在环境VNI 98上。

图3:VXLAN部署 - 跨三层网络的VTEP

除了上面的服务器作为VTEP的部署方法外,还有实现了VXLAN协议的物理服务器作为VTEP的方法。另一个场景是VXLAN重叠网络的节点需要与其他不同网络类型的节点通信,比如VLAN网络。这些节点可能是虚机货实体机。为了支持这种通信,部署环境里可以加上VXLAN网关(见图4的交换机作为VXLAN网关)用来转发VXLAN和非VXLAN的流量。

图4的交换机符合下面的规则。对于从VXLAN口的进来的帧,网关去除VXLAN头部并发往内部以太帧目的mac地址相连的物理端口。如果没有配置trunk,解封装的帧如果带有VLAN ID应该被丢弃。从非VXLAN口进来的帧需要根据VLAN ID对应到一个特定的VXLAN网络。除非有显示的配置,不然VLAN ID在封包前需要移除。

这些提供了VXLAN边界功能的网关可能是接入交换机或者是数据中心拓扑种更上层的交换机,比如核心交换甚至WAN边界设备。WAN边界设备可以有提供者边界(PE)路由在一个多云环境里中提供VXLAN边界。不管哪种,网关功能可以被硬件或者软件实现。

图4:VXLAN部署 - VXLAN网关

6.1. 内部VLAN标签处理

VTEP和VXLAN网关的内部VLAN标签处理应当遵守以下约定:

没有显示配置的情况下,如果解封装的包有内部VLAN标签应该被丢弃。在封装时没有显示配置情况下VTEP不应该包括内部VLAN标签。如果虚机的包带有VLAN标签,没有显示配置时应该去除该标签。

7. 安全意见

传统的2层网络只有可能被“内部”的流氓节点攻击 – 要么通过伪造包取代mac帧的方法来访问一个LAN并窥探流量。要么利用洪泛来导致拒绝服务(DoS)。MAC利用IP协议来传递流量的机制大大的拓宽了攻击范围。通过订阅一到多个携带者VXLAN段广播流量的多播组来实现注入。或者通过伪造UDP上的MAC帧来注入伪造流量,是有可能劫持mac地址的。

本文不会讨论防止此类IP层上而非其他传统机制攻击的方法,只会简单描述一些VXLAN环境下可能的安全方法。

传统伪节点2层网络攻击的风险能够通过限制部署和管理虚机及网关的管理员范围来减小。此外,这种管理方法可以通过配置类似于802.1X的方法来控制每个节点的访问。基于UDP封装的VXLAN允许物理交换机的配置和5元组ACL(访问控制列表)的使用也能控制一部分。

VXLAN重叠网络是设计运行在已有的LAN基础环境上的。为了保证VXLAN节点和VTEP在LAN上是经过认证的,建议这个设计给VXLAN流量和VTEP的VLAN提供一种安全方法。

而且,VXLAN要求VNI和虚机成员有合适的映射。同样建议有一个的安全机制来保证VTEP上的管理通道的通信。

8. IANA意见

UDP端口(4789)已经被IANA分配给VXLAN用于服务名和传输层协议端口号了。看第5节关于端口号的讨论。

9. 引用

9.1 规范引用

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

9.2 信息引用

[802.1aq] IEEE, “Standard for Local and metropolitan area networks – Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks – Amendment 20: Shortest Path Bridging”, IEEE P802.1aq-2012, 2012.

[802.1D] IEEE, “Draft Standard for Local and Metropolitan Area Networks/ Media Access Control (MAC) Bridges”, IEEE P802.1D-2004, 2004.

[802.1X] IEEE, “IEEE Standard for Local and metropolitan area networks – Port-Based Network Acces Control”, IEEE Std 802.1X-2010, February 2010.

[RFC1191] Mogul, J. and S. Deering, “Path MTU discovery”, RFC 1191, November 1990.

[RFC1981] McCann, J., Deering, S., and J. Mogul, “Path MTU Discovery for IP version 6”, RFC 1981, August 1996.

[RFC4541] Christensen, M., Kimball, K., and F. Solensky, “Considerations for Internet Group Management Protocol(IGMP) and Multicast Listener Discovery (MLD) Snooping Switches”, RFC 4541, May 2006.

[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)”, RFC 4601, August 2006.

[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, “Bidirectional Protocol Independent Multicast (BIDIR-PIM)”, RFC 5015, October 2007.

[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, “Routing Bridges (RBridges): Base Protocol Specification”, RFC 6325, July 2011.

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, “Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry”, BCP 165, RFC 6335, August 2011.

10. 致谢

作者希望感谢:Ajit Sanzgiri对于安全意见章节的贡献和编辑意见;Joseph Cheng, Margaret Petrus, Milin Desai, Nial de Barra, Jeff Mandin, and Siva Kollipara的检查、录入和评论。

各位作者地址

   Mallik Mahalingam
   Storvisor, Inc.
   640 W. California Ave, Suite #110
   Sunnyvale, CA 94086.
   USA

   EMail: mallik_mahalingam@yahoo.com


   Dinesh G. Dutt
   Cumulus Networks
   140C S. Whisman Road
   Mountain View, CA 94041
   USA

   EMail: ddutt.ietf@hobbesdutt.com


   Kenneth Duda
   Arista Networks
   5453 Great America Parkway
   Santa Clara, CA 95054
   USA

   EMail: kduda@arista.com


   Puneet Agarwal
   Broadcom Corporation
   3151 Zanker Road
   San Jose, CA 95134
   USA

   EMail: pagarwal@broadcom.com
   
   
   Lawrence Kreeger
   Cisco Systems, Inc.
   170 W. Tasman Avenue
   San Jose, CA 95134
   USA

   EMail: kreeger@cisco.com


   T. Sridhar
   VMware, Inc.
   3401 Hillview
   Palo Alto, CA 94304
   USA

   EMail: tsridhar@vmware.com


   Mike Bursell
   Intel
   Bowyer's, North Road
   Great Yeldham
   Halstead
   Essex. C09 4QD
   UK

   EMail: mike.bursell@intel.com


   Chris Wright
   Red Hat, Inc.
   100 East Davie Street
   Raleigh, NC 27601
   USA

   EMail: chrisw@redhat.com