Ejemplo: Configuración de la inspirización de multidifusión
Descripción de la inspirización de multidifusión
Los dispositivos de red, como los enrutadores, funcionan principalmente a nivel de paquete o de capa 3. Otros dispositivos de red, como puentes o conmutadores LAN, funcionan principalmente a nivel de trama o capa 2. La multidifusión funciona principalmente a nivel de paquete, capa 3, pero hay una forma de asignar direcciones de grupo de multidifusión IP de capa 3 a direcciones de grupo de multidifusión MAC de capa 2 en el nivel de trama.
Los enrutadores pueden manejar la información de direcciones de capa 2 y capa 3 porque la trama y sus direcciones se deben procesar para tener acceso al paquete encapsulado dentro. Los enrutadores pueden ejecutar protocolos de multidifusión de capa 3, como PIM o IGMP, y determinar dónde reenviar contenido de multidifusión o cuándo un host en una interfaz se une o abandona un grupo. Sin embargo, los puentes y conmutadores LAN, como dispositivos de capa 2, no deben tener acceso a la información de multidifusión dentro de los paquetes que transportan sus tramas.
¿Cómo son entonces los puentes y otros dispositivos de capa 2 para determinar cuándo un dispositivo en una interfaz se une o deja un árbol de multidifusión, o si un host en una LAN adjunta quiere recibir el contenido de un grupo de multidifusión determinado?
La respuesta es que el dispositivo de capa 2 implemente la supervisión de multidifusión. La supervisión de multidifusión es un término general y se aplica al proceso de un dispositivo de capa 2 "snooping" en el contenido del paquete de capa 3 para determinar qué acciones se toman para procesar o reenviar una trama. Hay formas más específicas de espionaje, como la supervisión IGMP o la supervisión PIM. En todos los casos, el espionaje implica que un dispositivo configurado para funcionar en la capa 2 tenga acceso a la información de capa 3 (paquete) normalmente "prohibida". El espionaje hace que la multidifusión sea más eficiente en estos dispositivos.
Consulte también
Descripción de la supervisión de multidifusión y la protección de raíz VPLS
La supervisión se produce cuando un protocolo de capa 2, como un protocolo de árbol de expansión, conoce los detalles operativos de un protocolo de capa 3, como el protocolo de administración de grupos de Internet (IGMP) u otro protocolo de multidifusión. La supervisión es necesaria cuando los dispositivos de capa 2, como los conmutadores VLAN, deben tener en cuenta la información de capa 3, como las direcciones de control de acceso de medios (MAC) de los miembros de un grupo de multidifusión.
La protección de raíz VPLS es un proceso de protocolo de árbol de expansión en el que solo una interfaz en un entorno multiconexión reenvía activamente tramas de protocolo de árbol de expansión. Esto protege la raíz del árbol de expansión contra los bucles de puente, pero también impide que ambos dispositivos de la topología multiconexión puedan obtener información de espionaje, como informes de pertenencia a IGMP.
Por ejemplo, considere una colección de hosts compatibles con multidifusión conectados a dos enrutadores de borde del cliente (CE1 y CE2) que están conectados entre sí (se configura un vínculo CE1-CE2) y multiconexión a dos enrutadores de borde de proveedor (PE1 y PE2, respectivamente). El PE activo solo recibe información de protocolo de árbol de expansión reenviada en el vínculo PE-CE activo, debido a la operación de protección raíz. Mientras el vínculo CE1-CE2 sea operativo, esto no es un problema. Sin embargo, si el vínculo entre CE1 y CE2 falla, y el otro PE se convierte en el vínculo activo del protocolo de árbol de expansión, no hay información de espionaje de multidifusión disponible en el nuevo PE activo. El nuevo PE activo no reenviará el tráfico de multidifusión al CE y a los hosts a los que presta servicio este enrutador CE.
La interrupción del servicio se corrige una vez que los hosts envían nuevos informes IGMP de membresía de grupo a los enrutadores CE. Sin embargo, se puede evitar la interrupción del servicio si la información de supervisión de multidifusión está disponible para ambos PEs, a pesar de la operación normal de protección raíz del protocolo de árbol de expansión.
Puede configurar el espionaje de multidifusión para ignorar los mensajes acerca de los cambios de topología de árbol de expansión en dominios de puente en conmutadores virtuales y dominios de puente de conmutadores de enrutamiento predeterminados. Puede usar el ignore-stp-topology-change comando para ignorar mensajes sobre cambios en la topología de árbol de expansión
Consulte también
Configuración de la inspirización de multidifusión
Para configurar los parámetros generales de espionaje de multidifusión para enrutadores serie MX, incluya la multicast-snooping-options instrucción:
multicast-snooping-options { flood-groups [ ip-addresses ]; forwarding-cache { threshold suppress value <reuse value>; } graceful-restart <restart-duration seconds>; ignore-stp-topology-change; multichassis-lag-replicate-state; nexthop-hold-time milliseconds; 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 routing-instances routing-instance-name][edit logical-systems logical-system-name routing-instances routing-instance-name]
De forma predeterminada, el espionaje de multidifusión está deshabilitado. Puede habilitar el espionaje de multidifusión en VPLS o tipos de instancia de conmutador virtual en la jerarquía de instancias.
Si hay varios dominios de puente configurados bajo una VPLS o una instancia de conmutador virtual, las opciones de espionaje de multidifusión configuradas en el nivel de instancia se aplican a todos los dominios de puente.
La ignore-stp-topology-change instrucción se admite solo para el tipo de instancia de enrutamiento de conmutador virtual y no se admite en la [edit logical-systems] jerarquía.
La nexthop-hold-time instrucción solo se admite en la [edit routing-instances routing-instance-name] jerarquía y solo para un tipo de instancia de conmutador virtual o vpls.
Consulte también
Ejemplo: Configuración de la inspirización de multidifusión
En este ejemplo, se muestra cómo configurar la inspirización de multidifusión en un escenario de puente o instancia de enrutamiento VPLS.
Requisitos
En este ejemplo, se utilizan los siguientes componentes de hardware:
Un enrutador serie MX
Un dispositivo de capa 3 que funciona como enrutador de multidifusión
Antes de comenzar:
Configure las interfaces.
Configure un protocolo de puerta de enlace interior. Consulte la biblioteca de protocolos de enrutamiento de Junos OS para dispositivos de enrutamiento.
Configure un protocolo de multidifusión. Esta función funciona con los siguientes protocolos de multidifusión:
DVMRP
PIM-DM
PIM-SM
PIM-SSM
Descripción general y topología
La supervisión IGMP impide que los dispositivos de capa 2 inunden indiscriminadamente el tráfico de multidifusión en todas las interfaces. La configuración que configure para la supervisión de multidifusión ayuda a administrar el comportamiento de la supervisión IGMP.
Puede configurar opciones de espionaje de multidifusión en la instancia maestra predeterminada y en instancias de puente o VPLS individuales. La configuración predeterminada de instancia maestra es global y se aplica a todas las instancias de puente o VPLS individuales en el enrutador lógico. La configuración de las instancias individuales anula la configuración global.
En este ejemplo, se incluyen las siguientes instrucciones:
grupos de inundación: le permite enumerar direcciones de grupo de multidifusión para las que se debe inundar el tráfico. Esta configuración si es útil para asegurarse de que la supervisión IGMP no impide la inundación de multidifusión necesaria. El bloque de direcciones de multidifusión de 224.0.0.1 a 224.0.0.255 está reservado para uso de cable local. Los grupos de este intervalo se asignan para varios usos, incluidos los protocolos de enrutamiento y los mecanismos de descubrimiento local. Por ejemplo, OSPF utiliza 224.0.0.5 para todos los enrutadores OSPF.
caché de reenvío: especifica cómo se envejecen las entradas de reenvío y cómo se controla la cantidad de entradas.
Puede configurar valores de umbral en la memoria caché de reenvío para suprimir (suspender) la inspección cuando las entradas de caché alcancen un determinado máximo y reutilizar la caché cuando el número cae a otro valor de umbral. De forma predeterminada, no se habilita ningún valor de umbral en el enrutador.
El umbral de supresión suprime las nuevas entradas de caché de reenvío de multidifusión. Un umbral de reutilización opcional especifica el punto en el que el enrutador comienza a crear nuevas entradas de caché de reenvío de multidifusión. El intervalo para ambos umbrales es del 1 al 200 000. Si está configurado, el valor de reutilización debe ser menor que el valor de supresión. El valor de supresión es obligatorio. Si no especifica el valor de reutilización opcional, el número de entradas de caché de reenvío de multidifusión se limita al valor de supresión. Se crea una nueva entrada tan pronto como el número de entradas de caché de reenvío de multidifusión cae por debajo del valor de supresión.
reinicio correcto: configura la hora después de la cual se sustituyen las rutas aprendidas antes de reiniciarlas por rutas que se vuelven a aprender. Si el reinicio correcto para el espionaje de multidifusión está deshabilitado, la información de espionaje se pierde después de reiniciar el motor de enrutamiento.
De forma predeterminada, la duración correcta del reinicio es de 180 segundos (3 minutos). Puede establecer este valor entre 0 y 300 segundos. Si establece la duración en 0, el reinicio correcto se deshabilita eficazmente. Establezca este valor un poco más grande que el intervalo de respuesta de la consulta IGMP.
ignore-stp-topology-change: configura el enrutador de la serie MX para ignorar los mensajes sobre el cambio de estado de la topología del árbol de expansión.
De forma predeterminada, el proceso de supervisión IGMP en un enrutador serie MX detecta los cambios de estado de interfaz realizados por cualquiera de los protocolos de árbol de expansión (STP).
En un entorno de multiconexión VPLS en el que dos enrutadores PE están conectados a dos enrutadores CE interconectados y la protección raíz STP está habilitada en los enrutadores de PE, una de las interfaces del enrutador de PE está en estado de reenvío y la otra está en estado de bloqueo.
Si el vínculo que interconecta los dos enrutadores CE falla, la interfaz del enrutador pe en el estado de bloqueo pasa al estado de reenvío.
La interfaz del enrutador de PE no espera a recibir informes de pertenencia en respuesta a la próxima consulta general o específica de grupo. En su lugar, el proceso de supervisión IGMP envía un mensaje de consulta general hacia el enrutador CE. Los hosts conectados al enrutador CE responden con informes para todos los grupos en los que están interesados.
Cuando se restaura el vínculo que interconecta los dos enrutadores CE, se restaura el estado original del árbol de expansión en ambos enrutadores PE. El PE de reenvío recibe un mensaje de cambio de topología de árbol de expansión y envía un mensaje de consulta general al enrutador CE para reconstruir inmediatamente el estado de pertenencia del grupo.
Nota:La
ignore-stp-topology-changeinstrucción solo se admite para el tipo de instancia de enrutamiento de conmutador virtual .
Topología
La Figura 1 muestra una topología multiconexión VPLS en la que una red de cliente tiene dos dispositivos CE con un vínculo entre ellos. Cada CE está conectada a un PE.
multiconexión VPLS
Configuración
Procedimiento
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía y, luego, ingrese commit desde el [edit] modo de configuración.
set bridge-domains domain1 multicast-snooping-options forwarding-cache threshold suppress 100 set bridge-domains domain1 multicast-snooping-options forwarding-cache threshold reuse 50 set bridge-domains domain1 multicast-snooping-options graceful-restart restart-duration 120 set routing-instances ce1 instance-type virtual-switch set routing-instances ce1 bridge-domains domain1 domain-type bridge set routing-instances ce1 bridge-domains domain1 vlan-id 100 set routing-instances ce1 bridge-domains domain1 interface ge-0/3/9.0 set routing-instances ce1 bridge-domains domain1 interface ge-0/0/6.0 set routing-instances ce1 bridge-domains domain1 multicast-snooping-options flood-groups 224.0.0.5 set routing-instances ce1 bridge-domains domain1 multicast-snooping-options ignore-stp-topology-change
Procedimiento paso a paso
En el ejemplo siguiente, debe navegar por varios niveles en la jerarquía de configuración. Para obtener más información sobre cómo navegar por la CLI, consulte la Guía del usuario de la CLI de Junos OS.
Para configurar la supervisión IGMP:
Configure la configuración de la inspección de multidifusión en la instancia de enrutamiento principal.
[edit bridge-domains domain1] user@host# set multicast-snooping-options forwarding-cache threshold suppress 100 reuse 50 user@host# set multicast-snooping-options graceful-restart 120
Configure la instancia de enrutamiento.
[edit routing-instances ce1] user@host# set instance-type virtual-switch
Configure el dominio de puente en la instancia de enrutamiento.
[edit routing-instances ce1 bridge-domains domain1] user@host# set domain-type bridge user@host# set interface ge-0/0/6.0 user@host# set interface ge-0/3/9.0 user@host# set vlan-id 100
Configure grupos de inundación.
[edit routing-instances ce1 bridge-domains domain1] user@host# set multicast-snooping-options flood-groups 224.0.0.5
Configure el enrutador para que ignore los mensajes acerca de los cambios en el estado de la topología del árbol de expansión.
[edit routing-instances ce1 bridge-domains domain1] user@host# set multicast-snooping-options ignore-stp-topology-change
Si ha terminado de configurar el dispositivo, confirme la configuración.
user@host# commit
Resultados
Confirme su configuración ingresando los show bridge-domains comandos y show routing-instances .
user@host# show bridge-domains
domain1 {
multicast-snooping-options {
forwarding-cache {
threshold {
suppress 100;
reuse 50;
}
}
}
}
user@host# show routing-instances
ce1 {
instance-type virtual-switch;
bridge-domains {
domain1 {
domain-type bridge;
vlan-id 100;
interface ge-0/3/9.0; ## 'ge-0/3/9.0' is not defined
interface ge-0/0/6.0; ## 'ge-0/0/6.0' is not defined
multicast-snooping-options {
flood-groups 224.0.0.5;
ignore-stp-topology-change;
}
}
}
}
Verificación
Para comprobar la configuración, ejecute los siguientes comandos:
muestra la interfaz de espionaje igmp
muestra la membresía de igmp snooping
muestra estadísticas de espionaje igmp
muestra la ruta de espionaje multidifusión
muestra la tabla de rutas
Habilitación de actualizaciones masivas para el espionaje de multidifusión
Cada vez que una interfaz individual se une o abandona un grupo de multidifusión, se instala una nueva entrada de salto siguiente en la tabla de enrutamiento y la tabla de reenvío. Puede usar la nexthop-hold-time instrucción para especificar un tiempo, de 1 a 1000 milisegundos (ms), durante el cual se acumulan los cambios de interfaz salientes y, a continuación, se actualizan de forma masiva a la tabla de enrutamiento y la tabla de reenvío. La actualización masiva reduce el tiempo de procesamiento y la sobrecarga de memoria necesarias para procesar la unión y dejar mensajes. Esto es útil para aplicaciones como la televisión Por Internet Potocol (IPTV), en la que los usuarios que cambian de canal pueden crear miles de interfaces que se unen o dejan un grupo en poco tiempo. En escenarios de IPTV, normalmente hay un número relativamente pequeño y controlado de secuencias y un alto número de interfaces salientes. El uso de actualizaciones masivas puede reducir el retraso de la unión.
En este ejemplo, configurará un tiempo de espera de 20 milisegundos para el conmutador virtual de tipo de instancia mediante la nexthop-hold-time instrucción:
Puede incluir la nexthop-hold-time instrucción solo para tipos de instancia de enrutamiento de conmutador virtual o vpls en el siguiente nivel jerárquico.
[edit routing-instances routing-instance-name multicast-snooping-options]
Si la nexthop-hold-time instrucción se elimina de la configuración del enrutador, se deshabilitan las actualizaciones masivas.
Consulte también
Habilitación de la inspirización de multidifusión para interfaces de grupo de agregación de vínculos multichasis
Incluya la multichassis-lag-replicate-state instrucción en el nivel de jerarquía para habilitar la [edit multicast-snooping-options] supervisión de IGMP y la replicación de estado para interfaces de grupo de agregación de vínculos multichasis (MC-LAG).
[edit]
multicast-snooping-options {
multichassis-lag-replicate-state;
}
Replicar la unión y dejar mensajes entre vínculos de una interfaz MC-LAG de doble vínculo permite una recuperación más rápida de la información de membresía para interfaces MC-LAG que experimentan la interrupción del servicio.
Sin replicación de estado, si una interfaz MC-LAG de vínculo dual experimenta una interrupción del servicio (por ejemplo, si un vínculo activo cambia a modo de espera), la información de pertenencia de la interfaz se recupera mediante la generación de una consulta IGMP a la red. Este método puede tardar de 1 a 10 segundos en completarse, lo que puede ser demasiado largo para algunas aplicaciones.
Cuando se proporciona replicación de estado para interfaces MC-LAG, el IGMP se une o deja los mensajes recibidos en un dispositivo MC-LAG se replican desde el vínculo MC-LAG activo al vínculo en espera mediante una conexión del Protocolo de comunicación de Interchassis (ICCP). El vínculo en espera procesa los mensajes como si se recibieran del vínculo MC-LAG activo correspondiente, excepto que no se agrega como un salto siguiente y no inunda el mensaje a la red. Después de una conmutación por error, el estado de pertenencia de multidifusión del vínculo se puede recuperar en unos segundos o menos mediante la recuperación de los mensajes replicados.
En este ejemplo, se habilita la replicación de estado para interfaces MC-LAG: