Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

EVPN optimización de intradifusión con host múltiple

 

La optimización de multidifusión en EVPN ofrece varias ventajas en cuanto a la conservación del ancho de banda y la reducción de la carga de procesamiento/replicación en los dispositivos de hoja. En virtud de la seguimiento del estado de Unión IGMP en las interfaces de Access (creadas a partir de informes IGMP) y en el núcleo de EVPN (creado a partir de BGP remoto tipo-6 SMET rutas), el dispositivo EVPN reenvía selectivamente el tráfico de multidifusión únicamente a las interfaces/PEs que tienen un agente de escucha detrás de él.

Este seguimiento del estado y el reenvío, basado en informes y SMET, muestra un escenario con un host múltiple en el que se requieren procedimientos adicionales para sincronizar el estado entre los dispositivos EVPN de host múltiple. En este capítulo se describen los retos que surgen al activar la supervisión IGMP con EVPN multitarjeta y se describen los procedimientos que abordan esos desafíos.

EVPN multitarjeta de host con IGMP: la supervisión

’Primero, es conveniente Figure 1considerar, donde hoja-3, hoja-4 y hoja-5 son multitarjeta en una ESI.

’Supongamos que hoja-4 es DF, y que hoja 3 y hoja-5 no son DFs. Los PEs de base único son los de hoja 2 y hoja-6.

Figure 1: IGMP: supervisión con escenario de host múltiple
IGMP: supervisión con escenario de host múltiple

Para describir el problema, deje’que hoja-1 sea la entrada y realice un reenvío inclusivo (IMET), por lo que hoja-1 inunda el tráfico al núcleo en lugar de un reenvío selectivo basándose en las rutas de Smet tipo 6.

Supongamos que el host 5 es un host IGMP interesado en el tráfico del grupo G y, por lo tanto, envía informes IGMP (*, G). El CE de host múltiple de las tres hojas sobre un lote de interfaz agregada (AE) puede enviar el informe a cualquiera de las hojas multitarjeta. Esto es debido al hash que el CE realiza en el paquete basándose en la tupla, compuesta de IP de origen, IP de destino, MAC de origen, etc. Bien,’Supongamos que CE envía el informe IGMP (*, G) a hoja-3.

Al recibir el informe (*, G), hoja-3 crea un estado IGMP para (*, G), de modo que si el tráfico de G llega desde el núcleo o desde otras interfaces de acceso, reenviará el tráfico al CE y, por lo tanto, a host 5. Sin embargo, LEAF-3 no es DF por EVPN de los procedimientos de multitarjeta de nuestro ejemplo. Dado que el informe no llegó al nodo hoja 4 o al de hoja 5, no crearán Estados IGMP para (*, G).

Cuando LEAF-1 comienza a enviar tráfico para el grupo G utilizando el reenvío inclusivo, todas las hojas multitarjeta recibirán el tráfico del núcleo. Gracias a las reglas (clásica-DF-NDF) , sólo el DF reenvía el tráfico a la interfaz de acceso. En este caso, LEAF-4 es el DF.

Sin embargo, como la hoja 4 no tiene el estado IGMP para (*, G), LEAF-4 no lo reenvía. La hoja 3, aunque tiene el estado IGMP para (*, G), no reenvía el tráfico, ya que no se trata del vínculo de host múltiple. LEAF-5, no tiene un estado IGMP, como también lo es un NDF.

Por lo tanto, acabamos en una situación en la que ninguno de los PEs múltiple avanza el tráfico hacia el host 5, lo cual es claramente indeseable.

Si, en algunos grupos, en virtud de la tupla de hash de CE, algunos informes IGMP alcanzaron la hoja 4, el DF, hoja-4 creará un estado (*, G), y cuando el tráfico llega del núcleo, hoja-4, el DF, reenviará el tráfico a los CE y a la recepción-1. Esto puede tener un estado estable.

Sin embargo, sigue habiendo un problema. Si hoja-4 se interrumpe o la interfaz de host múltiple en hoja-4 deja de funcionar, es posible que hoja-3 se haya elegido como DF. Puesto que hoja-3 no tiene un estado IGMP (*, G), no reenviará el tráfico. La actualización del informe se puede enviar a hoja-5, sin DF, y es posible que acabemos en el mismo estado que tenía anteriormente.

Problema de multihost con el reenvío selectivo

