借助多宿主实现 EVPN 内部多播优化

IGMP 侦听 EVPN 多宿主问题

首先’，Figure 1让在 ESI 上，叶、叶、叶和叶片为多主机。

让’我们假设树叶是 DF，叶级和叶片-5 是非 DFs。叶和叶-6 是其他单一宿主 Pe。

Figure 1: 具有多宿主情景的 IGMP 侦听

要在此处描述问题，’请考虑叶片-1 是入口并且执行了非独占（IMET）转发，因此叶级-1 会将流量泛滥到核心，而不是根据类型 6 SMET 路由选择性转发。

假设 Host-5 是一个对组 G 的流量感兴趣的 IGMP 主机，因此发送 IGMP （*，G）报告。在聚合接口（AE）束上通过多宿主到三个枝叶的 CE 可能会将报告发送至多宿主枝叶中的任何一个。这是由于 CE 基于由来源 IP、目标 IP、源 MAC 等组成的元组在数据包上执行的散列。好的，’让我们假设 CE 将 IGMP （*，G）报告发送至叶-3。

收到（*，G）报告后，叶级将为（*，G）创建一个 IGMP 状态，这样，如果 G 的流量来自核心或其他接入接口，则会将流量转发给 CE，进而发送到 Host 5。但是，叶级在我们的示例中每 EVPN 个多宿主过程都是非 DF。由于报告未到达叶或叶片，因此不会为（*、G）创建 IGMP 状态。

当叶片1开始使用包容转发发送组 G 的信息流时，所有多宿主枝叶都将接收来自核心的流量。按（古典-DF-NDF）规则，只有 DF 将流量转发至接入接口。在此，叶-4 是 DF。

但是，由于叶片-4 没有 IGMP 状态为（*，G），叶-4 不会转发信息流。叶级，虽然它具有 IGMP 状态（*、G），但不会转发流量，因为它是多宿主链路上的非 DF。叶-5，不具有 IGMP 状态，也是 NDF。

因此，我们在这种情况下，两个多宿主条件都不会将流量转发至 Host-5，这显然是不必要的。

如果对于某些组，由于 CE 上的哈希元组的存在，某些 IGMP 报告到达了叶片，DF、叶-4 将创建（*、G）状态，而从核心、叶-4、DF 到达流量时，将向 CE 和 Rcv-1 转发信息流。这将保持稳定状态。

但是，仍然存在问题。如果叶-4 关闭或叶节点上的多宿主接口停机，则可以选择叶片作为 DF。由于叶片3没有 IGMP （*、G）状态，因此不会转发信息流。报告的刷新可能会发送至叶、非 DF，我们可能会与以前一样，最终处于相同状态。

选择性转发的多宿主问题

与 EVPN 核心的信息流到达所有多宿主对等方的流量时，不会将其转发至接收器，因为具有 IGMP 状态的叶级是非 DF，而叶-4 又是 DF，而叶片不具有 IGMP 状态。让’我们回顾Figure 2一下。

Figure 2: 使用选择性转发的多宿主方案的 IGMP 侦听

这也是选择性转发的问题。如果叶和叶片发出 BGP 类型为6的 SMET 路由，以反映它在访问时发现的状态，则叶-1 仅将多播流量转发至叶和叶片-6。在这种情况下，叶级具有 IGMP 状态，但不会将流量转发给接收方，因为它是非 DF。

由于信息流将被叶片（即 BUM 泛滥的过程）淹没，并且会到达所有出口叶设备，因此这不是一个问题，这不是一种不存在于DF 就是将流量转发给主机。

由于 igmp 侦听和选择性（SMET）转发可缓解‘所有无处’不在的问题，因此如果我们解决这一特定情况，在以下部分中，我们将对 EVPN 路由类型的 igmp 侦听和 EVPN 多宿主进行处理，从而帮助您解决此问题。

BGP 类型7联接-同步路由，以同步多宿主 Pe 中的 IGMP 状态

要解决此处介绍的问题，我们需要在多宿主 Pe 之间同步组 G 的 IGMP 状态。如果 IGMP 状态在多宿主 Pe 之间同步，则 DF 将具有（*，G）状态，因此会将流量转发给接收方。

通过 ESI 接口学习的特定组的 IGMP 状态与其他 MH 对等方进行同步，此类对托管相同的 ESI，BGP 类型7加入同步路由。基于这种交换，多宿主 EVPN Pe 可同步 IGMP 状态并为该组安装转发状态。通过执行此操作，任何相关多宿主 Pe 都将位于为该 ESI 选择 DF 的转发流量的位置。

