EVPN la multidifusión intravlan con optimización

EVPN Intra-VLAN Multicast Without Optimization capítulo de optimización y de Assisted Replication EVPN los procedimientos de multidifusión en los que el tráfico de conmutación L2 fue ' inundado en todo el mundo’. Este flujo de información a los PE remotos, que no tienen ningún agente de escucha detrás de ellos, y los PEs que’inundan el tráfico en todas las interfaces de acceso, incluso si no hay escuchas, no es claramente conveniente.

Uno de los inconvenientes de esta unrestrained es que todos los dispositivos de hoja se cargan con el tráfico de procesamiento. Esto no es útil. Algunos dispositivos de hoja pueden ser dispositivos de low-end, o incluso pueden ser dispositivos de hoja virtual. Si estos dispositivos están sometidos a un tráfico de multidifusión elevado, extraerán otras aplicaciones de tráfico y disminuirán el rendimiento.

Además, el tráfico redundante que se envía en las interfaces de acceso puede afectar al uso de vínculos, con lo que se degradan otros flujos auténticos para los que hay escuchas. La inundación del tráfico en EVPN Core con la replicación de entrada a los PE que no tienen oyentes detrás produce un consumo de ancho de banda principal y un exceso de carga en la hoja de entrada para crear varias copias redundantes.

En este capítulo se describen los mecanismos que garantizan que el tráfico se reenvía únicamente a esas interfaces de acceso donde hay interés en la escucha. También se describen los procedimientos en los que el tráfico está replicado a través del núcleo EVPN a solo aquellos PE EVPN remotos que han expresado su interés de escuchas. Analicemos’los procedimientos que le ayudarán a mitigar el flujo Unbridled de tráfico de multidifusión en todos los lugares. Para lograr este fin, presentamos la supervisión de IGMP, el reenvío selectivo de multidifusión, BGP ruta SMET Type-6, etc.

Estos procedimientos ayudan a optimizar el reenvío de multidifusión en el tejido de CC. Se toma la precaución de garantizar que el tráfico de multidifusión sólo se reenvía hacia los PEs o las interfaces de acceso que tienen un interés de oyentes para un flujo determinado. Como resultado, existe una ganancia importante en términos de uso de la conexión y el ancho de banda central, la reducción en la carga de la replicación de entrada y la reducción de la carga de procesamiento de salida.

Cuando estas técnicas de optimización se utilizan junto con AR (descritas en un capítulo anterior), obtenemos las ventajas de la optimización y de la transferencia de la carga de replicación a AR-Replicator.

Debido a dispositivos heredados, es posible que, en algunos casos, no sea posible tener esta capacidad de optimización en todas las hojas. En este capítulo se describen los procedimientos que sirven para acomodar dichos dispositivos y garantizar que el reenvío de multidifusión se realiza de la manera correcta.

EVPN con IGMP: supervisión

La optimización de multidifusión en un conmutador L2 se describe como tal porque EVPN como una tecnología habilita el estiramiento del dominio L2 a través de dispositivos remotos. Un dispositivo de hoja EVPN desempeña el papel de un conmutador L2 en sus interfaces de acceso. Con la supervisión IGMP habilitada en un dispositivo de hoja EVPN Figure 1(consulte), el tráfico de multidifusión solo se envía en aquellas interfaces que tienen escuchas detrás de ellas.

’Supongamos que, Figure 1en, PE2 se configura con EVPN y IGMP con supervisión. Cuando el tráfico de multidifusión enviado desde el origen MCAST llega a PE2 sobre EVPN, PE2 debe reenviar ‘el’tráfico de multidifusión solo a la interfaz a, ya que ha recibido un informe ‘IGMP’(interés de escuchas) solo de la interfaz a.

El tráfico no se inunda en otras interfaces de acceso b, c y d.

PE2 es un dispositivo EVPN que se habilita con la supervisión IGMP en el puente-dominio. PE2 supervisa la información de pertenencia a la interfaz de acceso y realiza el seguimiento de la asociación. Cuando el tráfico de multidifusión llega desde el núcleo o desde una interfaz de acceso, el tráfico se desborda únicamente en aquellas interfaces en las que se ha aprendido el estado IGMP.

Manual sobre la supervisión de IGMP

En esta sección, vamos’a explorar las técnicas de optimización de multidifusión L2 que se han implementado ampliamente en el mundo de los conmutadores durante más de una década. Esta optimización de multidifusión en las interfaces de acceso se consigue con la supervisión IGMP. Esto se ha utilizado ampliamente en el mundo de conmutación L2, donde es necesario reenviar el tráfico hacia las interfaces con los oyentes que se encuentran detrás.