El problema con el reenvío inclusivo es que cuando el tráfico del núcleo EVPN llega a todos los equipos de host múltiple, no se reenvía al receptor porque la hoja-3 que tiene el estado IGMP es distinto de DF y la hoja 4, que es el DF, no tiene el estado IGMP. Volvamos’a la Figure 2revisión.

Figure 2: IGMP: supervisión con escenario de host múltiple con el reenvío selectivo
IGMP: supervisión con escenario de host múltiple con el reenvío selectivo

Esto también es un problema con el reenvío selectivo. Si LEAF-3 y LEAF-6 originaron el BGP tipo-6 SMET ruta para reflejar el estado que aprendió en el acceso, LEAF-1 reenviará el tráfico de multidifusión solo a hoja-3 y hoja-6. En este caso, hoja-3, aunque tiene el estado IGMP para el grupo, no reenvía el tráfico al receptor porque es un non-DF.

Con el reenvío inclusivo y sin la supervisión IGMP (es decir, los procedimientos de inundación BUM), esto no constituye un problema, ya que el tráfico estará inundado por LEAF-1 y llegará a todos los dispositivos de salida de hojas. La hoja que es el DF reenviará el tráfico al host.

Dado que el reenvío de IGMP y selectivo (Smet) mitiga el ‘’problemade las situaciones de inundaciones, merece la pena si abordaremos esta situación en particular debido a la supervisión de IGMP y a los hosts de EVPN en las siguientes secciones de EVPN tipos de ruta que pueden ayudarlo a resolver este problema.

Ruta BGP Type-7 join-sincronizar para sincronizar el estado IGMP en los PEs de multitarjeta

Para tratar el problema que se describe aquí, es necesario que el estado IGMP del grupo G se sincronice entre el PEs de host múltiple. Si el estado de IGMP está sincronizado entre los PEs de host múltiple, el DF tendrá el estado (*, G) y, por lo tanto, reenviará el tráfico hacia los receptores.

El estado IGMP de un grupo determinado, aprendido a través de una interfaz ESI, está sincronizado con otros colegas de la MH que alojan la misma ESI en virtud de BGP ruta de sincronización de combinación de tipo 7. Basándose en este intercambio, el EVPN de host múltiple PE puede sincronizar el estado IGMP e instalar el estado de reenvío para el grupo. De este modo, cualquiera de los PEs de host múltiple relevantes estará en posición de reenviar el tráfico de ser elegido como el DF para esa ESI.

Figure 3: Procedimientos de plano de control de rutas BGP de sincronización de la combinación IGMP de tipo 7
Procedimientos de plano de control de rutas BGP de sincronización de la combinación IGMP de tipo 7

En Figure 3, el informe de IGMP ha alcanzado el hoja-3. Como parte del suceso-[1], hoja-3 origina un BGP tipo-7 con la VLAN, grupo y la información de la ESI. Esta ruta de tipo 7 es importada únicamente por hoja de 4 y hoja-5, ya que estas hojas hospedan la ESI. Otras hojas no importan esta ruta de tipo 7.

Cuando hojas-4 y hoja-5 reciben esta ruta de tipo 7, crean un estado IGMP para ese grupo en particular con la interfaz de salida como la interfaz ESI de host múltiple (evento-[2]). De este modo, el estado IGMP del grupo G se sincroniza entre el PEs de host múltiple.

En virtud del estado IGMP aprendido para la VLAN, los procedimientos descritos en el capítulo EVPN Intra-VLAN Multicast with Optimization tendrán como resultado que los PES de host múltiple originen rutas de tipo 6 para el grupo/VLAN. (evento-[3]).

EVPN Type-7 NLRI Route

La ruta de tipo 7 consta de una diferenciadora de ruta, VLAN, grupo de multidifusión y fuente, ESI y una IP de origen. La ruta también incluye el valor ESI en una comunidad extendida. Esto ayuda a garantizar que solo los PEs que hospedan la ESI importen esta ruta de tipo 7.

La ruta de tipo 7 también transporta una comunidad denominada EVI-COM. Esta comunidad identifica la instancia de EVPN en la que se debe sincronizar el estado IGMP. El destino de ruta típico que se agrega en las rutas de tipo 2 y tipo 6 no se agrega porque queremos que las rutas de tipo 7 se importen solo en aquellos PEs que hospeden la ESI concreta en cuestión.

Figure 4: Encabezado de ruta de tipo 7
Encabezado de ruta de tipo 7

