Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

EVPN la multidifusión intra-VLAN sin optimización

 

En este capítulo se explica cómo funciona la multidifusión no optimizada en una estructura del centro de datos EVPN. En primer lugar, describe la multidifusión en una topología con dispositivos de EVPN de una sola vivienda para que podamos hacerlo a la inversa de los procedimientos y la terminología. Posteriormente, el capítulo examina los procedimientos para el reenvío de multidifusión en una topología con dispositivos EVPN de host múltiple (como el reenvío basado en DF/NDF y el reenvío basado en la diferenciación local).

Al final de este capítulo, debe tener un conocimiento equitativo de lo siguiente:

  • Multidifusión dentro de una subred en una estructura de EVPN de CC

  • Procedimientos de multidifusión en L2 conmutados en topologías de multitarjeta EVPN

  • Reglas generales de reenvío de multidifusión para multidifusión L2 en EVPN

Topología física para una estructura EVPN

Figure 1ilustra una topología típica de IP-CLOSe. Normalmente, existen dos dispositivos de hojas de borde (BL) y varios dispositivos de hoja (en el orden de centenares). Asimismo, hay dos (o cuatro) dispositivos de lomo eficiente (LS) que participan en el EVPN de subyacente para conectividad física entre dispositivos en el tejido EVPN.

Normalmente, en el tejido, los hosts y orígenes de multidifusión residen detrás de los dispositivos de hoja.

Figure 1: Topología típica de "IP-CLOSe Physical"
Topología típica de "IP-CLOSe Physical"

Topología lógica

Para ilustrar los procedimientos de la multidifusión no optimizada de este Figure 2 capítulo, se muestra una topología lógica en la que se configura una red EVPN únicamente en los dispositivos BL y hoja. Normalmente, la capa de la espina eficiente solo lo ayuda con subyacente y no se configura con EVPN.

En un principio, describiremos los hosts de una sola base. Los dispositivos de hoja de la hoja 6 a la hoja-200 tienen vínculos de acceso y tienen hosts detrás de ellos. Para explicar los principios y los procedimientos, utilizaremos hoja-1 a hoja-5. Los mismos procedimientos se aplicarían también al resto de los dispositivos de hoja.

Figure 2: Topología de Singlehomed lógica
Topología de Singlehomed lógica

Multidifusión dentro de una subred sin optimización

En esta sección, vamos’a explorar los procedimientos para el reenvío de multidifusión dentro de la estructura de CC en una sola VLAN (multidifusión con conmutación L2). En esta topología, solo hay una VLAN, VLAN-101. Normalmente, se deben tener en cuenta cuatro conjuntos de comportamientos con respecto al reenvío de multidifusión. (Más adelante en este capítulo se incluye la configuración de los dispositivos EVPN.)

  • No existen fuentes ni oyentes

  • Los orígenes no existen, pero existen agentes de escucha

  • Existen orígenes pero no existen agentes de escucha

  • Existen fuentes y oyentes

No Sources and Listeners Exist

Esto es sencillo porque se trata de una estructura sin escuchas de multidifusión u orígenes todavía iniciados.

Sources Do Not Exist but Listeners Exist

En este caso, los oyentes (hosts representados por host-3 y host Figure 35 de la misma) están interesados en el tráfico de un grupo determinado G1, di 235.1.1.1. Dado que no se ha iniciado aún el tráfico de multidifusión para ese grupo,’los oyentes no reciben ningún tráfico.

Sources Exist but No Listeners Exist

Considere un caso en el que el origen de multidifusión (representado por el Figure 3origen de host 1) ha empezado a enviar el tráfico del grupo G1, diga 235.1.1.1, pero no hay escuchas todavía para ese grupo. En este caso, el reenvío de multidifusión dentro de la subred, la hoja 1 que recibe el tráfico de multidifusión reenviará el tráfico a todas las interfaces de acceso de capa 2 de dicha VLAN (conmutador L2). IE., hacia host-2. (SH-FWD). Además, LEAF-1 no reenviará el tráfico de regreso a host-1, basado en el horizonte dividido.(Access-Split-HRZN).