En un entorno típico de conmutación L2, el tráfico de multidifusión siempre se reenvía en todas las interfaces. En Figure 2’la topología s, el conmutador dispone de cinco interfaces de acceso: a, b, c, d y x. Digamos que no hay ninguna optimización de multidifusión con conmutación L2 configurada en el conmutador.

Supongamos que suponemos que’Host1 por sí solo está interesado en el tráfico del grupo G y envía un informe IGMP para (*, G). IGMP es un protocolo que utilizan los hosts y los enrutadores o conmutadores adyacentes para establecer pertenencias a grupos de multidifusión. Con un informe IGMP para el grupo G, el host expresa el interés de la escucha para el grupo G en el conmutador/enrutador más próximo de la LAN.

En un conmutador sin optimización de multidifusión, cuando el origen comienza a enviar tráfico en x para el grupo G, el conmutador inundará el tráfico – en las cuatro interfaces a, b, – c y d, aunque los hosts 2, 3 y 4 no estén interesados en ese grupo.

En un caso distinto, cuando no hay escuchas para el grupo y el origen envía tráfico, el conmutador seguirá inundando el tráfico en las cuatro interfaces: a, b, c y d. Esto es claramente indeseable.

A continuación’, digamos que el conmutador está configurado con supervisión IGMP. Con la supervisión IGMP, cuando se recibe (espionaje) un informe/combinación IGMP en la interfaz a, el conmutador abrirá el informe (*, G) y creará un estado IGMP asociado para G con la interfaz a.

Reenvío de multidifusión L2 optimizado con la supervisión IGMP

WEl tráfico de multidifusión de W ‘llega’ a la interfaz x del grupo G, el conmutador lo ‘reenviará’ únicamente a la interfaz a según el estado (*, G) mantenido ‘para’la interfaz a. (Access-Snoop) . Por lo tanto, se evita la inundación innecesaria de tráfico en las interfaces b, c y d.

Además, si no hay informes IGMP de ninguna de las interfaces (a, b, c, d) y si el tráfico llega a la ‘interfaz’x, con la supervisión IGMP habilitada, el conmutador no reenviará el tráfico a ninguna de las interfaces (a, b, c, d).

Por lo general, el conmutador tendrá varios puertos. Si está habilitada la supervisión IGMP en el conmutador, se reduce considerablemente el uso del ancho de banda en las interfaces. Además, los hosts que no están interesados en el grupo no se cargan con tráfico innecesario. No hace falta decir que la carga de replicación del conmutador para crear copias redundantes también se reduce en virtud de la supervisión de IGMP.

El conmutador envía periódicamente consultas ‘’ generales IGMP para solicitar el interés del agente de escucha mediante informes IGMP procedentes de hosts. Cuando un host ya no está interesado en el flujo de datos en cuestión, el host envía un mensaje de salida IGMP. Al recibir el mensaje de salida IGMP, el conmutador envía una ‘consulta’ específica al grupo para el grupo g, para solicitar si todavía hay otros hosts interesados en el grupo g.

Hacia este fin, el conmutador inicia un cronómetro denominado ‘última consulta’de pertenencia. Una vez que el temporizador ha caducado, el conmutador está seguro de la ausencia del interés de la escucha en la interfaz. En función de esto, el conmutador elimina el estado IGMP para el grupo de la interfaz.

Reenvío selectivo de multidifusión hacia el núcleo

Hasta ahora hemos descrito la optimización del tráfico de multidifusión en el lado del acceso. Es imprescindible que el tráfico que se inunda al núcleo con la replicación de entrada se optimice también, de forma que sólo los PEs que tengan escuchas reciban realmente tráfico. Esto se denomina reenvío de multidifusión selectivo de EVPN.

Considere Figure 4 en qué lugar están habilitados todos los dispositivos hoja VLAN-101/VNI-101. La hoja 3 no tiene un agente de escucha para el grupo G, detrás de él. Pero, ¿qué sucede si hubiera cientos de hojas, como hoja 3, que no tuvieran oyentes detrás de ellas para el grupo G?

Si el PE de entrada, hoja 1 en Figure 4, excluye estas hojas en la lista de saturación de la replicación de entrada, deberíamos lograr el reenvío de multidifusión selectivo para el grupo G. Esto tiene como resultado el ancho de banda de núcleo y la exención de las hojas que’no tienen escuchas detrás de las mismas de la sobrecarga de procesamiento de tráfico.