Tracking of Type-7 Routes from Peers

Un EVPN PE crea un estado local de IGMP basado en el informe IGMP entrante en una ESI determinada. Puede ser que haya varios hosts detrás de la misma ESI que envía informes para un grupo. Puede ser que los informes se desembarquen en distintos interlocutores de host múltiple. En este caso, el PEs que recibió el informe IGMP de la interfaz ESI del lado del acceso es de tipo 7.

Cuando se produce un tiempo de espera de estado IGMP en una hoja, no debe eliminar el estado inmediatamente. En su lugar, debe comprobar si hay otras rutas remotas de tipo 7 anunciadas para las mismas VLAN/Group/ESI/EVI. Si es así, se retira el tipo original 7, pero se conserva el estado IGMP.

Type-7 Withdraw Semantics

Se retira una ruta de tipo 7 cuando se agota el tiempo de espera del estado IGMP (hosts Haven’t actualizado el estado en la ESI). Un dispositivo hoja, al recibir el retirado del tipo 7, debe tener cuidado a la hora de borrar el estado. Este retirado del tipo 7 puede deberse a que el enlace de la ESI está fuera de funcionamiento o a que el nodo originador no funciona. El PE receptor tiene que confirmar que es realmente un tiempo de espera de estado y, a continuación, proceder a borrar el estado o que se producirán caídas del tráfico.

De tipo no DF a origen-6 ruta de SMET para una mejor convergencia

Normalmente, al recibir este tipo-Route, solo el DF necesita originar el tipo 6, ya que se supone que debe extraer el tráfico del núcleo y reenviar el tráfico a Access. Sin embargo, si se produce un error en el nodo DF o se produce un error en el vínculo ESI del DF, debe ser elegido el nuevo DF y, a continuación, debe originar la ruta SMET Type-6. Además, la entrada tiene que incluir el nuevo DF en su lista de PE saliente. Esto puede producir una latencia considerable, ya que implica BGP el intercambio de mensajes.

Esto se puede mitigar si los PEs no pertenecientes al DF también originan el tipo de ruta SMET, de modo que extraerán el tráfico de la entrada en estado continuo, pero no lo reenvíen en virtud de ser distinto de DF. Más tarde, cuando se produzca un error en el DF, el nuevo DF, una vez elegido, tendrá el tráfico que llega al núcleo. Por lo tanto, todo lo que necesita hacer el nuevo DF es reenviar el tráfico a Access. Esto da como resultado una ganancia considerable de convergencia.

Figure 5: Procedimientos de plano de control de rutas de sincronización BGP de la combinación IGMP de tipo 7 para una mejor convergencia
Procedimientos de plano de control de rutas de sincronización BGP de la combinación IGMP de tipo 7 para una mejor convergencia

En Figure 5, todos los PE – de host múltiple-3, hoja-4 y hoja 5 – se originan de tipo 6 Smet rutas para el grupo. Esto da como resultado hoja-1, incluidos todos los PE de host múltiple en su lista. Por lo tanto, los PEs no DF reciben tráfico, pero no lo reenvían en la interfaz ESI, pero están listos para reanudar el reenvío tan pronto como se vayan volteando a DF.

Resumen: la sincronización de la Unión IGMP y el reenvío de multidifusión

Con este esquema, con independencia de dónde llegue el informe a un segmento multitarjeta, todos los PEs de host múltiple de la ESI tienen el estado IGMP para el grupo G y están listos para reenviarse solamente con DF PE reenviando el tráfico hacia el receptor. La ruta de tipo 7 lleva información de modo que el PE receptor pueda crear el estado de IGMP adecuado exactamente para las VLAN, EVI y ESI relevantes.

Figure 6: Reenvío de tráfico basado en sincronización de estado IGMP
Reenvío de tráfico basado en sincronización de estado IGMP

Todos los PE de host múltiple de una ESI tienen el estado IGMP para el grupo G. Como mínimo, DF-PE para la ESI origina las rutas del tipo 6, pero para garantizar una mejor convergencia, el que no DF PEs también origina el tráfico de extracción y de tipo 6. Cuando el tráfico llega al núcleo, DF PE, ya que tiene sincronizado el estado IGMP con BGP rutas de sincronización de combinación de tipo 7, se reenvía el tráfico a la interfaz de Access ESI.

