Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Descripción de la fisgoneo de MLD

La detección de escucha de multidifusión (MLD) restringe la inundación del tráfico de multidifusión IPv6 en las VLAN. Cuando la supervisión MLD está habilitada en una VLAN, un dispositivo Juniper Networks examina los mensajes MLD entre hosts y enrutadores de multidifusión y aprende qué hosts están interesados en recibir tráfico para un grupo de multidifusión. Sobre la base de lo que aprende, el dispositivo reenvía el tráfico de multidifusión solo a las interfaces de la VLAN que están conectadas a receptores interesados en lugar de inundar el tráfico a todas las interfaces.

La snooping MLD es compatible con MLD versión 1 (MLDv1) y MLDv2. Para obtener más información sobre MLDv1 y MLDv2, consulte los siguientes estándares:

  • MLDv1: consulte RFC 2710, Descubrimiento de escucha de multidifusión (MLD) para IPv6.

  • MLDv2: consulte RFC 3810, Descubrimiento de escucha de multidifusión versión 2 (MLDv2) para IPv6.

Ventajas de la fisgonear MLD

  • Optimized bandwidth utilization— El principal beneficio de la fisgonear MLD es reducir la inundación de paquetes. Los datos de multidifusión IPv6 se reenvían selectivamente a una lista de puertos que desean recibir los datos, en lugar de inundarse a todos los puertos de una VLAN.

  • Improved security— Se evitan los ataques de denegación de servicio de fuentes desconocidas.

Cómo funciona el espionaje MLD

De forma predeterminada, el dispositivo inunda el tráfico de multidifusión de capa 2 en todas las interfaces que pertenecen a esa VLAN del dispositivo, excepto en la interfaz que es el origen del tráfico de multidifusión. Este comportamiento puede consumir cantidades significativas de ancho de banda.

Puede habilitar el espionaje MLD para evitar esta inundación. Cuando habilita la snooping MLD, el dispositivo monitorea los mensajes MLD entre receptores (hosts) y enrutadores de multidifusión y utiliza el contenido de los mensajes para crear una tabla de reenvío de multidifusión IPv6: una base de datos de grupos de multidifusión IPv6 y las interfaces que están conectadas a los miembros interesados de cada grupo. Cuando el dispositivo recibe tráfico de multidifusión para un grupo de multidifusión, utiliza la tabla de reenvío para reenviar el tráfico solo a las interfaces conectadas a receptores que pertenecen al grupo de multidifusión.

La figura 1 muestra un ejemplo del flujo de tráfico de multidifusión con la snooping MLD habilitada.

Figura 1: Flujo de tráfico de multidifusión con la snooping MLD habilitada Multicast Traffic Flow with MLD Snooping Enabled

Tipos de mensajes MLD

Los enrutadores de multidifusión utilizan MLD para aprender, para cada una de sus redes físicas conectadas, qué grupos tienen escuchas interesadas. En cualquier subred dada, un enrutador de multidifusión se elige para actuar como un enrutador MLD. El querier mlD envía los siguientes tipos de consultas a hosts:

  • Consulta general: pregunta si algún host está escuchando a cualquier grupo.

  • Consulta específica del grupo: pregunta si cualquier host está escuchando a un grupo de multidifusión específico. Esta consulta se envía en respuesta a un host que abandona el grupo de multidifusión y permite que el enrutador determine rápidamente si los hosts restantes están interesados en el grupo.

  • Consulta específica de grupo y origen: (solo MLD versión 2) Pregunta si cualquier host está escuchando el tráfico de multidifusión de grupo desde un origen de multidifusión específico. Esta consulta se envía en respuesta a un host que indica que ya no está interesado en recibir tráfico de multidifusión de grupo desde el origen de multidifusión y permite que el enrutador determine rápidamente si los hosts restantes están interesados en recibir tráfico de multidifusión de grupo desde ese origen.

Los hosts que son escuchas de multidifusión envían los siguientes tipos de mensajes:

  • Informe de membresía: indica que el host desea unirse a un grupo de multidifusión determinado.

  • Dejar informe: indica que el host quiere dejar un grupo de multidifusión determinado.

Solo los hosts MLDv1 utilizan dos tipos diferentes de informes para indicar si desean unirse o dejar un grupo. Los hosts MLDv2 solo envían un tipo de informe, cuyo contenido indica si quieren unirse o dejar un grupo. Sin embargo, por motivos de simplicidad, la documentación de espionaje de MLD utiliza el término informe de pertenencia para un informe que indica que un host quiere unirse a un grupo y usa el informe de licencia de término para un informe que indica que un host quiere dejar un grupo.

Cómo los hosts se unen y dejan grupos de multidifusión

