Descripción de MLD Snooping
La supervisión del detector de escucha de multidifusión (MLD) restringe la inundación del tráfico de multidifusión IPv6 en las redes VLAN. Cuando se habilita la supervisión de MLD 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 solo a aquellas interfaces en la VLAN que están conectadas a los receptores interesados, en lugar de inundar el tráfico a todas las interfaces.
MLD snooping es compatible con 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, Detección de escucha de multidifusión (MLD) para IPv6.
-
MLDv2: consulte RFC 3810, Detección de escucha de multidifusión versión 2 (MLDv2) para IPv6.
Beneficios de MLD Snooping
-
Optimized bandwidth utilization—El principal beneficio de MLD snooping 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 la supervisión de MLD para evitar esta inundación. Cuando se habilita la supervisión de MLD, el dispositivo supervisa los mensajes MLD entre los receptores (hosts) y los 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 que estén conectadas a receptores que pertenezcan 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 aprender, 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 solicitante de MLD. El solicitante de 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 al enrutador determinar rápidamente si algún host restante está interesado en el grupo.
-
Consulta específica de grupo y fuente: (solo MLD versión 2) pregunta si algún host está escuchando el tráfico de multidifusión de grupo desde una fuente de multidifusión específica. 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 anfitrión desea unirse a un grupo de multidifusión determinado.
-
Dejar informe: indica que el anfitrión 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 MLD snooping usa el término informe de membresía para un informe que indica que un anfitrión quiere unirse a un grupo y usa el término informe de licencia para un informe que indica que un anfitrión quiere abandonar un grupo.
Cómo los anfitriones se unen y abandonan grupos de multidifusión
Los anfitriones pueden unirse a grupos de multidifusión de dos maneras:
-
Mediante el envío de un informe de membresía no solicitado que especifica el grupo de multidifusión al que el host está intentando unirse.
-
Mediante el envío de un informe de membresía en respuesta a una consulta desde un enrutador de multidifusión.
Un enrutador de multidifusión sigue reenviando 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 abandonar los grupos de multidifusión de cualquiera de estas 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 una "licencia silenciosa".
-
Mediante el envío de un informe de baja.
Si un host está conectado al dispositivo a través de un concentrador, este no abandonará 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 pertenencia al grupo y se produce una salida silenciosa. Si otro host se conecta al puerto concentrador antes de que se produzca la ausencia silenciosa, es posible que el nuevo host reciba el tráfico de multidifusión del grupo hasta la salida silenciosa, 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 incluye 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 EXCLUD, 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 de MLDv2 que están en modo INCLUDE y EXCLUD.
Interfaces de reenvío y supervisión de MLD
Para determinar cómo reenviar tráfico de multidifusión, el dispositivo con la supervisión de MLD habilitada mantiene información acerca de las siguientes interfaces en su tabla de reenvío de multidifusión:
-
Interfaces enrutador multidifusión: estas interfaces conducen a enrutadores multidifusión o a solicitantes de MLD.
-
Interfaces de 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 de 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 de grupo.
Las entradas de tabla para las interfaces sobre las 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 de esa interfaz de su tabla de reenvío de multidifusión.
Para que el dispositivo aprenda interfaces multidifusión-enrutador e interfaces de miembros de grupo, debe existir un solicitante de MLD en la red. Para que el dispositivo funcione como un solicitante de 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 acerca de 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 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 en la VLAN.
-
Las consultas específicas del grupo MLD recibidas en una interfaz de enrutador de multidifusión se reenvían solo a las interfaces de la VLAN que son miembros del grupo.
-
Los informes MLD recibidos en una interfaz de host se reenvían a las interfaces del 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 únicamente a las interfaces de host en la VLAN que son miembros del grupo de multidifusión y a todas las interfaces de enrutador de multidifusión en 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 está bloqueado y 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 del enrutador de multidifusión creadas como parte de la configuración de supervisión 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 supervisión IGMP.
Ejemplos de MLD Snooping Reenvío de multidifusión
Los siguientes ejemplos se proporcionan para ilustrar cómo MLD snooping 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 consulta MLD)
- Escenario 4: Reenvío de tráfico de multidifusión de dispositivos de capa 2/capa 3 entre redes 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 mostrada en la Figura 2, el dispositivo que actúa como dispositivo de capa 2 recibe tráfico de multidifusión perteneciente 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 del origen B, que está conectado 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 recibe 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 del enrutador de multidifusión.
En el ejemplo, los hosts A y C han respondido a las consultas generales con informes de membresía 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 desde el origen B a la interfaz del enrutador de multidifusión P1.
de multidifusión
Escenario 2: Reenvío de tráfico de multidifusión de dispositivos a otro dispositivo
En la topología mostrada en la Figura 3, una fuente de multidifusión está conectada 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 de 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 siguiente consulta general; Sin embargo, puede provocar un retraso en el host que recibe tráfico de multidifusión. Para resolver este problema, puede configurar estáticamente la interfaz P6 como interfaz de enrutador de multidifusión.
Escenario 3: Dispositivo conectado solo a hosts (sin consulta MLD)
En la topología que se muestra en la Figura 4, el dispositivo está conectado a una fuente de multidifusión y a hosts. No hay ningún enrutador de multidifusión en esta topología; por lo tanto, no hay ningún solicitante de MLD. Sin un solicitante de MLD al 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 membresía no solicitado para unirse a un grupo de multidifusión, se agotará el tiempo de espera de su membresía en el grupo de multidifusión.
Para que la supervisión de 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 solicitante de 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 redes VLAN
En la topología mostrada en la Figura 5, una fuente 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 redes 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 las VLAN 10 y VLAN 20 para permitir el enrutamiento del tráfico de multidifusión entre las VLAN.
Comportamiento de espionaje de MLD específico de la plataforma
Use el Explorador de características para confirmar la compatibilidad de plataforma y versión para características específicas.
Utilice la siguiente tabla para revisar el comportamiento específico de la plataforma para su plataforma.
| Plataforma |
Diferencia |
|---|---|
| Firewalls de la serie SRX, conmutadores de la serie QFX y conmutadores de la serie EX que ejecutan supervisión MLD, excepto los conmutadores EX9200 |
|