云计算和虚拟化都要用到的核心技术 VXLAN 网络，你掌握了吗？

Posted 2021-04-29 奇妙的Linux世界

公众号关注 「奇妙的 Linux 世界」

设为「星标」，每天带你提升技术视野！

云计算、虚拟化相关技术的发展，传统的网络无法满足于规模大、灵活性要求高的云数据中心的要求，于是便有了 overlay 网络的概念。overlay 网络中被广泛应用的就是 vxlan 技术。首先我们了解一下随着云计算的发展，传统网络面临哪些挑战。

1. 虚拟机迁移范围受到网络架构限制

2. 虚拟机规模受网络设备表项规格的限制

3. 网络隔离/分离能力限制

VLAN作为当前主流的网络隔离技术，在标准定义中只有12比特，也就是说可用的VLAN数量只有4000个左右。对于公有云或其它大型虚拟化云计算服务这种动辄上万甚至更多租户的场景而言，VLAN的隔离能力显然已经力不从心。

VXLAN网络的初相识

1. VXLAN网络模型

从上图可以看到，VXLAN网络中出现了以下传统数据中心网络中没有的新元素：

• VTEP（VXLAN Tunnel Endpoints，VXLAN隧道端点）
  
  

VXLAN网络的边缘设备，是VXLAN隧道的起点和终点，VXLAN报文的相关处理均在这上面进行。总之，它是VXLAN网络中绝对的主角。VTEP既可以是独立的网络设备（比如华为的CE系列交换机），也可以是虚拟机所在的服务器。那它究竟是如何发挥作用的呢？答案稍候揭晓。

• VNI（VXLAN Network Identifier，VXLAN 网络标识符）
  
  

前文提到，以太网数据帧中VLAN只占了12比特的空间，这使得VLAN的隔离能力在数据中心网络中力不从心。而VNI的出现，就是专门解决这个问题的。VNI是一种类似于VLAN ID的用户标示，一个VNI代表了一个租户，属于不同VNI的虚拟机之间不能直接进行二层通信。VXLAN报文封装时，给VNI分配了足够的空间使其可以支持海量租户的隔离。详细的实现，我们将在后文中介绍。

• VXLAN隧道

“隧道”是一个逻辑上的概念，它并不新鲜，比如大家熟悉的GRE。说白了就是将原始报文“变身”下，加以“包装”，好让它可以在承载网络（比如IP网络）上传输。从主机的角度看，就好像原始报文的起点和终点之间，有一条直通的链路一样。而这个看起来直通的链路，就是“隧道”。顾名思义，“VXLAN隧道”便是用来传输经过VXLAN封装的报文的，它是建立在两个VTEP之间的一条虚拟通道。

2. VXLAN是如何解决以上挑战

2.1 解决虚拟机迁移范围受到网络架构限制问题

overlay网络的本质是在三层网络中实现二层网络的扩展。三层网络可以通过路由的方式在网络中分发，而路由网络本身并无特殊网络结构限制，具备良性大规模扩展能力，并且对设备本身无特殊要求，以高性能路由转发为佳，且路由网络本身具备很强的的故障自愈能力、负载均衡能力。前面提到，为了保证业务不中断，VM的迁移就必须发生在同一个二层域内。有了VTEP的封装机制和VXLAN隧道后，所谓的 “二层域”就可以轻而易举的突破物理上的界限？也就是说，在IP网络中， “明”里传输的是跨越三层网络的UDP报文，“暗”里却已经悄悄将源VM的原始报文送达目的VM。就好像在三层的网络之上，构建出了一个虚拟的二层网络，而且只要IP网络路由可达，这个虚拟的二层网络想做多大就做多大。

2.2 解决虚拟机规模受网络设备表项规格的限制问题

2.3 解决网络隔离/分离能力限制