Figure 3: Inundación del tráfico de multidifusión de capa 2
Inundación del tráfico de multidifusión de capa 2

En Figure 3, Leaf-1 reenviará el tráfico hacia el núcleo de EVPN a todos los EVPN PE mediante la replicación de entrada. El PEs al que se envía el tráfico está determinado por la participación’ remota de PES en la VLAN, vlan-101. (núcleo-IMET-FWD)

La participación de una hoja en una VLAN se determina en virtud de EVPN tipo-3S recibido de ellos. Puede ver todas las hojas excepto el host de hoja 5, VLAN-101. Por lo tanto, LEAF-5 no enviaría un tipo 3 para VLAN-101. El tráfico de multidifusión será replicado a BLs y a todas las hojas excepto LEAF-5. (CORE-IMET-SKIP)

Todos los dispositivos de la hoja y BL que recibieron el tráfico del núcleo EVPN enviarán este tráfico a todas sus interfaces de acceso, independientemente de la presencia de agentes de escucha Figure 3como se muestra en la. La hoja 2 reenviará hacia host-3 y host 4. La hoja 3 avanzará hacia el host 5, y así sucesivamente. Incluso cuando no hay oyentes en la VLAN, puede ver que el tráfico de multidifusión se ‘inunda en todo’el mundo.

Esto puede no ser conveniente, ya que un volumen tan alto de tráfico innecesariamente inundando en todo el mundo puede afectar al uso del ancho de banda en el núcleo y las interfaces de acceso de distintos dispositivos EVPN en la estructura. La inundación es una de las características de EVPN multicast sin optimización. Los capítulos posteriores describen cómo los procedimientos de optimización ayudan a abordar este problema de inundación.

Sources Exist and Listeners Exist

Considere el caso en el que el origen envía tráfico para el grupo G1, diga 235.1.1.1, y hay escuchas en el tejido tal y Figure 4como se muestra en la. Por lo tanto, host-3 y host 5 están interesados en el tráfico del grupo G1 tal y como se muestra. El interés del oyente lo transmiten los hosts mediante el envío de un informe IGMP. El interés del oyente se representa Figure 4 mediante un círculo verde en el host.

Estos hosts IGMP expresan interés en el tráfico del grupo G1 de cualquier origen mediante el envío de un informe IGMP (*, G1). Tal y como se describe en la última sección, en virtud de la inundación del tráfico de multidifusión en todo el mundo, llega a las escuchas interesadas en la estructura y la consumen.

Figure 4: Flujo de tráfico de multidifusión L2 con escuchas
Flujo de tráfico de multidifusión L2 con escuchas

Multidifusión dentro de subred en EVPN topologías multitarjeta

Una de las ventajas de la implementación EVPN es la característica de multihost con el identificador de segmento Ethernet (ESI). Una ESI ayuda a agrupar un conjunto de enlaces en diferentes dispositivos de EVPN, de manera que los dispositivos que hospedan una ESI determinada se consideren a sí mismos de host múltiple en esa ESI. Esto se logra gracias a los dispositivos que intercambian BGP EVPN tipo 1 y a las rutas Type-4 y deducen el multihomedness de la ESI.

Generalmente, el conjunto de enlaces agrupados como ESI se termina en el CE, en una interfaz agregada de posposición Ethernet (AE). En términos generales, el paradigma de EVPN ESI garantizará la redundancia y las funciones de balanceo de carga de los PEs de host múltiple hacia el CE. El conjunto de interfaces de AE de la CE garantizará la redundancia y las funciones de equilibrio de carga para los PEs de host múltiple.