Además, el seguimiento del tipo de 7s del mismo nivel es imperativo para que el estado sincronizado de IGMP sea coherente. La retirada de una ruta de tipo 7 se debe controlar cuidadosamente para determinar la causa de la retirada y, a continuación, continuar con la limpieza/retención del estado IGMP.

Problema con IGMPv2 Leave

En secciones anteriores, se describía cómo el estado de informe IGMP (*, G) está sincronizado entre el PEs de host múltiple. En esta sección se describe un problema por el que el control de un mensaje de abandono de IGMP en un escenario multitarjeta requiere una consideración especial.

Introducción a IGMP de baja

Igual que se utiliza un mensaje de informe IGMP para (*, G) para transmitir el interés de la escucha para un grupo en particular G, el mensaje de salida IGMP se utiliza para transmitir la retirada del interés del agente de escucha para el grupo por el host.

Cuando un conmutador recibe un mensaje de salida IGMP, es necesario borrar el estado IGMP (*, G) que se utiliza para reenviar tal que ya no se envía tráfico a los receptores. Antes de borrar el estado, es necesario que el conmutador garantice que no hay otros host interesados en el grupo.

Para lograr este fin, el conmutador envía una consulta de último miembro (LMQ) para que el grupo G solicite cualquier informe de otros hosts interesados. Si el conmutador no recibe ningún informe del grupo G hasta un periodo de tiempo determinado, LMQ intervalo, el conmutador borra el estado de (*, G). Si cualquier otro host envía un informe antes del intervalo, el estado se conserva.

¿Qué es la latencia de salida?

Las aplicaciones de multidifusión son muy sensibles al tráfico no deseado. Por ejemplo, un host IPTV puede desear el canal 1 mediante el envío de un informe IGMP para el grupo G1 y puede estar recibiendo tráfico. Supongamos que el ancho de banda de la interfaz de acceso incluye el tráfico de un canal. Cuando el usuario cambie al canal-2, el host retiraría el interés por el canal 1 mediante el envío de la baja del grupo G1 y el envío de un informe IGMP al grupo G2.

El modificador debe procesar el mensaje Leave para G1, comprobar si existen otros oyentes y, si no hay otras escuchas, borrar el estado de G1 y detener el reenvío a G1. Poco después, cuando el conmutador recibe el informe IGMP para el grupo G2, debe crear el estado para (*, G2) e iniciar el reenvío del tráfico de G2.

Si por alguna razón el conmutador tarda más tiempo en borrar el estado de G1, pero crea para G2 y reenvía tráfico para ambos grupos, es posible que el ancho de banda aprovisionado no sea suficiente para transportar ambos canales y puede causar distorsiones en el host IPTV. También puede ser que el host no sea capaz de controlar el tráfico de dos grupos.

En general, es imprescindible que el conmutador reaccione lo suficiente para recibir un mensaje Leave, la diligencia debida en LMQ y borra el estado si no existen oyentes. Este retraso en el estado de borrado se denomina latencia de salida y es un factor importante a tener en cuenta en las aplicaciones IPTV y cotización de bolsa.

Si un mensaje de abandonar ‘se pierde en’ el cable o no se procesa, el tráfico se reenviará al agente de escucha. El conmutador, si no recibe los informes IGMP periódicamente, diga cada 60 segundos, borrará el estado después del intervalo de tiempo de espera de IGMP, por ejemplo, después de 210 segundos.

Por lo tanto, si un mensaje de salida se pierde o no se controla, el tráfico seguirá fluyendo hasta que se produzca la espera IGMP. La latencia de salida se considera más detenidamente que la velocidad de aprendizaje IGMP debida a la sensibilidad de los hosts IPTV.

Una característica sutil del IGMPv2 dejar el mensaje

Los mensajes de informe IGMP tienen una IP de origen como origen del host y el campo IP de destino como dirección del grupo de multidifusión G en la que está interesado el host.

Sin embargo, un mensaje de abandono de IGMP tiene un campo IP de destino como 224.0.0.2 y el grupo que se desea retirar está presente dentro de la carga del mensaje Leave. Históricamente, la razón lo ha sido el caso con IGMPv2. Dado que los hosts de IGMPv2 están muy extendidos y han estado funcionando bien, han permanecido de esta manera.

Why is This Relevant to Optimized Multicast with Multihoming?

