数据中心：网络虚拟化

一、概述

网络虚拟化是指在单一物理网络基础设施上创建和管理多个独立的、隔离的虚拟网络的技术。

每一个虚拟网络都认为自己独占：接口、链接、转发表、数据包缓存以及链路队列。

每一个虚拟网络都认为除了自己外，没有其他网络存在。

网络虚拟化用于云计算中，类似于服务器虚拟化。

数据中心的网络虚拟化方案有：VLAN、VRF（Virtual Routing and Forwarding）、VxLAN。

其中，VLAN和VRF属于内嵌虚拟网络，而VxLAN属于Overlay虚拟网络。

注：内嵌虚拟网络是指在物理网络基础设施上直接实现虚拟网络的技术，这些虚拟网络依赖于物理网络设备的原生支持。Overlay虚拟网络是在现有物理网络（Underlay）之上构建的虚拟网络，它不依赖于物理网络设备的直接支持，而是通过封装和隧道技术在物理网络上传输虚拟网络流量。

在Overlay网络中，交换机并不能感知到包转发面内的虚拟网络的存在。

但在控制平面，控制协议仍然掌握着所有虚拟网络的状态信息。

网络虚拟化的控制协议有两种模型：

（1）集中式控制模型

采用SDN集中控制，使用OVSDB协议进行隧道的创建、使用OpenFlow协议进行数据转发的控制。

具体来说，通过一个或多个SDN控制器来实现网络策略的统一管理和自动化配置。

• OVSDB协议：用于配置和管理Open vSwitch，进行端口配置、流表设置等操作。

• OpenFlow协议：直接控制网络设备的数据转发行为，实现网络流量的动态路由和负载均衡。

公有云提供商，如AWS、Azure和Google Cloud，普遍采用集中式控制模型来构建和管理其大规模的虚拟网络环境，以提供高度可定制的网络服务。

（2）基于协议的控制模型

使用在网络设备上运行的控制协议来分发映射关系。也称为无控制器VxLAN解决方案。

EVPN是其中一个实例。FRR是支持EVPN的开源路由解决方案。

二、VxLAN协议基础

VTEP在什么位置？在Clos拓扑中，有Spine交换机、Leaf交换机和服务器。

VTEP可以位于服务器上和Leaf交换机上，而不会放在Spine交换机上，因为二层网络终结在Leaf节点。

如果VTEP位于服务器上，那么Spine-Leaf交换机可以专注于传统的三层路由转发，而不必处理二层虚拟网络。

公有云厂商通常使用这种三层路由模型，但每个厂商的封装方式可能各不相同。

三、VxLAN协议控制平面

首先需要澄清概念：VTEP和VXLAN隧道：

• VTEP (VXLAN Tunnel End Point)：VTEP是一个网络设备，也就是交换机上的网络接口，VTEP的创建大致需要：创建Bridge、查询Bridge id、创建与Bridge关联的Port、查询Port id、创建与Port关联Interface。配置好VTEP，也就是已经配置了VTEP IP地址、VNI关联等相关参数。

• VXLAN隧道：VXLAN隧道是在两个VTEP之间建立的逻辑连接，用于传输封装后的VXLAN报文。

再来看VxLAN控制平面的职责，主要有：

（1）VXLAN隧道的建立与维护：

• 发现网络中的VTEP（VXLAN Tunnel End Points，VXLAN隧道的端点设备）。

• 建立和维护VXLAN隧道。

（2）MAC地址学习与传播：

• 管理MAC地址表，记录主机MAC地址与所属VTEP的对应关系。

• 当MAC地址发生变化时，需要更新MAC地址表，并将这些变化通知给网络中的其他VTEP，以便它们也能更新各自的MAC地址表。

VxLAN控制平面的实现形式有：传统方式（静态配置）、SDN和EVPN。需要注意的是无论是哪种方式，VTEP都已先建好。

四、传统静态配置方式

起初，VxLAN实现方案没有控制平面，是通过数据平面的流量泛洪进行VTEP发现和主机信息。

在配置VTEP时，管理员必须手动输入对端VTEP的IP地址、VXLAN Network Identifier (VNI)，以及其他必要信息。

（1）VxLAN隧道的创建

VxLAN隧道的建立完全依赖于网络管理员的手动配置。

（2）MAC地址学习

MAC地址学习依赖于广播或组播机制。

以Unknown Unicast（未知单播）为例来说明。

未知单播也就是：在二层网络中，当交换机接收到一个目的地MAC地址不在其MAC地址表中的数据帧时，交换机无法确定数据帧应该发送到哪个端口，因此它会执行未知单播泛洪（Unknown Unicast Flooding），也就是将数据帧发送到除接收端口之外的所有其他端口，以尝试找到正确的目的地。