Los hosts pueden unirse a grupos de multidifusión de dos maneras:

  • Mediante el envío de un informe de pertenencia no solicitado que especifica el grupo de multidifusión al que el host intenta unirse.

  • Mediante el envío de un informe de pertenencia en respuesta a una consulta de un enrutador de multidifusión.

Un enrutador de multidifusión sigue reenviendo tráfico de multidifusión a una interfaz, siempre y cuando al menos un host de esa interfaz responda a las consultas generales periódicas que indican su pertenencia. Por lo tanto, para que un host siga siendo miembro de un grupo de multidifusión, debe seguir respondiendo a las consultas generales periódicas.

Los hosts pueden dejar grupos de multidifusión de dos maneras:

  • Al no responder a consultas periódicas dentro de un intervalo de tiempo establecido. Esto da como resultado lo que se conoce como "licencia silenciosa".

  • Mediante el envío de un informe de licencia.

Nota:

Si un host está conectado al dispositivo a través de un concentrador, el host no deja automáticamente el grupo de multidifusión si se desconecta del concentrador. El host sigue siendo miembro del grupo hasta que se agota el tiempo de espera de la membresía del grupo y se produce una licencia silenciosa. Si otro host se conecta al puerto del concentrador antes de que se produzca la licencia silenciosa, el nuevo host podría recibir el tráfico de multidifusión del grupo hasta la licencia silenciosa, aunque nunca envió un informe de pertenencia.

Soporte para fuentes de multidifusión MLDv2

En MLDv2, un host puede enviar un informe de pertenencia que incluya una lista de direcciones de origen. Cuando el host envía un informe de pertenencia en el modo INCLUDE, el host está interesado en el tráfico de multidifusión de grupo solo desde esos orígenes en la lista de direcciones de origen. Si el host envía un informe de pertenencia en el modo EXCLUIR, el host está interesado en el tráfico de multidifusión de grupo desde cualquier origen , excepto los orígenes de la lista de direcciones de origen. Un host también puede enviar un informe EXCLUDE en el que el parámetro de lista de origen está vacío, lo que se conoce como informe EXCLUDE NULL. Un informe EXCLUDE NULL indica que el host desea unirse al grupo de multidifusión y recibir paquetes de todas las fuentes.

Los dispositivos compatibles con el espionaje MLD admiten informes de membresía mlDv2 que se encuentran en el modo INCLUDE y EXCLUDE. Sin embargo, los dispositivos de la serie SRX, los conmutadores serie QFX y los conmutadores de la serie EX que ejecutan espionaje MLD, excepto los conmutadores EX9200, no admiten el reenvío por fuente. En su lugar, el dispositivo consolida todos los informes del modo INCLUDE y EXCLUDE que recibe en una VLAN para un grupo especificado en una sola ruta que incluye todas las fuentes de multidifusión para ese grupo, siendo el salto siguiente todas las interfaces que tengan receptores interesados para el grupo. Como resultado, los receptores interesados en la VLAN pueden recibir tráfico de un origen que no incluyeron en su informe INCLUDE o de un origen que excluyeron en su informe EXCLUDE. Por ejemplo, si el host 1 quiere tráfico para el grupo G desde el origen A y el host 2 quiere tráfico para el grupo G desde el origen B, ambos reciben tráfico para el grupo G, independientemente de si A o B envían el tráfico.

Interfaces de espionaje y reenvío de MLD

Para determinar cómo reenviar tráfico de multidifusión, el dispositivo con la función de espionaje MLD habilitada mantiene información sobre las siguientes interfaces en su tabla de reenvío de multidifusión:

  • Interfaces de enrutador de multidifusión: estas interfaces conducen a enrutadores de multidifusión o enrutadores MLD.

  • Interfaces miembro de grupo: estas interfaces conducen a hosts que son miembros de grupos de multidifusión.

El dispositivo aprende sobre estas interfaces mediante la supervisión del tráfico MLD. Si una interfaz recibe consultas MLD, el dispositivo agrega la interfaz a su tabla de reenvío de multidifusión como interfaz de enrutador de multidifusión. Si una interfaz recibe informes de pertenencia para un grupo de multidifusión, el dispositivo agrega la interfaz a su tabla de reenvío de multidifusión como interfaz miembro de grupo.

Las entradas de tabla para interfaces de las que el dispositivo aprende están sujetas a un envejecimiento. Por ejemplo, si una interfaz de enrutador de multidifusión aprendida no recibe consultas MLD dentro de un intervalo determinado, el dispositivo quita la entrada para esa interfaz de su tabla de reenvío de multidifusión.

Nota:

Para que el dispositivo aprenda las interfaces de enrutador de multidifusión y las interfaces de miembro de grupo, debe existir una aplicación MLD en la red. Para que el propio dispositivo funcione como un operador mlD, mld debe estar habilitado en el dispositivo.