一个VNI代表了一个租户，属于不同VNI的虚拟机之间不能直接进行二层通信。VTEP在对报文进行VXLAN封装时，给VNI分配了24比特的空间，这就意味着VXLAN网络理论上支持多达16M（即：2^24-1）的租户隔离。相比VLAN，VNI的隔离能力得到了巨大的提升，有效得解决了云计算中海量租户隔离的问题。

3. VXLAN报文格式

VTEP对VM发送的原始以太帧（Original L2 Frame）进行了以下“包装”：

• VXLAN Header:

增加VXLAN头（8字节），其中包含24比特的VNI字段，用来定义VXLAN网络中不同的租户。此外，还包含VXLAN Flags（8比特，取值为00001000）和两个保留字段（分别为24比特和8比特）。

• UDP Header:

VXLAN头和原始以太帧一起作为UDP的数据。UDP头中，目的端口号（VXLAN Port）固定为4789，源端口号（UDP Src. Port）是原始以太帧通过哈希算法计算后的值。

• Outer IP Header:

• Outer MAC Header:

VXLAN报文转发机制

以CE系列交换机的实现为例

1. 建立VXLAN隧道

前面提到的“同一大二层域”，就类似于传统网络中VLAN（虚拟局域网）的概念，只不过在VXLAN网络中，它有另外一个名字，叫做Bridge-Domain，简称BD。

我们知道，不同的VLAN是通过VLAN ID来进行区分的，那不同的BD是如何进行区分的呢？其实前面已经提到了，就是通过VNI来区分的。对于CE系列交换机而言，BD与VNI是1：1的映射关系，这种映射关系是通过在VTEP上配置命令行建立起来的。配置如下：

bridge-domain 10 //表示创建一个“大二层广播域”BD，其编号为10 vxlan vni 5000  //表示在BD 10下，指定与之关联的VNI为5000

VTEP会根据以上配置生成BD与VNI的映射关系表，该映射表可以通过命令行查看，如下所示：

<HUAWEI> display vxlan vniNumber of vxlan vni : 1VNI BD-ID State ----------------------------------5000           10               up

有了映射表后，进入VTEP的报文就可以根据自己所属的BD来确定报文封装时该添加哪个VNI。那么，报文根据什么来确定自己属于哪个BD呢？

在回答“如何确定报文属于哪个BD”之前，必须先要回答“哪些报文要进入VXLAN隧道”。

在VXLAN网络中，VTEP上有一个叫做“二层子接口”的逻辑接口，主要做两件事：一是根据配置来检查哪些报文需要进入VXLAN隧道；二是判断对检查通过的报文做怎样的处理。在二层子接口上，可以根据需要定义不同的流封装类型（类似于传统网络中不同的接口类型）。CE系列交换机目前支持三种不同的流封装类型，分别是dot1q、untag和default，它们各自对报文的处理方式如表3-1所示。有了这张表，你就能明白哪些报文要进VXLAN隧道了。

说明：VXLAN隧道两端二层子接口的配置并不一定是完全对等的。正因为这样，才可能实现属于同一网段但是不同VLAN的两个VM通过VXLAN隧道进行通信。

看了上面的描述，再来回答“如何确定报文属于哪个BD”就非常简单了。其实，只要将二层子接口加入指定的BD，然后根据二层子接口上的配置，就可以确定报文属于哪个BD啦！

比如下图所示的组网，我们可以分别在VTEP的两个物理接口10GE 1/0/1和10GE 1/0/2上配置不同流封装类型的二层子接口并将其分别加入不同的BD。

基于二层物理接口10GE 1/0/1，分别创建二层子接口10GE 1/0/1.1和10GE 1/0/1.2，且分别配置其流封装类型为dot1q和untag。配置如下：

interface 10GE1/0/1.1 mode l2 //创建二层子接口10GE1/0/1.1 encapsulation dot1q vid 10 //只允许携带VLAN Tag 10的报文进入VXLAN隧道 bridge-domain 10   //报文进入的是BD 10

