Reconstrucción de entradas multidifusión con CGMP y cambios de topología en el árbol de expansión

Introducción

Este documento describe cómo funciona el Cisco Group Management Protocol (CGMP) en los switches Cisco Catalyst y los routers Cisco IOS® con respecto a la reconstrucción de las entradas multicast para CGMP después de un cambio en la topología del spanning tree.

Prerequisites

Requirements

Cisco recomienda tener conocimientos de estos temas:

• operación básica de switches, routers y multidifusión

• funcionamiento básico del árbol de extensión, CGMP y el protocolo de administración de grupos de Internet (IGMP)

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Catalyst 3550 versión 12.1(9)EA1c

• Catalyst 2900/3500XL versión 12.0(5)WC3b

• Catalyst 4000 Supervisor Engine III versión 12.1(11b)EW

• Catalyst 4000 Supervisor Engine I/II versión 7.2(2)

• Catalyst 6500 Supervisor Engine Cisco IOS Software Release 12.1(11b)EX

• Catalyst 6500 Catalyst OS (CatOS) versión 7.2(2)

• Catalyst 5500 CatOS versión 4.5(13a)

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Cambios de CGMP y topología

Esta sección describe paso a paso lo que ocurre y los problemas que pueden surgir cuando se detecta un cambio de topología de árbol de expansión en una VLAN donde se utiliza CGMP para contener el tráfico multicast de la inundación en todos los puertos. Como muestra este ejemplo, la red analizada en este documento consta de un router, un switch y cuatro PC:

• puerto 1: receptor PC 1

• puerto 2: receptor PC 2

• puerto 3: receptor PC 3

• puerto 4: no es un receptor PC 4

• puerto 5 - otro switch (sin receptores o routers en este switch)

• port 48 — router del IOS de Cisco ejecutando IGMP y CGMP

A los efectos de este documento, se asume que los PC receptores utilizan IGMP y que el switch ejecuta CGMP. El router Cisco IOS ejecuta IGMP y CGMP, que recibe un flujo multicast de un servidor de video en una interfaz diferente. Esta interfaz envía al grupo de multidifusión IP 239.100.100.100.

Estado estable

Una vez que todos los dispositivos se inician y los PC receptores han enviado sus mensajes de unión IGMP para el grupo 239.100.100.100, CGMP los agrega al grupo de Capa 2 correspondiente representado por la dirección MAC 01-00-5e-64-64-64.

Esta lista muestra qué puertos, resaltados en negrita, en el switch reciben el flujo multicast que llega a través del router Cisco IOS.

• puerto 1: receptor PC 1

• puerto 2: receptor PC 2

• puerto 3: receptor PC 3

• puerto 4: no es un receptor PC 4

• puerto 5 - otro switch (sin receptores o routers en este switch)

• puerto 48: router Cisco IOS que ejecuta IGMP y CGMP

Nota: El router Cisco IOS también se agrega al grupo multicast, pero como es el origen, no recibe sus propios paquetes.

En cada intervalo de consulta, el router Cisco IOS envía una consulta general IGMP (que se envía al grupo multicast 224.0.0.1 y, por lo tanto, se inunda en todos los demás componentes). Cuando esto sucede, todos los receptores comienzan a generar un informe IGMP para el grupo 239.100.100.100. Los receptores envían este informe de vuelta al grupo de multidifusión IP 239.100.100.100, con una dirección MAC de capa 2 01-00-5E-64-64-64. Dado que esto se envía a la dirección del grupo, todos los receptores reciben los informes que envían otros receptores, así como el informe que el primer receptor devuelve. Esto hace que los otros PC receptores cancelen su informe para este grupo. Esto significa que se envía para este grupo sólo un mensaje adjunto de CGMP con la dirección MAC de origen de la computadora que respondió en primer lugar. Esto continúa durante un largo período de tiempo y todos los ordenadores receptores reciben la transmisión de vídeo.

Durante y después del cambio de topología

En este punto, el otro switch desencadena un cambio de topología en la red. Según la especificación CGMP al recibir el cambio de topología, el switch borra todas las entradas multicast que había aprendido a través de CGMP. El tráfico multicast del router se inunda en todos los puertos del switch.

Esta lista muestra qué puertos, resaltados en negrita, en el switch reciben el flujo multicast que llega a través del router Cisco IOS:

• puerto 1: receptor PC 1

• puerto 2: receptor PC 2

• puerto 3: receptor PC 3

• puerto 4: no es un receptor PC 4

• puerto 5 - otro switch (sin receptores o routers en este switch)

• puerto 48: router Cisco IOS que ejecuta IGMP y CGMP

Como el tráfico se inunda en todos los puertos, los ordenadores receptores no notan ninguna diferencia y siguen recibiendo la transmisión de vídeo. Sin embargo, como el tráfico se inunda en todos los puertos, PC 4, que no es un receptor, y el otro switch ahora también recibe el flujo multicast, aunque no lo han solicitado. Esto continúa hasta que el router IOS de Cisco envía su consulta periódica general IGMP nuevamente. El valor predeterminado para esto es de 60 segundos en los routers del IOS de Cisco (configurados con un intervalo de consulta IP IGMP).

