《Cloud Native Data Center Network》读书笔记-13 终

第十六章 EVPN在数据中心

16.1 为什么EVPN会流行

EVPN是一项成熟的技术，已经在MPLS网络中使用了一段时间。它使用BGP作为控制协议来交换虚拟网络的可达性信息。简而言之，EVPN已经有能力作为基于控制器的VXLAN解决方案的替代方案。

成熟技术(VXLAN和EVPN)的融合很好地结合了对商家交换芯片的支持，允许部署具有网络虚拟化支持的生产质量数据中心。这就是今天数据中心的EVPN相关的原因。

16.2 网络虚拟化控制平面必须解决的问题

Overlay的网络虚拟化控制平面必须解决以下问题：

提供内部地址到外部地址的映射
标识内部地址所属的虚拟网络
标识给定可以有多个可用的封装
除此之外，VXLAN还需要知道哪些VTEPs对哪些虚拟网络工作感兴趣，因此多目标帧，如广播、未知单播和多播(BUM)流量只能传输到感兴趣的端点。

EVPN将会更进一步，并对以下内容提供了支持：

ARP/ND抑制

路由

多宿主节点

L3组播

除此之外，您还需要执行特定于设备的单独配置，例如：

创建一个VTEP
将VXLAN虚拟网络与其虚拟网络的本地版本相关联，通常是VLAN，
指定处理多目标帧的方法：入口复制（也称为头端复制）或多播
处理与使用多播相关联的配置
16.3 VTEP的驻点在哪？

VTEP，是网络虚拟覆盖的边缘，非虚拟网络与虚拟网络相遇的地方；数据包在进入Overlay时被封装，在离开Overlay时被解封的地方。VTEP功能越接近端点，网络的核心就越能不受网络虚拟化状态变化的影响。将主机端点作为vtep允许组成Clos拓扑的路由器与路由器一样运行。

一些使用EVPN的私有云解决方案正在使用FRR从主机启动EVPN。

在Clos拓扑的情况下，除了宿主之外，VTEP的下一个理想位置是Leaf。在Spine或Super Spine上做VTEP没有意义，因为EVPN连接了由路由底层分隔的虚拟L2网络段，而在两层Clos网络中，L2网络终止于Leaf。Leaf VTEPs是数据中心中最常见的EVPN部署模型。

16.4 一种协议负责全部，或者？

如前所述，NVO3由两个部分组成：一个路由的Underlay和Overlay。我们讨论了如何使用OSPF和BGP作为路由协议来构建路由的底层。BGP，特别是eBGP，在数据中心远比OSPF更受欢迎。然而，当涉及到EVPN时，考虑到它在服务提供商世界中作为VPN解决方案的使用，传统的供应商正在寻求一种看起来类似于它在服务提供商世界中部署的解决方案。其中，OSPF(或IS-IS)用于构建路由的Underlay，iBGP用于交换虚拟网络信息。

正如FRR通过无编号的BGP创新了BGP的配置一样，它也是第一个使用单个eBGP会话来构建路由底层和虚拟网络信息交换的配置。换句话说，交换MAC地址就像在BGP中启用另一个AFI/SAFI，比如IPv6一样简单。

16.4.1 iBGP特征

iBGP对等体通常发生在由路由网络分隔的对等体之间。这与eBGP对等体非常不同，后者几乎总是在物理链接两侧的对等体之间。两个独立的解决方案解决iBGP全互联的问题：BGP联盟和路由反射器(RRs)。在这两种方法中，RR是迄今为止最流行的解决方案，也是人们考虑使用NVO3部署iBGP的方式。

RR遵循一个hub-and-spoke模型，其中所有的iBGP宣告者连接到一组中央RR路由器。RR的工作是计算一条路由的最佳路径，并向每个RR客户端做通告。然而，与eBGP不同的是，RR不会修改路由的下一跳网络地址；相反，它保留了RR收到的通告中的任何值。

为了说明这一点，请考虑图16-1，它说明了eBGP和iBGP在下一跳中的传播与学习路线的不同。在eBGP的情况下，下一跳总是被修改为通告路由器。这被称为next-hop-self。如果是iBGP，当向对等站点发布通告时，与路由关联的下一跳不会被修改。在所示的示例中，A可以选择完全绕过B到例如10.1.1.0/24的数据路径。如果您假设B为RR，那么它只卸载计算重复和实现iBGP宣告者之间的全互联。因此，发现计算节点作为RR的功能并不少见。如果有多个RRs，RRs甚至不必相互通信来完成他们作为RR的工作。如图16-2所示，这意味着您可以仅仅使用Clos网络作为一个连接层；

图16-1 eBGP与iBGP相对于下一跳传播的行为

图16-2 RRs作为服务器和纯L3的Underlay

在更典型的部署中，Clos拓扑中的Spine充当RRs。Spine是底层的一部分，对虚拟网络没有任何了解。它们也是所有Leaf连接到的节点。所以这似乎很自然地适合Spine作为RRs的功能。唯一的要求是，所有Spine都可以作为RRs，以确保所有Spine共享相同的性能特性，并且RRs的故障特性与底层和包转发保持相同。

16.4.2 单独的Underlay和Overlay协议

传统的网络供应商在Underlay使用IS-IS或者OSPF，Overlay使用iBGP，Spine通常用作iBGP-RR。这种方式的缺点如下：

如果已经在Underlay使用了EBGP，那想要去替换是很具有破坏性的。
更多的协议意味着更复杂，当出现问题时更难排除。
为了解决第一个问题，一个供应商提倡使用eBGP作为路由Underlay和iBGP为Overlay。大多数路由器运行单个的BGP进程来同时处理eBGP和iBGP会话。因此，这在Leaf和Spine之间增加了额外的BGP会话，几乎没有什么额外的好处。单独的会话意味着两个会话之间的事情仍然可能不同步。

一个供应商提倡使用两个eBGP会话：一个在Underlay的接口IP地址上，另一个在Overlay的Leaf和Spine的环背之间。尽管他们的官方声称这更稳健，但我从内部消息来源听到，因为一个错误的实现，会导致较长的收敛时间。

16.4.3 只使用EBGP

首先在FRR中实现的另一种方法是使用单个eBGP会话来交换Underlay和Overlay路由信息。在我自己看来，在与许多BGP专家交谈后，这个选项是数据中心的Clos拓扑的更简单、更优雅的解决方案。