En general, para el caso de los agentes de escucha de host múltiple, el objetivo es garantizar que los oyentes no reciban copias duplicadas del mismo tráfico. En el caso de las fuentes multitarjeta, el objetivo es garantizar que el tráfico no se vuelva a crear un bucle hacia el origen. Considere la topología lógica de multihost de EVPN Figure 5en.

Figure 5: Topología multitarjeta lógica
Topología multitarjeta lógica

EVPN multitarjeta de host con ESI es una característica L2. Por lo tanto, dos PEs se consideran de host múltiple en una ESI (por VLAN por cada instancia EVPN). En esta sección se describe cómo los dispositivos de hoja son multitarjeta. Los dispositivos BL en los que se ejecuta PIM L3-el enrutamiento de host múltiple a enrutadores de inquilino (titulados multidifusión externas) se describen en detalle en capítulos posteriores.

Lo describiremos con el fin de ilustrar las reglas de reenvío de BUM:

  • El agente de escucha se encuentra detrás de las hojas multitarjeta y el origen tiene un único host.

  • El origen está detrás de una hoja multitarjeta de host múltiple.

  • El origen se encuentra detrás de una hoja que tiene escucha de host múltiple en una ESI diferente.

Los oyentes situados detrás de los dispositivos de hojas de host múltiple y el origen son Singlehomed

Tenga en cuenta la topología Figure 6 en la que dos dispositivos de hoja, hoja-3 y hoja-4, son multitarjeta de host-5. El fundamento de la lógica de host de multitarjeta-5 a hoja-3 y hoja-4 es que, en caso de que se produzca un error de una de las hojas, el tráfico se reanuda en la otra hoja tan pronto como sea posible (resistencia). Además, si hay varios flujos de unidifusión que van de la hoja 1 a la host 5, algunos flujos se enviarán sobre la hoja 3 y otros sobre hoja 4 (equilibrio de carga).

Figure 6: Agente de escucha detrás de PEs multitarjeta
Agente de escucha detrás de PEs multitarjeta

Para el tráfico de multidifusión, debe extremarse la atención de que el tráfico de EVPN Core no lo envía, tanto en la hoja 3 como en la hoja 4, Lest que produce duplicados para host 5. (Los duplicados son un problema peor para las aplicaciones de multidifusión que la pérdida de tráfico!).

La hoja de entrada, hoja 1, inundará el tráfico de multidifusión hacia la hoja 3 y la hoja 4. Ambas hojas reciben el tráfico. Sin embargo, solo una hoja debe reenviar el tráfico a la interfaz de la ESI donde se ha dado cuenta de la relación de multitarjeta.

Para lograr esto, las hojas multitarjeta determinan el DF para una ESI entre los PEs que son multitarjeta de esa ESI. Esta determinación se realiza mediante la ejecución de un algoritmo de elección de DF (basado en MOD, preferencia local, etc.) según las rutas del tipo 4. Una vez completada esta determinación, se elige como NDF (sin DF) una de las de PEs de host múltiple para la ESI, mientras que los otros PEs de alojamiento múltiple para esa ESI se marcan.

Cuando el tráfico de multidifusión llega desde el núcleo EVPN, las reglas de reenvío son las siguientes:

  • En una interfaz de acceso de host único, desborde el tráfico.

  • En una interfaz de acceso de múltiples hosts, si se elige como DF, desborde el tráfico.

  • En una interfaz de acceso de múltiples hosts, si está marcada como’NDF, no desbordará el tráfico.

En Figure 6hojas-3 y hoja-4, que son multitarjeta para el host-5 sobre una ESI, ejecute una elección para DF. Supongamos que hoja-3 se elige como DF y hoja-4 es NDF para la ESI. Cuando hoja-3 recibe tráfico del centro (la entrada se replica desde la hoja 1), se inunda a host 5, ya que es el DF en la ESI (clásica-DF-NDF).