Con el reenvío selectivo, Figure 4 en hoja 1 se cambiará el tráfico L2 (del código fuente solo a hoja-2 y hoja-4). Además, LEAF-2 inundará el tráfico de multidifusión únicamente en aquellas interfaces de Access en las que haya oyentes (en virtud de la supervisión IGMP en Access (Access-Snoop)). Por lo tanto, LEAF-2 envía el tráfico únicamente a host-3, pero no a host-4. HOJA 4 inunda el tráfico únicamente en el host 6. Ninguna otra interfaz de acceso lleva el tráfico. Además, ningún otro dispositivo hoja recibe el tráfico a lo largo del núcleo.

Se acumulan tres tipos de beneficios:

La carga de’replicación de hoja 1 s se reduce considerablemente, por ejemplo, al replicar el tráfico en tan solo dos hojas como, en comparación con el envío a 200 hojas de la hoja de entrada.
La utilización del ancho de banda principal está considerablemente reducida. Cada paquete replicado superfluo habría tenido que desplazarse únicamente a dispositivos hoja no deseados para quitarlos.
Las hojas de la hoja 3 y otras tales que no tienen oyentes han sobrecargado el procesamiento de este tráfico innecesario, con lo que se libera a otras tareas.

Cuando un host que se encuentra detrás de una hoja se une a un grupo G, la entrada envía el tráfico del grupo G a la hoja. De manera similar, cuando el host envía una salida IGMP para el grupo G, la entrada deja de enviar el tráfico del grupo G a la hoja. En otras palabras, la entrada reenvía el tráfico de un grupo G a una hoja únicamente mientras haya una escucha remota que tenga interés en el grupo situado detrás de dicha hoja

Procedimientos básicos para el reenvío selectivo de multidifusión

Ahora deje’que s describa el mecanismo con el que se realiza el reenvío selectivo de multidifusión. Tal y como se describe en la sección principal de la supervisión de IGMP, que se encuentra al principio de este capítulo, los dispositivos de hoja EVPN expiden los informes y mantienen el estado IGMP asociado a la interfaz.

BGP Type-6 SMET (Selective Multicast Ethernet Tag) Route

El dispositivo de hoja EVPN, cuando recibe un informe para el grupo G1 de cualquiera de las interfaces de acceso de una VLAN, originará una BGP EVPN tipo-6 NLRI ruta para G1. Esta ruta de tipo 6 contiene un distintivo de ruta, una etiqueta Ethernet, una dirección de grupo de multidifusión y una dirección IP de Figure 5origen, tal y como se muestra en la.

Este enrutamiento también lleva la comunidad RT-Target, que identifica la instancia EVPN, de tal forma que solo aquellos EVPNrs que hospedan la instancia EVPN relevante importarán esta ruta.

El campo E-Tag incluye la VLAN para la que es relevante el interés de la escucha para la dirección del grupo. Para un grupo G en una VLAN V-101, puede haber varios o varios dispositivos de hoja que tengan un interés de oyentes. Cada uno de estos dispositivos hoja originará esta ruta de tipo 6. Dado que sus distintivos de ruta y su dirección IP de origen serán diferentes, los ingresos serán capaces de identificar claramente los dispositivos de hoja interesados y crear los Floodlist selectivos en consecuencia.

El término lista de interfaces de salida (OIL) se utiliza tradicionalmente para hacer referencia a las interfaces de lista en las que se debe enviar el tráfico de multidifusión de un grupo específico G1. En nuestros debates, el aceite de un grupo G1 en una entrada será el VTEP interfaces que señalen a los dispositivos de hoja específicos para ese grupo.

Esta ruta BGP tipo 6 se puede considerar como el equivalente EVPN de un informe IGMP recibido en el acceso, por lo que esta ruta del tipo 6 equivale al informe IGMP (*, G1) en el núcleo EVPN.

En Figure 6, hoja-2, cuando recibe el informe IGMP (*, G1) del host-3 en vlan-101 desde Access, originará una ruta tipo EVPN 6 para VLAN vlan-101 y Group G1. Del mismo modo, LEAF-4 también originará un tipo-6 para el grupo G1 en VLAN-101.

Note

Hay que tener en cuenta que LEAF-2 no reenviará el informe IGMP al núcleo, puesto que ya ha señalado el interés de la escucha con el tipo 6. Esta ruta de tipo 6 también ayuda a evitar que se actualicen los informes IGMP innecesarios en el núcleo.

HOJA-1 importará las rutas tipo 6 para el grupo G1 de hoja-2 y hoja-4. Además, LEAF-1 instalará una entrada de reenvío de supervisión de multidifusión específicamente para G1 que incluye únicamente la hoja-2 y la hoja-4 en su aceite. Cuando llega el tráfico del grupo G1 a partir del origen, el tráfico llegará a la entrada de reenvío de multidifusión específica para G1 y se replicará de forma selectiva únicamente en la hoja 2 y la sola hoja.