为了简化同时传输Underlay和Overlay信息的eBGP会话的配置，FRR会自动避免修改虚拟网络路由的下一跳地址，同时继续对Underlay路由修改下一跳地址。

Spine上的BGP过程需要保留它收到的关于Underlay和Overlay的信息。它使用Underlay信息来构建Underlay数据包转发表。它需要保留从Leaf接收的Overlay信息，将其传递给其他Leaf（类似RR）。然而，这些Spine对虚拟网络一无所知，除非另有指示，否则它们会删除关于它们的信息。当FRR识别到相同的会话用于携带Underlay和Overlay路线时，它会自动使Spine保留这些信息。在其他支持单个eBGP会话模型的供应商实现中，可能需要添加其他配置。

16.5 BGP构建以支持虚拟网络路由

BGP支持通告虚拟网络路由。首先出现在服务提供商网络中的MPLS L3 vpn的背景下。第一个问题是AFI/SAFI将使用什么。EVPN使用l2vpn/evpn的AFI/SAFI。这是因为EVPN被认为是一种L2VPN。接下来，BGP必须处理允许跨虚拟网络复制地址的模型。

每个BGP实现都维护两种路由表：全局表和每个虚拟网络。BGP在全局表上运行最佳路径算法，选择一条路径为每个前缀发布到其对等点。因为RD对每个发起者都是唯一的，所以一个路线的所有副本都将被通告给邻居。要将路由安装到虚拟网络的路由表中，BGP首先使用导入RT子句从全局表中选择特定的要导入到该虚拟网络中的候选路由。然后，它再次在导入的候选路由上运行最佳路径算法，但这次是在虚拟网络的路由表的上下文中。如果使用多个RT宣传同一地址，最佳路径算法将选择最好的一个。可以将多个RTs导入到单个虚拟网络路由表中。

16.5.1 RD

如前一节所述，RD是一个8字节的值，它被添加到每个虚拟网络地址中，以保持该地址的全局唯一性。RFC4364的第4.2节定义了RD及其格式及其用途。有三种不同的RD格式。EVPN中使用的RD格式由RFC7432定义，如图16-3所示。

图16-3 用于EVPN的RD格式

如果您想知道虚拟网络实例(VNI)如何有三个字节长，但可以在RD的两个字节空间中编码，这不是问题，因为假定实际上VTEP不会托管超过64,000个VNi。目前，大多数交换机硬件都不支持一个设备上的这么多vni。即使他们可以或确实支持，在单个设备上支持这很多vni也被认为是不可接受的，因为将受到设备故障影响的客户数量。是路由器的IPv4环回地址和VNI的组合，使RD在整个网络中是唯一的。因此，RD的VNI特定部分的值是VNI的设备本地编码，而不一定是VNI的绝对值。

由于路由器的环回IP地址是RD的一部分，因此具有相同虚拟网络的两个节点最终会有不同的RD。这就解决了区分具有相同IP地址的源的问题。

RD在MP_REACH_NLRI和MP_UN-REACH_NLRI属性中被编码为NLRI的一部分。

16.5.2 RT

RT是添加到虚拟网络NLRI中的一个附加路径属性。如前所述，RT对它所属的虚拟网络进行编码。一个宣传虚拟网络及其地址的BGP宣告者使用一种称为导出RT的特定RT。接收和使用通告的BGP宣告者使用此RT来决定将路由添加到哪个本地虚拟网络。这被称为导入RT。在典型的VPN配置中，网络管理员必须同时配置导入和导出rt。

RT的定义和使用在RFC4364的第4.3.1节中都有规定。EVPN与VXLAN的RT编码在RFC8365的5.1.2.1节中描述，如下图16-4所示。

图16-4 EVPN-VXLAN的RT格式

不同字段的定义如下：

ASN

BGP宣告者的通告地址的双字节ASN。

A

指示RT是自动派生还是手动配置的位。

Type

表示EVPN中所用封装的三位字段。对于VXLAN，它为1，而对于VLAN，它为0。

Domain-ID (D-ID)

四个位通常为零。在某些情况下，如果VXLAN编号空间中有重叠，则此字段用于限定VNI所属的管理域。

Service ID

包含虚拟网络标识符的三个字节。对于VXLAN，它是3字节的VNI；对于VLAN，它是12位（3字节字段的下12位）。

16.5.3 FRR对RD和RT的使用

EVPN标准指定，如果需要，可以自动导出RT。并不是所有的实现都支持这个模型，但FRR确实支持了。它如前所述编码RT，假设VXLAN为封装。大多数其他实现都要求您通过路由目标导入自动等配置来说明此目标。

FRR维护一个位图，其中每个位代表一个单独的VNI。RD中特定于VNI的两个字节来自于这个位位置的值。FRR还允许管理员手动配置特定虚拟网络的RT，但由于可能会出现错误，因此不建议这样做。

16.5.4 EVPN路线类型

正如我们前面所讨论过的，非ipv4单播路由是通过MP_REACH_NLRI和MP_UNREACH_NLRI属性发布的。对于大多数AFI/SAFI组合，更新消息中携带的可达性信息的结构和内容与AFI/SAFI之间是相同的。EVPN的情况并非如此。有一些不同的信息需要交换。例如，更新可以访问特定的MAC地址，也可以访问整个虚拟网络。此外，与IPv4和IPv6不同，因为EVPN已经同时消耗了AFI和SAFI，因此没有办法分离关于单播和多播地址的信息。为了适应这些额外的细分，EVPN NLRI通过路由类型编码不同类型的信息。表16-1列出了数据中心中适用的类型。

除了这里列出的路线类型外，EVPN中还出现了更多的路线类型。

16.5.5 BUM处理的通信选择

正如在“VXLAN中的多目标帧处理”中所解释的，在处理BUM流量时，有几个选择：头端复制或路由多播。因此，每个VTEP必须通知其他VTEPs它可以支持什么。RT-3 EVPN消息可以携带一个名为提供者多播服务接口(PMSI)的BGP属性，该属性标识该设备支持的BUM数据包处理的类型。PMSI属性是用一个与通常的EVPN标准完全不同的标准(RFC6514)来定义的。EVPN草案建议的传递复制模型信号的值如下。大多数是协议独立的多播(PIM)的变体，在“多播路由协议”中描述：