En la recepción de tráfico del núcleo EVPN, hoja 4 no inunda el tráfico hacia host-5 puesto que se marcó la ESI como NDF (clásica-DF-NDF). Por lo tanto, host 5 no recibe duplicados. Sin embargo, LEAF-4 inunda el tráfico hacia host-6 ya que se trata de una interfaz de acceso individual.

Origen de multidifusión detrás de los dispositivos de hojas de host múltiple

CSider Figure 7 donde la fuente de multidifusión es de host múltiple a dos dispositivos de hoja en una ESI donde Leaf es el ndf y Leaf-2 es el DF. Cuando el código fuente comienza el envío de tráfico, puede enviarse el tráfico en cualquiera de los miembros del paquete de posposición por el hecho de que la interfaz de AE tenga un algoritmo hash. Por lo tanto, host 1 puede enviar el tráfico a la hoja 1 o a la hoja 2.

’Supongamos que el tráfico de multidifusión se envía a hoja-1. Si no se emprende ningún tratamiento especial para este escenario, ocurrirá lo siguiente, basado en los procedimientos (clásica-DF-NDF) descritos anteriormente. HOJA-1 enviará tráfico hacia el núcleo. Al recibir este tráfico del núcleo, hoja-2 se desbordará en las interfaces donde se encuentra el DF elegido.

En este caso, como LEAF-2 es el DF elegido en host-1, finalizará su reenvío hacia el origen. Este comportamiento no es correcto. Por lo tanto, se requiere un manejo especial, de modo que hoja-2 no devuelva el tráfico de la ESI que sea multitarjeta a hoja-1.

MPLS tiene la etiqueta de horizonte dividido para tratar dichos escenarios. ¿Cómo se puede resolver este problema en VXLAN?

Si es posible que LEAF-2 deduce que el paquete lo envió la hoja-1, LEAF-2 puede programar su reenvío de modo que si los paquetes proceden de hoja-1, se omita el reenvío en aquellas interfaces que sean de host múltiple con hoja 1. Compensemos’esto en detalle.

Figure 7: Origen detrás de los PEs multitarjeta
Origen detrás de los PEs multitarjeta

HOJA-1 envía los paquetes de multidifusión con la dirección IP VTEP de origen de hoja-1, por ejemplo, S-VTEP-IP-1. HOJA-2 sabe que hoja-1 tiene S-VTEP-IP-1 como VTEP de origen a partir de BGP rutas tipo 3.

LEAF-2 recorre sus interfaces de acceso/ESIs y crea una lista de interfaces de host múltiple con Leaf-1 , donde es de host múltiple a Leaf-1. A continuación, LEAF-2 crea una regla en la que, cuando un paquete llega con SVTEP-IP-1, omitirá el reenvío en esta lista de interfaces de host múltiple con LEAF-1. Estas normas de reenvío deben generarse para cada hoja con la que hoja-2 sea de host múltiple. ’Haga referencia a él como (DST-local-bias).

Una vez que se ha programado el reenvío, cuando LEAF-2 recibe tráfico de S-VTEP-IP-LEAF-1, el tráfico no se envía de nuevo a la interfaz multitarjeta, sino que se inunda hacia host-3 y host-4 (ya que estas interfaces no tienen multitarjeta con hojas-1).

El origen está detrás de una hoja que tiene una escucha de host múltiple

Antes de volver a examinar las reglas de reenvío multitarjeta y reescribir las reglas generales de reenvío de multidifusión L2, debemos considerar una topología más en la que un dispositivo de EVPN hoja tenga un origen local y tenga una interfaz de host múltiple que esté en interfaces/ESIs diferentes.

Tenga en cuenta la topología que Figure 8 se muestra en la donde Leaf-1 tiene una fuente de multidifusión en una interfaz de host único y una de agente de escucha-3 en una interfaz multitarjeta compartida con hoja-2. Basándose en una elección,’deje que hoja-1 sea el ndf y que hoja-2 sea el DF para la ESI.