Figure 3: BGP 类型-7 IGMP 加入同步路由控制平面过程

在Figure 3中，IGMP 报告已到达叶片3。作为事件的一部分-[1]，叶级发出了 BGP 类型7，其中包含 VLAN、group 和 ESI 信息。此类型-7 路由仅根据叶和叶片导入，因为这些枝叶托管了 ESI。其他枝叶不会导入此类型7路由。

当叶和叶片收到此类型7路由时，将生成该特定组的 IGMP 状态，并将输出接口用作多宿主 ESI 接口（事件-[2]）。通过这种方式，组 G 的 IGMP 状态在多宿主 Pe 中同步。

通过为 VLAN 获知的 IGMP 状态， EVPN Intra-VLAN Multicast with Optimization章节中描述的过程将导致多宿主 pe 发起组/VLAN 的类型6路由。（事件-[3]）。

EVPN Type-7 NLRI Route

类型为7的路由由路由 distinguisher、VLAN、多播组和源、ESI 和原始 IP 组成。路由还在扩展社区中携带 ESI 值。这有助于确保只有承载 ESI 的那些 Pe 才会导入此类型7路由。

此外，类型7路由还携带称为 EVI COM 的社区。此社区标识必须同步 IGMP 状态的 EVPN 实例。不会添加在2类和类型-6 路由中添加的典型路由目标，因为我们希望仅在托管特定 ESI 的那些 Pe 上导入类型7路由。

Figure 4: 类型7路由标头

Tracking of Type-7 Routes from Peers

EVPN PE 基于特定 ESI 上的传入 IGMP 报告创建本地 IGMP 状态。可能会出现这样的情况：一个组的 ESI 发送报告后面有多个主机。可能是报表供应在不同的多宿主对等方。在这种情况下，从接入端 ESI 接口接收 IGMP 报告的 Pe 源自类型7。

当一个叶上发生 IGMP 状态超时时，它不应立即删除该状态。相反，应检查是否有任何其他类型为7的远程、为同一 VLAN/Group/ESI/EVI 的路由。如果是，则会撤消原始类型为7，但 IGMP 状态将保留。

Type-7 Withdraw Semantics

当 IGMP 状态超时（主机’没有刷新 ESI 上的状态）时，将会撤消类型7路由。在接收类型7撤消时，叶设备应小心地清除状态。此类型-7 撤消可能是由于 ESI 链路已关闭或发起方节点本身会停止。接收 PE 必须确定它确实是状态超时，然后继续清除状态，否则将发生流量下降。

发起类型为 6 SMET 路由的非 DF 以实现更好的融合

通常，在收到此类型-7 路由时，只有 DF 需要源于类型6，因为它应该从核心提取流量，并将流量转发给接入。但是，如果 DF 节点发生故障或 DF 上的 ESI 链路发生故障，则需要选择新的 DF，然后它必须发起类型 6 SMET 路由。此外，入口必须在其传出 PE 列表中包含新的 DF。由于涉及 BGP 消息交换，因此可能会造成相当大的延迟。

如果非 DF Pe 还会产生类型为6的 SMET 路由，以便将流量从处于稳定状态的入口中拉出，但不能通过非 DF 转发访问，则可以缓解这种情况。之后，当 DF 发生故障时，新的 DF 一经选择，就会将流量从核心到达。因此，所有新的 DF 都需要做才能将流量转发至接入。这将导致融合的巨大收益。

Figure 5: BGP 类型-7 IGMP 联接-同步路由控制平面过程以实现更好的融合

在Figure 5中，所有多宿主– PE 叶级、叶级和叶-5 –均源自该组的 SMET 路由类型6。这将导致叶级-1 包括其列表中的所有多宿主 Pe。因此，非 DF Pe 接收流量但不将其转发到 ESI 接口上，但在将其反向为 DF 时，可以立即恢复转发。

Summary-IGMP 联接-同步和多播转发

借助此方案，ESI 的所有多宿主 Pe 都具有组 G 的 IGMP 状态，并且只需使用 DF PE 将流量转发给接收方，即可使用这种架构。类型-7 路由携带信息，使接收 PE 可以准确地为相关 VLAN、EVI 和 ESI 创建相应的 IGMP 状态。

Figure 6: 基于 IGMP 状态同步的流量转发