在VTEP的工作场景中，如下图所示，MAC地址为55：55：0A的VM要ping通MAC地址为55：55：0C的VM。

VTEP（10.1.1.1）查询其L2表（字段为MAC、VNI、Remote VTEP），没有查询到记录。

则：

（1）封装原始以太帧成VXLAN包。其中包的外层目的IP地址为组播地址。

（2）通过组播将VXLAN包发送给VTEP（10.1.1.2、10.1.1.3）。

（3）VTEP(10.1.1.3）接收到VXLAN包时，学习到（55:55:0A、VNI、VTEP）信息。

（4）MAC地址为55：55：0C的VM返回响应包后，传输到VTEP（10.1.1.1），同样也可以学习到（55:55:0C、VNI、VTEP）信息。

总的来说，这种方式存在如下问题：

因采用手动配置而适用于小型网络中，不适用于大型或动态变化的网络环境中。

因采用广播或组播的方式学习MAC地址，可能产生广播风暴，进而导致网络性能的下降。

五、SDN方式

采用SDN集中控制，使用OVSDB协议进行隧道的创建（含VTEP的创建）、使用OpenFlow协议进行数据转发的控制。

具体来说，通过一个或多个SDN控制器来实现网络策略的统一管理和自动化配置。

• OVSDB协议：用于配置和管理Open vSwitch，进行端口配置、流表设置等操作。

• OpenFlow协议：直接控制网络设备的数据转发行为，实现网络流量的动态路由和负载均衡。

公有云提供商，如AWS、Azure和Google Cloud，普遍采用集中式控制模型来构建和管理其大规模的虚拟网络环境，以提供高度可定制的网络服务。

私有云解决方案OpenStack也使用该方式，下面以此为例来说明。

Open vSwitch (OVS)被部署在计算节点上，用于连接虚拟机实例。

OVS 支持多种网络虚拟化技术，VxLAN是其中之一。OVS 实现了VTEP，用于封装和解封装 VXLAN 数据包。

借助OVSDB 和 OpenFlow 协议，SDN 控制器能够动态地管理 VTEP 的配置和 VXLAN 隧道的流量，实现对 OpenStack 网络的集中式控制。例如，当一个虚拟机启动时，SDN 控制器可以自动配置相应的 VTEP 和流表规则，确保虚拟机可以正确地接入网络，并与其他虚拟机或外部网络进行通信。

六、EVPN方式

1. 概述

EVPN是一项成熟的技术，可以应用在MPLS、PBB和NVO中。

NVO的实现技术之一是VxLAN。

EVPN已经可以作为基于控制器的VXLAN解决方案的替换方案。

EVPN使用BGP作为控制协议来交换虚拟网络的可达信息。

其基本思想是在BGP协议的基础上定义了一种新的NLRI（Network Layer Reachability Information，网络层可达信息），也就是EVPN NLRI。通过EVPN NLRI定义的几种新BGP EVPN路由类型，来实现VxLAN隧道创建和MAC地址动态学习。

下面来看下Type2和Type3的定义：

Type2 MAC/IP路由

报文格式如下：

各字段的含义为：

Type 3 Inclusive Multicast路由

报文格式如下：

各字段的含义为：

需要关注的是，Type-3 Inclusive Multicast路由的通告不仅是BUM流量分发机制的核心，而且会触发一系列后续操作，包括VXLAN隧道的创建和转发树的构建。详情如下：

在传统的二层网络中，BUM流量通常通过泛洪（Flooding）的方式转发，也就是所有的端口或VTEP都会接收到这些流量，这不仅浪费带宽，还可能导致不必要的流量复制和延迟。

为此，引入EVPN Type-3 Inclusive Multicast路由，以解决多播和广播流量的分发问题。

在大型EVPN VxLAN网络中，包含大量的VTEP，这些VTEP可能是网状的，也可能存在环。

如果直接转发，则可能导致VTEP之间存在重复的转发。

所以，

首先通过基于BGP的扩展团体属性中的DF选举属性，进行DF选举（每个VNI选出一个），来确定DF，该DF负责向所有其他VTEP复制BUM流量。

再次，以该DF为起点，构建转发树。这个转发树确保BUM流量能够沿最优路径从DF传输到其他VTEP，而不必在全网范围内泛洪。

2. 实现过程

下面以同子网主机互通的情况下为例，说明VTEP配置、VXLAN隧道建立和MAC地址动态学习。

（1）VTEP配置

首先需要手工配置（或使用自动化配置工具）VTEP，以交换机Leaf1 VTEP配置为例：

[Leaf1]                               #--在Leaf1这台设备上进行配置
 bridge-domain 10                      #--用于隔离不同二层网络的逻辑实体 10
vxlan vni 20                          #--为桥接域10关联VXLAN Network Identifier（VNI）20，这意味着所有属于这个桥接域的流量都将被打上VNI 10的标签，以便在VXLAN隧道中传输。
evpn                                  #--启用EVPN实例。用于在数据中心环境中构建和管理VXLAN网络。
route-distinguisher 2:1              #--EVPN实例的RD，用于在多实例的环境中唯一标识一个VRF
vpn-target 20:1 export-extcommunity   #--用于标识一组站点，用于控制路由信息的发布范围。
vpn-target 20:1 import-extcommunity   #--IRT用于控制接收路由信息，只有带有IRT 0:10扩展团体属性的路由信息才会被接受并加入本地路由表。
#                                     #--当前配置段的结束
interface Nve1                        #--Nve接口是VTEP用于建立VXLAN隧道的逻辑接口
source 1.1.1.1                        #--//Leaf1 的VTEP IP 地址
vni 10 head-end peer-list protocol bgp #--为Nve1接口配置VNI 10，并指定使用BGP协议与对端VTEP建立VXLAN隧道
#

上面的命令创建了二层广播域，并在二层广播域下配置关联的二层VNI；进而在二层广播域下创建EVPN实例，并配置本端EVPN实例的RD、出方向VPN-Target（ERT）、入方向VPN-Target（IRT）。最后，配置interface和本端VTEP IP地址。

（2）VxLAN隧道的创建

VTEP配置完成后，Leaf1和Leaf2会生成BGP EVPN路由并发送给对端，这个路由中携带本端EVPN实例的出方向VPN-Target和BGP EVPN协议新定义的Type3路由（Inclusive Multicast路由）。

其中，VTEP IP地址存放在前缀的Originating Router's IP Address字段中，二层VNI存放在PMSI属性的MPLS Label字段中。

Leaf1和Leaf2接收到对端路由后，检查对端出方向VPN-Target和本端入方向VPN-Target是否相等。

如相等，则接收该路由，并根据对端VTEP IP地址和二层VNI，创建VXLAN隧道；同时，本端会创建一个基于VNI的头端复制表并将对端VTEP IP地址加入其中，用于后续BUM报文转发。

如不相等，则丢弃。

（3）MAC地址学习

Host3到Leaf1(VTEP)的本地学习：

Host3首次与Leaf1通信时，发送ARP报文，Leaf1学习到Host3的MAC地址、BDID（二层广播域标识）和报文入接口（即二层子接口对应的物理接口Port1）的对应关系，并在本地MAC表中生成Host3的MAC表项，其出接口为Port1。

VTEP间的MAC地址学习：

通过MP-BGP传输Route Type 2的MAC/IP路由。Leaf1生成BGP EVPN路由并发送给Leaf2，这个路由携带本端EVPN实例的出方向VPN-Target、路由下一跳属性以及BGP EVPN协议新定义的Type2路由（MAC/IP路由）。其中，路由下一跳属性携带的是本端VTEP IP地址；Host3的MAC地址存放在MAC Address Length和MAC Address字段中，二层VNI存放在MPLS Label1字段中。

Leaf2的MAC地址学习：

Leaf2收到Leaf1发来的BGP EVPN路由后，检查该路由的出方向VPN-Target与本端的入方向VPN-Target是否相等。

如相等，则接收该路由，获得Host3的MAC地址、BDID和Leaf1上VTEP IP地址（下一跳属性）的对应关系，并在本地的MAC表中生成Host3的MAC表项。

如不相等，则丢弃该路由。

所有的VTEP学习到本地的MAC地址之后，通过MP-BGP发送给BGP RR。BGP RR再将收到的MAC转发信息，发送给所有其他的VTEP。经过BGP RR的反射之后，各个VTEP已经有了所有其他VTEP的MAC转发信息，如下图所示：

看一看图中各个VTEP的L2 Table，第一列是MAC地址，第二列是对应的Remote VTEP（远端MAC）或者当前VTEP连接的端口（本地MAC），第三列是VXLAN ID。

七、附

1.桥接和路由

（1）二层桥接模型

二层桥接模型是指在OSI模型的第二层，也就是数据链路层。网络设备（通常是交换机）使用MAC地址来决定如何转发数据帧。当一个数据帧到达交换机时，交换机会检查帧头中的目的MAC地址，并查找其MAC地址表，以确定该帧应该从哪个端口转发出去。

桥接模型的一些关键特点包括：

• 广播域：在二层桥接网络中，所有设备都在同一个广播域内，这意味着广播和未知单播帧会传播到该域内的所有端口。

• MAC地址学习：交换机会学习和维护一个MAC地址表，记录每个设备的MAC地址和其连接的端口。

• 缺乏网络隔离：由于所有设备都在同一个广播域，这可能导致安全和性能问题，特别是在多租户环境中。

（2）三层路由模型

三层路由模型在OSI模型的第三层，即网络层，进行数据包的转发。路由器使用IP地址和子网掩码来确定数据包的转发路径。当数据包到达路由器时，路由器会检查IP报头中的目的IP地址，并使用路由表来决定最佳的下一跳。

三层路由模型的特点包括：

• 路由决策：基于IP地址和路由表进行决策，可以实现不同网络之间的数据包转发。

• 网络隔离：每个子网都是一个独立的广播域，这有助于提高安全性并减少广播风暴。

• 访问控制：通过使用ACL（Access Control List）和防火墙规则，可以实现更精细的访问控制和网络隔离。

2.MP-BGP

BGP最初被设计用于在自治系统（AS）之间交换IPv4路由信息。然而，随着时间的推移，网络变得越来越复杂，需要支持更多类型的网络层可达性信息，如IPv6、MPLS标签交换路径（LSPs）、VLANs等。为了满足这些需求，BGP被扩展以支持多种地址族，这就是所谓的“Multiprotocol BGP”或“MP-BGP”。

在MP-BGP中，使用AFI（Address Family Identifier）和SAFI（Subsequent Address Family Identifier）来标识不同的地址族和子地址族。常见的AFI和SAFI取值及其含义的列表如下：

3. iBGP和路由反射器RR

数据中心网络中，使用OSPF或IS-IS构建Underlay路由网络，使用iBGP（内部边界网关协议）交换虚拟网络信息。

iBGP的设计初衷是为了在同一个自治系统（AS）内的路由器之间交换路由信息。在传统的iBGP设计中，为了防止路由环路，所有的iBGP对等体需要形成一个全连接的网格（full mesh），这意味着每一个iBGP路由器都需要与AS内的其他每一个iBGP路由器建立直接的对等连接。然而，随着网络规模的增长，这种全连接的网格结构很快就变得不可扩展且管理复杂度急剧上升。

在Spine-Leaf架构下，当Leaf节点之间直接建立iBGP对等互联时，随着Leaf节点数量的增加，全连接的网格结构会导致以下问题：

（1）连接数量激增：在n个节点的全连接网格中，每个节点需要与其他n-1个节点建立连接，总连接数为n*(n-1)/2。这意味着网络规模越大，所需的连接数呈指数级增长，这不仅消耗了大量的网络资源（如接口、CPU、内存），还增加了配置和管理的复杂性。

（2）单点故障风险：在全连接的网格中，任何一个节点的故障都可能影响到与其直接相连的所有其他节点，这导致网络的健壮性和可用性降低。

为了解决这些问题，现代网络设计引入了路由反射器（Route Reflector，RR）和BGP联盟（BGP Confederation）的概念。路由反射器可以充当“中间人”，减少iBGP对等体之间的直接连接需求，而BGP联盟允许将一个大的AS划分成若干子AS，从而简化iBGP的配置和管理。

通过使用路由反射器，只有少数选定的路由器（即路由反射器）需要与其他所有iBGP路由器建立连接，而非每个路由器都需要与其他所有路由器直接连接。路由反射器负责收集路由信息并将其反射给其他非客户端iBGP路由器，从而大大减少了所需的iBGP连接数量，提高了网络的可扩展性和稳定性。同样，BGP联盟通过将一个大的AS逻辑上分成几个较小的AS，也降低了iBGP的复杂性。

借用知乎专栏的资料，可以简单地来理解：

BGP协议要求每个交换机都直接与其他所有交换机形成对等体关系，也就是建立全连接（full mesh）。

但这会带来复杂的配置和管理。

为此，

引入BGP RR（BGP Router Reflector，BGP路由反射器）。

BGP RR的职责是从BGP Speaker接收路由更新信息，然后将这些信息反射（即广播）给所有其他BGP Speaker。

实际应用中，部署的架构为：

另外，关注以下信息：

FRR采用创新的方式通过无编号BGP进行BGP配置，使用单一eBGP来构建Underlay路由网络和交换虚拟网络信息。

iBGP部署使用RR。在Clos拓扑中，Spine节点充当路由反射器RR。

参考资料

https://zhuanlan.zhihu.com/p/28611292
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-overlay-08
https://mp.weixin.qq.com/s/UtLWc4dmQmkAorVruD0xbA
https://www.ruijie.com.cn/jszl/82104/
https://support.huawei.com/enterprise/zh/doc/EDOC1100277368/a7119a61