An Example with Two Different Groups G1 and G2

Figure 7describe a los hosts interesados en dos grupos distintos, por ejemplo G1 y G2. El host-3 hosts y el host 5 están interesados en el grupo G1, mientras que host-2 y host-6 están interesados en el grupo G2. Las respectivas rutas de tipo 6 del grupo G1 se originaron por hoja-2 y hoja-3, mientras que para el grupo G2, por hoja-1 y hoja-4.

Desde la hoja de PE de entrada-’1 s punto de vista, el aceite de G2 incluirá Leaf-4 y también accederá a ‘la’ interfaz x hacia host-2. El PE de entrada creará un aceite con una VTEP interfaz hacia el servidor de hoja 4, además de una interfaz ‘de’ acceso x hacia host-2. El tráfico del grupo G2 no se enviará a ninguno de los dispositivos de la hoja 200, excepto en ‘la’ hoja 4 y en la x hacia el host-2. Se trata de una optimización significativa conàrespecto a las secciones EVPN Intra-VLAN Multicast Without Optimization de capítulos.

Supongamos que existe un grupo G3 (no Figure 7mostrado en) para el que no hay oyentes en ninguna parte de la RIC FAB. La entrada, LEAF-1, no recibe ninguna ruta de tipo 6 para G3 y, por lo tanto, no instala una entradas de reenvío específicas para G3. Cuando un origen envía tráfico para G3 hacia la hoja 1, la hoja 1 no reenvía el tráfico a G3 hacia el núcleo.

Con frecuencia, hay un tráfico de multidifusión de gran volumen que se envía para varios grupos, pero no hay escuchas activas para dichos grupos. Con el mecanismo de reenvío selectivo de multidifusión, el tráfico de alto volumen no se envía hacia el núcleo a cualquiera de los dispositivos de la hoja 200 para dichos grupos, lo que ahorra un ancho de banda central considerable.

BGP Type-6 NRLI SMET Route and Selective Multicast Forwarding

La ruta de tipo 3 de EVPN también se conoce como ruta de etiqueta Ethernet de multidifusión inclusiva (IMET), ya que de acuerdo con este enrutamiento, el tráfico se reenvía ‘de manera’ inclusiva, por ejemplo, a los dispositivos de hoja, independientemente del interés de la escucha.

La ruta del tipo de EVPN-6 se conoce como ruta selectiva de la etiqueta Ethernet de multidifusión (Smet).

La sutil utilización de los términos aquí marca la diferencia:

Ruta de SMET: Esto hace referencia al BGP ruta de NLRI de tipo 6 que los dispositivos hoja de EVPN se originan cuando hay un interés de la escucha para un grupo en particular en una VLAN determinada.
Reenvío de multidifusión selectivo (SMET) (a veces llamado reenvío de SMET): Esta es la capacidad de entrada EVPN PE, que crea en un grupo el de reenvío de multidifusión de varias difusiones, el que tiene un interés específico para los’ dispositivos de hojas VTEPs, basándose en las rutas del tipo de EVPN remoto que ha oído desde los dispositivos de hojas. (NÚCLEO-SMET-FWD)
El reenvío de IGMP (SMET) y de supervisión selectiva son técnicas para optimizar el tráfico de multidifusión. Para optimizar el reenvío de multidifusión en el núcleo para que funcione bien, es fundamental que ‘las’ anteriores ‘a’ y b se admitan en los dispositivos apropiados. Por ejemplo, un dispositivo EVPN que está conectado a escuchas debe admitir al menos SMET ruta de la capacidad. Un dispositivo EVPN que está en la entrada debe admitir la capacidad de ruta SMET y el paradigma de reenvío de multidifusión selectiva (SMET).

Dado que las rutas de tipo 6 se envían desde la hoja a la espina, se evitan las actualizaciones periódicas de los informes IGMP a través del núcleo. En la interfaz de acceso, cuando los agentes de escucha envían un permiso IGMP para un grupo G, la hoja enviará una consulta específica al grupo para asegurarse de que no existe ningún otro agente de escucha para ese grupo. Una vez que la hoja ha afirmado que el interés del oyente ha desaparecido, retira la ruta anunciada del tipo 6. Esto da como resultado que las Ingress se actualicen su aceite con la hoja remota eliminada de la lista.

Un estado de supervisión de IGMP para un grupo en el lado del acceso, hace un seguimiento de cada interfaz L2 en la que se recibe un informe de escucha para G. Merece la pena mencionar aquí que el tipo 6 para el grupo G es representativo del interés de la escucha en esa VLAN de la hoja.