interface 10GE1/0/1.2 mode l2   //创建二层子接口10GE1/0/1.2 encapsulation untag //只允许不携带VLAN Tag的报文进入VXLAN隧道 bridge-domain 20   //报文进入的是BD 20

基于二层物理接口10GE 1/0/2，创建二层子接口10GE 1/0/2.1，且流封装类型为default。配置如下：

interface 10GE1/0/2.1 mode l2 //创建二层子接口10GE1/0/2.1 encapsulation default //允许所有报文进入VXLAN隧道 bridge-domain 30   //报文进入的是BD 30

此时你可能会有这样的疑问，为什么要在10GE 1/0/1上创建两个不同类型的子接口？是否还可以继续在10GE 1/0/1上创建一个default类型的二层子接口？换句话说，用户应该如何选择配置哪种类型的二层子接口？三种类型的二层子接口之间，是否存在配置约束关系？

答案是不可以。其实根据上表的描述，这一点很容易理解。因为default类型的二层子接口允许所有报文进入VXLAN隧道，而dot1q和untag类型的二层子接口只允许某一类报文进入VXLAN隧道。这就决定了，default类型的二层子接口跟其他两种类型的二层子接口是不可以在同一物理接口上共存的。否则，报文到了接口之后如何判断要进入哪个二层子接口呢。所以，default类型的子接口，一般应用在经过此接口的报文均需要走同一条VXLAN隧道的场景，即下挂的VM全部属于同一BD。例如，图3-3中VM3和VM4均属于BD 30，则10GE 1/0/2上就可以创建default类型的二层子接口。

再来看下为什么可以在10GE 1/0/1上分别创建dot1q和untag类型的二层子接口。如图上所示，VM1和VM2分别属于VLAN 10和VLAN 20，且分别属于不同的大二层域BD 10和BD 20，显然他们发出的报文要进入不同的VXLAN隧道。如果VM1和VM2发出的报文在到达VTEP的10GE 1/0/1接口时，一个是携带VLAN 10的Tag的，一个是不携带VLAN Tag的（比如二层交换机上行连接VTEP的接口上配置的接口类型是Trunk，允许通过的VLAN为10和20，PVID为VLAN 20），则为了区分两种报文，就必须要在10GE 1/0/1上分别创建dot1q和untag类型的二层子接口。所以，当经过同一物理接口的报文既有带VLAN Tag的，又有不带VLAN Tag的，并且他们各自要进入不同的VXLAN隧道，则可以在该物理接口上同时创建dot1q和untag类型的二层子接口。

现在，我们可以来看下VXLAN隧道是怎么建立起来的了。一般而言，隧道的建立不外乎手工方式和自动方式两种。

• 手工方式

对于CE系列交换机，以上配置是在NVE（Network Virtualization Edge）接口下完成的。配置过程如下：

interface Nve1 //创建逻辑接口NVE 1 source 1.1.1.1 //配置源VTEP的IP地址（推荐使用Loopback接口的IP地址） vni 5000 head-end peer-list 2.2.2.2  vni 5000 head-end peer-list 2.2.2.3

<HUAWEI> display vxlan vni 5000 verbose BD ID : 10 State : up NVE : 288 Source : 1.1.1.1 UDP Port : 4789 BUM Mode : head-end Group Address : -  Peer List : 2.2.2.2 2.2.2.3

根据上表中的Peer List，本端VTEP就可以知道属于同一BD（或同一VNI）的对端VTEP都有哪些，这也就决定了同一大二层广播域的范围。当VTEP收到BUM（Broadcast&Unknown-unicast&Multicast，广播&未知单播&组播）报文时，会将报文复制并发送给Peer List中所列的所有对端VTEP（这就好比广播报文在VLAN内广播）。因此，这张表也被称为“头端复制列表”。当VTEP收到已知单播报文时，会根据VTEP上的MAC表来确定报文要从哪条VXLAN隧道走。而此时Peer List中所列的对端，则充当了MAC表中“出接口”的角色。在后面的报文转发流程中，你将会看到头端复制列表是如何在VXLAN网络中指导报文进行转发的。

