Un IPTV que se traba y un flujo CCTV que se convierte en mosaico suelen ser la misma falla con dos caras distintas — una unión multicast que nunca se completa, una tabla de reenvío a la que le falta una entrada, o ráfagas de tráfico que superan lo que el puerto de salida puede almacenar en búfer. Este es el orden de verificación que encuentra más rápido cuál de los dos es — los comandos display exactos para IGMP, las tablas multicast de capa 2 y 3, y las causas que explican la mayoría de estos casos en el campo.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
Ya sea un decodificador que se traba o un flujo CCTV que se disuelve en bloques, la pregunta de fondo es la misma: ¿el flujo multicast realmente llega a este puerto, y llega lo bastante rápido?
El congelamiento de IPTV y el mosaico de video CCTV se reportan como si fueran problemas distintos — uno es una queja de decodificador, el otro una queja de videovigilancia — pero en el fondo, el video multicast solo puede fallar de dos maneras: el flujo nunca se reenvía al puerto, o se reenvía pero llega tarde, incompleto o descartado. La primera es un problema de unión/tabla — IGMP, IGMP Snooping o PIM nunca construyeron el camino. La segunda es un problema de capacidad — el camino existe, pero algo entre la fuente y la pantalla no puede mantener el ritmo por un instante.
A continuación, el orden de verificación que separa ambos casos: si la unión realmente llegó al dispositivo, si las tablas multicast de capa 2 y 3 realmente tienen las entradas correctas, y solo entonces si el tráfico en sí está en ráfagas que superan lo que un puerto puede almacenar en búfer — además de las causas que aparecen una y otra vez en implementaciones reales de CCTV e IPTV, y las respuestas a las preguntas que esto genera con más frecuencia.
El congelamiento y el mosaico se dividen en exactamente dos formas en este árbol: no hay flujo en absoluto, o hay un flujo pero está degradado.
Ubicar primero el síntoma aquí indica cuál de las secciones siguientes aplica realmente — perseguir un problema de ancho de banda cuando la falla real es una entrada de tabla IGMP Snooping faltante (o al revés) hace perder mucho tiempo.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Una entrada de tabla de reenvío faltante y un problema de ancho de banda/ráfaga se ven idénticos en la pantalla — ambos se manifiestan como congelamiento o mosaico — pero están en lugares completamente distintos y necesitan soluciones completamente distintas. El árbol de arriba es lo que los distingue antes de tocar cualquier configuración.
Tres verificaciones, en orden — cada una es contexto para la siguiente, y los comandos que indican en cuál está realmente atascado.
Si el enrutamiento multicast nunca se habilitó, el tráfico multicast desconocido se inunda como broadcast — y eso solo basta para causar mosaico.
<Device> display interface 10GE0/0/1
Output: 490255596853 packets, 722496062037058 bytes
Discard: 416538726, Pause: 0
// Discard counter climbing on the output side -> congestion, not a join fault
<Device> display igmp snooping configuration
Info: There is no igmp snooping configuration.
// no multicast table at all -> unknown multicast is flooded exactly like broadcast
#
igmp snooping enable
vlan 10
igmp snooping enable
igmp snooping querier enableEl multicast puede estar habilitado en todos lados y la unión aun así no construir la entrada que lleva el tráfico a este puerto específico.
<Device> display l2-multicast forwarding-table
VLAN Total (Source,Group) Interface
100 1 (*, 226.0.1.205)
// no outgoing interface toward the PC listed -> entry never reached this port
<Device> display igmp snooping vlan 10
IGMP Version is Set to default 2
// third-party device sends IGMPv3 Query; this device is v2 and can't process it
// -> router-port ages out once the v3 Query goes out, stream cutsAquí es donde un flujo del que se ha comprobado que llega al puerto correcto y a la entrada de tabla correcta puede aun así congelarse o convertirse en mosaico.
<Device> display interface 10GE0/0/2
Output: ... Discard: 33021, still increasing
// mirror the source-facing port and check with Wireshark:
// server sleeps ~1s, then bursts near 1Gbit/s for a few ms -- average rate only ~10Mbit/s
[Device] interface 10GE0/0/2
[Device-10GE0/0/2] qos burst-mode enhanced
// enhanced burst mode gives the egress port more buffer for this traffic shapeUna vez realizadas las tres verificaciones anteriores, estas cinco causas explican la mayoría de lo que realmente falla en implementaciones reales de CCTV e IPTV.
SÍNTOMAEl flujo de la cámara muestra mosaico desde el momento en que se conecta — display interface en el puerto muestra un contador Discard grande y en aumento en el lado de salida.
CAUSALa red del cliente llevaba video multicast, pero el dispositivo de acceso no tenía ninguna configuración de IGMP Snooping. Sin una tabla multicast que consultar, el tráfico multicast desconocido se reenvía exactamente como broadcast — inundado a todos los puertos de la VLAN — y la congestión resultante descarta paquetes, lo que se muestra en pantalla como mosaico.
SOLUCIÓNHabilite IGMP Snooping globalmente y en la VLAN específica, y habilite la función de consultador de capa 2 en el switch más cercano a la fuente multicast si la VLAN no tiene otro consultador.
igmp snooping enable
vlan 10
igmp snooping enable
igmp snooping querier enableSÍNTOMAEl video se reproduce normalmente por un tiempo y luego se corta — desconectar y reconectar el cable del usuario solo retrasa la misma falla, no la soluciona.
CAUSAUna versión superior de IGMP/IGMP Snooping puede procesar los paquetes de protocolo de una versión inferior, pero no al revés. El primer reporte del usuario construye correctamente la entrada de reenvío en ambos dispositivos — pero una vez que la Consulta IGMPv3 periódica del dispositivo aguas arriba se emite, el dispositivo de versión inferior no puede procesarla, la entrada envejece, y el flujo se detiene.
SOLUCIÓNConfigure la misma versión de IGMP / IGMP Snooping en todos los dispositivos del mismo dominio multicast — cuando los dispositivos están mezclados, alinéelos todos a la misma versión en lugar de suponer que un dispositivo de versión superior es automáticamente retrocompatible en ambas direcciones.
<Device> display igmp snooping vlan 10
IGMP Version is Set to default 2
[Device-vlan10] igmp snooping version 3SÍNTOMAEl mosaico aparece específicamente en las horas pico de actividad, y display interface en el puerto orientado al usuario muestra un contador Discard que sigue subiendo.
CAUSAAlgunos codificadores de fuente multicast usan codificación de tasa de bits variable (VBR) y envían datos en ráfagas cortas y extremadamente rápidas en lugar de un flujo constante — un caso real de campo midió que la fuente reposaba poco más de un segundo, luego enviaba cerca de 1Gbit/s durante unos milisegundos antes de volver a reposar, aunque la tasa promedio en el tiempo era de solo unos 10Mbit/s. El búfer de salida del dispositivo, dimensionado según el promedio, no puede absorber una ráfaga de ese tamaño, y el desbordamiento se descarta.
SOLUCIÓNDonde la fuente lo permita, cámbiela de VBR a codificación de tasa de bits constante (CBR) para suavizar el patrón de envío; de lo contrario, aumente el ancho de banda del puerto de salida (un Eth-Trunk, o un puerto de mayor velocidad), o configure un modo de ráfaga mejorado en el puerto para darle más búfer para exactamente este tipo de tráfico.
[Device] interface 10GE0/0/2
[Device-10GE0/0/2] qos burst-mode enhancedSÍNTOMAAparece pérdida de paquetes aleatoria y dispersa en muchos grupos multicast diferentes, aproximadamente dos minutos después de que el flujo comienza, en lugar de una falla limpia en un solo grupo.
CAUSAExistía más de un consultador IGMP en el mismo segmento de usuario, y sus intervalos de consulta no coincidían — un intervalo de consulta más largo que el tiempo de envejecimiento predeterminado del switch deja solo unos segundos en cada ciclo para refrescar una gran cantidad de entradas multicast, y el dispositivo no puede procesar el refresco lo bastante rápido, por lo que las entradas envejecen y se reconstruyen, mostrándose como pérdidas dispersas en varios grupos.
SOLUCIÓNDesactive el consultador redundante — debería haber exactamente un consultador IGMP activo en un segmento de capa 2 dado — y si el intervalo debe personalizarse, configúrelo de forma consistente en todos los dispositivos del segmento, no solo en el más cercano a la fuente.
<Device> display igmp interface
// querier elected on a device other than expected -- check its query-interval, disable the duplicateSÍNTOMALa reproducción se traba fuertemente a través de un dispositivo de agregación con muchos dispositivos aguas abajo en una VLAN, pero el mismo contenido se reproduce limpiamente cuando el terminal del usuario se conecta directamente al dispositivo del lado de la fuente.
CAUSACon una gran cantidad de dispositivos ramificados bajo un switch de agregación en la misma VLAN, el tráfico broadcast inunda cada puerto de esa VLAN y puede consumir por sí solo suficiente ancho de banda para privar al flujo multicast que comparte el enlace, aunque la ruta de reenvío multicast en sí funcione correctamente.
SOLUCIÓNConfigure el aislamiento de puertos en el dispositivo de agregación para que los puertos aguas abajo ya no se inunden entre sí de tráfico broadcast, manteniendo el ancho de banda compartido disponible para el flujo multicast.
[Device-Ethernet0/0/1] portswitch
[Device-Ethernet0/0/1] port default vlan 204
[Device-Ethernet0/0/1] port-isolate enable group 1Extraídas directamente del campo — las que vale la pena tener una respuesta lista.
IGMP es el protocolo que un host usa para decirle a su router directamente conectado a qué grupo multicast quiere unirse — funciona en la capa 3. IGMP Snooping es una función de switch de capa 2 que escucha esos mismos mensajes IGMP que pasan por él, para que el switch pueda construir su propia tabla de reenvío y enviar el tráfico multicast solo a los puertos que realmente tienen miembros, en lugar de inundarlo a toda la VLAN. Un switch de acceso puramente de capa 2 sin interfaz multicast de capa 3 aún necesita IGMP Snooping habilitado, o el multicast desconocido se inunda como broadcast.
Revise primero la tabla de capa 2 — display igmp snooping router-port y display l2-multicast forwarding-table para la VLAN en cuestión. Si falta ahí la interfaz saliente hacia el usuario, es un problema de capa 2, sin importar cómo se vea la capa 3. Si la entrada de capa 2 es correcta, suba a display pim routing-table y display multicast routing-table — una entrada (S,G) faltante o estancada ahí, con el contador Matched sin subir, apunta en cambio a la ruta de capa 3.
Confirme que multicast routing-enable esté configurado globalmente, y que pim sm e igmp enable estén configurados en la interfaz de capa 3 orientada al usuario — solo IGMP sin PIM en la misma interfaz no construirá la tabla. Luego revise display igmp snooping router-port en el dispositivo de capa 2 entre el usuario y el router — si el router-port no está ahí, el mensaje de unión del usuario nunca llegó realmente al dispositivo de capa 3.
Ese patrón temporal apunta a un problema de ráfaga o ancho de banda en lugar de un problema de unión/tabla — revise display interface en busca de un contador Discard en el puerto afectado que suba específicamente durante esas horas, y espeje el puerto orientado a la fuente para verificar ráfagas de tráfico tipo VBR. Una falla de unión/tabla (entrada IGMP Snooping faltante, incompatibilidad de versión) suele mostrarse de forma constante, no solo en horas específicas.
Esto a menudo enmascara el síntoma por un tiempo, pero no responde por qué ocurrió la ráfaga o la inundación en primer lugar, y tiende a volver una vez que el tráfico crece de nuevo. Confirmar el mecanismo real — ráfagas VBR, una entrada IGMP Snooping faltante, un consultador duplicado, o inundación de broadcast compartiendo la VLAN — toma aproximadamente el mismo puñado de comandos display de cualquier forma, y es la única manera de saber si más ancho de banda realmente lo solucionará o solo comprará unos meses.
Esta nota se basa en el modelo de resolución de problemas de multicast de los routers y switches Huawei serie AR y sus comandos display igmp snooping / pim routing-table / multicast routing-table, además de los casos de campo que los respaldan — varios de implementaciones reales de CCTV e IPTV. Si su equipo de acceso o agregación es de otro fabricante, los comandos exactos cambian, pero el orden de verificación subyacente — unión, tabla, capacidad — se traslada directamente. No cubre en profundidad casos específicos de mapeo SSM ni escenarios de multicast sobre overlay MPLS/VPN.
Cuéntenos si es IPTV o CCTV, si el síntoma es constante o solo en horas pico, junto con la salida de display igmp snooping / pim routing-table, y le ayudamos a interpretarla.