Mientras exista al menos una interfaz L2 de acceso en la que haya interés en la escucha, se origina una ruta tipo 6 para el grupo G. Además, cuando no hay ninguna interfaz L2 de acceso en la VLAN en la que existe un interés de oyentes para el grupo G, se retira el tipo-6 del grupo G de dicha VLAN.

Hasta ahora, sólo se han descrito escenarios de una sola vivienda en los que se ilustra el reenvío optimizado. Con los hosts múltiples, existen desafíos que se exploran en EVPN Intra-Multicast Optimization with Multihoming .

EVPN Multicast Flags Community: SMET Feature Capability Exchange

Muchas veces, en situaciones prácticas, hay una mezcla de dispositivos que admiten el reenvío selectivo (SMET) y los que no lo admiten. Además, es posible que algunos dispositivos de la hoja no se habiliten con la supervisión IGMP. Por lo tanto, es necesario intercambiar la capacidad para que los dispositivos de EVPN participantes puedan interoperar correctamente.

Para lograr este fin, EVPN las marcas de multidifusión de la comunidad (MF-COM) se introdujeron para ayudar a las capacidades de intercambio de los dispositivos de EVPN en la estructura, de modo que el PE’de entrada pueda acomodar los dispositivos’que no admitan la funcionalidad y que no puedan interoperar bien. Puede ver el encabezado para EVPN MF-COM en Figure 8la.

Un dispositivo den EVPN habilitado con IGMP: supervisión y admite el BGP Smet de enrutamiento de tipo 6 agregará una comunidad BGP extendida denominada EVPN de etiquetas de multidifusión (EVPN-MF) a su ruta EVPN tipo 3.

Además, este dispositivo establecerá el bit menos significativo (LSB) del octeto en la comunidad en 1 para sugerir la compatibilidad con la capacidad SMET. Un dispositivo compatible con la supervisión IGMP y admite BGP SMET capacidad de tipo 6 de ruta de distribución debe agregar la comunidad EVPN-MF y establecer el LSB en el octeto en 1.

Asimismo, si un dispositivo no está habilitado para la supervisión de IGMP, _o_ no admiten BGP Smet tipo de ruta 6 _o si se desea que el tráfico se desborde independientemente de que los oyentes lo salte, omitirá la adición de la comunidad EVPN-MF o agregará la comunidad EVPN-MF, pero devolverá el LSB del octeto en la comunidad a 0 para

Una vez que esta comunidad se intercambie en EVPN ruta de tipo 3, los PEs participantes tienen información en qué dispositivos hoja deben incluirse para todo el tráfico, y a qué hojas deben reenviarse selectivamente.

Procedimientos adicionales para el reenvío selectivo de multidifusión

Forward L2-switched Traffic to L3-PIM Spines

Cuando una hoja recibe el tráfico de su interfaz de acceso para el grupo G1, la hoja debe reenviar selectivamente el tráfico únicamente a los dispositivos EVPN PE que hayan originado un tipo 6 para dicho grupo G1.

Además de reenviar el tráfico a los dispositivos de hojas que han sido originados en el tipo 6 del grupo G1, la entrada debe transferir el tráfico a los dispositivos de L3-PIM también. Si no hay escuchas remotas para el grupo, el tráfico debe seguir enviándose únicamente a los dispositivos L3-PIM.

La razón es la siguiente. Un dispositivo L3-PIM realiza enrutamiento entre subredes desde la VLAN de origen hasta las VLAN de otros destinatarios (la multidifusión entre VLAN se ilustrará con detalle en EVPN Intra-Multicast Optimization with Multihoming ). Por lo tanto, el dispositivo L3-PIM debe atraer y recibir el tráfico en la VLAN de origen todo el tiempo. Además, el dispositivo L3-PIM que es PIM DR debe registrar el origen de multidifusión en el PIM-RP. Por lo tanto, el tráfico debe alcanzar el dispositivo L3-PIM todo el Figure 9tiempo (consulte).

How Is a L3-PIM Device Detected?

En la última sección, la entrada reenvía el tráfico del grupo G1 a los dispositivos L3-PIM. Este dispositivo L3-PIM se detecta en virtud del dispositivo L3-PIM que restablece el LSB en la comunidad EVPN-MF en una ruta de tipo 3 BGP.

Es un poco de una paradoja por la que el dispositivo L3-PIM está habilitado con la supervisión IGMP, capaz de ser las rutas de tipo 6 de SMET de origen, así como capaz del reenvío selectivo (SMET). Sin embargo, el dispositivo L3-PIM tiene que atraer tráfico para los propósitos del enrutamiento entre VLAN y registrar el origen de multidifusión con el RP.

