Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Descripción general de IGMP Snooping

El espionaje del Protocolo de administración de grupos de Internet (IGMP) limita la inundación del tráfico de multidifusión IPv4 en las VLAN de un dispositivo. Con la supervisión IGMP habilitada, el dispositivo supervisa el tráfico IGMP en la red y utiliza lo que aprende para reenviar el tráfico de multidifusión solo a las interfaces descendentes que están conectadas a los receptores interesados. El dispositivo conserva el ancho de banda enviando tráfico de multidifusión solo a interfaces conectadas a dispositivos que desean recibir el tráfico, en lugar de inundar el tráfico a todas las interfaces descendentes de una VLAN.

Beneficios de IGMP Snooping

  • Optimized bandwidth utilization—El principal beneficio del espionaje IGMP es reducir la inundación de paquetes. El dispositivo reenvía selectivamente los datos de multidifusión IPv4 a una lista de puertos que desean recibir los datos en lugar de inundarlos a todos los puertos de una VLAN.

  • Improved security: evita ataques de denegación de servicio de fuentes desconocidas.

Cómo funciona IGMP Snooping

Por lo general, los dispositivos aprenden las direcciones MAC de unidifusión comprobando el campo de dirección de origen de las tramas que reciben y, a continuación, envían cualquier tráfico para esa dirección de unidifusión solo a las interfaces adecuadas. Sin embargo, una dirección MAC de multidifusión nunca puede ser la dirección de origen de un paquete. Como resultado, cuando un dispositivo recibe tráfico para una dirección de destino de multidifusión, inunda el tráfico en la VLAN relevante, enviando una cantidad significativa de tráfico para el cual no necesariamente puede haber receptores interesados.

El espionaje IGMP evita esta inundación. Cuando se habilita la supervisión IGMP, el dispositivo supervisa los paquetes IGMP entre los receptores y los enrutadores de multidifusión, y utiliza el contenido de los paquetes para crear una tabla de reenvío de multidifusión, una base de datos de grupos de multidifusión y las interfaces que están conectadas a los miembros de los grupos. Cuando el dispositivo recibe paquetes de multidifusión, utiliza la tabla de reenvío de multidifusión para reenviar selectivamente el tráfico sólo a las interfaces que están conectadas a los miembros de los grupos de multidifusión adecuados.

En los conmutadores serie EX y QFX que no admiten el estilo de configuración Enhanced Layer 2 Software (ELS), la supervisión IGMP está habilitada de forma predeterminada en todas las VLAN (o solo en la VLAN predeterminada en algunos dispositivos) y puede deshabilitarla selectivamente en una o más VLAN. En todos los demás dispositivos, debe configurar explícitamente la supervisión IGMP en una VLAN o en un dominio de puente para habilitarla.

Nota:

No puede configurar la supervisión IGMP en una VLAN secundaria (privada) (PVLAN). Sin embargo, a partir de Junos OS versión 18.3R1 en conmutadores EX4300 y chasis virtual EX4300, y Junos OS versión 19.2R1 en conmutadores multigigabit EX4300, cuando se habilita la supervisión IGMP en una VLAN principal, también se habilita implícitamente en cualquier VLAN secundaria definida para esa VLAN principal. Consulte Espionaje IGMP en VLAN privadas (PVLAN) para obtener más información.

Cómo funciona IGMP Snooping con interfaces VLAN enrutadas

El dispositivo puede utilizar una interfaz VLAN enrutada (RVI) para reenviar el tráfico entre VLAN en su configuración. La supervisión IGMP funciona con interfaces de capa 2 y RVI para reenviar tráfico de multidifusión en una red conmutada.

Cuando el dispositivo recibe un paquete de multidifusión, sus motores de reenvío de paquetes realizan una búsqueda de multidifusión en el paquete para determinar cómo reenviar el paquete a sus interfaces locales. A partir de los resultados de la búsqueda, cada motor de reenvío de paquetes extrae una lista de interfaces de capa 3 que tienen puertos locales para el motor de reenvío de paquetes. Si la lista incluye una RVI, el dispositivo proporciona un ID de grupo de multidifusión de puente para la RVI al motor de reenvío de paquetes.

Para las VLAN que incluyen receptores de multidifusión, el ID de multidifusión del puente incluye un ID de subsalto siguiente, que identifica las interfaces de capa 2 en la VLAN que están interesadas en recibir el flujo de multidifusión. A continuación, el motor de reenvío de paquetes reenvía el tráfico de multidifusión a los ID de multidifusión de puente que tienen receptores de multidifusión para un grupo de multidifusión determinado.

Tipos de mensajes IGMP

Los enrutadores de multidifusión utilizan IGMP para saber qué grupos tienen oyentes interesados en cada una de sus redes físicas conectadas. En cualquier subred dada, un enrutador de multidifusión actúa como un cuestionario IGMP. El cuestionario IGMP 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: (solo IGMPv2 e IGMPv3) Pregunta si algún host está escuchando 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 IGMPv3) 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: (solo IGMPv2 e IGMPv3) Indica que el host desea abandonar un grupo de multidifusión determinado.

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 mensaje de unión IGMP no solicitado a un enrutador de multidifusión que especifica el grupo de multidifusión IP al que el host desea unirse.

  • Mediante el envío de un mensaje de unión IGMP en respuesta a una consulta general de un enrutador de multidifusión.