ESI 上的所有多宿主 Pe 都具有组 G 的 IGMP 状态。ESI 的 DF-PE 至少会产生类型为6的路由，但为了确保更好的融合，非 DF Pe 也源于类型6和拉流量。当流量到达核心（DF PE）时，由于其 IGMP 状态已与 BGP 类型7加入同步路由同步，因此会将流量转发至接入 ESI 接口。

此外，对对等类类型7s 的跟踪也是强制性的，以便 IGMP 同步状态保持一致。应仔细处理类型7路由的提款，以确定提款的原因，然后继续执行清除/保留 IGMP 状态。

IGMPv2 的问题

在前面的部分中，我们介绍了 IGMP （*、G）报告状态如何在多宿主 Pe 上同步。本节介绍在多宿主情景中处理 IGMP 请假消息的问题，需要特别考虑。

IGMP 离开入门

就像（*，G）这样的 IGMP 报告消息用于为特定组 G 传达侦听方兴趣时，IGMP 请假消息用于通过主机传达对组的监听器兴趣。

当交换机收到 IGMP 离开消息时，需要清除 IGMP （*、G）状态，用于转发，这样流量就不再发送至接收方。在清除状态之前，交换机需要确保没有其他主机对该组感兴趣。

为此，交换机将向组 G 发送最后一个成员查询（LMQ），以征求来自其他受兴趣主机的任何报告。如果交换机在特定时间段（LMQ 间隔）内未收到组 G 的任何报告，则交换机将清除（*、G）的状态。如果任何其他主机在间隔之前发送报告，则状态将保留。

什么是离开延迟？

多播应用程序对有害信息流非常敏感。例如，IPTV 主机可能需要通道-1，方法是发送组 G1 的 IGMP 报告，并且可能会接收信息流。假设接入接口的带宽具有来自一个通道的信息流。当用户切换到通道2时，主机将收回对通道1的兴趣，方法是发送组 G1 并发送组 G2 的 IGMP 报告。

交换机必须处理 Leave 消息 G1，检查是否存在其他侦听器，如果没有其他侦听器，请清除 G1 的状态并停止转发到 G1。不久之后，当交换机收到组 G2 的 IGMP 报告时，它应该为（*，G2）创建状态，并启动 G2 的转发信息流。

如果由于某种原因交换机需要较长时间来清除 G1 的状态，但是为两个组创建 G2 和转发流量，调配的带宽可能不足以携带两个通道，并且可能会在 IPTV 主机上造成失真。此外，主机可能不能处理两个组的信息流。

总而言之，交换机必须及时响应，以足够短时间接收请假消息、执行对 LMQ 的重要努力，并在不存在侦听程序时清除状态。清除状态延迟称为 "离开延迟"，是在 IPTV 和股票信息检索应用程序中考虑的重要因素。

如果在电线‘’上丢失或未处理离开消息，则流量将转发至监听器。如果交换机未定期收到 IGMP 报告（每隔60秒），将在 IGMP 超时间隔后清除状态，例如210秒。

因此，如果离开消息丢失或未处理，流量将在发生 IGMP 超时之前一直流动。由于 IPTV 主机的敏感性，保留延迟比 IGMP 学习速率更仔细考虑。

IGMPv2 消息的微妙特性

IGMP 报告消息将源 IP 作为主机源，将目标 ip 字段作为主机所关注的多播组地址 G。

但是，IGMP 请假消息的目标 IP 字段为224.0.0.2，而要撤消的组则存在于请假消息的有效负载内。从历史上看，IGMPv2 是如此。由于 IGMPv2 主机广泛流行，并且工作良好，因此一直保持这种方式。

Why is This Relevant to Optimized Multicast with Multihoming?

如前所述， CE 将根据来源 Ip、目标 IP、源 MAC 等对传入数据包进行散列处理。由于报告的目标 IP 字段地址不同于请假消息的位置，因此报告将发送至一个多宿主 EVPN PE，但该请假消息会发送至另一个多宿主 EVPN PE。

IGMPv3

在下一节中，我们将描述由于 IGMPv2 保留消息的目标地址为224.0.0.2 而产生的挑战。IGMPv3 受这一挑战的困扰，因为 IGMPv3 report 和 IGMPv3 Leave 消息将在有效负载中携带，而报告的目标地址和请假消息都224.0.0.22。您很快就会了解这种差异为何相关。

How Does This Cause a Problem in a Multihoming Scenario?