En este extremo, el L3-PIM se salta agregando la comunidad EVPN-MF o agrega la comunidad EVPN-MF, pero restablece el LSB en el octeto en 0. Cualquier PE de la hoja de entrada que reciba dicho tipo-3 inundará todo el tráfico en este dispositivo L3-PIM.

Accommodating Devices That Do Not Support Snooping/SMET Route

En determinadas implementaciones, es posible que existan pocos dispositivos de hoja que no estén habilitados con la supervisión IGMP. Además, puede haber varios dispositivos de hoja EVPN que estén habilitados con la supervisión IGMP, pero los dispositivos no tienen la compatibilidad con la ruta de origen BGP tipo 6.

Tales dispositivos de hoja heredados no transmiten los intereses de multidifusión de interés de la escucha remota a otros PEs. ’Supongamos que hoja-5 en Figure 10 es un dispositivo heredado que no admite la supervisión de IGMP.

Sin embargo, tales dispositivos de hojas heredados pueden disponer de oyentes interesados en el tráfico del grupo G1. Dado que no se originan en una ruta del tipo 6, la entrada no tiene una manera de determinar si hay escuchas detrás de dichos PE heredados o no. Si la entrada no reenvía el tráfico al PEs heredado, los oyentes que se encuentran detrás del PEs heredado no obtendrán el tráfico. Por lo tanto, la entrada tiene que inundar el tráfico hacia los PEs heredados y, de este modo, garantizar la compatibilidad con los dispositivos que no admiten los procedimientos de multidifusión optimizados.

How is a Legacy Device Detected?

En una sección anterior, vimos que el ingreso reenvía el tráfico del grupo G1 a los dispositivos de hojas heredados. Esta hoja heredada se detecta en virtud de la ausencia de una comunidad EVPN-MF en una ruta de tipo 3 BGP.

El dispositivo de entrada, cuando aprenda de los dispositivos de hoja del tipo 3, comprobará esta comunidad. Si la entrada detecta que el EVPN-MF no está presente, la entrada deducirá que se trata de un dispositivo heredado. En función de esto, la entrada siempre inundará el tráfico hacia este dispositivo heredado.

En el Figure 10, para G1, Leaf-1 tendrá en su aceite, Leaf-2, Leaf-4, BLS y Leaf-5. Otras hojas que’no dispongan de oyentes no serán parte del aceite.

Forwarding Prefix for L3-PIM and Legacy Devices to Flood Traffic

Para lograr la inundación del tráfico en los casos especiales descritos anteriormente, donde el PEs de salida desea atraer tráfico for_todos los grupos, se instala una ruta predefinida por el prefijo de multidifusión del 224/4 con su aceite, que contiene L3-PIM y dispositivos heredados . Esto hará que el tráfico de flujos que’no dispongan de una entrada de ruta específica instalada (por ejemplo, 235.1.1.1) afecte a este prefijo 224/4 y llegue a los dispositivos L3-PIM. Si hubiera oyentes existentes para 235.1.1.1 del grupo, el aceite de 235.1.1.1 incluirá los dispositivos L3-PIM y heredados .

Flood 224/24 Groups (for example, OSPF/LDP Hellos) Everywhere

Consideremos los grupos de multidifusión especiales conocidos, como 224.0.0.5, 224.0.0.13. Estos son grupos de multidifusión de buena conocida para distintos propósitos, por ejemplo, 224.0.0.5 es un grupo de multidifusión usado para OSPF Hola, 224.0.0.13 para los Hola a PIM. Estos grupos conocidos se especifican en un rango de 224.0.0.0/24 (224.0.0.1 a 224.0.0.255).

El tráfico destinado a tales grupos debe estar inundado en cualquier parte porque los dispositivos hoja no tienen como origen el tipo 6 para dichos grupos. Por ejemplo, puede haber dispositivos de OSPF L3 detrás de hoja-1 y hoja-2. Los dispositivos OSPF deben descubrirse mutuamente mediante los saludos. Estos mensajes de saludo deben reenviarse unos a otros por las hojas. Por lo tanto, el PE de entrada instala en el siguiente salto un PEs de 224.0.0.0/24 de reenvío específico, que en el tejido. Esto ocurre sin necesidad de configuración alguna.

Flood User-configured Groups Everywhere