Como se explicó anteriormente, CE aplicará el algoritmo hash a los paquetes entrantes según la dirección IP de origen, el IP de destino, el origen, el código Mac, etc. Dado que las direcciones del campo IP de destino del informe no son las mismas que las del mensaje de salida, esto ocurre cuando el informe se envía a un EVPN PE multitarjeta, pero el mensaje Leave se envía a otro PE EVPN multitarjeta.

IGMPv3

En la sección siguiente, describimos el desafío que surge debido a que el mensaje Leave IGMPv2 con la dirección de destino 224.0.0.2. IGMPv3 es inmune a este desafío porque el informe IGMPv3 y IGMPv3 dejan mensajes en la carga, y la dirección de destino tanto del informe como del mensaje Leave es 224.0.0.22. En breve, entenderá por qué es relevante esta diferencia.

How Does This Cause a Problem in a Multihoming Scenario?

En Figure 7, es posible que se envíe el informe IGMP a hoja-3. Más adelante, cuando el host 5 no está interesado en el tráfico del grupo G, lo envía para (*, G). Esta salida IGMP para el mismo grupo se puede enviar a hoja 5 porque el campo de dirección IP de destino de Leave es 224.0.0.2, mientras que el informe IGMP es el propio grupo. Esto se debe a que CE incluye la dirección IP de destino del paquete para calcular la tupla de hash.

Figure 7: Problema con IGMPv2 Leave en un escenario de multitarjeta
Problema con IGMPv2 Leave en un escenario de multitarjeta

Veamos’esto con más detalle. En Figure 7, hoja-3 recibió el informe IGMP en la interfaz de acceso, creó el estado IGMP (*, G) (aprendido localmente) y originó una ruta de tipo 7. HOJA 4 y hoja-5 importaron el tipo-7 y creamos un estado IGMP (*, G) (conocido de forma remota). Hasta ahora tan bueno.

Considere el escenario en el que el mensaje Leave llega a hoja-5. ¿Cuál es el comportamiento esperado en este caso? Debe enviarse un LMQ hacia CE para solicitar informes y si no llegan informes antes de un intervalo determinado, el estado debe borrarse de todos los PEs, especialmente de DF, para que el reenvío de tráfico se detenga para el grupo G.

¿Cuáles son nuestras opciones? Si dejamos que las reglas de procesamiento de IGMP existentes por separado, Kick-5, al salir de la audición, enviará una LMQ. ¿Qué ocurre si ya no hay ningún host interesado? HOJA 3, en la que el informe inicialmente desembarcado no ha oído hablar de la baja. Por lo tanto, hoja-3 no borrará el estado durante unos 210 segundos y el tipo-7 seguirá anunciado durante ese tiempo.

La hoja 5 estará en un flujo en el que se ha recibido un mensaje Leave, pero también tiene un estado aprendido de forma remota. HOJA-5 no puede retirar un tipo-7 dado que no era el originador de la ruta del tipo 7 en primer lugar, por lo que el problema obtiene más implicada. HOJA: 5 conserva el estado, ya que hay un tipo remoto de-7 a partir de la hoja 3. HOJA 4, y DF conservará el estado traducido de IGMP (*, G) y conservará el reenvío durante 210 segundos.

En general, incluso si el host envió un permiso y llegó de hecho al conjunto de PE multitarjeta, la latencia de dejar sigue siendo 210 segundos. Esto es claramente indeseable, no obstante, son características de hosts y optimización.

Se complica cuando otro host envía un informe antes de que el LMQ y este informe aterrizan en otro PE, por ejemplo, LEAF-4. Ahora, la hoja 3 y la hoja 4 tienen Estados aprendidos localmente, mientras que hoja 5 tiene un estado aprendido remotamente y un permiso para controlar. En este escenario, los Estados tienen que conciliar de tal forma que el estado de IGMP (*, G) se mantenga en todos los PEs.

Por lo tanto, es imprescindible abordar este escenario de control de permisión tanto como una sincronización de Unión IGMP. Es difícil resolver este problema confiando en los procedimientos de tratamiento de IGMP existentes de forma independiente, ya que es necesario sincronizar la salida. Además, aunque IGMP join (*, G) es un estado que se puede traducir en BGP rutas e intercambiar, el mensaje Leave es, en realidad, un evento y no un estado.

Con Leave messages, se borra el estado aprendido anteriormente. Por lo tanto, aparece como un evento para la hoja en la que se obtuvo una baja. Tradicionalmente BGP notifica a la adición, eliminación o actualización de una comunidad autónoma. Este mensaje de salida tiene como resultado la retirada de BGP ruta y el estado, pero el hecho de que el abandono llegue al no originador del estado hace que sea difícil transmitir la retirada del estado.