3用于PIM-SSM
4用于PIM-SM
5用于Bidir PIM或双向PIM
6用于入向复制
许多实现宣传使用了入口复制，但没有使用多播。这可能与实现除了所列出的选项之外所做的事情有关。

16.6 EVPN和桥接

EVPN如何取代802.1Q的泛洪和学习模型。主要的区别是，EVPN使用BGP将可达性分配到MAC地址和IP路由以及相关的虚拟网络。此外，也不使用STP。要了解桥接如何与EVPN一起工作，请考虑图16-5中所示的拓扑结构。

图16-5 EVPN桥接拓扑举例

记住，底层是路由的；也就是说，Leaf和Spine之间的数据包是双向路由的，从来没有桥接。如前所述，这些Leaf是VTEP。要作为VTEP，他们需要一个IP地址来源和接收数据包。通常，所有VNI都使用单个IP地址。在所有的Leaf上也启用了EVPN。802.1Q桥接仅在Leaf和本地连接的服务器之间的端口上启用，就像在Clos网络中一样。

这些Spine只是Underlay的一部分。我们假设下面依次有一个eBGP会话，但如果Spine作为rr起作用，其行为就没有那么大的不同。

设备本地配置还定义了本地VLAN到全局VNI的映射。在图16-5中，假设红色VLAN（由粗线表示）映射到红色VNI，而蓝色VLAN（由较细的线表示）映射到蓝色VNI。

首先要注意的是，与以前的Clos网络插图不同，这个图中的子网并不局限于单个机架。子网172.16.1.0/24在红色VNI，无论红色VNI在哪里，子网172.16.101.0/24在蓝色VNI。不同的Leaf可以将一个子网与不同的VLANID关联起来，只要所有这些不同的VLANID都映射到相同的全局VNI。在EVPN中交换的所有信息都是关于全局VNI的，而不是它的本地VLAN实例化。因此，子网也与全局VNI相关联，因为它跨多个路由器。

接下来，每个Leaf都有第二个IP地址，即VTEP IP地址，所有VXLAN封装的数据包都将具有来自此子网的源和目标IP地址。网络管理员还必须确保此VTEP IP地址通过BGP发布；否则，其他VTEP将不知道如何到达此地址。

每一Leaf都通过RT-3路由学习其他Leaf感兴趣的虚拟网络。所以Leaf01知道Leaf02和Leaf04对红色VNI感兴趣，Leaf03和Leaf04对蓝色VNI感兴趣。类似地，其他Leaf从BGP更新中学习这些信息。

16.6.1 带有入口复制的EVPN桥接

现在，让我们按照数据包的序列来了解EVPN桥接是如何使用前端复制的。让服务器101向服务器104发送数据包。由于服务器101和服务器104属于同一子网，因此服务器101发送一个ARP请求包，请求服务器104的MAC地址。这是一个以太网广播数据包的形式，目标MAC为FF：FF：FF：FF：FF：FF：FF：FF和MAC的101源MAC地址

在这种情况下，从服务器101发送到Leaf01的数据包与传统的桥接没有什么不同。Leaf01接收此包，并且像传统桥接一样，了解到通过MAC101连接的端口可访问MAC101。Leaf01不认为该数据包是一个广播数据包，因此需要发送到红色VNI的所有收件人。Leaf01使用头端复制将包泛洪到所有感兴趣的Leaf—在这种情况下，Leaf02和Leaf04。大多数商家芯片要求您编程头端复制中每个隧道端点的下一跳点列表。因此，实现可以选择将头端复制的负载分散到整个Spine上。
Leaf01 VXLAN封装包并将一个副本发送到Spine01（删除到Leaf02），将一个副本发送到Spine02（发送到Leaf03）。到Leaf02的数据包具有Leaf02的VTEP的目标IP地址，例如10.0.127.12，以及Leaf01的源IP地址，10.0.127.11。类似地，到Leaf04的数据包具有10.0.127.14的目标IP地址10.0.127.14，源IP地址为10.0.127.11。
当Spine01接收到数据包时，它会对VXLAN报头中的IP进行路由查找，即Leaf02的路由查找。然后，它将数据包路由出端口到Leaf02。Spine02对于要到达Leaf04的包做同样的操作。
当这些VXLAN封装的数据包到达Leaf02和Leaf04时，它们都知道它们是出口VTEP，因为数据包中的目标IP地址是它们的IP地址，而UDP目标端口说这是一个VXLAN数据包。它们将数据包去掉头部，并使用本地802.1Q桥接来确定将数据包发送到的本地附加端口。Leaf02和Leaf04都没有试图以VXLAN封装的形式将此数据包发送到任何其他节点。因此，它们避免在斩首后将VXLAN封装的数据包泛洪回VXLAN Overlay层中，相当于IP中的自转发检查。在EVPN中，该检查由其路由协议名称称为分割检查。现在，服务器104和服务器102都接收该数据包。
Leaf02和Leaf04都没有从这个被泛洪淹没的数据包中了解到任何关于MAC101的信息。无论如何，leaf01的MAC转发表中有一个新的本地条目。因此，leaf01通过BGP更新消息来宣传红色虚拟网络中对MAC101的可达性。特别的，它使用一个EVPNRT-2消息，它携带{VNI，MAC}通告。该消息说，红色虚拟网络中的MAC101可以通过VTEP Leaf01可访问。Leaf01将这些信息传递给其BGP同行，Spine01和Spine02。Spine01和Spine02反过来将这个信息传递给它们的同行，即Leaf02、Leaf03和Leaf04。Leaf收到多个更新的副本，每个Spine有一个。这些Leaf现在用关于MAC101的信息来填充它们的MAC转发表。他们注意到MAC101是远程的，可以通过Leaf01的VTEP IP地址10.0.127.11.leaf03，没有红色VNI，只需存储这个消息（或可以丢弃它）。因为Spine不知道虚拟网络，他们不知道Leaf03没有红色的VNI，所以对这个消息不感兴趣。