Puede configurar estáticamente una interfaz para que sea una interfaz de enrutador de multidifusión o una interfaz miembro de grupo. El dispositivo agrega una interfaz estática a su tabla de reenvío de multidifusión sin tener que aprender sobre la interfaz, y la entrada en la tabla no está sujeta a la antigüedad. Puede tener una combinación de interfaces configuradas estáticamente y aprendidas dinámicamente en el dispositivo.

Reglas generales de reenvío

El tráfico de multidifusión recibido en la interfaz del dispositivo en una VLAN en la que está habilitada la supervisión MLD se reenvía según las siguientes reglas.

El tráfico del protocolo MLD se reenvía de la siguiente manera:

  • Las consultas generales mlD recibidas en una interfaz de enrutador de multidifusión se reenvían a todas las demás interfaces de la VLAN.

  • Las consultas específicas del grupo MLD recibidas en una interfaz de enrutador de multidifusión se reenvían solo a aquellas interfaces de la VLAN que son miembros del grupo.

  • Los informes MLD recibidos en una interfaz host se reenvían a interfaces de enrutador de multidifusión en la misma VLAN, pero no a las otras interfaces de host de la VLAN.

El tráfico de multidifusión que no es tráfico de protocolo MLD se reenvía de la siguiente manera:

  • Un paquete de multidifusión no registrado(es decir, un paquete para un grupo que no tiene miembros actuales) se reenvía a todas las interfaces de enrutador de multidifusión en la VLAN.

  • Un paquete de multidifusión registrado se reenvía solo a las interfaces de host de la VLAN que son miembros del grupo de multidifusión y a todas las interfaces de enrutador de multidifusión de la VLAN.

Nota:

Cuando la supervisión IGMP y MLD se habilitan en la misma VLAN, las interfaces del enrutador de multidifusión se crean como parte de la configuración de la supervisión IGMP y MLD. El tráfico de multidifusión no registrado no está bloqueado y se puede pasar a través de interfaces de enrutador, por lo que debido a las limitaciones de hardware, el tráfico de multidifusión IPv4 no registrado puede pasar a través de las interfaces de enrutador de multidifusión creadas como parte de la configuración de supervisión de MLD, y el tráfico de multidifusión IPv6 no registrado puede pasar a través de interfaces de enrutador de multidifusión creadas como parte de la configuración de espionaje IGMP.

Ejemplos de reenvío de multidifusión de snooping MLD

Los siguientes ejemplos se proporcionan para ilustrar cómo la espionaje MLD reenvía el tráfico de multidifusión en diferentes topologías:

Escenario 1: Reenvío de tráfico multidifusión de dispositivos a un enrutador de multidifusión y hosts

En la topología mostrada en la figura 2, el dispositivo que actúa como dispositivo de capa 2 recibe tráfico de multidifusión que pertenece al grupo de multidifusión ff1e::2010 desde el origen A, que está conectado al enrutador de multidifusión. También recibe tráfico de multidifusión que pertenece al grupo de multidifusión ff15::2 de la fuente B, que se conecta directamente al dispositivo. Todas las interfaces del dispositivo pertenecen a la misma VLAN.

Dado que el dispositivo recibe consultas MLD del enrutador de multidifusión en la interfaz P1, la inspección de MLD aprende que la interfaz P1 es una interfaz de enrutador de multidifusión y agrega la interfaz a su tabla de reenvío de multidifusión. Reenvía cualquier consulta general de MLD que reciba en esta interfaz a todas las interfaces de host del dispositivo y, a su vez, reenvía los informes de pertenencia que recibe de hosts a la interfaz del enrutador de multidifusión.

En el ejemplo, los hosts A y C han respondido a las consultas generales con informes de pertenencia para el grupo ff1e::2010. El espionaje MLD agrega las interfaces P2 y P4 a su tabla de reenvío de multidifusión como interfaces miembro para el grupo ff1e::2010. Reenvía el tráfico de multidifusión del grupo recibido de la fuente A a los hosts A y C, pero no a los hosts B y D.

El host B respondió a las consultas generales con un informe de membresía para el grupo ff15::2. El dispositivo agrega la interfaz P3 a su tabla de reenvío de multidifusión como interfaz miembro para el grupo ff15::2 y reenvía el tráfico de multidifusión que recibe del origen B al host B. El dispositivo también reenvía el tráfico de multidifusión que recibe del origen B a la interfaz del enrutador de multidifusión P1.

Figura 2: Escenario 1: Reenvío de tráfico multidifusión de dispositivos a un enrutador de multidifusión y hosts Scenario 1: Device Forwarding Multicast Traffic to a Multicast Router and Hosts