Dos preguntas generales sobre IGMP después de la notificación de cambio de topología

Cuando el router Cisco IOS envía su primera consulta general IGMP, todos los PC receptores comienzan a generar su informe IGMP para el grupo 239.100.100.100. Una de ellas (en este documento, la PC 3) es la primera en enviar su informe IGMP. Dado que aún no se ha creado una entrada de multidifusión en el switch, todas las PC la reciben y las otras PC receptoras cancelan sus informes IGMP. El router del IOS de Cisco recibe el informe y envía el mensaje de incorporación CGMP subsiguiente con la dirección de origen del receptor PC 3.

El switch construye una entrada multidifusión nuevamente para el grupo 01-00-5e-64-64-64 y le agrega el puerto 3, dado que ésta es la dirección de origen en el paquete de incorporación del protocolo CGMP. Dado que el puerto 5 es un puerto de router de multidifusión, también se agrega al grupo de multidifusión. Por lo tanto, sólo el receptor PC 3 recibe la secuencia de video mientras que la secuencia de video de PC 1 y PC 2 permanece inamovible.

Esta lista muestra qué puertos, resaltados en negrita, en el switch reciben el flujo multicast que llega a través del router Cisco IOS:

• puerto 1: receptor PC 1

• puerto 2: receptor PC 2

• puerto 3: receptor PC 3

• puerto 4: no es un receptor PC 4

• puerto 5 - otro switch (sin receptores o routers en este switch)

• port 48 — router del IOS de Cisco ejecutando IGMP y CGMP

Al final de un intervalo de consulta IGMP, el router Cisco IOS envía otra consulta general IGMP. Luego de recibir la consulta, todas las PC de recepción crean un informe para el grupo 239.100.100.100. Esta vez, sin embargo, los informes de los otros PC sólo son recibidos por el receptor PC 3 y el router Cisco IOS. (El puerto del router se agrega automáticamente a cada grupo de multidifusión.)

Dado que los receptores PC 1 y PC 2 no ven un informe de algún otro receptor, ambos envían sus informes. El router Cisco IOS posteriormente envía un mensaje de incorporación CGMP con la dirección MAC de origen de las respectivas PC y, por lo tanto, se agregan y comienzan a recibir la secuencia de multidifusión nuevamente a través del router Cisco IOS.

Esta lista muestra qué puertos, resaltados en negrita, en el switch reciben el flujo multicast que llega a través del router Cisco IOS:

• puerto 1: receptor PC 1

• puerto 2: receptor PC 2

• puerto 3: receptor PC 3

• puerto 4: no es un receptor PC 4

• puerto 5 - otro switch (sin receptores o routers en este switch)

• port 48 — router del IOS de Cisco ejecutando IGMP y CGMP

La configuración vuelve al estado estable original y todo funciona correctamente de nuevo. Este es un desglose de lo que ha ocurrido:

1. Se produce un cambio de topología.

   Sugerencia: Cuando portfast no está habilitado en un puerto host, cada vez que se reinicia un host o se conecta/desconecta con/desde el puerto, un cambio en el estado de los links activa una notificación de cambio de topología en la VLAN. Si la depuración de CGMP está habilitada en el momento del cambio de topología, se muestra este mensaje de depuración:

   CGMP SHIM: got short age timer

2. La inundación comienza en todos los puertos.

3. Se envía la primera consulta general IGMP.

4. Las inundaciones se detienen.

5. No todos los receptores reciben el flujo multicast.

6. Se envía la segunda consulta general IGMP.

7. Todos los receptores se agregan y reciben el flujo multicast de nuevo.

Mejoras de CGMP

Dado que no siempre es aceptable la pérdida de un flujo de multidifusión durante un minuto (el intervalo de consulta IGMP predeterminado) para un PC, se han realizado algunas mejoras tanto para los routers como para los switches que ejecutan CGMP.

Comunicación entre el switch y el router

Dado que los routers son dispositivos de Capa 3 y, por lo tanto, no suelen conocer los cambios en el árbol de expansión y la topología que se producen, es necesario que los switches en la red alerten al router de este cambio de topología. Se define un mensaje de ausencia global IGMP para manejar esto.

Este mensaje de abandono global IGMP es una ausencia IGMP que puede transmitir un switch pidiéndole que abandone al grupo 0.0.0.0.

Para asegurarse de que el router no esté sobrecargado con mensajes de ausencia globales IGMP, solamente el switch raíz en un dominio de árbol de expansión es responsable de enviar este mensaje de ausencia global IGMP cuando el cambio de topología se haya terminado.

Comportamiento del router

