Catalyst 6500 con Supervisor Engine 720 que ejecuta Cisco IOS® Software Release 12.2(18)SXD5
Catalyst 3750 que ejecuta una imagen de Cisco IOS Software Release 12.2(25)SEB2
Cualquier switch Catalyst que ejecute una versión de software de Cisco IOS y también admita indagación de protocolo de administración de grupos de Internet (IGMP)

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Convenciones

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

Antecedentes

Además, algunos servidores/aplicaciones que utilizan paquetes multicast para la operación de clúster/alta disponibilidad pueden fallar si no configura los switches apropiadamente. Esto también se trata en este artículo.

Nota: Refiérase a la sección IGMP Snooping Feature Catalyst Switch Support Matrix del documento Multicast Catalyst Switches Support Matrix para ayudar a identificar estos switches.

Problema

El tráfico multidifusión no pasa a través de los switches Catalyst, incluso en la misma VLAN.La figura 1 muestra este escenario.

Figura 1: Configuración de red con fuente y receptores de multidifusión

Network Diagram Diagrama de la red

El origen multicast está conectado al Switch 1, que es un Catalyst 6500 Switch con Supervisor Engine 720 que ejecuta Cisco IOS Software. El Receptor 1 está conectado al Switch 1, y el Receptor 2 está conectado al Switch 2. El switch 2 es un Catalyst 3750. Existe un link de Capa 2, ya sea de acceso o troncal, entre el Switch 1 y el Switch 2.

En esta configuración, se encuentra que el Receptor 1, que está en el mismo switch que el origen, obtiene la secuencia de multidifusión sin problemas. Sin embargo, Receiver 2no obtiene ningún tráfico de multidifusión. El presente documento tiene por objeto resolver este problema.

Revisión de los conceptos clave de multidifusión

Antes de explorar la solución y las diferentes opciones disponibles, debe tener claros determinados conceptos clave de la multidifusión de capa 2. En esta sección se definen estos conceptos.

Nota: Esta sección proporciona una explicación muy simple y directa que se centra solo en este problema en particular. Consulte la sección Información Relacionada al final de este documento para obtener una explicación detallada de estos términos.

IGMP

IGMP es un protocolo que permite a los hosts finales (receptores) informar a un router multidifusión (solicitante IGMP) de la intención del host final de recibir tráfico multidifusión determinado. Este es un protocolo que se ejecuta entre un router y los hosts finales y permite:

Routers que preguntan a los hosts finales si necesitan una secuencia de multidifusión determinada (consulta IGMP)
Hosts finales para indicar o responder al router si buscan un flujo de multidifusión concreto (informes IGMP)

IGMP Snooping

La indagación IGMP es un mecanismo para restringir el tráfico multicast a los puertos que tienen receptores conectados solamente. El mecanismo añade eficiencia porque permite que un switch de Capa 2 envíe selectivamente paquetes multicast solamente en los puertos que los necesitan. Sin la indagación IGMP, el switch inunda los paquetes en cada puerto. El switch "escucha" el intercambio de mensajes IGMP por el router y los hosts finales. De esta manera, el switch genera una tabla de indagación IGMP que tiene una lista de todos los puertos que han solicitado un grupo multicast determinado.

Puerto Mrouter

El puerto mrouter es simplemente el puerto desde el punto de vista del switch que se conecta a un router multicast. La presencia de al menos un puerto mrouter es absolutamente esencial para que la operación de indagación IGMP funcione a través de los switches. Consulte la sección Comprensión del problema y sus soluciones de este documento para obtener más detalles.

Multidifusión en L2

Cualquier tráfico IP versión 4 (IPv4) con una IP de destino en el rango de 224.0.0.0 a 239.255.255.255 es un flujo de multidifusión. Todos los paquetes de multidifusión IPv4 se asignan a una dirección IEEE MAC predefinida con el formato 01.00.5e. xx . xx . xx .

Nota: La indagación IGMP sólo funciona si la dirección MAC de multidifusión se asigna a este intervalo MAC compatible con IEEE. Algunos intervalos de multidifusión reservados se excluyen de los snooped por diseño. Si un paquete de multidifusión no conforme se origina en una red conmutada, el paquete se inunda a través de esa VLAN, lo que significa que se trata como tráfico de difusión.

Comprender el problema y sus soluciones

De forma predeterminada, los switches Catalyst tienen habilitada la indagación IGMP. Con la indagación IGMP, el switch indaga (o escucha) los mensajes IGMP en todos los puertos. El switch crea una tabla de indagación IGMP que básicamente asigna un grupo multicast a todos los puertos del switch que lo han solicitado.