Puede haber escenarios en los que el operador desee que algunos grupos de multidifusión se inunden en todo el infrarrojos respectivo de la presencia de los oyentes. Estos grupos no pueden estar en el rango 224/24. Supongamos que existe un 230.1.1.1 de grupo para el cual el operador quiere que el tráfico se inunde en cualquier parte. Esto se puede lograr con una configuración en la entrada. La configuración contendrá una lista de los grupos a los que se debe inundar el tráfico. Cuando el tráfico llega para 230.1.1.1, independientemente de que los oyentes estén en el centro de acceso o de Access, el tráfico se inunda en todo el mundo.

Reglas para el reenvío selectivo de multidifusión

Por lo tanto, las reglas de reenvío selectivo de multidifusión para el tráfico destinado al grupo G1 se mejoran de la siguiente manera:

L2-reenvía el tráfico de multidifusión para el grupo G1 hacia aquellos PE EVPN que han originado una BGP ruta SMET tipo 6 para ese grupo G1.
L2-reenvía el tráfico de multidifusión para el grupo G1 hacia los dispositivos spine L3 con el propósito de la multidifusión entre subredes y el registro de la fuente de multidifusión con PIM-RP.
L2-reenvía el tráfico de multidifusión para el grupo G1 hacia los dispositivos de hojas heredados que no están habilitados con supervisión IGMP o que no admiten BGP origen de ruta de tipo 6 SMET.
L2-reenvía el tráfico de multidifusión para el grupo en el rango 224.0.0/24, a todos los EVPN PEs de la estructura.
L2-reenvía el tráfico de multidifusión para los grupos configurados por el usuario a todos los EVPN PE de la estructura.

Resumen del capítulo

Este capítulo exploró la multidifusión optimizada con el reenvío de IGMP y selectivo (SMET). En las implementaciones multidifusión de gran escala con un alto volumen de tráfico, estas optimizaciones desempeñan un papel fundamental en la conservación de la banda ancha tanto en el núcleo como en el acceso, y también en la carga de procesamiento de paquetes y replicación en los dispositivos EVPN participantes.

También exploró distintos procedimientos de señalización con SMET rutas del tipo 6 y cómo se consigue la interoperabilidad con dispositivos heredados. Examinamos los distintos valores atípicos que un dispositivo EVPN toma en cuenta al crear la lista de PEs, por lo tanto, los dispositivos L3-PIM, los dispositivos heredados, etc., y también las reglas de reenvío especiales necesarias para las direcciones de multidifusión local de vínculo 224/4.

SMET el reenvío está habilitado cuando la supervisión de IGMP está habilitada. Puede ser debido a que algunos grupos se tienen que inundar en todo el mundo. Esto se puede lograr mediante una configuración en la que el operador pueda seleccionar las direcciones de grupo en las que se debe inundar el tráfico.

En EVPN Intra-Multicast Optimization with Multihoming un capítulo de multitarjeta, exploraremos el reenvío de multidifusión optimizado en multihomedscenarios..

Automática

La topología de referencia se muestra en Figure 11la.

Habiendo revisado la optimización del tráfico intravlan de multidifusión para’EVPN, deje que lo vea en acción activando el reenvío de IGMP (Smet) o de supervisión selectiva, y observando cómo se optimiza el reenvío de tráfico.

Configurar IGMP: supervisión

Active la supervisión IGMP en el PEs EVPN. Al activar la supervisión IGMP en el nivel de BD/VLAN, también se activa el reenvío selectivo (SMET) de origen de ruta de SMET tipo 6.

Configure VLAN-101 en LEAF-5. Sin embargo, dado que queremos que hoja-5 simule un dispositivo heredado que no sea compatible con la supervisión IGMP, no activamos la supervisión IGMP en ninguna de las VLAN de la hoja 5.

Antes de comenzar, detenga el tráfico y los receptores en RT, y cargue los siguientes fragmentos de configuración en los siguientes dispositivos:

HOJA-1, HOJA-2, HOJA-3, HOJA-4:

BL-1, BL-2:

Configurar VLAN-101 en hoja-5

Cargue estos fragmentos de configuración en la hoja 5:

Verificación del tráfico

Desde host 1, empiece a enviar tráfico de multidifusión a 10 PPS para el grupo 225.1.1.1 en VLAN-101.

En host-6 de una sola red de alojamiento en hoja-4, inicie un receptor para el grupo de multidifusión 225.1.1.1 en VLAN-101.

Traffic Statistics on Router Tester

A partir de las estadísticas Figure 12de RT en, puede ver que el tráfico enviado por host-1 en 10 PPS lo recibe ahora el receptor interesado, host 6, y el dispositivo heredado, host-7, en VLAN-101.

Multicast Traffic Outputs - LEAF-1