Este evento también debe transmitirse entre los PEs de host múltiple, de modo que estén sincronizados con la última actividad de la interfaz de Access ESI del grupo para garantizar que la latencia de la salida se encuentre dentro de los límites aceptables. Las distintas combinaciones también tienen que funcionar sin latencia de salida mucho, lo más habitual (i) una combinación IGMP seguida de Leave, o (II), una combinación seguida por Leave y seguida por otra combinación, etc.

Este problema se soluciona mediante la introducción de otro ruta BGP denominada ruta de permiso de salida de 8 bits de modo que el PEs multitarjeta esté sincronizado entre sí sobre el estado del grupo (*, G).

Ruta BGP tipo 8 de la sincronización de Leave para conciliar el estado IGMP

Para tratar el problema descrito en la sección anterior, examinemos’el enfoque. El objetivo de la solución es el siguiente:

  • Cuando se recibe una combinación de Access, el estado de unión de IGMP debe sincronizarse entre todos los PEs de host múltiple.

  • Cuando se recibe una baja del acceso en una instalación de host múltiple, el temporizador de LMQ debe iniciarse en todos los interlocutores multitarjeta y el DF debe enviar el LMQ en el acceso.

  • Si no se recibe ninguna combinación hasta que expire el temporizador de LMQ, el estado de IGMP debe eliminarse en todos los equipos de host múltiple.

  • Si se recibe una Unión IGMP de invalidación antes de que caduque el temporizador de LMQ, el estado de IGMP debe conservarse en todos los equipos de host múltiple.

En Figure 8, se recibió una Unión en el acceso desde host-5 en hoja-3 y el estado se sincronizó entre los interlocutores multitarjeta que utilizaban una ruta de sincronización de combinación de tipo 7. Ahora, deje’que diga, host 5 envía una salida IGMP y esta salida IGMP llega a hoja-5 (evento: [1]).

Figure 8: Ruta de permiso de sincronización del tipo 8 de BGP
Ruta de permiso de sincronización del tipo 8 de BGP

Al recibir un permiso, LEAF-5 origina una ruta Type-8 (Event-[2]) que tiene los mismos campos NLRI que un tipo-7 (VLAN, ESI, grupo, source, IP de origen, etc.). El desencadenador para el origen de tipo 8 es un mensaje Leave, pero no hay ningún desencadenador para la retirada de esta ruta. Por lo tanto, hoja 5 ‘inicia un temporizador’ Leave-sent para retirar la ruta una vez que se sirve su propósito de la permisión de la sincronización Leave.

Otros interlocutores de host múltiple, hoja 3 y hoja-4, reciben el tipo 8. En función de esto, todos los PEs de host múltiple buscan enviar el LMQ Send e iniciar el temporizador LMQ. Dado que este LMQ es un mensaje de multidifusión, solo el DF enviará el LMQ en la ESI. (evento-[3]).

En este temporizador LMQ pueden producirse dos eventos.

  • Evento-A: No se recibieron uniones en la LAN para este grupo antes de que LMQ expire.

  • Evento-B: Unión recibida en la LAN para este grupo antes de que LMQ expire.

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

En Figure 9, después de enviar LMQ e iniciar el temporizador de LMQ, los interlocutores de host múltiple esperan a ver si se actualiza algún informe IGMP para ese grupo. Si no se recibe ningún informe y el temporizador de LMQ caduca (evento: [1]).

Figure 9: Evento A: No se recibieron uniones en la LAN en respuesta a LMQ
Evento A: No se recibieron uniones en la LAN en respuesta a LMQ

En Figure 9, el originador del tipo-7 retira su ruta de tipo 7 (Event-[2]). En la retirada de ruta remota de tipo 7, los interlocutores multitarjeta eliminan el estado IGMP, por lo que se detiene el reenvío del tráfico al acceso. (evento-[3]).

Según el estado local que se va de la ubicación, si no hay ninguna otra interfaz de acceso interesada en la VLAN de ese grupo, los dispositivos de host múltiple retirarán su ruta de tipo 6 originada anteriormente. (evento-[4]).