Suponga que, sin ninguna configuración previa, el Receptor 1 y el Receptor 2 han señalado sus intenciones de recibir un flujo multicast para 239.239.239.239 que se asigna a la dirección MAC multicast L2 de 01.00.5e.6f.ef.ef. Tanto el Switch 1 como el Switch 2 crean una entrada en sus tablas de snooping para estos receptores en respuesta a los informes IGMP que generan los receptores. El switch 1 ingresa el puerto Gigabit Ethernet 2/48 en su tabla, y el switch 2 ingresa el puerto Fast Ethernet 1/0/47 en su tabla.

Nota: En este momento, el origen de multidifusión no ha iniciado su tráfico y ninguno de los switches conoce el puerto del router del switch.

Cuando el origen en el Switch 1 comienza a transmitir tráfico multicast, el Switch 1 ha "visto" el informe IGMP desde el Receptor 1. Como resultado, el switch 1 ofrece el puerto de salida de multidifusión Gigabit Ethernet 2/48. Sin embargo, dado que el switch 2 "absorbió" el informe IGMP del receptor 2 como parte del proceso de indagación IGMP, el switch 1 no ve un informe IGMP (solicitud de multidifusión) en el puerto Gigabit Ethernet 2/46. Como resultado, el Switch 1 no envía ningún tráfico multicast al Switch 2. Por lo tanto, el Receptor 2 nunca recibe tráfico multicast, aunque el Receptor 2 esté en la misma VLAN pero meramente en un switch diferente que el origen multicast.

La razón de este problema es que la indagación IGMP no se soporta realmente en ninguna plataforma Catalyst sin un mrouter. El mecanismo se "interrumpe" en ausencia de un puerto mrouter. Si desea una solución para esta solución, debe hacer que los switches aprendan o sepan de alguna manera de un puerto mrouter. Consulte la sección Soluciones de este documento para obtener una explicación adicional del procedimiento. Aún debe descubrir cómo la presencia de un puerto mrouter en los switches soluciona el problema.

Básicamente, cuando los switches aprenden o conocen estáticamente un puerto mrouter, ocurren dos cosas críticas:

El switch "transmite" los informes IGMP desde los receptores al puerto mrouter, lo que significa que los informes IGMP van hacia el router multicast. El switch no retransmite todos los informes IGMP. En cambio, el switch envía solamente algunos de los informes al mrouter. A los efectos de este examen, el número de informes no es importante. El router multicast sólo necesita saber si hay al menos un receptor que todavía esté interesado en el flujo descendente de multicast. Para tomar la determinación, el router multicast recibe los informes IGMP periódicos en respuesta a sus consultas IGMP.
En un escenario de multidifusión de solo origen, en el que ningún receptor aún se ha "unido", el switch solo envía la secuencia de multidifusión fuera de su puerto mrouter.

Cuando los switches conocen su puerto mrouter, el Switch 2 transmite el informe IGMP que el switch recibió del Receptor 2 a su puerto mrouter. Este puerto es Fast Ethernet 1/0/3. El switch 1 obtiene este informe IGMP en el puerto Gigabit Ethernet 2/46 del switch. Desde la perspectiva del Switch 1, el switch ha recibido simplemente otro informe IGMP. El switch agrega ese puerto a su tabla de indagación IGMP y comienza a enviar el tráfico multicast en ese puerto también. En este punto, ambos receptores reciben el tráfico multicast solicitado, y la aplicación funciona como se espera.

Para averiguar cómo los switches identifican su puerto mrouter de modo que funcione la indagación IGMP ya que se espera que funcione en un entorno simple, vea la sección Soluciones para obtener respuestas.

Soluciones

Utilice estas soluciones para resolver el problema.

Solución 1: habilite PIM en la interfaz de VLAN/router de capa 3

Todas las plataformas Catalyst tienen la capacidad de aprender dinámicamente sobre el puerto mrouter. Los switches escuchan pasivamente los saludos de Protocol Independent Multicast (PIM) o los mensajes de consulta IGMP que un router multicast envía periódicamente.

Este ejemplo configura la interfaz virtual conmutada (SVI) VLAN 1 en el Catalyst 6500 con ip pim sparse-dense-mode .

Switch1#show run interface vlan 1
!
interface Vlan1
 ip address 10.1.1.1 255.255.255.0
 ip pim sparse-dense-mode
