Descripción de MLD Snooping
La detección de escucha de multidifusión (MLD) limita la inundación del tráfico de multidifusión IPv6 en las VLAN. Cuando la supervisión de MLD está habilitada en una VLAN, un dispositivo de 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 sólo a aquellas interfaces de la VLAN que están conectadas a los receptores interesados, en lugar de inundar el tráfico a todas las interfaces.
MLD snooping admite MLD versión 1 (MLDv1) y MLDv2. Para obtener más información sobre MLDv1 y MLDv2, consulte las siguientes normas:
MLDv1: consulte RFC 2710, Multicast Listener Discovery (MLD) para IPv6.
MLDv2: consulte RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) para IPv6.
Beneficios de MLD Snooping
Optimized bandwidth utilization—El principal beneficio del espionaje 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 MLD Snooping
De forma predeterminada, el dispositivo inunda el tráfico de multidifusión de capa 2 en todas las interfaces que pertenecen a esa VLAN en el 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 se habilita la supervisión de MLD, el dispositivo supervisa 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 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 sólo a interfaces que están conectadas a receptores que pertenecen al grupo de multidifusión.
La figura 1 muestra un ejemplo de flujo de tráfico de multidifusión con la supervisión de MLD habilitada.
Tipos de mensajes MLD
Los enrutadores de multidifusión utilizan MLD para saber, para cada una de sus redes físicas conectadas, qué grupos tienen oyentes interesados. En cualquier subred dada, se elige un enrutador de multidifusión para que actúe como un cuestionario MLD. La consulta MLD envía los siguientes tipos de consultas a los hosts:
Consulta general: pregunta si algún anfitrión está escuchando a algún grupo.
Consulta específica del grupo: pregunta si algún 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 algún host restante está interesado en el grupo.
Consulta específica de grupo y origen: (solo MLD versión 2) Pregunta si algún host está escuchando 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 del origen de multidifusión y permite al enrutador determinar rápidamente si los hosts restantes están interesados en recibir tráfico de multidifusión de grupo de ese origen.
Los hosts que son oyentes de multidifusión envían los siguientes tipos de mensajes:
Informe de pertenencia: indica que el host desea unirse a un grupo de multidifusión determinado.
Dejar informe: indica que el host desea abandonar un grupo de multidifusión determinado.
Solo los hosts MLDv1 usan dos tipos diferentes de informes para indicar si desean unirse o abandonar un grupo. Los hosts MLDv2 envían solo un tipo de informe, cuyo contenido indica si desean unirse o abandonar un grupo. Sin embargo, en aras de la simplicidad, la documentación de espionaje de MLD utiliza el término informe de membresía para un informe que indica que un anfitrión desea unirse a un grupo y usa el término informe de licencia para un informe que indica que un anfitrión desea abandonar un grupo.
Cómo los anfitriones se unen y abandonan los 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 solicitada que especifique el grupo de multidifusión al que el host está intentando 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 continúa reenviando tráfico de multidifusión a una interfaz siempre que 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 abandonar los grupos de multidifusión de dos maneras:
Al no responder a las consultas periódicas dentro de un intervalo de tiempo establecido. Esto resulta en lo que se conoce como una "salida silenciosa".
Mediante el envío de un informe de licencia.
Si un host está conectado al dispositivo a través de un concentrador, el host no abandona automáticamente el grupo de multidifusión si se desconecta del concentrador. El anfitrión sigue siendo miembro del grupo hasta que se agota el tiempo de espera de pertenencia al grupo y se produce un permiso silencioso. Si otro host se conecta al puerto de concentrador antes de que se produzca la salida silenciosa, es posible que el nuevo host reciba el tráfico de multidifusión del grupo hasta que se vaya en silencio, aunque nunca haya enviado un informe de pertenencia.
Compatibilidad con fuentes de multidifusión MLDv2
En MLDv2, un host puede enviar un informe de membresía que incluya una lista de direcciones de origen. Cuando el host envía un informe de pertenencia en modo INCLUDE, el host está interesado en el tráfico de multidifusión de grupo solo desde los orígenes de la lista de direcciones de origen. Si el host envía un informe de pertenencia en modo EXCLUDE, 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 source-list 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 todos los orígenes.
Los dispositivos que admiten la supervisión de MLD admiten informes de membresía MLDv2 que están en modo INCLUDE y EXCLUDE. Sin embargo, los firewalls serie SRX, los conmutadores serie QFX y los conmutadores serie EX que ejecutan la supervisión MLD, excepto los conmutadores EX9200, no admiten el reenvío por fuente. En su lugar, el dispositivo consolida todos los informes de modo INCLUDE y EXCLUDE que recibe en una VLAN para un grupo especificado en una única ruta que incluye todos los orígenes de multidifusión para ese grupo, siendo el siguiente salto todas las interfaces que tienen receptores interesados para el grupo. Como resultado, los receptores interesados en la VLAN pueden recibir tráfico de una fuente que no incluyeron en su informe INCLUDE o de una fuente que excluyeron en su informe EXCLUDE. Por ejemplo, si el host 1 quiere tráfico para el grupo G del origen A y el host 2 quiere tráfico para el grupo G del origen B, ambos reciben tráfico para el grupo G independientemente de si A o B envían el tráfico.
Interfaces de reenvío y espionaje MLD
Para determinar cómo reenviar tráfico de multidifusión, el dispositivo con la supervisión de 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 consultas MLD.
Interfaces de miembro de grupo: estas interfaces conducen a hosts que son miembros de grupos de multidifusión.
El dispositivo aprende acerca de 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 una 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 una interfaz de miembro del grupo.
Las entradas de tabla para las interfaces que el dispositivo aprende están sujetas a antigüedad. 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.
Para que el dispositivo aprenda las interfaces del enrutador de multidifusión y las interfaces de miembro del grupo, debe existir una consulta MLD en la red. Para que el dispositivo en sí funcione como una consulta 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 de 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 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 de MLD se reenvía de acuerdo con las siguientes reglas.
El tráfico del protocolo MLD se reenvía de la siguiente manera:
Las consultas generales de 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 de host se reenvían a interfaces de enrutador de multidifusión en la misma VLAN, pero no a las otras interfaces de host en 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.
Cuando la supervisión IGMP y MLD están habilitadas en la misma VLAN, se crean interfaces de enrutador de multidifusión como parte de la configuración de supervisión IGMP y MLD. El tráfico de multidifusión no registrado no se bloquea y se puede pasar a través de interfaces de enrutador, por lo que, debido a 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 espionaje 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 MLD Snooping
Se proporcionan los siguientes ejemplos para ilustrar cómo el espionaje MLD reenvía el tráfico de multidifusión en diferentes topologías:
- Escenario 1: Reenvío de tráfico de multidifusión de dispositivos a un enrutador y hosts de multidifusión
- Escenario 2: Reenvío de tráfico de multidifusión de dispositivos a otro dispositivo
- Escenario 3: dispositivo conectado solo a hosts (sin MLD Querier)
- Escenario 4: Reenvío de tráfico de multidifusión de dispositivos de capa 2/capa 3 entre VLAN
Escenario 1: Reenvío de tráfico de multidifusión de dispositivos a un enrutador y hosts de multidifusión
En la topología que se muestra 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 del origen A, que está conectado al enrutador de multidifusión. También recibe tráfico de multidifusión perteneciente al grupo de multidifusión ff15::2 de la fuente B, que está conectada 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 supervisió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 membresía que recibe de los hosts a la interfaz de enrutador de multidifusión.
En el ejemplo, los anfitriones A y C han respondido a las consultas generales con informes de pertenencia para el grupo ff1e::2010. MLD snooping 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 de grupo recibido del origen A a los hosts A y C, pero no a los hosts B y D.
El anfitrión B ha respondido 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 P1 del enrutador de multidifusión.
de multidifusión
Escenario 2: Reenvío de tráfico de multidifusión de dispositivos a otro dispositivo
En la topología que se muestra 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 de los dispositivos A y B son miembros potenciales 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 demás 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 del 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 de miembro del grupo y reenvía el tráfico de multidifusión desde el origen al dispositivo B.
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 retrasos en un host que recibe tráfico de multidifusión. Por ejemplo, si el dispositivo B recibe informes de membresía no solicitados de sus hosts antes de saber 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 el 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 un enrutador de multidifusión en esta topología; por lo tanto, no hay una consulta MLD. Sin una consulta de MLD a la que responder, un anfitrión no envía informes periódicos de membresía. Como resultado, incluso si el host envía un informe de pertenencia no solicitado para unirse a un grupo de multidifusión, se agotará el tiempo de espera de su pertenencia al grupo de multidifusión.
Para que la supervisión de MLD funcione correctamente en esta red, de modo que el dispositivo reenvíe tráfico de multidifusión solo a los hosts A y C, puede:
Configure las interfaces P2 y P4 como interfaces estáticas miembro del 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 cuestionario MLD y los hosts pueden unirse dinámicamente al grupo de multidifusión y actualizar su pertenencia al grupo respondiendo a las consultas.
Escenario 4: Reenvío de tráfico de 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 están conectados 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 se encuentran en la VLAN 20.
En un entorno de capa 2 puro, el tráfico no se reenvía entre VLAN. Para que el host C reciba el tráfico de multidifusión del origen en la VLAN 10, se deben crear RVI (o interfaces IRB) en la VLAN 10 y la VLAN 20 para permitir el enrutamiento del tráfico de multidifusión entre las VLAN.