Como hacía anteriormente, el tráfico de multidifusión de carga equilibrada llega a la interfaz de acceso ae0 en LEAF-1. Sin embargo, el tráfico de multidifusión que llega a la hoja 1 ya no se reenvía a ninguna de las interfaces de acceso de hoja-1, ya que no hay receptores, lo que evita los residuos de ancho de banda de la parte de acceso:

El tráfico de multidifusión se reenvía al VTEPs hacia los PEs (101.101.101.101 y 102.102.102.102) y LEAF-5 (109.109.109.109) de los hojas de borde.

El tráfico también se envía en el VTEP hacia hoja-4 (108.108.108.108) que tiene un receptor interesado.

HOJA-2 (106.106.106.106) y hoja-3 (107.107.107.107) que no tienen ningún destinatario interesado quedan libres de tráfico:

Multicast Traffic Outputs - LEAF-4

La funcionalidad de supervisión IGMP de acceso garantiza que el tráfico de multidifusión que llega a la hoja 4 se reenvía a la interfaz de host único, XE-0/0/3.0, que ahora tiene un receptor, pero que no se reenvía en la interfaz multitarjeta AE 0.0 que no tiene un receptor:

Multicast Traffic Outputs - LEAF-5

A partir de la hoja 5 un dispositivo heredado y configurado con VLAN-101, ahora recibe el tráfico y lo inunda en su interfaz de acceso, XE-0/0/2,0, aunque no tiene un receptor:

Multicast Traffic Outputs – BL-1 and BL-2

De nuevo, pasaremos por alto el comportamiento de enrutamiento de tráfico en estos dispositivos hasta que EVPN el capítulo EVPN Intra-VLAN Multicast Without Optimization .

Verificación detallada del plano de control

Verification of Base EVPN IGMP Snooping State

Compruebe que la supervisión IGMP esté habilitada en VLAN-101 en todos los PEs EVPN, excepto hoja-5:

Las salidas similares se pueden ver en hoja-2, hoja-3, hoja-4, BL-1 y BL-2.

Ahora vamos’a comprobar que la ruta de tipo 3 que se anuncia por la función hoja normal EVPN PES (hoja de valor 1 a hoja-4) ahora transporta la comunidad de marcas de multidifusión a la Community “con el conjunto” de bits de compatibilidad con proxy IGMP:

Compruebe que la hoja 5 del servidor habilitado para la supervisión no IGMP sigue anunciando rutas de tipo 3 sin la comunidad de marcas de multidifusión “o con el” bit de compatibilidad del proxy IGMP en la comunidad de marcas de multidifusión:

Verifique que la hoja de borde EVPN PEs (BL-1 y BL-2) habilitados con IGMP-Snoop y L3-multicast (PIM), publicidad de tipo 3 sin la comunidad de marcas de multidifusión o con “la compatibilidad con” proxy IGMP bit de soporte en la comunidad de etiquetas de multidifusión:

Compruebe que el PEs de la hoja habilitada para supervisión ha programado su tabla de reenvío de multidifusión de modo que todo el tráfico de multidifusión múltiple desconocido se envíe hacia el PES de hoja de borde y hacia el PEs habilitado para la supervisión no IGMP:

Verification of EVPN IGMP Proxy State with Remote Receivers

Compruebe que en hoja 4, la pertenencia al grupo IGMP se ha aprendido en la interfaz VLAN-101 xe-0/0/3.0 mediante la supervisión de los informes IGMP:

Compruebe que hoja-4, tras haber aprendido la pertenencia IGMP local para el grupo 225.1.1.1, que crea el estado local de proxy IGMP EVPN y que se origina en las rutas del proxy IGMP de tipo 6 para notificar el interés remoto de PEs a la recepción de tráfico de multidifusión para el Grupo:

Compruebe que todos los procesos remotos de PEs de EVPN tienen el tipo 6 y descubra que LEAF-4 es un receptor de EVPN remoto interesado para el Grupo:

Comprobación del estado de reenvío de multidifusión con el receptor remoto

Compruebe que el estado de reenvío de multidifusión creado para el grupo 225.1.1.1 en hoja-4 incluye la interfaz de host único que interesa xe-0/0/3.0:

Compruebe que en todos los demás PEs, LEAF-4 (vtep. 32771) se haya agregado al próximo salto de EVPN principal para el grupo 225.1.1.1. Tenga en cuenta que, además, también estará presente BL-1 (vtep. 32770), BL-2 (vtep. 32774) y hoja-5 (vtep. 32773) en EVPN siguiente salto principal para el Grupo:

Compruebe que el estado de reenvío de multidifusión creado para el grupo 225.1.1.1 incluye el siguiente salto de EVPN principal mostrado anteriormente:

ON THIS PAGE