在Figure 7中，IGMP 报告可能发送到树叶。稍后当主机5对组 G 的流量感兴趣时，将向（*，G）发送 IGMPv2 离开。对于相同的组，此 IGMP 保留可发送至叶片-5，因为用于保留的目标 IP 地址字段是224.0.0.2，而 IGMP 报告的是组本身。这是因为 CE 包括计算哈希元组时数据包的目标 IP 地址。

Figure 7: IGMPv2 的问题在多宿主场景中保持

让’我们更详细地了解这一点。在Figure 7中，叶片在接入接口上收到 igmp 报告，创建了 igmp （*，G）状态（本地学习），来源于类型7路由。叶和叶片-5 导入了类型7并创建 IGMP （*、G）状态（远程学习）。目前为止，一切都好。

当离开消息到达叶片时，请考虑这种情况。预期的行为是什么？LMQ 必须向 CE 发送以征求报告要求，并且在特定时间间隔之前，如果没有报告到达，则必须从所有多宿主 Pe （特别是 DF）中清除状态，以便为组 G 停止流量转发。

我们有哪些选择？如果我们让现有 IGMP 休假处理规则开始，则听力开时听到的树叶将发送 LMQ。如果不再有兴趣的主机，该如何做？叶级，报告最初供应的情况下，还没有听说离开。因此，叶级3不会清除状态良好的210秒，而类型7将保持公布这么长时间。

叶级将处于波动，其中已在访问时收到留言消息，但它还具有远程了解的状态。不能撤消类型7，因为它最初不是类型7路由的始发者，因此问题更涉及。由于从树叶-3 开始了远程类型7，叶级5保留了相应的状态。叶片和 DF 将保留已转换的 IGMP （*，G）状态，并将转发保留210秒。

总之，即使主机发送了一只离开，但确实到达了多宿主 PE 集，仍留出的延迟仍然是210秒。这显然是不必要的，还是多宿主和优化功能。

当另一台主机在 LMQ 之前发送报告，而此报告位于不同的 PE （例如叶-4）时，这会变得更复杂。现在，叶级和叶节点具有本地了解的状态，而叶片-5 具有远程学习状态和处理过程。在这种情况下，状态必须协调，以便在所有 Pe 上保留 IGMP （*、G）的状态。

因此，必须尽可能将这种长期处理情景视为 IGMP 联接同步。此问题很难解决，仅依靠现有的 IGMP 保留处理过程，因为需要同步离开。此外，虽然 IGMP 联接（*、G）是可转换为 BGP 路由和交换的状态，但请假消息确实是一个事件，而非状态。

对于请假消息，将清除先前学习的状态。因此，对于有离开的树叶，这会显示为事件。传统上 BGP 通知添加/删除/更新状态。这种请假消息应该会导致撤销 BGP 路由和状态，但在状态的非发信方，离开的事实将很难表达州的提款。

此活动还必须在多宿主 Pe 中传达，以便它们与组的访问 ESI 接口上的最新活动同步，以确保 "保持延迟" 在可接受的限制范围内。不同的组合也必须能够在不会造成延迟的情况下工作，最常见的是（i）一个 IGMP 联接，后跟 Leave，或者（ii），接下来跟有离开，接下来是另一条联接等。

此问题的解决方法是引入了另一个称为类型8保留同步路由的 BGP 路由，使多宿主 Pe 相互同步，以了解组的状态（*、G）。

BGP 类型-8 保持同步路由，以协调 IGMP 状态

为了解决上一节中介绍的问题，让’我们来探讨方法。该解决方案的目标如下：

• 从访问接收到连接时，IGMP 加入状态应在所有多宿主 Pe 之间同步。

• 当在多宿主设置上从接入接收时，LMQ 计时器应在所有多宿主对等方上启动，而 LMQ 应通过 DF 在访问时发送。

• 如果在 LMQ 计时器过期之前不会接收任何连接，则应在所有多宿主对等方上删除 IGMP 状态。

• 如果在 LMQ 计时器过期之前收到了替代 IGMP 联接，则 IGMP 状态应保留在所有多宿主对等方上。

在Figure 8中，从叶片上的 Host-5 开始的连接收到联接，并使用类型7联接同步路由在多宿主对等方之间同步状态。现在，让’我们来说，Host 5 发送 igmp 请假，而此 igmp 保留到达叶-5 （事件-[1]）。

Figure 8: BGP 类型-8 个离开同步路由