Escenario 2: Reenvío de tráfico multidifusión a otro dispositivo

En la muestra de topología en la figura 3, un origen de multidifusión está conectado al dispositivo A. El dispositivo A a su vez está conectado a otro dispositivo, el dispositivo B. Los hosts en el dispositivo A y B son posibles miembros del grupo de multidifusión. Ambos dispositivos actúan como dispositivos de capa 2 y todas las interfaces de los dispositivos son miembros de la misma VLAN.

El dispositivo A recibe consultas MLD del enrutador de multidifusión en la interfaz P1, lo que convierte a la interfaz P1 en una interfaz de enrutador de multidifusión para el dispositivo A. El dispositivo A reenvía todas las consultas generales que recibe en esta interfaz a las otras interfaces del dispositivo, incluida la interfaz que conecta el dispositivo B. Dado que el dispositivo B recibe las consultas MLD reenviadas en la interfaz P6, P6 es la interfaz de enrutador de multidifusión para el dispositivo B. El dispositivo B reenvía el informe de pertenencia que recibe del host C al dispositivo A a través de su interfaz de enrutador de multidifusión. El dispositivo A reenvía el informe de pertenencia a su interfaz de enrutador de multidifusión, incluye la interfaz P5 en su tabla de reenvío de multidifusión como interfaz miembro del grupo y reenvía el tráfico de multidifusión desde el origen al dispositivo B.

Figura 3: Escenario 2: Reenvío de tráfico multidifusión a otro dispositivo Scenario 2: Device Forwarding Multicast Traffic to Another Device

En ciertas implementaciones, es posible que tenga que configurar P6 en el dispositivo B como una interfaz estática de enrutador de multidifusión para evitar un retraso en un host que recibe tráfico de multidifusión. Por ejemplo, si el dispositivo B recibe informes de pertenencia no solicitados de sus hosts antes de que aprenda qué interfaz es su interfaz de enrutador de multidifusión, no reenvía esos informes al dispositivo A. Si el dispositivo A recibe tráfico de multidifusión, no reenvía el tráfico al dispositivo B, ya que no ha recibido ningún informe de pertenencia en la interfaz P5. Este problema se resolverá cuando el enrutador de multidifusión envíe su próxima consulta general; sin embargo, puede causar un retraso en el host que recibe tráfico de multidifusión. Puede configurar estáticamente la interfaz P6 como una interfaz de enrutador de multidifusión para resolver este problema.

Escenario 3: Dispositivo conectado solo a hosts (sin mlD querier)

En la topología que se muestra en la figura 4, el dispositivo está conectado a un origen de multidifusión y a hosts. No hay ningún enrutador de multidifusión en esta topología, por lo tanto, no hay un mlD querier. Sin un MLD que sea más fácil de responder, un host no envía informes periódicos de membresía. Como resultado, incluso si el host envía un informe de membresía no solicitado para unirse a un grupo de multidifusión, su pertenencia al grupo de multidifusión se agotará.

Para que el espionaje MLD funcione correctamente en esta red, de modo que el dispositivo reenvíe el tráfico de multidifusión solo a los hosts A y C, puede:

  • Configure las interfaces P2 y P4 como interfaces estáticas miembro de grupo.

  • Configure una interfaz VLAN enrutada (RVI), también conocida como interfaz de enrutamiento y puente integrados (IRB), en la VLAN y habilite MLD en ella. En este caso, el propio dispositivo actúa como un operador de MLD, y los hosts pueden unirse dinámicamente al grupo de multidifusión y actualizar su pertenencia al grupo respondiendo a las consultas.

Figura 4: Escenario 3: Dispositivo conectado solo a hosts (sin mlD querier) Scenario 3: Device Connected to Hosts Only (No MLD Querier)

Escenario 4: reenvío de tráfico multidifusión de dispositivos de capa 2/capa 3 entre VLAN

En la topología que se muestra en la figura 5, un origen de multidifusión, el enrutador de multidifusión A y los hosts A y B se conectan al dispositivo y se encuentran en la VLAN 10. El enrutador de multidifusión B y los hosts C y D también están conectados al dispositivo y están en la VLAN 20.

En un entorno de capa 2 puro, el tráfico no se reenvía entre redes VLAN. Para que el host C reciba el tráfico de multidifusión desde el origen en la VLAN 10, las RVI (o interfaces IRB) se deben crear en vlan 10 y VLAN 20 para permitir el enrutamiento del tráfico de multidifusión entre las VLAN.

Figura 5: Escenario 4: Dispositivo de capa 2/capa 3 que reenvía tráfico multidifusión entre VLAN Scenario 4: Layer 2/Layer 3 device Forwarding Multicast Traffic Between VLANs