Cuando el router recibe este mensaje de ausencia global de IGMP en una interfaz que ejecuta Cisco IOS Software, reconoce que se ha producido un cambio en la topología del árbol de expansión en esa interfaz y realiza estas acciones para intentar limitar la pérdida de tráfico multicast para los receptores de multidifusión:

1. Envía mensajes de unión por lotes CGMP después de haber recibido el mensaje de salida global IGMP. El router envía un mensaje de unión CGMP con su propia dirección MAC como la dirección de origen de usuario para cada grupo multicast que tiene en su memoria caché IGMP para esa interfaz. Al enviar estos mensajes de autoincorporación CGMP, los switches CGMP crean automáticamente una entrada para cada grupo con sólo el puerto del router en él.

   Esta lista muestra la red utilizada en este documento, después de la unión del lote CGMP. Solo se ha agregado el router Cisco IOS al grupo multicast, como se muestra en negrita.

   Nota: Mientras que en los ejemplos anteriores de este documento, los puertos que reciben tráfico del router multicast se mostraron en negrita, este ejemplo muestra todos los puertos que se agregan en el switch al grupo multicast.

   • puerto 1: receptor PC 1

   • puerto 2: receptor PC 2

   • puerto 3: receptor PC 3

   • puerto 4: no es un receptor PC 4

   • puerto 5 - otro switch (sin receptores o routers en este switch)

   • port 48 — router del IOS de Cisco ejecutando IGMP y CGMP

2. Envía una consulta IGMP general. Todos los receptores reciben esta consulta general IGMP y crean un informe para cada grupo al que se han unido. Dado que el switch CGMP ya ha construido una entrada multidifusión para cada uno de los grupos con sólo el router como receptor, todos los informes son enviados únicamente al router. El router envía mensajes de unión CGMP subsiguientes para agregar todos los receptores a los grupos correspondientes.

   Después de que todos los receptores hayan enviado su informe IGMP y el router haya enviado los mensajes de unión CGMP correspondientes, todos los receptores deberían haber sido agregados de nuevo al grupo multicast.

3. Después de 10 segundos (tiempo máximo de respuesta de IGMP predeterminado), se envía otra consulta general de IGMP para asegurarse de que se agregan todos los receptores. Este paso se repite algunas veces para asegurarse de que todos los receptores vuelvan a unirse al grupo de multidifusión.

   Se han agregado todos los puertos que deberían haberse agregado al grupo multicast, como se muestra en negrita en este ejemplo:

   • puerto 1: receptor PC 1

   • puerto 2: receptor PC 2

   • puerto 3: receptor PC 3

   • puerto 4: no es un receptor PC 4

   • puerto 5 - otro switch (sin receptores o routers en este switch)

   • port 48 — router del IOS de Cisco ejecutando IGMP y CGMP

Comportamiento de switch de Catalyst

Dentro de la variedad de switches Catalyst, existen algunas diferencias de comportamiento. Cada switch que es compatible con CGMP hace lo que se describe en la sección CGMP y Cambios de Topología de este documento. Las mejoras para CGMP, no obstante, no están implementadas en todas las plataformas. Esta tabla provee una lista de switches Catalyst y la manera en que reaccionan frente al CGMP:

	Switch CGMP	Router CGMP	Envía el Abandono global con la Raíz del Protocolo de árbol de expansión (STP)
Catalyst 6500 que ejecuta Cisco IOS Software	N	S	S
Catalyst 6500 con CatOS	N	N	N
Catalyst 5500, Catalyst 2926/2926G	S	N	S
Catalyst 4000 Supervisor Engine I/II, Catalyst 2948G/2980G, Catalyst 4912G	S	N	S
Catalyst 4000/4500 Supervisor Engine III/IV	N	S	S
Catalyst 2900XL/3500XL	S	N	S
Catalyst 2940	N	N	N
Catalyst 2950	N	N	N
Catalyst 2970	N	N	N
Catalyst 3550	N	S	S
Catalyst 3750	N	S	S

Nota: En el Catalyst 4000/4500 con Supervisor Engine III/IV, el comportamiento con respecto a los cambios de topología y CGMP es configurable. Ejecute este comando para configurar el Catalyst 4000 para enviar o no enviar un mensaje de ausencia global IGMP cuando no sea la raíz del árbol de expansión:

• ip igmp snooping tcn query solicit

Nota: Ejecute esta forma "no" del comando para desactivarlo:

• no ip igmp snooping tcn query solicit

Información Relacionada

• Cómo Comprender los Cambios de Topología de Protocolo de Spanning Tree
• Multicast en una red de oficinas centrales: Indagación CGMP y IGMP
• Restricción del tráfico de multidifusión con fuente y receptores en la misma VLAN en switches Catalyst ejecutando Catalyst OS
• Guía de Configuración para Catalyst 4000 Cisco IOS Software: Introducción a la indagación IGMP y su configuración
• Página de soporte técnico del árbol de expansión
• Páginas de Soporte de Productos de LAN
• Página de Soporte de LAN Switching
• Soporte Técnico y Documentación - Cisco Systems