在收到请假时，叶级产生了一个类型为8的路由（事件-[2]），其 NLRI 字段与类型7（VLAN、ESI、Group、source、原始 IP 等）相同。类型为-8 的源的触发器是一条留下消息，但是没有用于撤销此路由的触发器。因此，叶级-5 ‘启动 "保留发送"’计时器，以便在同步离开的目的后撤消路由。

其他多宿主对等方、叶级和树叶-4 接收类型8。基于这种情况，所有多宿主 Pe 都希望发送发送 LMQ 并启动 LMQ 计时器。由于此 LMQ 是一条多播消息，因此只有 DF 将在 ESI 上发送 LMQ。（事件-[3]）。

此 LMQ 计时器可能会发生两个事件。

• 事件-A：在 LMQ 过期之前，此组的 LAN 上未收到任何连接。

• 事件-B：在 LMQ 过期之前，此组在 LAN 上收到的连接。

Event-A: No Joins Received on LAN in Response to LMQ (Join + Leave)

在Figure 9中发送 LMQ 和启动 LMQ 计时器之后，多宿主对等方等待查看是否为该组刷新了任何 IGMP 报告。如果未收到报告，并且 LMQ 计时器过期（事件-[1]）。

Figure 9: 事件 A：未在 LAN 上收到响应 LMQ 的连接

在Figure 9中，类型为7的发起方提取其类型7路由（事件-[2]）。在类型7远程路由撤销中，多宿主对等方将删除 IGMP 状态，从而停止到访问的转发流量。（事件-[3]）。

根据本地状态，如果该群组没有 VLAN 中的其他感兴趣的接入接口，则多宿主设备会撤消其先前发起的类型为6的路由。（事件-[4]）。

使用类型8路由时，状态现在被清除，而叶级提取其类型8路由（事件-[5]）以避免任何类型为8的过时延迟，从而清除该流的所有状态。

Event-B: Join Received Before LMQ Timer Expires (Join + Leave + Join)

在Figure 10中发送 LMQ 和启动 LMQ 计时器之后，多宿主对等方会等待一段时间来查看是否为该组刷新了任何 IGMP 报告。假设在 LMQ 计时器到期之前，另一台主机会在 LAN 上发送一个 IGMP 报告。此报告可能会出现在早期类型为7、叶片或新发信方（如叶片）上的原始发起方。

Figure 10: 事件 B：LMQ 过期前在 LAN 上收到的连接

If Refresh Report Arrived on LEAF-3, the Earlier Type-7 Originator

叶片，在接收更新的访问报告时停止其 LMQ 计时器。_Not撤消其类型7路由。之后，在其他多宿主对等方上，当 LMQ 计时器过期时，将检查该组是否有远程类型7。由于有适用于该组的远程类型7，多宿主对等方将保留 IGMP 状态并继续转发流量。

If Refresh Report Arrived on LEAF-4, Which Is Not the Earlier Type-7 Originator

在接收到访问的更新报告时，叶级4停止其 LMQ 计时器。它还会产生与其他多宿主对等方同步的类型7路由。’收到远程类型7路由后，其他多宿主对等方将其导入其表中。

当 LMQ 过期时（自其报告未刷新），将从叶-3 上提取出原始类型7。但是，由于至少有一个远程类型7（从叶到4），叶级3保留 IGMP 状态。

在叶片上，当 LMQ 到期时，至少存在一种远程类型7（从叶到4）。因此，叶级-5 也保留 IGMP 状态。

将所有这些整合在一起，实现优化的多播

Figure 11重复我们的原始拓扑，使其恢复为大图。Host-3 和 Host 5 （多宿主主机）对信息流感兴趣。多宿主叶设备同步 IGMP 状态并确保发生正确转发。本章的信息流验证部分详细说明了这种情况。

Figure 11: 优化多播转发

本章总结

本章探讨了在多宿主拓扑中优化多播的细微差别。为此，详细说明在 ESI 链路上接收的 IGMP 报告如何在托管了 ESI 的多宿主对等方之间同步。它还检查了多宿主对等方的类型6路由的来源，以实现融合。

此外，还有一项挑战，即 IGMP 离开消息到达一个与接收 IGMP 报告不同的 PE 的情况，以及如何通过类型8路由解决这一问题。

对于类型-6/7/8，我们在核心和接入方面确保了多播优化。我们还解决了多宿主挑战。在Assisted Replication with SMET我们将探讨这些优化与 AR 的结合如何带来这两个领域的最佳优势。

配置

Figure 12描述了参考拓扑。

Figure 12: 参考拓扑

Configuration

在EVPN Intra-VLAN Multicast with Optimization章节中完成的配置足以满足这一节的要求。

