EN ESTA PÁGINA
Modificación del intervalo de mensajes de consulta de host IGMP
Especificación de la eliminación inmediata de host para IGMP
Filtrado de informes IGMP no deseados en el nivel de interfaz IGMP
Modificación del intervalo de consulta del último miembro IGMP
Limitar el número de uniones de grupos de multidifusión IGMP en interfaces lógicas
Configuración de IGMP
Descripción de los protocolos de pertenencia a grupos
Hay una gran diferencia entre los protocolos de multidifusión utilizados entre el host y el dispositivo de enrutamiento y entre los propios dispositivos de enrutamiento de multidifusión. Los hosts de una subred determinada solo necesitan informar a su dispositivo de enrutamiento si están o no interesados en recibir paquetes de un determinado grupo de multidifusión. El host de origen solo necesita informar a sus dispositivos de enrutamiento de que es el origen del tráfico de un grupo de multidifusión determinado. En otras palabras, ningún host necesita un conocimiento detallado del árbol de distribución; Solo se necesita un protocolo de pertenencia a grupos para informar a los dispositivos de enrutamiento de su participación en un grupo de multidifusión. Por otro lado, entre dispositivos de enrutamiento adyacentes, los protocolos de enrutamiento de multidifusión deben evitar bucles, ya que crean un sentido detallado de la topología de red y el árbol de distribución desde el origen hasta la hoja. Por lo tanto, se utilizan diferentes protocolos de multidifusión para la parte host-enrutador y la parte enrutador-enrutador de la red de multidifusión.
Los protocolos de pertenencia a grupos de multidifusión permiten que un dispositivo de enrutamiento detecte cuándo un host en una subred conectada directamente, normalmente una LAN, desea recibir tráfico de un determinado grupo de multidifusión. Incluso si más de un host en la LAN desea recibir tráfico para ese grupo de multidifusión, el dispositivo de enrutamiento envía sólo una copia de cada paquete para ese grupo de multidifusión en esa interfaz, debido a la naturaleza de difusión inherente de las LAN. Cuando el protocolo de pertenencia a grupos de multidifusión informa al dispositivo de enrutamiento de que no hay hosts interesados en la subred, los paquetes se retienen y esa hoja se poda del árbol de distribución.
El Protocolo de administración de grupos de Internet (IGMP) y el Protocolo de detección de escucha de multidifusión (MLD) son los protocolos estándar de pertenencia a grupos de multidifusión IP: IGMP y MLD tienen varias versiones compatibles con hosts y dispositivos de enrutamiento:
IGMPv1: el protocolo original definido en RFC 1112. Se envía un mensaje de unión explícito al dispositivo de enrutamiento, pero se agota el tiempo de espera para determinar cuándo los hosts abandonan un grupo. Este proceso desperdicia ciclos de procesamiento en el dispositivo de enrutamiento, especialmente en dispositivos de enrutamiento más antiguos o más pequeños.
IGMPv2: definido en RFC 2236. Entre otras características, IGMPv2 agrega un mensaje de ausencia explícito al mensaje de unión para que los dispositivos de enrutamiento puedan determinar más fácilmente cuándo un grupo no tiene oyentes interesados en una LAN.
IGMPv3: definido en RFC 3376. Entre otras características, IGMPv3 optimiza la compatibilidad con un único origen de contenido para un grupo de multidifusión o multidifusión específica del código fuente (SSM).
MLDv1: definido en RFC 2710. MLDv1 es similar a IGMPv2.
MLDv2: definido en RFC 3810. MLDv2 similar a IGMPv3.
Las diversas versiones de IGMP y MLD son compatibles con versiones anteriores. Es común que un dispositivo de enrutamiento ejecute varias versiones de IGMP y MLD en interfaces LAN. La compatibilidad con versiones anteriores se logra volviendo a la más básica de todas las versiones que se ejecutan en una LAN. Por ejemplo, si un host ejecuta IGMPv1, cualquier dispositivo de enrutamiento conectado a la LAN que ejecute IGMPv2 puede volver a la operación IGMPv1, eliminando efectivamente las ventajas de IGMPv2. La ejecución de varias versiones de IGMP garantiza que los hosts IGMPv1 e IGMPv2 encuentren pares para sus versiones en el dispositivo de enrutamiento.
En las plataformas de la serie MX, IGMPv2 e IGMPv3 pueden o no configurarse juntos en la misma interfaz, según la versión de Junos OS en su instalación. Configurar ambos juntos puede provocar un comportamiento inesperado en el reenvío de tráfico de multidifusión.
Ver también
Entendiendo IGMP
El Protocolo de administración de grupos de Internet (IGMP) administra la pertenencia de hosts y dispositivos de enrutamiento en grupos de multidifusión. Los hosts IP utilizan IGMP para informar de sus pertenencias a grupos de multidifusión a cualquier dispositivo de enrutamiento de multidifusión vecino inmediato. Los dispositivos de enrutamiento de multidifusión utilizan IGMP para saber, para cada una de sus redes físicas adjuntas, qué grupos tienen miembros.
IGMP también se utiliza como transporte para varios protocolos de multidifusión relacionados (por ejemplo, Protocolo de enrutamiento de multidifusión por vector de distancia [DVMRP] y Multidifusión independiente de protocolo versión 1 [PIMv1]).
Un dispositivo de enrutamiento recibe mensajes explícitos de unión y poda de aquellos dispositivos de enrutamiento vecinos que tienen miembros del grupo descendente. Cuando PIM es el protocolo de multidifusión en uso, IGMP comienza el proceso de la siguiente manera:
Para unirse a un grupo de multidifusión, G, un host transmite su información de membresía a través de IGMP.
A continuación, el dispositivo de enrutamiento reenvía los paquetes de datos dirigidos a un grupo G de multidifusión sólo a aquellas interfaces en las que se han recibido mensajes de unión explícitos.
Un enrutador designado (DR) envía mensajes periódicos de unión y poda hacia un punto de encuentro (RP) específico del grupo para cada grupo para el que tiene miembros activos. Uno o más dispositivos de enrutamiento se designan automática o estáticamente como RP, y todos los dispositivos de enrutamiento deben unirse explícitamente a través del RP.
Cada dispositivo de enrutamiento a lo largo de la ruta hacia el RP crea un estado comodín (cualquier origen) para el grupo y envía mensajes de unión y poda hacia el RP.
El término entrada de ruta se utiliza para referirse al estado mantenido en un dispositivo de enrutamiento para representar el árbol de distribución.
Una entrada de ruta puede incluir campos como:
dirección de origen
Dirección del grupo
Interfaz entrante desde la que se aceptan paquetes
Lista de interfaces salientes a las que se envían paquetes
Temporizadores
marcar bits
La interfaz entrante de la entrada de ruta comodín apunta hacia el RP.
Las interfaces salientes apuntan a los dispositivos de enrutamiento descendentes vecinos que han enviado mensajes de unión y poda hacia el RP, así como a los hosts conectados directamente que han solicitado la pertenencia al grupo G.
Este estado crea un árbol de distribución compartido, centrado en RP, que llega a todos los miembros del grupo.
IGMP también se utiliza como transporte para varios protocolos de multidifusión relacionados (por ejemplo, Protocolo de enrutamiento de multidifusión por vector de distancia [DVMRP] y Multidifusión independiente de protocolo versión 1 [PIMv1]).
A partir de Junos OS versión 15.2, PIMv1 no es compatible.
IGMP es una parte integral de IP y debe habilitarse en todos los dispositivos de enrutamiento y hosts que necesitan recibir tráfico de multidifusión IP.
Para cada red conectada, un dispositivo de enrutamiento de multidifusión puede ser un querier o un nonquerier. El dispositivo de enrutamiento de consulta envía periódicamente mensajes de consulta generales para solicitar información de pertenencia a grupos. Los hosts de la red que son miembros de un grupo de multidifusión envían mensajes de informe. Cuando un host abandona un grupo, envía un mensaje de abandono del grupo.
IGMP versión 3 (IGMPv3) admite listas de inclusión y exclusión. Las listas de inclusión permiten especificar qué orígenes se pueden enviar a un grupo de multidifusión. Este tipo de grupo de multidifusión se denomina grupo de multidifusión específico del origen (SSM) y su dirección de multidifusión es 232/8.
IGMPv3 proporciona compatibilidad con el filtrado de código fuente. Por ejemplo, un dispositivo de enrutamiento puede especificar dispositivos de enrutamiento particulares desde los que acepta o rechaza tráfico. Con IGMPv3, un dispositivo de enrutamiento de multidifusión puede aprender qué fuentes son de interés para los dispositivos de enrutamiento vecinos.
El modo de exclusión funciona de manera opuesta a una lista de inclusión. Permite que cualquier fuente, excepto las enumeradas, envíe al grupo SSM.
IGMPv3 interopera con las versiones 1 y 2 del protocolo. Sin embargo, para seguir siendo compatibles con hosts IGMP y dispositivos de enrutamiento más antiguos, los dispositivos de enrutamiento IGMPv3 también deben implementar las versiones 1 y 2 del protocolo. IGMPv3 admite los siguientes tipos de registros de informes de membresía: se permite el modo, permitir nuevas fuentes y bloquear fuentes antiguas.
Ver también
Configuración de IGMP
Antes de empezar:
Determine si el enrutador está conectado directamente a algún origen de multidifusión. Los receptores deben ser capaces de localizar estas fuentes.
Determine si el enrutador está conectado directamente a algún receptor de grupo de multidifusión. Si hay receptores presentes, se necesita IGMP.
Determine si desea configurar la multidifusión para utilizar el modo disperso, denso o disperso. Cada modo tiene diferentes consideraciones de configuración.
Determine la dirección del RP si se utiliza el modo disperso o de densidad dispersa.
Determine si desea localizar el RP con la configuración estática, BSR o el método de RP automático.
Determine si desea configurar la multidifusión para que utilice su propia tabla de enrutamiento RPF al configurar PIM en modo disperso, denso o de densidad dispersa.
Configure los protocolos SAP y SDP para escuchar anuncios de sesiones de multidifusión. Consulte Configuración del protocolo de anuncio de sesión.
Para configurar el Protocolo de administración de grupos de Internet (IGMP), incluya la igmp
instrucción:
igmp { accounting; interface interface-name { disable; (accounting | no-accounting); group-policy [ policy-names ]; immediate-leave; oif-map map-name; promiscuous-mode; ssm-map ssm-map-name; static { group multicast-group-address { exclude; group-count number; group-increment increment; source ip-address { source-count number; source-increment increment; } } } version version; } query-interval seconds; query-last-member-interval seconds; query-response-interval seconds; robust-count number; traceoptions { file filename <files number> <size size> <world-readable | no-world-readable>; flag flag <flag-modifier> <disable>; } }
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit protocols]
[edit logical-systems logical-system-name protocols]
De forma predeterminada, IGMP está habilitado en todas las interfaces en las que configure la multidifusión independiente del protocolo (PIM) y en todas las interfaces de difusión en las que configure el Protocolo de enrutamiento de multidifusión por vector de distancia (DVMRP).
Puede configurar IGMP en una interfaz sin configurar PIM. PIM generalmente no es necesario en interfaces descendentes IGMP. Por lo tanto, solo se crea una "interfaz pseudoPIM" para representar todas las interfaces IGMP descendentes (solo IGMP) en el enrutador. Esto reduce la cantidad de recursos del enrutador, como la memoria, que se consumen. Debe configurar PIM en las interfaces IGMP ascendentes para habilitar el enrutamiento de multidifusión, realizar el reenvío de ruta inversa para paquetes de datos de multidifusión, rellenar la tabla de reenvío de multidifusión para las interfaces ascendentes y, en el caso de los modos dispersos PIM y PIM bidireccionales, distribuir las pertenencias a grupos IGMP en el dominio de enrutamiento de multidifusión.
Habilitación de IGMP
El Protocolo de administración de grupos de Internet (IGMP) administra los grupos de multidifusión mediante el establecimiento, el mantenimiento y la eliminación de grupos en una subred. Los dispositivos de enrutamiento de multidifusión utilizan IGMP para saber qué grupos tienen miembros en cada una de sus redes físicas conectadas. IGMP debe estar habilitado para que el enrutador reciba paquetes de multidifusión IPv4. IGMP solo es necesario para redes IPv4, ya que la multidifusión se maneja de manera diferente en las redes IPv6. IGMP se habilita automáticamente en todas las interfaces IPv4 en las que configure PIM y en todas las interfaces de difusión IPv4 cuando configure DVMRP.
Si IGMP no se ejecuta en una interfaz, ya sea porque PIM y DVMRP no están configurados en la interfaz o porque IGMP está explícitamente deshabilitado en la interfaz, puede habilitar explícitamente IGMP.
Para habilitar explícitamente IGMP:
Ver también
Modificación del intervalo de mensajes de consulta de host IGMP
El objetivo de IGMP es mantener los enrutadores actualizados con la pertenencia a grupos de toda la subred. Los enrutadores no necesitan saber quiénes son todos los miembros, solo que existen miembros. Cada host realiza un seguimiento de los grupos de multidifusión a los que están suscritos. En cada enlace, un enrutador es elegido el querier. El enrutador de consulta IGMP envía periódicamente mensajes generales de consulta de host en cada red conectada para solicitar información de membresía. Los mensajes se envían a la dirección del grupo de multidifusión de todos los sistemas, 224.0.0.1.
El intervalo de consulta, el intervalo de respuesta y la variable de solidez están relacionados en el sentido de que son variables que se usan para calcular el tiempo de espera de pertenencia a grupos. El tiempo de espera de pertenencia a grupos es el número de segundos que deben pasar antes de que un enrutador de multidifusión determine que no existen más miembros de un grupo host en una subred. El tiempo de espera de pertenencia al grupo se calcula como (variable de robustez x intervalo de consulta) + (intervalo de respuesta de consulta). Si no se reciben informes para un grupo determinado antes de que expire el tiempo de espera de pertenencia a grupos, el dispositivo de enrutamiento deja de reenviar paquetes de multidifusión originados remotamente para ese grupo a la red conectada.
De forma predeterminada, los mensajes de consulta de host se envían cada 125 segundos. Puede cambiar este intervalo para cambiar el número de mensajes IGMP enviados a la subred.
Para modificar el intervalo de consulta:
Ver también
Modificación del intervalo de respuesta de consulta IGMP
El intervalo de respuesta de consulta es la cantidad máxima de tiempo que puede transcurrir entre el momento en que el enrutador de consulta envía un mensaje de consulta de host y el momento en que recibe una respuesta de un host. La configuración de este intervalo permite ajustar los picos de ráfaga de los mensajes IGMP en la subred. Establezca un intervalo mayor para que el tráfico sea menos intenso. El tráfico en ráfaga se refiere a un patrón desigual de transmisión de datos: a veces una velocidad de transmisión de datos muy alta, mientras que otras veces una velocidad de transmisión de datos muy baja.
El intervalo de respuesta de consulta, el intervalo de consulta de host y la variable de solidez están relacionados en el sentido de que son variables que se usan para calcular el tiempo de espera de pertenencia a grupos. El tiempo de espera de pertenencia a grupos es el número de segundos que deben pasar antes de que un enrutador de multidifusión determine que no existen más miembros de un grupo host en una subred. El tiempo de espera de pertenencia al grupo se calcula como (variable de robustez x intervalo de consulta) + (intervalo de respuesta de consulta). Si no se reciben informes para un grupo determinado antes de que expire el tiempo de espera de pertenencia al grupo, el dispositivo de enrutamiento deja de reenviar paquetes de multidifusión originados remotamente para ese grupo a la red conectada.
El intervalo de respuesta de consulta predeterminado es de 10 segundos. Puede configurar un intervalo de subsegundos de hasta un dígito a la derecha del punto decimal. El rango configurable es de 0,1 a 0,9, luego en intervalos de 1 segundo de 1 a 999.999.
Para modificar el intervalo de respuesta a la consulta:
Ver también
Especificación de la eliminación inmediata de host para IGMP
La configuración de licencia inmediata es útil para minimizar la latencia de licencia de las membresías IGMP. Cuando esta opción está habilitada, el dispositivo de enrutamiento abandona el grupo de multidifusión inmediatamente después de que el último host abandone el grupo de multidifusión.
La configuración de licencia inmediata permite el seguimiento del host, lo que significa que el dispositivo realiza un seguimiento de los hosts que envían mensajes de unión. Esto permite a IGMP determinar cuándo el último host envía un mensaje de exclusión para el grupo de multidifusión.
Cuando la opción de licencia inmediata está habilitada, el dispositivo quita una interfaz de la entrada de la tabla de reenvío sin enviar primero consultas específicas del grupo IGMP a la interfaz. La interfaz se poda del árbol de multidifusión para el grupo de multidifusión especificado en el mensaje de licencia IGMP. La configuración de licencia inmediata garantiza una administración óptima del ancho de banda para los hosts de una red conmutada, incluso cuando se utilizan varios grupos de multidifusión simultáneamente.
Cuando la licencia inmediata está deshabilitada y un host envía un mensaje de salida de grupo, el dispositivo de enrutamiento envía primero una consulta de grupo para determinar si otro receptor responde. Si ningún receptor responde, el dispositivo de enrutamiento quita todos los hosts de la interfaz del grupo de multidifusión. La licencia inmediata está deshabilitada de forma predeterminada tanto para IGMP versión 2 como para IGMP versión 3.
Aunque el seguimiento de host está habilitado para IGMPv2 y MLDv1 cuando habilita la licencia inmediata, use la licencia inmediata con estas versiones solo cuando haya un host en la interfaz. La razón es que IGMPv2 y MLDv1 utilizan un mecanismo de supresión de informes mediante el cual solo un host en una interfaz envía un informe de unión a un grupo en respuesta a una consulta de pertenencia. Los otros hosts interesados suprimen sus informes. El propósito de este mecanismo es evitar una avalancha de informes para el mismo grupo. Pero también interfiere con el seguimiento del host, porque el enrutador solo sabe sobre el host interesado y no sabe sobre los demás.
Para habilitar la licencia inmediata en una interfaz:
Ver también
Filtrado de informes IGMP no deseados en el nivel de interfaz IGMP
Supongamos que necesita limitar las subredes que pueden unirse a un determinado grupo de multidifusión. La group-policy
instrucción permite filtrar informes IGMP no deseados en el nivel de interfaz. Cuando esta instrucción está habilitada en un enrutador que ejecuta IGMP versión 2 (IGMPv2) o versión 3 (IGMPv3), después de que el enrutador recibe un informe IGMP, el enrutador compara el grupo con la directiva de grupo especificada y realiza la acción configurada en esa política (por ejemplo, rechaza el informe si la directiva coincide con la dirección o red definidas).
La directiva se define para que coincida únicamente con las direcciones de grupo IGMP (para IGMPv2) mediante la instrucción de la directiva para que coincida con la dirección del route-filter
grupo. La directiva se define para que coincida con las direcciones IGMP (origen, grupo) (para IGMPv3) utilizando la instrucción de route-filter
la directiva para que coincida con la dirección del grupo y la instrucción de source-address-filter
la directiva para que coincida con la dirección de origen.
En las plataformas de la serie MX, IGMPv2 e IGMPv3 pueden o no configurarse juntos en la misma interfaz, según la versión de Junos OS en su instalación. Configurar ambos juntos puede provocar un comportamiento inesperado en el reenvío de tráfico de multidifusión.
Para filtrar informes IGMP no deseados:
Ver también
Aceptar mensajes IGMP de subredes remotas
De forma predeterminada, las interfaces IGMP solo aceptan mensajes IGMP de la misma subred. La inclusión de la promiscuous-mode
instrucción permite que el dispositivo de enrutamiento acepte mensajes IGMP de subredes conectadas indirectamente.
Cuando habilite IGMP en una interfaz Ethernet no numerada que utilice una dirección de circuito cerrado /32 como dirección de donante, debe configurar el modo promiscuo IGMP para aceptar los paquetes IGMP recibidos en esta interfaz.
Cuando se habilita el modo promiscuo, todos los enrutadores del segmento Ethernet deben configurarse con la instrucción de modo promiscuo. De lo contrario, solo la interfaz configurada con la dirección IPv4 más baja actúa como la consulta para IGMP para este segmento de Ethernet.
Para habilitar el modo promiscuo IGMP en una interfaz:
Ver también
Modificación del intervalo de consulta del último miembro IGMP
El intervalo de consulta de último miembro es la cantidad máxima de tiempo entre los mensajes de consulta específicos del grupo, incluidos los enviados en respuesta a los mensajes de grupo de salida. Puede configurar este intervalo para cambiar la cantidad de tiempo que tarda un dispositivo de enrutamiento en detectar la pérdida del último miembro de un grupo.
Cuando el dispositivo de enrutamiento que actúa como consulta recibe un mensaje de grupo de salida de un host, el dispositivo de enrutamiento envía varias consultas específicas de grupo al grupo que se va a dejar. El solicitante envía un número específico de estas consultas en un intervalo específico. El número de consultas enviadas se denomina recuento de consultas del último miembro. El intervalo en el que se envían las consultas se denomina intervalo de consulta del último miembro. Dado que ambas opciones son configurables, puede ajustar la latencia de licencia. La latencia de salida IGMP es el tiempo transcurrido entre una solicitud para abandonar un grupo de multidifusión y la recepción del último byte de datos para el grupo de multidifusión.
El recuento de consultas de último miembro x (veces) el intervalo de consulta de último miembro = (igual) la cantidad de tiempo que tarda un dispositivo de enrutamiento en determinar que el último miembro de un grupo ha abandonado el grupo y en detener el reenvío del tráfico del grupo.
El intervalo de consulta predeterminado del último miembro es de 1 segundo. Puede configurar un intervalo de subsegundos de hasta un dígito a la derecha del punto decimal. El rango configurable es de 0,1 a 0,9, luego en intervalos de 1 segundo de 1 a 999.999.
Para modificar este intervalo:
Puede configurar el recuento de consultas de último miembro configurando la variable de solidez. Los dos son siempre iguales.
Ver también
Modificación de la variable de robustez IGMP
Ajuste la variable de robustez IGMP para permitir la pérdida esperada de paquetes en una subred. El recuento robusto cambia automáticamente ciertos intervalos de mensajes IGMP para IGMPv2 e IGMPv3. El aumento del conteo robusto permite más pérdida de paquetes, pero aumenta la latencia de licencia de la subred.
Cuando el enrutador de consulta recibe un mensaje de licencia IGMP en una red compartida que ejecuta IGMPv2, el enrutador de consulta debe enviar un mensaje de consulta de grupo IGMP un número especificado de veces. El número de mensajes de consulta de grupo IGMP enviados está determinado por el recuento robusto.
El valor de la variable de robustez también se utiliza para calcular los siguientes intervalos de mensajes IGMP:
Intervalo de miembros del grupo: cantidad de tiempo que debe pasar antes de que un enrutador de multidifusión determine que no hay más miembros de un grupo en una red. Este intervalo se calcula de la siguiente manera: (variable de robustez x intervalo de consulta) + (1 x intervalo de respuesta-consulta).
Otro intervalo actual de consulta: el recuento robusto se utiliza para calcular la cantidad de tiempo que debe pasar antes de que un enrutador de multidifusión determine que ya no hay otro enrutador de multidifusión que sea el consulta. Este intervalo se calcula de la siguiente manera: (variable de robustez x intervalo de consulta) + (0,5 x intervalo de respuesta-consulta).
Recuento de consultas de último miembro: número de consultas específicas de grupo enviadas antes de que el enrutador asuma que no hay miembros locales de un grupo. El número de consultas es igual al valor de la variable de robustez.
En IGMPv3, un cambio de estado de interfaz hace que el sistema transmita inmediatamente un informe de cambio de estado desde esa interfaz. En caso de que uno o más enrutadores de multidifusión pierdan el informe de cambio de estado, se retransmite. El número de veces que se retransmite es el recuento robusto menos uno. En IGMPv3, el recuento robusto también es un factor para determinar el intervalo de pertenencia al grupo, el intervalo de consulta de la versión anterior y el otro intervalo presente de la consulta.
De forma predeterminada, la variable de robustez se establece en 2. Es posible que desee aumentar este valor si espera que una subred pierda paquetes.
El número puede ser del 2 al 10.
Para cambiar el valor de la variable de robustez:
Ver también
Limitar la velocidad máxima de mensajes IGMP
En esta sección se describe cómo cambiar el límite para el número máximo de paquetes IGMP transmitidos en 1 segundo por el enrutador.
Aumentar el número máximo de paquetes IGMP transmitidos por segundo podría ser útil en un enrutador con un gran número de interfaces que participan en IGMP.
Para cambiar el límite del número máximo de paquetes IGMP que el enrutador puede transmitir en 1 segundo, incluya la maximum-transmit-rate
instrucción y especifique el número máximo de paquetes por segundo que se transmitirán.
Ver también
Cambio de la versión IGMP
De forma predeterminada, el dispositivo de enrutamiento ejecuta IGMPv2. Los dispositivos de enrutamiento que ejecutan diferentes versiones de IGMP determinan la versión común más baja de IGMP compatible con los hosts de su subred y funcionan en esa versión.
Para habilitar la funcionalidad de multidifusión específica del origen (SSM), debe configurar la versión 3 en el host y en el dispositivo de enrutamiento conectado directamente del host. Si se especifica una dirección de origen en un grupo de multidifusión configurado estáticamente, la versión debe establecerse en IGMPv3.
Si se configura un grupo de multidifusión estática con la dirección de origen definida y la versión del IGMP está configurada para ser la versión 2, el origen se omite y sólo se agrega el grupo. En este caso, la unión se trata como una unión de grupo IGMPv2.
Si configura la opción de versión IGMP en el nivel de jerarquía de interfaz individual, se invalida la interface all
instrucción. Es decir, la nueva interfaz no hereda el número de versión que especificó con la interface all
instrucción. De forma predeterminada, esa nueva interfaz está habilitada con version 2
. Debe especificar explícitamente un version number
al agregar una nueva interfaz. Por ejemplo, si especificó version 3
con interface all
, deberá configurar la version 3
instrucción para la nueva interfaz. Además, si configura una interfaz para un grupo de multidifusión en el nivel jerárquico, debe especificar uno version number
y los demás parámetros de [edit interface interface-name static group multicast-group-address]
grupo. De lo contrario, la interfaz se habilita con el valor predeterminado version 2
.
Si ya configuró el dispositivo de enrutamiento para usar IGMP versión 1 (IGMPv1) y, a continuación, configurarlo para usar IGMPv2, el dispositivo de enrutamiento continuará usando IGMPv1 durante un máximo de 6 minutos y, a continuación, usa IGMPv2.
Para cambiar a IGMPv3 para la funcionalidad de SSM:
En las plataformas de la serie MX, IGMPv2 e IGMPv3 pueden o no configurarse juntos en la misma interfaz, según la versión de Junos OS en su instalación. Configurar ambos juntos puede provocar un comportamiento inesperado en el reenvío de tráfico de multidifusión.
Ver también
Habilitación de la pertenencia a grupos estáticos IGMP
Puede crear la pertenencia a grupos estáticos IGMP para probar el reenvío de multidifusión sin un host receptor. Cuando se habilita la pertenencia a grupos estáticos IGMP, los datos se reenvían a una interfaz sin que dicha interfaz reciba informes de pertenencia de hosts posteriores. El enrutador en el que habilite la pertenencia a grupos IGMP estáticos debe ser el enrutador designado (DR) para la subred. De lo contrario, el tráfico no fluye aguas abajo.
Al habilitar la pertenencia a grupos estáticos IGMP, no puede configurar varios grupos mediante las instrucciones group-count, group-increment, source-count y source-increment
si se especifica la opción all como interfaz IGMP.
El ajuste de clase de servicio (CoS) no se admite con la pertenencia a grupos estáticos IGMP.
En este ejemplo, se crea el grupo estático 233.252.0.1.
Cuando configura entradas de grupo IGMP estáticas en vínculos punto a punto que conectan dispositivos de enrutamiento a un punto de encuentro (RP), las entradas de grupo IGMP estáticas no generan mensajes de unión hacia el RP.
Cuando cree la pertenencia a grupos estáticos IGMP para probar el reenvío de multidifusión en una interfaz en la que desee recibir tráfico de multidifusión, puede especificar que se creen automáticamente varios grupos estáticos. Esto resulta útil cuando desea probar el reenvío a varios receptores sin tener que configurar cada receptor por separado.
En este ejemplo, se crean tres grupos.
En el DR, configure el número de grupos estáticos que se crearán incluyendo la
group-count
instrucción y especificando el número de grupos que se crearán.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 group-count 3
Después de confirmar la configuración, utilice el
show configuration protocol igmp
comando para comprobar la configuración del protocolo IGMP.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { static { group 233.252.0.1 { group-count 3; } } }
Después de confirmar la configuración y después de que el origen envíe tráfico, utilice el
show igmp group
comando para comprobar que se han creado los grupos estáticos 233.252.0.1, 233.252.0.2 y 233.252.0.3.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.2 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.3 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
Al crear la pertenencia a grupos estáticos IGMP para probar el reenvío de multidifusión en una interfaz en la que desea recibir tráfico de multidifusión, también puede configurar la dirección del grupo para que se incremente automáticamente para cada grupo creado. Esto resulta útil cuando desea probar el reenvío a varios receptores sin tener que configurar cada receptor por separado y cuando no desea que las direcciones de grupo sean secuenciales.
En este ejemplo, se crean tres grupos y se aumenta la dirección del grupo en un incremento de dos para cada grupo.
En el DR, configure el incremento de dirección de grupo incluyendo la
group-increment
instrucción y especificando el número en el que se debe incrementar la dirección para cada grupo. El incremento se especifica en notación decimal punteada similar a una dirección IPv4.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 group-count 3 group-increment 0.0.0.2
Después de confirmar la configuración, utilice el
show configuration protocol igmp
comando para comprobar la configuración del protocolo IGMP.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { group-increment 0.0.0.2; group-count 3; } } }
Después de confirmar la configuración y de que el origen envíe tráfico, utilice el
show igmp group
comando para comprobar que se han creado los grupos estáticos 233.252.0.1, 233.252.0.3 y 233.252.0.5.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.3 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.5 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
Cuando crea la pertenencia a grupos estáticos IGMP para probar el reenvío de multidifusión en una interfaz en la que desea recibir tráfico de multidifusión y su red funciona en modo de multidifusión específica del origen (SSM), también puede especificar que se acepte la dirección de origen de multidifusión. Esto resulta útil cuando desea probar el reenvío a receptores de multidifusión desde un origen de multidifusión específico.
Si especifica una dirección de grupo en el intervalo de SSM, también debe especificar un origen.
Si se especifica una dirección de origen en un grupo de multidifusión configurado estáticamente, la versión de IGMP en la interfaz debe establecerse en IGMPv3. IGMPv2 es el valor predeterminado.
En este ejemplo, se crea el grupo 233.252.0.1 y se acepta la dirección IP 10.0.0.2 como único origen.
En el DR, configure la dirección de origen incluyendo la
source
instrucción y especificando la dirección IPv4 del host de origen.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 source 10.0.0.2
Después de confirmar la configuración, utilice el
show configuration protocol igmp
comando para comprobar la configuración del protocolo IGMP.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { source 10.0.0.2; } } }
Después de confirmar la configuración y el origen envía tráfico, utilice el comando para comprobar que se ha creado el
show igmp group
grupo estático 233.252.0.1 y que se ha aceptado el origen 10.0.0.2.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
Al crear la pertenencia a grupos estáticos IGMP para probar el reenvío de multidifusión en una interfaz en la que desea recibir tráfico de multidifusión, puede especificar que se acepten automáticamente varios orígenes de multidifusión. Esto resulta útil cuando se desea probar el reenvío a receptores de multidifusión desde más de un origen de multidifusión especificado.
En este ejemplo, se crea el grupo 233.252.0.1 y se aceptan las direcciones 10.0.0.2, 10.0.0.3 y 10.0.0.4 como orígenes.
En la DR, configure el número de direcciones de origen de multidifusión que se aceptarán incluyendo la
source-count
instrucción y especificando el número de orígenes que se van a aceptar.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 source 10.0.0.2 source-count 3
Después de confirmar la configuración, utilice el
show configuration protocol igmp
comando para comprobar la configuración del protocolo IGMP.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { source 10.0.0.2 { source-count 3; } } } }
Después de confirmar la configuración y el origen envía tráfico, utilice el comando para comprobar que se ha creado el
show igmp group
grupo estático 233.252.0.1 y que se han aceptado los orígenes 10.0.0.2, 10.0.0.3 y 10.0.0.4.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.3 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.4 Last reported by: Local Timeout: 0 Type: Static
Cuando configure grupos estáticos en una interfaz en la que desee recibir tráfico de multidifusión y especifique que se acepten automáticamente varios orígenes de multidifusión, también puede especificar el número en el que se debe incrementar la dirección para cada origen aceptado. Esto resulta útil cuando desea probar el reenvío a varios receptores sin tener que configurar cada receptor por separado y no desea que las direcciones de origen sean secuenciales.
En este ejemplo, se crea el grupo 233.252.0.1 y se aceptan las direcciones 10.0.0.2, 10.0.0.4 y 10.0.0.6 como orígenes.
Configure el incremento de la dirección de origen de multidifusión incluyendo la
source-increment
instrucción y especificando el número en el que se debe incrementar la dirección para cada origen. El incremento se especifica en notación decimal punteada similar a una dirección IPv4.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 source 10.0.0.2 source-count 3 source-increment 0.0.0.2
Después de confirmar la configuración, utilice el
show configuration protocol igmp
comando para comprobar la configuración del protocolo IGMP.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { source 10.0.0.2 { source-count 3; source-increment 0.0.0.2; } } } }
Después de confirmar la configuración y después de que el origen envíe tráfico, utilice el comando para comprobar que se ha creado el
show igmp group
grupo estático 233.252.0.1 y que se han aceptado los orígenes 10.0.0.2, 10.0.0.4 y 10.0.0.6.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.4 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.6 Last reported by: Local Timeout: 0 Type: Static
Cuando configure grupos estáticos en una interfaz en la que desee recibir tráfico de multidifusión y la red funcione en modo de multidifusión específica del origen (SSM), puede especificar que se excluyan determinadas direcciones de origen de multidifusión.
De forma predeterminada, la dirección de origen de multidifusión configurada en un grupo estático funciona en modo de inclusión. En el modo de inclusión, el tráfico de multidifusión para el grupo se acepta desde la dirección de origen configurada. También puede configurar el grupo estático para que funcione en modo de exclusión. En el modo de exclusión, el tráfico de multidifusión del grupo se acepta desde cualquier dirección que no sea la dirección de origen configurada.
Si se especifica una dirección de origen en un grupo de multidifusión configurado estáticamente, la versión de IGMP en la interfaz debe establecerse en IGMPv3. IGMPv2 es el valor predeterminado.
En este ejemplo, se excluye la dirección 10.0.0.2 como origen para el grupo 233.252.0.1.
En la recuperación ante desastres, configure un grupo estático de multidifusión para que funcione en modo de exclusión incluyendo la
exclude
instrucción y especificando qué dirección de origen IPv4 desea excluir.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 exclude source 10.0.0.2
Después de confirmar la configuración, utilice el
show configuration protocol igmp
comando para comprobar la configuración del protocolo IGMP.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { exclude; source 10.0.0.2; } } }
Después de confirmar la configuración y el origen envía tráfico, utilice el comando para comprobar que se ha creado el
show igmp group detail
grupo estático 233.252.0.1 y que el grupo estático funciona en modo de exclusión.user@host> show igmp group detail Interface: fe-0/1/2 Group: 233.252.0.1 Group mode: Exclude Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
Ver también
Grabación de eventos IGMP Join and Leave
Para determinar si es necesario ajustar IGMP en una red, puede configurar el dispositivo de enrutamiento para grabar eventos de unión y salida IGMP. Puede registrar eventos globalmente para el dispositivo de enrutamiento o para interfaces individuales.
En la Tabla 1 se describen los eventos IGMP registrables.
Etiqueta ERRMSG |
Definición |
---|---|
RPD_IGMP_JOIN |
Registra eventos de unión IGMP. |
RPD_IGMP_LEAVE |
Registra eventos de salida IGMP. |
RPD_IGMP_ACCOUNTING_ON |
Registra cuándo está habilitada la contabilidad IGMP en una interfaz IGMP. |
RPD_IGMP_ACCOUNTING_OFF |
Registra cuando la contabilidad IGMP está deshabilitada en una interfaz IGMP. |
RPD_IGMP_MEMBERSHIP_TIMEOUT |
Registra los eventos de tiempo de espera de membresía IGMP. |
Para habilitar la contabilidad IGMP:
Ver también
Limitar el número de uniones de grupos de multidifusión IGMP en interfaces lógicas
La group-limit
instrucción permite limitar el número de combinaciones de grupos de multidifusión IGMP para interfaces lógicas. Cuando esta instrucción está habilitada en un enrutador que ejecuta IGMP versión 2 (IGMPv2) o versión 3 (IGMPv3), el límite se aplica al recibir el informe de grupo. Una vez que se alcanza el límite de grupo, se rechazan las solicitudes de unión posteriores.
Al configurar límites para grupos de multidifusión IGMP, tenga en cuenta lo siguiente:
Cada grupo de cualquier fuente (*,G) cuenta como un grupo hacia el límite.
Cada grupo específico de la fuente (S, G) cuenta como un grupo hacia el límite.
Los grupos en el modo de exclusión IGMPv3 se cuentan para el límite.
Varios grupos específicos de origen cuentan individualmente para el límite de grupo, incluso si pertenecen al mismo grupo. Por ejemplo, (S1, G1) y (S2, G1) contarían como dos grupos para el límite configurado.
Las combinaciones de cualquier grupo de origen y grupos específicos de origen cuentan individualmente para el límite de grupo, incluso si son para el mismo grupo. Por ejemplo, (*, G1) y (S, G1) contarían como dos grupos para el límite configurado.
Si se configura y confirma un límite de grupo en una red inferior al que ya existe en la red, se eliminan todos los grupos de la configuración. A continuación, los grupos deben solicitar volver a unirse a la red (hasta el límite de grupo recién configurado).
Puede limitar dinámicamente los grupos de multidifusión en interfaces lógicas IGMP mediante perfiles dinámicos.
A partir de Junos OS versión 12.2, opcionalmente puede configurar un umbral de advertencia de registro del sistema para las uniones de grupos de multidifusión IGMP recibidas en la interfaz lógica. Es útil revisar los mensajes de registro del sistema con fines de solución de problemas y detectar si se ha recibido una cantidad excesiva de combinaciones de grupos de multidifusión IGMP en la interfaz. Estos mensajes de registro transmiten cuando se ha superado el límite de grupos configurado, cuando se ha superado el umbral configurado y cuando el número de grupos cae por debajo del umbral configurado.
La group-threshold
instrucción permite configurar el umbral en el que se registra un mensaje de advertencia. El rango es de 1 a 100 por ciento. El umbral de advertencia es un porcentaje del límite de grupo, por lo que debe configurar la group-limit
instrucción para configurar un umbral de advertencia. Por ejemplo, cuando el número de grupos supera el umbral de advertencia configurado, pero permanece por debajo del límite de grupos configurado, se siguen aceptando grupos de multidifusión y el dispositivo registra el mensaje de advertencia. Además, el dispositivo registra un mensaje de advertencia después de que el número de grupos caiga por debajo del umbral de advertencia configurado. Además, puede especificar la cantidad de tiempo (en segundos) entre los mensajes de registro configurando la log-interval
instrucción. El rango es de 6 a 32,767 segundos.
Podría considerar la posibilidad de limitar los mensajes de registro porque cada entrada agregada después del umbral configurado y cada entrada rechazada después del límite configurado provoca un mensaje de advertencia. Mediante la configuración de un intervalo de registro, puede limitar la cantidad de mensajes de advertencia de registro del sistema generados para las uniones de grupos de multidifusión IGMP.
En los enrutadores de la serie ACX, el número máximo de rutas de multidifusión es 1024.
Para limitar las uniones de grupos de multidifusión en una interfaz lógica IGMP:
Para confirmar la configuración, utilice el show protocols igmp
comando. Para comprobar el funcionamiento de IGMP en la interfaz, incluido el límite de grupo configurado y el umbral de advertencia opcional y el intervalo entre mensajes de registro, utilice el show igmp interface
comando.
Ver también
Rastreo del tráfico del protocolo IGMP
Las operaciones de seguimiento registran mensajes detallados sobre el funcionamiento de los protocolos de enrutamiento, como los distintos tipos de paquetes de protocolo de enrutamiento enviados y recibidos, y las acciones de directiva de enrutamiento. Puede especificar qué operaciones de seguimiento se registran incluyendo indicadores de seguimiento específicos. En la tabla siguiente se describen los indicadores que puede incluir.
Bandera |
Descripción |
---|---|
todo |
Realice un seguimiento de todas las operaciones. |
notificación al cliente |
Notificaciones de seguimiento. |
General |
Rastree el flujo general. |
grupo |
Rastrear operaciones de grupo. |
notificación de host |
Rastrear notificaciones de host. |
Salir |
Seguimiento de mensajes de grupo de salida (solo IGMPv2). |
mtrace |
Rastree paquetes mtrace. Utilice el |
normal |
Realizar un seguimiento de eventos normales. |
Paquetes |
Rastree todos los paquetes IGMP. |
política |
Seguimiento del procesamiento de políticas. |
consulta |
Realice un seguimiento de los mensajes de consulta de pertenencia a IGMP, incluidas las consultas generales y específicas del grupo. |
informe |
Seguimiento de mensajes de informes de pertenencia. |
ruta |
Rastrear la información de enrutamiento. |
estado |
Transiciones de estado de seguimiento. |
tarea |
Procesamiento de tareas de seguimiento. |
temporizador |
Procesamiento del temporizador de seguimiento. |
En el ejemplo siguiente, el seguimiento está habilitado para todos los paquetes de protocolo de enrutamiento. Luego, el seguimiento se reduce para centrarse solo en paquetes IGMP de un tipo particular. Para configurar operaciones de seguimiento para IGMP:
Ver también
Desactivación de IGMP
Para deshabilitar IGMP en una interfaz, incluya la disable
instrucción:
disable;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit protocols igmp interface interface-name]
[edit logical-systems logical-system-name protocols igmp interface interface-name]
Nota:Los enrutadores de la serie ACX no admiten
[edit logical-systems logical-system-name protocols]
el nivel de jerarquía.
Ver también
IGMP y enrutamiento activo sin interrupciones
Las configuraciones de enrutamiento activo sin paradas (NSR) incluyen dos motores de enrutamiento que comparten información para que el enrutamiento no se interrumpa durante la conmutación por error del motor de enrutamiento. Estas configuraciones NSR incluyen soporte pasivo con IGMP en conexión con PIM. El motor de enrutamiento principal utiliza IGMP para determinar su estado de multidifusión PIM, y esta información derivada de IGMP se replica en el motor de enrutamiento de reserva. IGMP en el nuevo motor de enrutamiento primario (después de la conmutación por error) vuelve a aprender la información de estado rápidamente a través de la operación IGMP. Mientras tanto, el nuevo motor de enrutamiento primario conserva el estado PIM derivado de IGMP tal como lo recibió el proceso de replicación del antiguo motor de enrutamiento primario. Esta información de estado agota el tiempo de espera a menos que IGMP lo actualice en el nuevo motor de enrutamiento principal. No se requiere ninguna configuración IGMP adicional.
Ver también
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.