• 自动方式

自动方式下VXLAN隧道的建立需要借助于其他的协议，例如BGP。CE系列交换机中，自动方式建立VXLAN隧道主要应用在EVN（Ethernet Virtual Network）和VXLAN的分布式网关场景中。本文不对该方式进行详细讲述，具体实现可参考EVN的相关资料。

从前面的描述我们知道，属于同一BD的VXLAN隧道可能不止一条，比如前面的头端复制列表中，同一个源端VTEP（1.1.1.1）对应了两个对端VTEP（2.2.2.2和2.2.2.3）。那就带来了另一个问题，报文到底应该走哪一条隧道呢？

2. VXLAN网络中报文的转发流程

• 同子网互通

VM_A、VM_B和VM_C同属于10.1.1.0/24网段，且同属于VNI 5000。此时，VM_A想与VM_C进行通信。

ARP请求报文转发流程

ARP请求报文的转发流程如下：

VTEP_1收到ARP请求后，根据二层子接口上的配置判断报文需要进入VXLAN隧道。确定了报文所属BD后，也就确定了报文所属的VNI。同时，VTEP_1学习MAC_A、VNI和报文入接口（Port_1，即二层子接口对应的物理接口）的对应关系，并记录在本地MAC表中。之后，VTEP_1会根据头端复制列表对报文进行复制，并分别进行封装。

封装后的报文，根据外层MAC和IP信息，在IP网络中进行传输，直至到达对端VTEP。

ARP应答报文转发流程

ARP应答报文的转发流程如下：

VTEP_3接收到VM_C发送的ARP应答报文后，识别报文所属的VNI（识别过程与步骤2类似）。同时，VTEP_3学习MAC_C、VNI和报文入接口（Port_3）的对应关系，并记录在本地MAC表中。之后，VTEP_3对报文进行封装。

封装后的报文，根据外层MAC和IP信息，在IP网络中进行传输，直至到达对端VTEP。

• 不同子网互通

BDIF接口的功能与VLANIF接口类似，是基于BD创建的三层逻辑接口，用以实现不同子网VM之间或VXLAN网络与非VXLAN网络之间的通信。

不同子网VM互通报文转发流程

数据报文从VM_A发送到VM_B的流程如下：

报文进入VTEP_3，VTEP_3对报文进行解封装，得到VM_A发送的原始报文。然后，VTEP_3会对报文做如下处理：

发现下一跳为10.1.20.10，出接口为BDIF 20。此时VTEP_3查询ARP表项，并将原始报文的源MAC修改为BDIF 20接口的MAC（MAC_20），将目的MAC修改为VM_B的MAC（MAC_B）。

报文到达VTEP_2后，VTEP_2对报文进行解封装，得到内层的数据报文，并将其发送给VM_B。

说明：VXLAN网络与非VXLAN网络之间的互通，也需要借助于三层网关。

VXLAN应用部署方式

我们以下图所示的典型的“Spine-Leaf”数据中心组网为例，给大家介绍一下CE系列交换机VXLAN的应用场景和部署方案。

在上图所示的数据中心里，企业用户拥有多个部门（部门1和部门2），每个部门中拥有多个VM（VM1和VM3，VM2和VM4）。同部门的VM属于同一个网段，不同部门的VM属于不同的网段。用户希望同一部门VM之间、不同部门VM之间，VM与Internet之间均可相互访问。

VXLAN网络的子网互通

1. 相同子网互通

• 部署方案
  
  

如图所示，Leaf1和Leaf2作为VXLAN网络的VTEP，两个Leaf之间搭建VXLAN隧道，并在每个Leaf上部署VXLAN二层网关，即可实现同一部门VM之间的相互通信。此时Spine只作为VXLAN报文的转发节点，不感知VXLAN隧道的存在，可以是任意的三层网络设备。