流量验证

将我们在 EVPN 中启动的现有信息流与 Host-1 和 Host 上的接收器等优化章节保持在EVPN Intra-VLAN Multicast with Optimization中;在 Host-3 上，从多宿主到叶和叶2。现在’，让我们为多播组启动接收器，225.1.1.1 在 VLAN-101 上。

在中的 RT 统计Figure 13信息中，您可以看到，Host-1 发送到 10 pps 的流量现在正在由感兴趣的单穴接收器接收：Host-6、有兴趣的多宿主接收器 Host-3 以及 VLAN-101 中的传统设备 Host 7。

Figure 13: RT 统计

Multicast Traffic Outputs - LEAF-1

与以前一样，负载平衡多播流量到达接入接口，ae0 在树叶-1 上。树叶-1 现在可将此信息流转发到其接入接口/自动曝光1。0 请记住，SRC-本地偏向规则允许叶-1 在 ae 1.0 上转发流量，而不考虑 DF/NDF 状态：

多播流量将转发到 VTEPs 面向边缘叶 Pe （101.101.101.101 和102.102.102.102）和叶片5（109.109.109.109）。该信息流还会在 VTEPs 上发送到叶（106.106.106.106）和叶-4 （108.108.108.108），因为他们有兴趣接收方。

没有任何感兴趣的接收方的叶级（107.107.107.107）仍可避免流量：

Multicast Traffic Outputs - LEAF-2

接入端 IGMP 侦听功能可确保到达叶2的多播流量不会转发到单穴接口、xe-0/0/4.0 或不带接收器的 ae 0.0 上。

虽然多主接入接口 ae 1.0 具有接收器，但请记住，DST 本地偏向规则确保多播流量不会在此接口上转发。这可确保不会向多宿主主机（Host-2）执行信息流复制

Multicast Traffic Outputs - LEAF-4, LEAF-5, and BL Devices

这些设备上的流量转发行为没有变化。因此，为了简洁起见，输出被省略。

详细的控制平面验证

Verification of EVPN Join-Sync with Multihomed Receivers

由于 Host 3 为多宿主，IGMP 报告可能会到达叶-1 或叶-2。在我们的示例中，它会达到叶-1。

让’我们通过侦听 igmp 报告，验证叶组成员关系已在 VLAN-101 接口 ae 1.0 上了解：

验证叶片-1 是否已产生 EVPN 类型7加入同步路由，此路由器在多宿主接口的自动曝光1.0 上已获知 IGMP 组成员身份：

验证叶版是否已处理了来自叶级的此 EVPN 类型7联接-同步路由并了解了 ae 1.0 上的远程成员：

Verification of EVPN IGMP Proxy State with Multihomed Receivers

验证225.1.1.1 是否已了解 group 的本地 IGMP 成员身份通过 EVPN 类型7联接同步路由、构建本地 EVPN IGMP 代理状态并生成类型 6 IGMP 代理路由，以通知远程 Pe 其接收多播流量的兴趣群.

请注意，叶级-2 还将基于源自叶的类型6（在EVPN Intra-VLAN Multicast with Optimization和 "优化" 章节）了解远程代理状态，而叶-1 （now）：

同样，由于其本地 IGMP 联接，叶级1也将产生一个类型为 group 225.1.1.1 的6类路由。叶级-1 还将根据源自叶的类型6（在EVPN Intra-VLAN Multicast with Optimization和 "优化章节" 中）了解远程代理状态，以及叶-2 （现在）：

验证所有远程 Pe 是否处理 EVPN 类型6路由并学习对组有兴趣的远程 EVPN 接收器的叶片-1 和叶-2。我们在 EVPN 的EVPN Intra-VLAN Multicast with Optimization中进行了这项工作，并采用了从叶到4的类型6的优化章节。这就是读者的练习。

Verification of Multicast Forwarding State

验证为在叶-1 和树叶-2 中的 group 225.1.1.1 创建的多播转发状态现在是否包含有兴趣的多宿主接口 ae 1.0：

验证在叶-1 （vtep 32771）之外，现在还将叶-2 （vtep 32769）添加到 group EVPN 的225.1.1.1 核心下一跳跃。请注意，此外，BL-1 （vtep 32770）、BL （vtep * 32774）和（vtep）也将在组的32773核心下一跳跃中出现：

验证为 group 225.1.1.1 创建的多播转发状态是否已更新为现在包括上面看到的 EVPN 核心下一跃点：