Un enrutador de multidifusión continúa reenviando tráfico de multidifusión a una VLAN siempre que al menos un host en esa VLAN responda a las consultas generales periódicas de IGMP. Para que un host siga siendo miembro de un grupo de multidifusión, debe seguir respondiendo a las consultas generales periódicas de IGMP.

Los hosts pueden abandonar un grupo de multidifusión de dos maneras:

  • Al no responder a consultas periódicas dentro de un intervalo de tiempo particular, lo que se considera una "licencia silenciosa". Este es el único método de salida para hosts IGMPv1.

  • Mediante el envío de un informe de licencia. Este método puede ser utilizado por hosts IGMPv2 e IGMPv3.

Compatibilidad con fuentes de multidifusión IGMPv3

En IGMPv3, 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 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 el proceso IGMPv3 INCLUYEN y EXCLUYEN informes de membresía, y la mayoría de los dispositivos reenvían el tráfico de multidifusión específico del origen (SSM) solo de los orígenes solicitados a los receptores suscritos según corresponda. Sin embargo, es posible que el dispositivo no reenvíe estrictamente el tráfico de multidifusión por fuente en algunas configuraciones, como:

  • Conmutadores serie EX y QFX que no utilizan el estilo de configuración de Enhanced Layer 2 Software (ELS)

  • Conmutadores EX2300 y EX3400 que ejecutan versiones de Junos OS anteriores a la 18.1R2

  • Conmutadores EX4300 con versiones de Junos OS anteriores a 18.2R1, 18.1R2, 17.4R2, 17.3R3, 17.2R3 y 14.1X53-D47

  • Puertas de enlace de servicios de la serie SRX

En estos casos, el dispositivo puede consolidar todos los informes de modo INCLUDE y EXCLUDE que reciba en una VLAN para un grupo especificado en una única ruta que incluya todos los orígenes de multidifusión para ese grupo, donde el siguiente salto represente 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 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 espionaje y reenvío IGMP

Para determinar cómo reenviar tráfico de multidifusión, el dispositivo con la supervisión IGMP 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 IGMP.

  • 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 IGMP. Si una interfaz recibe consultas IGMP o actualizaciones de multidifusión independiente del protocolo (PIM), 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 aprendidas de la tabla de interfaz caducan después de un período de tiempo. Por ejemplo, si una interfaz de enrutador de multidifusión aprendida no recibe consultas IGMP o saludos PIM 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 del enrutador de multidifusión y las interfaces de los miembros del grupo, la red debe incluir una consulta IGMP. Esto ocurre a menudo en un enrutador de multidifusión, pero si no hay ningún enrutador de multidifusión en la red local, puede configurar el propio dispositivo para que sea un cuestionario IGMP.

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. Un dispositivo puede tener una combinación de interfaces configuradas estáticamente y aprendidas dinámicamente.

Reglas generales de reenvío

Una interfaz en una VLAN con snooping IGMP habilitado recibe tráfico de multidifusión y lo reenvía de acuerdo con las siguientes reglas.

Tráfico IGMP:

  • Reenvíe las consultas generales IGMP recibidas en una interfaz de enrutador de multidifusión a todas las demás interfaces de la VLAN.

  • Reenvíe las consultas específicas del grupo IGMP recibidas en una interfaz de enrutador de multidifusión solo a aquellas interfaces de la VLAN que sean miembros del grupo.

  • Reenvíe los informes IGMP recibidos en una interfaz de host a interfaces de enrutador de multidifusión en la misma VLAN, pero no a las otras interfaces de host en la VLAN.

Tráfico de multidifusión que no es tráfico IGMP:

  • Inunde paquetes de multidifusión con una dirección de destino de 233.252.0.0/24 a todas las demás interfaces de la VLAN.

  • Reenvíe paquetes de multidifusión no registrados (paquetes para un grupo que no tiene miembros actuales) a todas las interfaces de enrutador de multidifusión en la VLAN.

  • Reenvíe los paquetes de multidifusión registrados a las interfaces de host de la VLAN que sean miembros del grupo de multidifusión y a todas las interfaces de enrutador de multidifusión de la VLAN.

Uso del dispositivo como consulta IGMP