如果服务器104对服务器101的ARP响应在Leaf04上的MAC表更新之前到达，那么返回包可以像广播包一样被泛洪，因为Leaf04还不知道MAC101。如果ARP回复在Leaf04根据BGP更新更新其MAP表后到达，则回复只能直接发送到Leaf01。如果包仅单播到Leaf01，则从服务器104接收的帧的包头的散希随机决定Leaf04是将包发送到spine01还是spine02。

Leaf04还了解到红色VNI中的MAC104连接到指向服务器104的本地端口。Leaf04发送具有EVPNRT-2类型的BGP更新消息，表明红色VNI中的MAC104可以通过Leaf04访问。此消息将同时传递到Spine01和Spine02。他们将此BGP更新传递到所有其他Leaf。在BGP处理结束时，Leaf01、Leaf02和Leaf04知道红色VNI中的MAC101可以通过VTEPLeaf01到达，而红色VNI中的MAC104可以通过Leaf04到达。

因此，以下是EVPN桥接与传统的802.1Q桥接之间的主要区别：

将远程MAC地址插入MAC表是通过EVPN中的BGP UPDATEs完成的，而不是从802.1Q中的数据包本身中学习。
从服务器104到服务器101的应答路径可以采取与EVPN中从服务器101到服务器104的包不同的路径，而在802.1Q桥接中是相同的。
EVPN桥和802.1Q桥的共同部分包括：

本地连接的MAC通过标准的802.1Q学习被填充在MAC表中。
泛洪的数据包被传送到虚拟网络中的所有端站。
每个{虚拟网络、MAC地址}元组都与单个出口端口相关联。
16.6.2 基于组播路由的EVPN桥接

让我们考虑与上一节相同的例子，但使用组播路由。数据包序列假设使用PIM-SM，而RP位于Spine上。尽管我们在“数据中心的PIM-SM”中提到，使用Spine作为RP是有问题的，但我们在这种情况下使用它来减少需要描述的数据包序列，并简化解释。我们假设使用OSPF来构造路由的单播底层。我们使用anycastRP允许任何Spine提供一个单个RP的外观(如“多个RP和MSDP”中解释)。

假设我们将多播组分配给VNI是一个特定于设备的配置。它不是通过BGP进行沟通的。为了简单起见，让我们为红色VNI中的BUM流量分配红色组播组(GREM)，为蓝色VNI中的BUM流量分配蓝色组播组(Gblue)。这个任务是在每个Leaf上完成的。

图16-6显示了数据包序列。与进入复制相比，具有组播的数据包序列的复杂性应该会非常清楚以组播路由作为底层的选项的复杂程度。

图16-6 具有路由多播包底层的EVPN桥接数据包序列

当红色多播组被分配给红色VNI时，每个Leaf都会向RP发送一个对(、Gred)多播路径感兴趣的PIM Join消息。不同的Leaf可以选择不同的Spine来发送这个消息。
服务器101一样向服务器104发送ARP请求。leaf01得到这个数据包。
Leaf01向Spine发送一个PIM注册器包，它决定是最接近它的RP。让我们假设它选择了Spine01。
Spine01接收PIM注册消息。咨询它的状态，Spine真实化，它有感兴趣的听众，Leaf02和Leaf04。它将为（Leaf01、Gred）发送一个PIM连接到Leaf01。它为(Leaf01，Gred)创建一个多播条目，RPF接口是指向Leaf01的接口，嗅觉是指向Leaf02和Leaf04的接口。实现通常会让RP通过(、Gred)树上的PIM寄存器重新发送数据包。
Leaf01从Spine接收PIM连接，并使用指向Spine01的嗅觉设置多播项（Leaf01，Gred）。
ARP请求需要继续出现，因为这些请求实际上还没有到达任何Leaf02或Leaf04。在leaf01接收到的下一个ARP包上，leaf01将该包封装在VXLAN头中，目标IP地址设置为Gred，源IP地址设置为其VTEPIP地址10.0.127.11.在多播路由表中对此数据包的查找将该数据包发送到spine01。
Spine01在接收到此数据包时，向Leaf01发送PIM寄存器停止消息，否则Leaf01将继续向红色VNI中接收到的每个新ARP数据包发送PIM寄存器数据包。
Spine01还根据其多播路由表将数据包转发到Leaf02和Leaf04。
Leaf04接收数据包，并注意到它在其多播路由表中没有(Leaf01，Gred)状态。它确实具有指向到服务器104的接口的(*、Gred)状态。该数据包被传送到服务器104。同样的情况也发生在Leaf02上，并且数据包被传送到服务器102。
Leaf04为(Leaf01，Gred)创建多播路由表条目，并查找单播路径到达Leaf01。它有两条路径，通过Spine01和Spine02。让我们假设它通过Spine01选择路径。它现在，将（Leaf01、Gred）的RPF接口设置为朝向Spine01的接口，而嗅觉是指向服务器104的接口。此时，分组使用路由的多播底层从Leaf01流到Leaf04。
现在Leaf02，就像Leaf04一样，也决定为(Leaf01，Gred)创建一个多播条目。它还向上查找Leaf01的单播路径，发现它可以使用Spine01或Spine02。让我们假设它选择了Spine02。它将多播条目的RPF接口设置到指向spine02的接口，并将该条目的列表设置为服务器102。它将为（Leaf01，Gred）发送一个PIM连接到Spine02。
Spine02接收PIM连接（Leaf01，Gred）。它可以看到，到Leaf01的路径是通过到Leaf01的接口。它为(Leaf01，Gred)创建多播路由条目，RPF接口设置为对Leaf01的接口，嗅觉是指向Leaf02的接口。它将为（Leaf01、灰色）发送一个PIM连接到Leaf01。
Leaf01从Spine02接收PIM连接，并将(Leaf01、Gred)条目的嗅觉设置为同时指向Spine01和Spine02。
从Leaf01的红色VNI的BUM包现在将同时到Spine01和Spine02。Spine01的数据包将被删除到Leaf02，因为Leaf02已经将该组的RPF接口设置为指向Spine02的接口。
现在，leaf02向spine01发送一条(Leaf01、Gred、RPTPrune)消息，因为它不再需要来自RPT树的数据包，并且它完成了SPT切换。
Spine01接收来自Leaf02的(Leaf01、Gred、RPTPrune)消息，并从其（Leaf01、Gred)多播路线条目列表中删除Leaf02。
一些实现选择在组播组分配给VNI时立即启动配置来加快树设置。让我们来检查这种实现中的数据包序列。为了简化数据包流，我们只从Leaf01的角度来检查设置。