Figure 8: Origen detrás de la escucha de host múltiple
Origen detrás de la escucha de host múltiple

Según las reglas descritas anteriormente, hoja 2, al recibir el tráfico del núcleo, no reenviará el tráfico a la lista de interfaces de host múltiple con hoja-1. Por lo tanto, LEAF-2 no reenviará el tráfico hacia host-3.

La hoja 1, siendo NDF hacia el host-3, es una situación de no ubicación. HOJA-2 no reenviará el tráfico hacia host-3 debido a (cambio de diferencia local de DST). De este forma, se garantiza que el tráfico recibido en las interfaces multitarjeta no vuelve al bucle de origen. Sin embargo, LEAF-1, siendo NDF hacia el host-3, no puede avanzar a host-3 en función de las reglas (clásica-DF-NDF) . ¿Cómo se obtiene el tráfico de host 3?

Para abordar esta situación,’conviene desviar ligeramente un poco de las reglas (clásicas-DF-NDF). Cuando hoja-1 recibe tráfico de una interfaz de acceso local, inunda el tráfico a todas las demás interfaces de acceso local sin tener en consideración si DF está o no en la interfaz de destino. Esto se puede hacer referencia a esto como (diferencia local de src).

En Figure 8, hojas-1 en la recepción de tráfico desde el origen desde la interfaz de acceso inundará todas sus interfaces de acceso con independencia de si se utiliza DF/NDF. Por lo tanto, LEAF-1 reenviará el tráfico a host-3, a pesar de ser NDF en la interfaz desde que el tráfico llegó desde una interfaz de acceso. Por lo tanto, host-3 recibirá el tráfico de hoja-1.

Hoja-2 al recibir el tráfico desde el núcleo desde la hoja 1, determinará el s-VTEP en s-VTEP-Leaf-1 y omitirá el reenvío a ‘la lista de interfaces de la MH’ a Leaf-1 (DST-local-bias). Por lo tanto, LEAF-2 no avanzará hasta host-3. La hoja 2 avanzará hacia el host 4 ya que no se trata de una interfaz multitarjeta con hoja-1.

Todo junto para la multidifusión de multivlan

Según las reglas de envío descritas hasta ahora en este capítulo, permita’relacionar el comportamiento de nuestra topologíaàde ejemplo en relación con las normas de reenvío. Consulte la sección de verificación de tráfico para obtener estadísticas.

En Figure 9 la hoja 1, el NDF se encuentra en las interfaces de MH que van a host-1 y host-3. HOJA 3 es el DF en la interfaz de la MH que va al host 5. Host 1 es la fuente de tráfico de multidifusión. Host-1, basado en el hash de su paquete de AE, puede enviar el tráfico a la hoja 1 o a la hoja 2. Supongamos que envía a hoja-1.

En este caso, LEAF-1 realiza las acciones siguientes:

  • No envía el tráfico de vuelta a host-1 (ACCESS-SPLIT-HRZN)

  • La entrada replica el tráfico a todos los PEs remotos a través de VTEP (CORE-IMET-FWD)

  • No envía a hoja-5 si no hay ningún tipo 3 para VLAN-101. (CORE-IMET-SKIP)

  • Envía tráfico al host-2 ya que se trata de una interfaz de un solo alojamiento (SH-FWD)

  • Envía al host-3, aunque es NDF y es de acceso de tráfico (origen SRC-LOCAL-BIAS)

Figure 9: Reglas de reenvío
Reglas de reenvío

Al recibir el tráfico de Core, hoja-2 realiza las acciones enumeradas a continuación:

  • No envía tráfico de vuelta al núcleo (división central-HRZN)

  • Envía tráfico hacia host-4 ya que se trata de una interfaz de un solo alojamiento. (SH-FWD)

  • No envía tráfico a host-1 (DST-LOCAL-BIAS)

  • No envía el tráfico al host 3 (DST-LOCAL-BIAS)