end

Switch 1 now reflects itself (Actually the internal router port) as an Mrouter port. 

Switch1#show ip igmp snooping mrouter 
vlan            ports
-----+----------------------------------------
   1  Router

Switch 2 receives the same PIM hellos on its Fa 1/0/33 interface. So it assigns that 
port as its Mrouter port.

Switch2#show ip igmp snooping mrouter 
Vlan    ports
----    -----
   1    Fa1/0/33(dynamic)

Solución 2: Habilitar la función de solicitante IGMP en un switch Catalyst de capa 2

El solicitante IGMP es una función relativamente nueva en los switches de Capa 2. Cuando una red/VLAN no tiene un router que pueda asumir la función de router multicast y proporcionar la detección de router multicast en los switches, puede activar la función IGMP solicitante. La función permite que el switch de Capa 2 realice proxy para un router multicast y envíe consultas IGMP periódicas en esa red. Esta acción hace que el switch se considere un puerto mrouter. El resto de los switches en la red simplemente definen sus respectivos puertos mrouter como la interfaz en la que recibieron esta consulta IGMP.

Switch2(config)#ip igmp snooping querier

Switch2#show ip igmp snooping querier 
Vlan      IP Address     IGMP Version   Port               
-------------------------------------------------------------
1         10.1.1.2        v2             Switch

El switch 1 ve ahora que el puerto Gig 2/46 enlaza al switch 2 como un puerto mrouter.

Switch1#show ip igmp snooping mrouter 
vlan            ports
-----+----------------------------------------
   1  Gi2/46

Cuando el origen en el Switch 1 comienza a transmitir tráfico multicast, el Switch 1 reenvía el tráfico multicast al Receptor 1 encontrado a través de la indagación IGMP (es decir, al puerto de salida Gig 2/48) y al puerto mrouter (es decir, al puerto de salida Gig 2/46).

Solución 3: Configure el puerto estático del router principal en el switch

El tráfico multicast falla dentro de la misma VLAN de Capa 2 debido a la falta de un puerto mrouter en los switches, la sección Comprensión del Problema y Sus Soluciones cubre este tema. Si configura estáticamente un puerto mrouter en todos los switches, los informes IGMP se pueden retransmitir en esa VLAN a todos los switches. Como resultado, es posible la multidifusión. Por lo tanto, en el ejemplo, debe configurar estáticamente el Catalyst 3750 Switch para que tenga Fast Ethernet 1/0/33 como un puerto mrouter.

En este ejemplo, sólo necesita un puerto mrouter estático en el Switch 2:

Switch2(config)#ip igmp snooping vlan 1 mrouter interface fastethernet 1/0/33

Switch2#show ip igmp snooping mrouter
Vlan    ports
----    -----
   1    Fa1/0/33(static)

Solución 4: Configuración de entradas MAC de multidifusión estática en todos los switches

Puede crear una entrada de memoria de contenido direccionable (CAM) estática para la dirección MAC de multidifusión en todos los switches de todos los puertos del receptor y los puertos del switch de flujo descendente. Cualquier switch obedece las reglas de entrada de CAM estática y envía el paquete a todas las interfaces que se especifican en la tabla CAM. Esta es la solución menos escalable para un entorno que tiene muchas aplicaciones de multidifusión.

Switch1(config)#mac-address-table static 0100.5e6f.efef vlan 1 interface 
gigabitethernet 2/46 gigabitethernet 2/48

!--- Note: This command should be on one line.

Switch1#show mac-address-table multicast vlan 1

 vlan   mac address     type   learn qos             ports
-----+---------------+--------+-----+---+--------------------------------
   1  0100.5e6f.efef    static  Yes          -   Gi2/46,Gi2/48


Switch2(config)#mac-address-table static 0100.5e6f.efef vlan 1 interface 
fastethernet 1/0/47

!--- Note: This command should be on one line.

Switch2#show mac-address-table multicast vlan 1
Vlan    Mac Address       Type       Ports
----    -----------       ----       -----
   1    0100.5e6f.efef    USER        Fa1/0/47

Solución 5: Desactive la función IGMP Snooping en todos los switches

Si inhabilita la indagación IGMP, todos los switches tratan el tráfico multicast como tráfico de broadcast. Esto inunda el tráfico a todos los puertos en esa VLAN, independientemente de si los puertos tienen receptores interesados para ese flujo de multidifusión.

Switch1(config)#no ip igmp snooping

Switch2(config)#no ip igmp snooping