当红色多播组被分配给红色VNI时，每个Leaf都会向RP发送一个对(、Gred)多播路径感兴趣的PIM Join消息。不同的Leaf可以选择不同的Spine来发送这个消息。
Leaf01知道，如果它从附加的服务器接收任何BUM包，它可能是一个源。因此，Leaf01向RP发送(Leaf01，Gred)组的PIM空寄存器。其他的Leaf也是如此。
RP使用此空注册器向Leaf01构建一个（Leaf01，Gred）树。它将Leaf01的PIM连接(Leaf01，Gred)发送到Leaf01，并将RPF接口设置为指向Leaf01的接口。嗅觉是Leaf02和Leaf04。
lLeaf01接收PIM连接，并创建一个（Leaf01，灰色）多播路由条目，其嗅觉为Spine01。
服务器101发送一个ARP请求。
因为已经有一个(Leaf01，Gred)多播路由条目，VXLAN封装的包流到Spine01。然而，Leaf01的PIM进程也会得到一个数据包的副本，然后将其作为PIM注册消息发送给spine01。
在接收到针对(Leaf01，Gred)的VXLAN封装的数据包后，spine01向Leaf01发送一个PIM寄存器停止消息。
VXLAN封装的包也流向Leaf02和Leaf04，它们在嗅觉中(Leaf01，Gred)。
数据包序列的其余部分看起来与以前的组播包序列相似。如果Leaf02将（，Gred）的PIM连接发送到Spine02，而Leaf04将其发送到Spine01，则会发生什么？这是可能的，因为这两个Spine的功能都是任何铸造的RP，不同的Leaf可以选择不同的Spine来发送它们的PIM连接。Leaf01将PIM注册器（或PIM空注册器）消息仅发送到其中一个Spine，比如Spine01，并且只有Spine01将创建（Leaf01，Gred）树。Leaf01的数据包将如何到达Leaf02？

本部分由MSDP处理。一旦Spine01创建了（Leaf01，Gred）多播路线，MSDP就会将该信息与Spine02同步。Spine02使用此信息发送(Leaf01、Gred)组的PIM连接，因为它连接到Leaf02，并且该Leaf表示对(*、Gred)多播流感兴趣。Spine02通过RPF接口将连接请求发送到01，Leaf01是指向01的链接。它将多播路由标记为指向Leaf02接口的列表。从Spine02接收PIM连接后，Leaf01将Spine02的接口添加到（Leaf01，Gred）多播路线。现在数据包将流到Leaf02和Leaf04。

16.6.3 处理MAC移动

提供L2连接会带来协议必须处理的大量附加并发。处理MAC移动就是这样一个问题。

在图16-5中，让服务器101托管一个MAC地址为MACVM101的虚拟机。在它第一次会话后，使用EVPN桥接的模型，所有的Leaf都知道MACVM101与VTEP Leaf01相关联。现在考虑一下，如果虚拟机现在迁移到服务器102，会发生什么。当它在移动后第一次会话时，Leaf02得知MACVM101局部附着在自己上。它还有一个条目，说明MACVM101与通过BGP填充的Leaf01关联。因为本地附加的条目优先于通过BGP学习的条目，所以Leaf02将其MAC表切换，使MACVM101指出端口到服务器102。然后，它发送一个BGPEVPNRT-2更新消息，指示其他人应该将他们对MACVM101的关联切换到Leaf02。Leaf02这样做没有问题。但是leaf01认为MAC地址是本地连接的。因为本地附加的条目优先于通过BGP学习的条目，所以leaf01不会将其与MACVM101的关联转换为leaf02，而是继续认为它是本地附加的。这是错误的。

为了解决这个问题，EVPN定义了一个名为MAC移动性的新的BGP扩展社区，其格式如图16-7所示。

图16-7 MAC移动性扩展社区的格式

关于使用这个扩展社区的第一个基本规则是，如果MAC地址已经与远程VTEP关联，则它必须用于发布本地学习的MAC地址的通告。序列号表示此MAC广告裙移动的次数。例如，当这个属性第一次被附加到一个MAC地址的RT-2附加程序中时，序列号就会被提升到1。第二个基本规则是，如果您收到具有此扩展社区的虚拟网络中MAC地址的通告，则必须接受此通告作为具有此扩展社区的条目或新通告中的序列号，则高于当前数据库中的最佳路径。如果收到具有相同序列号但来自不同vtep的多个更新，则VTEP IP地址较低的更新将获胜。

静态MAC地址是不允许移动的MAC地址。当为这些MAC地址做通告时，该路由必须被标记为MAC移动性扩展社区和社区集中的“S”位。当任何VTEP接收到带有此类标签的MAC通告时，它必须忽略关联的虚拟网络中该MAC地址中在本地检测到的任何更改。

有时，指示已移动的MAC地址的消息将不正确。原因之一是L2网络的安全性松懈，这使得欺骗MAC地址并使其从安全主机移动到受损主机成为可能。虚假移动的另一个原因是，连接的802.1Q网络中的问题会导致STP不断更新其树。当树被更新时，一个MAC地址可能会出现在树中的不同位置，使其看起来像已移动的MAC地址。

要处理所有这些情况，如果VTEP检测到MAC地址更新的频率太频繁，它可以停止发送或处理对该MAC地址的进一步更新。它还必须通知管理员正在发生这种情况。没有明确的方法来摆脱这种情况。

FRR的EVPN实现支持由标准定义的MAC移动性。如果它检测到一个MAC地址在指定的时间段内移动了太多次，则在重新启动MAC移动计时器之前，它将在一段时间内忽略与该MAC地址相关联的MAC地址更新。所有都可以指定移动的次数和时间段。

16.7 对双宿主主机的支持

如前所述，在企业网络中，计算节点经常连接到多个交换机上。这样做主要是为了确保单个链路故障或单个交换机故障不会使计算节点与网络断开连接。这还允许该中心升级一个交换机，而无需在升级窗口期间删除与该交换机关联的所有计算节点。作为一种企业网络解决方案，EVPN还经常使用双连接的主机进行部署。