HOJA-3, al recibir tráfico desde el núcleo, realiza las acciones siguientes:

  • Envía a host 5 ya que se trata de DF en la interfaz (clásica-DF-NDF).

En la hoja 4, al recibir tráfico desde el núcleo, realiza las acciones siguientes:

  • No realiza envíos a host-5, ya que es NDF (clásica-DF-NDF).

  • Reenvía el tráfico a host-6, ya que se trata de una interfaz de host único (SH-FWD).

  • HOJA-5 no recibe tráfico del núcleo ya que no aloja VLAN-1.

Reglas de reenvío general para el tráfico de multidifusión en EVPN

Vamos a mejorar las reglas descritas anteriormente en este capítulo y tomar multitarjeta en cuenta.

(CLÁSICO: DF-NDF)

  • Cuando el tráfico llega de EVPN Core desde un PE que no tengo multitarjeta con

  • En una interfaz de acceso de host único, desborde el tráfico.

  • En una interfaz de acceso de múltiples hosts, si se ha elegido DF, desborde el tráfico

  • En una interfaz de acceso de múltiples hosts, si está marcada como’NDF, no desbordará el tráfico

(DST-LOCAL-BIAS)

  • Cuando el tráfico llega de EVPN Core desde un PE, por ejemplo, PE-X, ¿quién soy de host múltiple con

  • En una interfaz de acceso de host único, desborde el tráfico.

  • En una interfaz de acceso de múltiples hosts con multitarjeta de host con PE-’X, no inundar tráfico, independientemente de DF/NDF.

  • En una interfaz de acceso de múltiples hosts en la que no hay multitarjeta con PE-X, se inunda si I am DF en la interfaz.

  • En una interfaz de acceso múltiple en la que no hay multitarjeta con PE-X, no desborde si soy NDF en esa interfaz.

(SRC-LOCAL-BIAS)

  • Cuando llega el tráfico desde la interfaz de acceso:

  • Se inunda en todas las otras interfaces de acceso con independencia de DF/NDF.

  • Las entrada se replican en el núcleo de todos los PE que hospedan la VLAN.

Los procedimientos anteriores, (2) y (3), para el envío del tráfico de BUM se suele denominar diferenciación local. Como su nombre sugiere, cuando el tráfico llega a una interfaz de acceso local, el dispositivo de hoja recibe la diferencia de reenviarlo en otras interfaces de acceso con independencia del DF/NDF. Los dispositivos remotos de host múltiple no reenvían la interfaz de acceso con múltiples hosts, con independencia de DF/NDF. Por lo tanto, se da preferencia al PE local a reenviar sobre el PE remoto (de ahí que sea el término diferencia local).

Tenemos que tener en cuenta que estas reglas de diferencia local solo son aplicables en EVPNoVXLAN. Con EVP-nompls, el uso de la etiqueta de horizonte dividido por la ESI trata los escenarios de host múltiple.

Note

Los procedimientos de etiqueta de horizonte dividido quedan fuera del alcance de este libro.

Resumen del capítulo

En este capítulo se han tratado distintas reglas de reenvío de BUM en topologías de alojamiento único y multitarjeta. Demostramos cómo el tráfico de multidifusión se inunda en todo el entramado de EVPN hacia el núcleo y todas las interfaces de acceso. Las reglas de reenvío de multitarjeta ayudan a garantizar que los oyentes no reciben duplicados o se vuelven de un bucle. Estas reglas tienen en cuenta el estado de DF/NDF de una ESI, si el tráfico llegó desde un PE con el que es multitarjeta y si el tráfico llegó a una interfaz de acceso.

El capítulo Assisted Replication explora los desafíos con la replicación de entrada y la forma en que se puede mitigar. Las configuraciones y comprobaciones ahora siguen.

Automática

Figure 10es la topología de referencia.

Figure 10: Topología de referencia
Topología de referencia