Con el tipo 8 de la ruta, los Estados se borran y hoja 5 retira su ruta de tipo 8 (evento-[5]) para evitar cualquier permanencia obsoleta de tipo-8, con lo que se borran todos los Estados de ese flujo.

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

En Figure 10, después de enviar LMQ e iniciar el temporizador de LMQ, los interlocutores de host múltiple esperan algún tiempo para ver si se actualiza algún informe IGMP para ese grupo. Supongamos que, antes de que el temporizador LMQ caduque, otro host envía un informe IGMP en la LAN. Este informe puede llegar al remitente anterior de tipo-7, hoja-3 o en un nuevo originador, por ejemplo, LEAF-4.

Figure 10: Evento B: Unión recibida en la LAN antes de que LMQ expire
Evento B: Unión recibida en la LAN antes de que LMQ expire

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

La hoja 3, al recibir el informe actualizado de Access, detiene su temporizador LMQ. _Not retira su ruta de tipo 7. Posteriormente, en otros homólogos multitarjeta, cuando el temporizador LMQ caduca, comprobar si hay un tipo remoto-7 para el grupo. Dado que hay un tipo remoto-7 para el grupo, los elementos de mismo nivel de hosts múltiples conservarán el estado IGMP y continuarán reenviando el tráfico.

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

Al recibir el informe actualizado de Access, LEAF-4 detiene su temporizador LMQ. También origina su ruta de tipo 7, que se sincroniza con otros interlocutores de host múltiple. ’Una vez recibida la ruta de tipo 7 remota, otros interlocutores de hosts múltiples lo importan a su tabla.

Cuando LMQ caduca (ya que no se actualizó su informe), se retira el tipo original-7 de la hoja-3. Sin embargo, dado que existe al menos otro tipo remoto (7) (de hoja 4), hoja-3 conserva el estado IGMP.

Y en hoja-5, cuando LMQ caduca, existe al menos un tipo remoto de 7 (de hoja-4). De modo que hoja-5 también conserva el estado IGMP.

Todo junto para optimizar la multidifusión

Figure 11repite nuestra topología original para devolver la imagen global. Host-3 y host 5, los hosts multitarjeta, están interesados en el tráfico. Los dispositivos hoja multitarjeta sincronizan el estado de IGMP y garantizan que se produzca el reenvío correcto. En la sección comprobación del tráfico de este capítulo se muestra este escenario de forma detallada.

Figure 11: Reenvío de multidifusión optimizado
Reenvío de multidifusión optimizado

Resumen del capítulo

Este capítulo exploró los matices asociados con la optimización de la multidifusión en topologías de hosts múltiples. Para lograr esto, detallando cómo se sincronizan los informes IGMP recibidos en un vínculo de ESI entre los interlocutores multitarjeta que hospedan la ESI. También examinó el origen de la ruta de tipo 6 por parte de los interlocutores multitarjeta con fines de convergencia.

Además de interés fue el desafío que surge en virtud de que el mensaje de salida IGMP llega a un PE diferente de aquél donde se recibió el informe IGMP y cómo se aborda con la ruta Type-8.

Con los tipos-6/7/8, hemos asegurado la optimización de multidifusión en el núcleo y el acceso. También abordamos los desafíos de los multihosts. En la Assisted Replication with SMET capítulo, analizaremos cómo la combinación de estas optimizaciones con ar ofrece lo mejor de ambos mundos.

Automática

Figure 12describe la topología de referencia.

Figure 12: Topología de referencia
Topología de referencia

Configuration

Las configuraciones realizadas en EVPN Intra-VLAN Multicast with Optimization son suficientes para esta sección.

Verificación del tráfico

Mantener el tráfico existente que comenzamos en EVPN Intra-VLAN Multicast with Optimization del host 1 y el receptor en host-6; en host-3, que es multitarjeta a hoja-1 y hoja-2. Ahora’, si s inicia un receptor para el grupo de multidifusión, 225.1.1.1 en VLAN-101.

A partir de las estadísticas Figure 13de RT en, puede ver que el tráfico enviado por host-1 a 10 PPS lo reciben ahora los receptores de alojamiento único interesados: Host-6, el receptor multitarjeta de red host deseado-3 y el dispositivo heredado, host-7 en VLAN-101.

Figure 13: Estadísticas RT
Estadísticas RT

Multicast Traffic Outputs - LEAF-1