图16-8显示了通常的拓扑结构，但是与主机服务器101、服务器201和服务器102双连接到Leaf01和Leaf02。尽管常见的情况是所有主机都是双连接的，但也遇到了一些节点是双连接的，有些节点是单连接的部署。当部署承载多个工作负载时，例如现代Hadoop集群、更传统的应用程序，甚至是OpenStack时，就会发生这种情况。

图16-8 具有双宿主主机的拓扑结构

下面的小节讨论了双连接主机的问题以及如何解决这些问题。需要解决的问题如下：

双宿主连接的主机如何连接到交换机？
其他vtep如何看到双连接节点？换句话说，图16-8中的vtep Leaf03和Leaf04如何查看服务器101、服务器201和服务器102？
当某些主机失去与其中一个交换机的连接时会发生什么？例如，如果服务器102失去了它到Leaf01的链接，会发生什么？
数据包传递如何用于多目标帧，例如BUM数据包？双连接的服务器是否得到副本，因为Leaf01和Leaf02都提供一个副本？如果某些应用程序没有在TCP等可靠的流协议上运行，那么副本可能会混淆它们。
16.7.1 主机交换机互连模型

在最常见的部署中，主机将这两个链接视为在一个绑定中（又名链接聚合）。主要优点是两个链路同时可用，并且作为一个绑定，链路需要一个IP地址而不是两个地址。同时使用两个链接也称为双活模式。

使用标准的LACP创建了一个绑定。LACP确保主机被正确地连接到正确的设备上。例如，如果服务器102不小心将电缆连接到Leaf03而不是Leaf02，则这将被LACP捕获，因为服务器102将发现它没有与两个链路上的同一实体通信。只有当链路连接到所有链路上的同一对设备时，LACP才支持连接。LACP还会遇到单向链路故障等问题。

一些主机供应商为启用LACP收取额外费用，因此很多交换机实现支持静态绑定的概念，其中管理员将链接的两端配置为在绑定中，而不使用LACP。

一些客户仅使用双交换机互连来处理故障。在这种情况下，其中一个链接处于待机模式。它只有在活动链接死亡时才会被激活。这被称为NIC组合或主备模式。这种模式做出了一些类似于键合模式的假设。它假设当备用链接激活时，它与最近死亡的链接具有相同的IP地址。它还假设此链路上的默认网关与另一个网关相同。

16.7.2 针对双连接主机的VXLAN模型

大多数包交换芯片实现都假设MAC地址在单个VTEP后面。在图16-8中，每个双连接的主机都有两个不同的交换机。那么，远程VTEPs（图中的Leaf03和Leaf04）如何处理这种情况呢？

有两种可能性：每个VTEP都有自己的IP地址，或者两个vtep共享一个共同的IP地址。共享的VTEP IP地址是最常见的部署。其主要原因是，MAC转发表的通用实现只支持单个退出端口。在传统的桥接中，MAC地址从来没有理由有多个退出端口。STP显式地消除了多个路径以消除循环。绑定后被表示为单个逻辑端口，以避免此问题；逻辑端口选择之后的附加逻辑允许实现选择单个传出的物理端口来传输数据包。

Linux内核和大多数交换芯片都支持单一的通用IP地址模型。因此，即使您有一个支持替代模型的供应商，使用公共IP地址模型也可以确保与其他供应商的互操作性。

根据这个模型，在图16-8的示例拓扑结构中，leaf01和leaf02都将为所有双连接的主机传输数据包，它们都具有共同的源VTEP IP地址。大多数实现验证了交换机具有通过多机箱链路聚合(MLAG)等协议配置的相同的公共IP地址，简要所述。我不知道有任何实现使用来自EVPN消息的信息来验证公共IP地址。网络管理员还必须确保此公共IP地址通过BGP发布；否则，其他VTEP将不知道如何到达此VTEP IP地址。

16.7.3 交换机监视选项

在我们继续研究其他问题以及如何处理它们之前，我们必须检查双连接主机连接到的一对交换机所采用的模型。基本上有两个答案：MLAG和EVPN。

MLAG

当链接在多个设备的一端拆分时，标准LACP不支持创建绑定。换句话说，该标准不支持将双连接的主机连接到两个不同的交换机（Leaf01和Leaf02）的模型。因此，每个网络供应商都有自己的专有解决方案来。此解决方案的通用名称是MLAG，但每个供应商的解决方案都有一个品牌名称，而且具体的实现和部署细节因实现而不同。

EVPN 对多目标的支持

EVPN本机支持双连接的设备。它称它们为多目的节点。该解决方案的主要细节见RFC7432的第8节和RFC8365的第8节。EVPN主要使用RT-1和RT-4消息类型来处理多目的节点。RT-1告诉网络，哪些交换机连接到哪个公共设备或以太网段。数据中心中的以太网段被定义为VTEP连接到的桥接网络或绑定链路。当连接到一个绑定时，RT-1通告携带远程节点的LACP标识符（即，在我们的例子中的主机）作为以太网段ID(ESI)。当其他vtep接收到此RT-1通告的BGP更新时，它们可以确定哪些对等点连接到同一主机上。

RT-4选择其中一个对等点作为多目标帧的指定转发器。RT-4通告将以太网段的映射传送到服务的路由器。从接收到的以太网段的所有通告中，每个VTEP选择VTEPIP地址最低的段作为虚拟网络的指定转发器。在这种情况下，跨两个对等点不需要一个通用的VTEP IP地址。

让我们使用我们的示例拓扑结构来分解这个问题。首先，该标准允许leaf01是一组节点服务器101和服务器201，leaf02是另一组节点服务器102的指定转发器。在图16-8中，每台主机只携带一个VLAN。但是，如果主机支持多个VLAN，该标准进一步允许leaf01作为一组vlan的节点的服务器101的指定转发器，leaf02作为另一组VLAN的该节点的指定转发器。

16.7.4 处理链接故障

如果其中一个主机—例如图16-8中的服务器102失去了到leaf01的链接，会怎么办？其答案也是特定于实现的。即使该解决方案涉及到MLAG，两种不同的实现也可能会做不同的事情。

在MLAG的情况下，使用对等链接通过另一个交换机到达主机是最常见的实现。在我们的示例中，Leaf01和Leaf02都通过一个公共的VTEPIP将可达性宣传到服务器102。位于Leaf01和Leaf02之间的公共VTEP IP。当Leaf01失去其与服务器102的连接时，它撤回其对服务器102的播发。然而，由于Leaf02的通告仍然有效，Leaf03和Leaf04看到，通过公共VTEP IP仍然可以访问MAC102。因此，到服务器102的包仍然可以在Leaf01结束，即使它们之间的链路已经关闭，Leaf01不能直接发送包。在这种情况下，Leaf01将包斩首并使用对等链路将未封装的包发送到Leaf02，然后将包发送到服务器102。

是否可以例如通过读取服务器102的MAC地址并指示其单附加到Leaf02来避免使用对等链路？毕竟，Leaf01和Leaf02都具有唯一属于它们的唯一IP地址。可惜的是，大多数数据包交换芯片只支持一个IP地址作为VXLAN VNI的源，即使一个VNI可以同时有双连接和单连接的主机。因此，实现不能指示服务器102使用Leaf02的唯一的VTEP IP，而服务器101使用通用的VTEP IP。因此，即使双连接主机丢失了到VTEP对等主机的链接，其地址也会使用公共VTEP IP地址宣布；对等链接用于将数据包传递到该主机。

如果没有对等链接，大多数实现将重新封装并将数据包发送到另一个交换机。在我们的示例中，Leaf01斩VXLAN数据包，使用Leaf02的目标IP添加一个新的VXLAN报头，并发送数据包。

在EVPN多宿主实现中，失去与主机连接的交换机也将撤回对主机LACP识别的ESI的可达性。这是对RT-1和RT-4路线都要做的。另一个交换机最终会收到这些撤回。在接收到RT-4退出时，剩余的交换机指定自己为服务器102的指定转发器。接收RT-1退出告诉交换机主机单独连接到它。当交换机失去与主机的连接时，它无法尝试将数据包转发到对等机。在我们的示例中，当Leaf02接收到由Leaf01发起的退出时，它知道如果它失去了到服务器102的链接，它就不能将数据包转发给叶01。但是，不使用路由而重新封装VXLAN数据包违反了分割范围检查。因此，该模型需要来自底层开关硅的额外支持。

16.7.5 避免重复的多目标框架

当使用通用的VTEPIP模型和进入复制时，只有一对交换机得到一个数据包。这是因为其他vtep代表具有单个公共VTEPIP地址的对，并且随机选择一个来获得任意强制转换的数据包。但是，在没有共享的公共VTEPIP地址的模型中，两个交换机都将获得多个目标帧的副本(例如，BUM数据包)。

为了确保这对节点中只有一个向终端站发送数据包，这两个节点使用RT-4消息只选择其中一个在虚拟网络中传递多目标帧。但是，控制协议更新需要时间，在选择指定转发器的过程中或在过渡期间，主机既不能接收多目标帧，也不能接收重复帧。这一点也无能为力。

16.8 ARP/ND抑制

ARP请求和无偿的ARP(GARP)数据包是BUM数据包，因为这些数据包被发送到广播地址。在示例拓扑中，如果服务器101对服务器104的MAC地址有ARP并获得了它，则似乎没有必要使服务器201对服务器104的MAC地址的ARP请求与服务器101的请求相同。Leaf01可以缓存服务器104的ARP信息并直接响应。这可以有效地减少网络中的BUM流量。

NDP相当于IPv6地址的ARP。因此，ND将受益于相同的Leaf01的缓存和响应。缓存远程主机的ARP/ND信息并响应对此信息的ARP/ND请求的功能是ARP/ND抑制。

ARP/ND抑制使用RT-2消息来传递与虚拟网络中的MAC地址关联的IP地址。它由实现来决定是要发送单独的MAC和MAC/IP通告，还是同时使用一条消息。当启用ARP/ND抑制时，FRR使用单个消息更新模型。

就像MAC转发表标记的是通过控制协议学习条目时一样，ARP缓存(或Linux内核中的IP邻居表)中的条目被标记为是通过控制协议学习的。内核不会尝试为此类条目运行ARP刷新。内核也不会老化已通过控制协议标记为学习的条目。当删除通告时，协议负责删除这些条目。FRR还可以在正常关闭或从崩溃中恢复时删除它们。

此功能必须通过配置来启用。某些实现只有当VTEP也是该虚拟网络的网关路由器时才允许此配置。思科就是这种实现的一个例子。Linux（以及积云）允许您配置它，而不独立于VTEP是否是该网络的网关路由器。

ARP/ND在Linux内核中提供了抑制支持，这要归功于积云工程师所做的工作。

16.9 EVPN和路由

我们已经研究了在“说明VXLAN桥接和路由”中路由覆盖数据包时的数据包流。本部分与桥接部分一样，重点介绍特定于EVPN的部分。冒着令人恶心的风险，当我们谈论EVPN路由时，我们谈论的是路由包下面的数据包——VTEP接收的原始数据包。

16.9.1 集中与分布式路由

我们在“说明VXLAN桥接和路由”中讨论了路由覆盖数据包的两种可能选项：集中式和分布式路由。什么时候部署一个比部署另一个更有意义？分布式路由应是首选的方法，除非：

你有很多不支持RIOT的路由器，升级盒子的成本令人望而却步。添加两个或更多支持RIOT的新路由器和使用分布式路由可能是一个更方便的解决方案。
只有在离开数据中心时才需要路由，例如，南北交通，因此使用出口离开路由器使集中路由变得容易。这还保留了在出口Leaf处部署防火墙等服务的推荐模型。
如果您确实选择部署集中式路由，您可以从一些可能的部署中进行选择。在第一种方法中，这两个路由器对所有vni都是活动的。在第二个选项中，每个VNI的一个子集是活动的，并配置为其他VNI的待机。

在第一种方法中，当所有vni都活动时，必须防止任何泛洪数据包导致重复路由数据包的风险。为了更好地理解这一点，请考虑服务器101何时将数据包发送到其第一跳路由器。如果leaf01不知道路由器的MAC地址，它将把数据包复制到所有对红色VNI感兴趣的VTEPs（因为服务器101在红色网络中）。如果两个或多个退出的Leaf充当路由器，它们都会收到这个被泛洪的数据包的副本，它们都将路由数据包，导致重复的数据包。如前所述，这可能会在某些网络流量中造成麻烦。