Ahora vamos’a centrarme en la configuración y verificación de la funcionalidad de multidifusión interna de la VLAN descrita en este capítulo, incluido el uso de multitarjeta en EVPNoVXLAN y los comandos utilizados. En esta sección, veremos el comportamiento de reenvío del tráfico de multidifusión EVPN intravlan, en particular el aspecto de la inundación en todo el mundo , en ausencia de optimizaciones.

Las configuraciones básicas de subyacente y superposición que se muestran en EVPN Base Configuration in DC Fabric Topology son suficientes para esta sección. Para todos nuestros debates internos de la VLAN, nos centraremos en VLAN-101 (VLAN id 101, VNI 101). Tenga en cuenta que LEAF-5 no hospeda VLAN-101/VNI-101.

Verificación del tráfico

Desde host-1, empiece a enviar tráfico de multidifusión a 10 PPS (paquetes por segundo) para 225.1.1.1 de grupo en VLAN-101. Tenga en cuenta que, a partir de ahora, ningún receptor realmente ha expresado interés en recibir este tráfico.

Desde las estadísticas de RT Figure 11en, puede ver que host-1 envía tráfico a 10 PPS, que son recibidos por todos los hosts del DC que forman parte de VLAN-101 (host-2 a host-6), aunque ninguno de ellos esté interesado en el tráfico. Host-7 solo, que no forma parte de VLAN-101, se extrae del tráfico. El host 8 se encuentra fuera de la estructura y se puede omitir por ahora.

Figure 11: Estadísticas RT
Estadísticas RT

Multicast Traffic Outputs - LEAF-1

Host-1 es multitarjeta a hoja-1 y hoja-2. Por lo tanto, el tráfico de host-1 hacia el hoja-1/hoja-2 puede tener equilibrio de carga, y puede llegar a hoja-1 o hoja-2. En nuestro caso, el tráfico de multidifusión llega a la interfaz de acceso, ae0 en LEAF-1.

No se produce un desbordamiento de tráfico en la interfaz entrante, AE 0.0: (ACCESS-SPLIT-HRZN).

En hoja 1, el tráfico se reenvía al resto de la interfaz de acceso de alojamiento único, XE-0/0/4 hacia host-2: (SH-FWD).

El tráfico se reenvía a todas las interfaces de acceso multitarjeta, AE 1.0 en hoja 1, independientemente del estado de DF/NDF (SRC-LOCAL-BIAS):

El tráfico de multidifusión también se reenvía al VTEPs hacia BL-1 (101.101.101.101) y BL-2 (102.102.102.102).

También se reenvía en el VTEPs hacia la hoja-2 (106.106.106.106), hoja-3 (107.107.107.107) y hoja-4 (108.108.108.108): (CORE-IMET-FWD).

El tráfico no se reenvía al VTEP hacia LEAF-5 (109.109.109.109) (CORE-IMET-SKIP):

Multicast Traffic Outputs - LEAF-2

El tráfico de multidifusión que llega a la hoja 2 no se reenvía a las interfaces de acceso de múltiples hosts, ae0 y AE1, aunque es el DF en estas dos interfaces, ya que el PE de origen, LEAF-1, es un sistema de host múltiple de la ESI de estas interfaces (DST-LOCAL-BIAS). Esto asegura que no hay bucle de tráfico hacia el origen multitarjeta, host-1, y que no hay duplicación de tráfico hacia el host multitarjeta host 3.

El tráfico se reenvía a Xe-0/0/4.0 (SH-FWD) hacia el host de alojamiento único, host 4:

El tráfico no se devuelve en ninguno de los VTEPs. Aunque VTEPs forman parte de la inundación del próximo salto, las reglas de horizonte dividido para el tráfico BUM que llega de un núcleo garantizan que el tráfico no vuelva a enviarse al núcleo. (NÚCLEO-DIVISIÓN-HRZN).

Multicast Traffic Outputs - LEAF-3