2. 不同子网互通（集中式网关）

• 部署方案
  
  

如图4-2所示，Leaf1、Leaf2和Spine作为VXLAN网络的VTEP，Leaf1和Spine之间、Leaf2和Spine之间分别搭建VXLAN隧道，并在Spine上部署VXLAN三层网关，即可实现不同部门VM之间的相互通信。

3. 不同子网互通（分布式网关）

3.1 出现背景

细心的读者可能已经发现，在不同子网互通（集中式网关）中，同一Leaf（Leaf1）下挂的不同网段VM（VM1和VM2）之间的通信，都需要在Spine上进行绕行，这样就导致Leaf与Spine之间的链路上，存在冗余的报文，额外占用了大量的带宽。同时，Spine作为VXLAN三层网关时，所有通过三层转发的终端租户的表项都需要在该设备上生成。但是，Spine的表项规格有限，当终端租户的数量越来越多时，容易成为网络瓶颈。

分布式网关的出现，很好的解决了这两个问题。

3.2 部署方案

• 同Leaf节点下不同部门VM之间的通信
  
  

如图4-3所示，Leaf1作为VXLAN网络的VTEP，在Leaf1上部署VXLAN三层网关，即可实现同Leaf下不同部门VM之间的相互通信。此时，VM1和VM2互访时，流量只需要在Leaf1节点进行转发，不再需要经过Spine节点，从而节约了大量的带宽资源。

• 跨Leaf节点不同部门VM之间的通信
  
  

如图4-3所示，Leaf1和Leaf2作为VXLAN网络的VTEP，在Leaf1和Leaf2上部署VXLAN三层网关。两个VXLAN三层网关之间通过BGP动态建立VXLAN隧道，并通过BGP的remote-nexthop属性发布本网关下挂的主机路由信息给其他BGP邻居，从而实现跨Leaf节点不同部门VM之间的相互通信。

说明：Leaf作为VXLAN三层网关时，只学习其下挂终端租户的表项，而不必像集中式三层网关一样，需要学习网络中所有终端租户的表项，从而解决了集中式三层网关带来表项瓶颈问题。

• VXLAN网络的可靠性

随着网络的快速普及和应用的日益深入，基础网络的可靠性日益成为用户关注的焦点，如何能够保证网络传输不中断对于终端用户而言非常重要。

在VXLAN网络的子网互通中，VM与Leaf之间，Leaf与Spine之间都是通过单归方式接入的。这种组网接入方式，显然已经不能满足用户对VXLAN网络可靠性的需求。

这时，可以按照如下图所示方式，提升VXLAN网络的可靠性。

• 接入层的可靠性

通常采用堆叠（CSS）方式提升接入层的可靠性。这是因为，接入层的设备数量繁多，堆叠方式可以将多台交换机设备组合在一起，虚拟化成一台交换设备，所有配置均在这一台虚拟交换机上进行，从而简化了接入层设备的运维复杂度。此外，堆叠系统内成员交换机之间在进行冗余备份的同时，能够利用跨设备的Eth-Trunk实现设备间链路的负载分担。

参考：

• http://support.huawei.com/huaweiconnect/enterprise/forum.php?mod=viewthread&tid=334207&extra=page%3D&page=1

• http://blog.csdn.net/sinat_31828101/article/details/50504656

来源：Luckylau's Blog
原文：http://t.cn/EadJNxn
题图：来自谷歌图片搜索 
版权：本文版权归原作者所有
投稿：欢迎投稿，投稿邮箱: [e-mail]

你可能还喜欢

假如服务器上没有 Docker 环境，你还能愉快的拉取容器镜像吗？

更多有趣的互联网新鲜事，关注「奇妙的互联网」视频号全了解！