Con la supervisión IGMP en una red local pura de capa 2 (es decir, la capa 3 no está habilitada en la red), si la red no incluye un enrutador de multidifusión, es posible que el tráfico de multidifusión no se reenvíe correctamente a través de la red. Es posible que vea este problema si la red local está configurada de tal manera que el tráfico de multidifusión debe reenviarse entre dispositivos para llegar a un receptor de multidifusión. En este caso, un dispositivo ascendente no reenvía el tráfico de multidifusión a un dispositivo descendente (y, por lo tanto, a los receptores de multidifusión conectados al dispositivo descendente) porque el dispositivo descendente no reenvía los informes IGMP al dispositivo ascendente. Puede resolver este problema configurando uno de los dispositivos para que sea un cuestionario IGMP. El dispositivo de consulta IGMP envía paquetes de consulta general periódicos a todos los dispositivos de la red, lo que garantiza que las tablas de pertenencia a espionaje estén actualizadas y evita la pérdida de tráfico de multidifusión.

Si configura varios dispositivos para que sean consultas IGMP, el dispositivo con la dirección de origen de consulta IGMP más baja (más pequeña) tiene prioridad y actúa como consulta. Los dispositivos con direcciones de origen de consulta IGMP más altas dejan de enviar consultas IGMP a menos que no reciban consultas IGMP durante 255 segundos. Si el dispositivo con una dirección de origen de consulta IGMP más alta no recibe ninguna consulta IGMP durante ese período, comienza a enviar consultas nuevamente.

Nota:

Los sistemas QFabric de Junos OS versión 14.1X53-D15 admiten la instrucción, pero no admiten esta igmp-querier instrucción en Junos OS 15.1.

Para configurar un dispositivo para que actúe como una consulta IGMP, escriba lo siguiente:

Para configurar un conmutador de dispositivo de nodo QFabric para que actúe como una consulta IGMP, escriba lo siguiente:

Espionaje IGMP en VLAN privadas (PVLAN)

Una PVLAN consta de VLAN secundarias aisladas y de comunidad configuradas dentro de una VLAN principal. Sin soporte de espionaje IGMP en las VLAN secundarias, las transmisiones de multidifusión recibidas en la VLAN principal se inundan a las VLAN secundarias.

A partir de Junos OS versión 18.3R1, los conmutadores EX4300 y el chasis virtual EX4300 admiten el espionaje IGMP con PVLAN. A partir de Junos OS versión 19.2R1, los conmutadores modelo multigigabit EX4300 admiten la supervisión IGMP con PVLAN. Cuando habilita el espionaje IGMP en una VLAN principal, también lo habilita implícitamente en todas las VLAN secundarias. El dispositivo aprende y almacena información del grupo de multidifusión en la VLAN principal, y también aprende la información del grupo de multidifusión en las VLAN secundarias en el contexto de la VLAN principal. Como resultado, el dispositivo restringe aún más las transmisiones de multidifusión solo a los receptores interesados en VLAN secundarias, en lugar de inundar el tráfico en todas las VLAN secundarias.

La CLI le impide configurar explícitamente el espionaje IGMP en VLAN secundarias aisladas o comunitarias. Solo necesita configurar la supervisión IGMP en la VLAN principal en la que se definen las VLAN secundarias. Por ejemplo, para una VLAN vlan-pri primaria con una VLAN aislada secundaria vlan-iso y una VLAN vlan-comm de comunidad secundaria:

Los informes IGMP y los mensajes de salida recibidos en los puertos VLAN secundarios se aprenden en el contexto de la VLAN principal. Los puertos troncales promiscuos o los vínculos entre conmutadores que actúan como interfaces de enrutador de multidifusión para la PVLAN reciben flujos de datos de multidifusión entrantes de fuentes de multidifusión y los reenvían solo a los puertos VLAN secundarios con entradas de grupo de multidifusión aprendidas.

Esta función no admite puertos VLAN secundarios como interfaces de enrutador de multidifusión. La CLI no impide estrictamente configurar estáticamente una interfaz en una VLAN comunitaria como un puerto de enrutador de multidifusión, pero el espionaje IGMP no funciona correctamente en PVLAN con esta configuración. Cuando la supervisión IGMP se configura en una PVLAN, el conmutador también deshabilita automáticamente el aprendizaje del puerto del enrutador de multidifusión dinámica en cualquier interfaz VLAN aislada o comunitaria. El espionaje IGMP con PVLAN tampoco admite configuraciones con una consulta IGMP en interfaces VLAN aisladas o comunitarias.

Consulte Descripción de VLAN privadas y Creación de una VLAN privada que abarque varios conmutadores de la serie EX con compatibilidad con ELS (procedimiento de CLI) para obtener más información sobre la configuración de PVLAN.

Tabla de historial de cambios

La compatibilidad con las funciones viene determinada por la plataforma y la versión que esté utilizando. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.

Lanzamiento
Descripción
19.2R1
A partir de Junos OS versión 19.2R1, los conmutadores modelo multigigabit EX4300 admiten la supervisión IGMP con PVLAN.
18.3R1
A partir de Junos OS versión 18.3R1, los conmutadores EX4300 y el chasis virtual EX4300 admiten el espionaje IGMP con PVLAN.
14,1 X 53-D15
Los sistemas QFabric de Junos OS versión 14.1X53-D15 admiten la instrucción, pero no admiten esta igmp-querier instrucción en Junos OS 15.1.