使用像VTEP这样的VTEP IP地址可以确保只有一个双接口获得数据包。或者，诸如虚拟路由器冗余协议(VRRP)这样的协议可以确保其中只有一个为网络路由数据包。第三种确保其中只有一个路由数据包的方法是使用“EVPN支持多归属”中描述的用来桥接的指定转发器模型。

我的建议是使用VTEP anycast IP模型，因为它很简单（没有额外的协议和最小的配置）。

使用分布式路由需要考虑的重点是重新考虑防火墙和负载平衡器等服务的部署方式。在集中式路由模型中，服务位于边界Leaf上。如果这些服务只需要进出数据中心的流量，那么在边界上部署服务仍然可以工作。但是，如果数据中心本身内的流量需要这些服务，那么部署这些服务的最佳方式是在每个主机本身上。解决服务问题的另一种方法是通过使用vrf，如“服务”中所述。

16.9.2 对称与非对称路由

“VXLAN和路由：H1到H6”涵盖了EVPN中不同的路由模型：不对称和对称。选择非对称路由模型的主要原因是您是否存在互操作性问题。数据中心空间中的所有主要供应商都支持对称模型。如果要部署集中式路由，则非对称路由是很自然的选择。如果你宣传非EVPN路由，如默认路由或其他非mac相关的路由，那么对称路由是一个明显的选择。我建议选择路由的对称模型，除非您有不能使用它的具体原因。

16.9.3 路由通告

EVPN RT-2通告包含与{MAC，VNI}元组关联的IP地址。此信息用于填充路由表。但在某些情况下，我们需要一个总结的路线或一个路线的广告，已经学习为一个IP路线。考虑路由表需要使用指向外部世界的默认路由填充的位置。通常，出口的Leaf会宣传这条路线。引入了一种新的路由类型RT-5来宣传IP路由。IP路由不会自动发布，它们必须进行配置。IP路由总是用L3 VNI做通告。在填充路由表之前，每个设备都将L3 VNI映射到本地VRF。

我们还在“说明VXLAN桥接和路由”中讨论了对称和不对称路由。不对称路由与RT-2通告一起工作得很好。对称路由需要额外的支持。

对称路由还需要三个附加信息：在进出VTEP之间使用的VNI、下一跳IP地址(即出口VTEP的IP地址)和出口VTEP的路由器MAC地址。这些需要在一些BGP更新消息中传达。出口VTEP的IP地址总是携带在BGP广告的附录属性中。RT-2消息中载有规定，允许它携带其他两条信息。

RT-2支持携带两个VNIs（或原始EVPN标准中的多协议标签交换[MPLS]标签）。对于非对称路由，两个VNI字段中只有一个用于宣布L2VNI。使用对称路由，使用两个VNI字段，一个用于L2VNI，另一个用于传输或L3VNI。

该路由还需要携带出口VTEP的MAC地址，因为该地址被用作内部数据包上的目标MAC地址。这个MAC地址在广告中作为一个新的BGP扩展社区携带。这个新的扩展社区被称为路由器MAC扩展社区。

16.9.4 VRFs的使用

在EVPN中，假定路由发生在VRF的上下文中。假设Underlay路由表位于默认值或全局路由表中，而假设Overlay路由表位于特定于VRF的路由表中。在不使用vrf的情况下，可以有不对称路由(在“说明VXLAN桥接和路由”中讨论)的工作。但是，如果端点必须与外部世界通信，vrf是必要的，因为涉及到RT-5通告。RT-5通告总是发生在VRF的背景下：通告中的L3VNI信号。因此，为了保持统一的路由模型，我强烈建议始终使用具有EVPN路由的vrf。

16.10 在大型网络中部署EVPN

正如我们所了解到的，除了RT-5，EVPN网络中的路由主要是/32条路由。这在典型的双层Clos网络中，可扩展到大约50,000到80,000个端点中是可以的。（这个数字更多的是企业中单个故障域的舒适区，而不是硬件或软件限制；它不是特定于供应商的。）然而，随着网络变得更大，我们进入三层Clos网络，总结的缺乏开始影响部署。这种无法总结不仅影响转发表的大小，还影响需要复制到入口复制的节点数和系统中的vni总数。所有这些都会对整个系统的稳健性产生了负面影响。如果系统故障可能会破坏整个网络或使其适应性低于您需要的水平，则您必须重新考虑该设计。由于这些原因，我不认为一个有超过128片Leaf的两层关闭可以坚固耐用。对于更大的网络，我强烈推荐一个三层的Clos设计。

仅提供L3连接的三层Clos网络不能直接适应EVPN网络。这是因为这个问题的答案：你要总结在哪里？我们不能在每个POD内的Spine层进行总结（参见“Cols网络中的路线总结”）。在纯L3Clos中，每个机架已经总结了所有本地连接的子网，因为一个子网只能连接到单个Leaf（或一对Leaf），因此网络可以比EVPN发布端点地址（/32或/128路径）更有效地扩展。将超级Spine作为总结的要点失败了Clos网络的主要设计，即通过将负载扩展到边缘来扩展网络，而不是将其吸收到网络的中心。超级Spine的设计和功能的规模和复杂性变得相当大。此外，在这个设计中，为POD进出的交通提供防火墙等服务变得困难

为了保持任务在网络中的有效分布，我建议添加POD退出Leaf，使用它们作为总结点，并作为连接防火墙等池级服务的位置。每个POD现在都是相当独立的，如图16-10所示。

图16-10 EVPN采用三层网络进行部署

首先让我说，如果这是一个四层Clos网络，它不是。我刚刚把图中退出Leaf的位置从其他Leaf旁边切换到顶部，大部分是为了适应屏幕上。

在这个网络中，出口Leaf主要总结特定于POD的前缀路线，将其宣传到超级Spine，并宣传到POD的默认路径。出口Leaf接收来自超级Spine的其他POD的前缀路径。

此模型如何处理VNI跨越多个POD的情况？POD中的出口Leaf不能总结这些vni。此外，BUM处理必须处理POD发送数据包。这使得跨POD拉伸的组的多播处理更加复杂，因为这些组必须为限制在POD内的组找到一个比RP更最优的RP。虽然解决方案总是可能的，但我的建议是尽可能避免拉伸vni，因为它们带来的额外的压力。

第十七章 部署网络虚拟化（略）

第十八章 验证网络配置（略）