El tráfico que llega a la hoja 3 no se reenvía a la interfaz de acceso de múltiples hosts, AE 0.0, ya que es el NDF (el clásico-DF-NDF). Esto garantiza que el host múltiple, host 5, no reciba tráfico duplicado:

El tráfico tampoco se devuelve en ninguna de las VTEPs (CORE-SPLIT-HRZN).

Multicast Traffic Outputs - LEAF-4

El tráfico de multidifusión que llega a la hoja 4 se reenvía a la interfaz de acceso multitarjeta de Access, AE 0.0, ya que es el DF y LEAF-1 no es un interlocutor de host múltiple (consulte la sección 3.4.1): (CLÁSICA-DF-NDF).

El tráfico también se reenvía a Xe-0/0/3.0 (SH-FWD) hacia el host de alojamiento único, host 6:

El tráfico no se devuelve a ningún VTEPs (CORE-SPLIT-HRZN).

Multicast Traffic Outputs - LEAF-5

HOJA 5, ya que no aloja el VLAN-101, no recibe el tráfico del nodo en la hoja 1.

Multicast Traffic Outputs –BL-1 and BL-2

El comportamiento de los dos dispositivos de hojas de borde solo será significativo una vez que lleguemos al capítulo sobre el reenvío de tráfico entre VLAN. Así que hasta entonces, omitiremos el comportamiento de reenvío de tráfico en estos dispositivos.

Verificación detallada del plano de control

Verifying the Flood Routes

Para cada VLAN, un PE crea un salto próximo que consiste en todas sus interfaces de acceso para esa VLAN, y en el VTEPs correspondiente a los interlocutores EVPN a partir de los cuales ha recibido rutas de tipo 3 para esa VLAN. El siguiente salto se usa para inundar el tráfico de multidifusión en la VLAN.

Por ejemplo, en LEAF-1, el próximo salto de la inundación se compone de VTEPs que corresponde a:

  • BL-1 (vtep. 32770)

  • BL-2 (vtep. 32774)

  • HOJA-2 (vtep. 32769)

  • HOJA-3 (vtep. 32772)

  • HOJA-4 (vtep. 32771)

Note

El VTEP correspondiente a LEAF-5 (VTEP. 32773) no está presente en el próximo salto de la torre para VLAN-101.

La información de inundación del próximo salto de los demás PEs será similar a la anterior.

Verification of Multihoming State

Cada PE que hospeda la ES, realiza una elección de DF para la ES.

Por lo tanto, para los segmentos Active/Active Ethernet de host múltiple a hoja-1 y hoja-2, así, 00:11:11:11:11:11:11:11:11:11 y 00:22:22:22:22:22:22:22:22:22, LEAF-2 (106.106.106.106) se elige DF.

Para el segmento de Ethernet activo/activo de host múltiple a hoja-3 y hoja-4, es decir 00:33:33:33:33:33:33:33:33:33, se elige DF-4 (108.108.108.108).

En la mayoría de los casos, verificaremos por sí mismos los Estados de una sola ESI en la hoja 1. Los Estados para otros ESIs y en otros PEs son similares y se dejan como un ejercicio para el lector.

DF Verification

Deje’que s Compruebe el estado de DF/NDF en el hoja 1:

Verification For ESI Status in Detail

Puede usar el siguiente comando para ver más detalles de la elección del DF para una ES:

Verifying ESI State: Forwarding/Blocked

Ahora vamos’a comprobar el estado de ESI.

LEAF-1, ya que no es el DF en interfaces de acceso multitarjeta AE 0.0 y AE01, lo marca en “modo” de bloqueo para el tráfico Bum, mientras que hoja-2, que es el DF, “marca estas” interfaces en modo de reenvío:

Los PE en los que esta interfaz es de host múltiple también se pueden ver en el resultado. Esta información se utiliza en este PE cuando se aplica el ajuste DST-LOCAL-BIAS para el tráfico que llega desde el núcleo.