Al igual que antes, el tráfico de multidifusión de carga equilibrada llega a la interfaz de acceso, ae0 en hoja 1. LEAF-1 reenvía ahora este tráfico a su interfaz de acceso AE 1.0, en el que se ha aprendido un receptor IGMP interesado. Recuerde que las reglas de compensación LOCAL de SRC permiten que LEAF-1 reenvíe el tráfico en AE 1.0, independientemente del estado de DF/NDF:

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 al VTEPs hacia hoja-2 (106.106.106.106) y hoja-4 (108.108.108.108), ya que tienen los receptores interesados.

HOJA-3 (107.107.107.107) que no tiene ningún destinatario interesado sigue subiendo en la sustitución del tráfico:

Multicast Traffic Outputs - LEAF-2

La funcionalidad de supervisión IGMP de acceso garantiza que el tráfico de multidifusión que llega a la hoja 2 no se reenvía a la interfaz de host único, XE-0/0/4.0 o on AE 0.0, que no tiene un receptor.

Aunque la interfaz de acceso multitarjeta AE 1.0 tiene un receptor, recuerde que las reglas de DST-LOCAL-BIAS garantizan que el tráfico de multidifusión no se reenvía a esta interfaz. Esto garantiza que no hay duplicación de tráfico hacia el host multitarjeta host-2:

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

No hay ningún cambio en el comportamiento de reenvío de tráfico de estos dispositivos. Por lo tanto, las salidas se omiten por motivos de brevedad.

Verificación detallada del plano de control

Verification of EVPN Join-Sync with Multihomed Receivers

Dado que host-3 es multitarjeta, el informe IGMP puede tener como hoja-1 o hoja-2. En nuestro caso, llega a LEAF-1.

Supongamos’que s Compruebe que en hoja-1, la pertenencia al grupo IGMP se ha aprendido en la interfaz VLAN-101 de AE 1.0 mediante la supervisión de los informes IGMP:

Compruebe que LEAF-1 ha originado una ruta de sincronización de unión de tipo 7 de EVPN correspondiente a esta pertenencia a un grupo IGMP aprendida localmente en la interfaz de host múltiple AE 1.0:

Compruebe que hoja-2 ha procesado esta ruta de sincronización de unión de tipo 7 de EVPN desde hoja 1 y ha aprendido la pertenencia remota en AE 1.0:

Verification of EVPN IGMP Proxy State with Multihomed Receivers

Compruebe que hoja-2, tras haber aprendido la pertenencia IGMP local para el grupo 225.1.1.1, mediante EVPN tipo 7: sincronizar rutas, genera el estado local EVPN proxy IGMP y origina una ruta de proxy IGMP tipo 6 para notificar al PE remoto el interés de recibir tráfico de multidifusión para el Agrupe.

Tenga en cuenta que hoja-2 también conocerá los Estados de proxy remoto según el tipo 6 originado por el capítulo 4 (en EVPN Intra-VLAN Multicast with Optimization ) y hoja-1 (ahora):

De manera similar, debido a su unión local de IGMP, LEAF-1 también originaría una ruta de tipo 6 para el grupo 225.1.1.1. HOJA-1 también conocerá los Estados de proxy remoto según el tipo 6 originado por hoja-4 (en EVPN Intra-VLAN Multicast with Optimization ) y hoja-2 (ahora):

Compruebe que todos los PEs remotos procesan las rutas del tipo 6 de EVPN y aprenden hoja-1 y hoja-2 como receptores de EVPN remoto interesado para el grupo. Esto lo hicimos en EVPN Intra-VLAN Multicast with Optimization para el tipo-6 de hoja-4. Por lo tanto, esto se deja como un ejercicio para el lector.

Verification of Multicast Forwarding State

Compruebe que el estado de reenvío de multidifusión creado para el grupo 225.1.1.1 en hojas-1 y hoja-2 incluye ahora la interfaz multitarjeta de host interesado AE 1.0:

Compruebe que en hoja-1, además de hoja 4 (vtep. 32771), ahora hoja-2 (vtep. 32769) se haya agregado también a EVPN siguiente salto principal para el 225.1.1.1 de grupo. Ten en cuenta que, además, el BL-1 (vtep. 32770), BL-2 (vtep. 32774) y hoja-5 (vtep. 32773), también estará presente en la EVPN siguiente salto principal del Grupo:

Compruebe que se ha actualizado el estado de reenvío de multidifusión creado para el grupo 225.1.1.1 para incluir ahora el siguiente salto de EVPN visto anteriormente: