Configuración de flujo multicast de Dante: crearlo, verificarlo y eliminarlo con seguridad

8 min de lectura · Actualizado el 10 de octubre de 2026 · Diseñadores de sistemas Dante, ingenieros de FOH y monitor, técnicos de red y AV, responsables de producción, técnicos de sala, ingenieros de broadcast y equipos de audio de gira

Configura deliberadamente un flujo multicast de Dante: selecciona canales, confirma receptores y comportamiento IGMP, prueba ancho de banda y audio, y conserva una ruta de reversión.

TL;DR — Crea manualmente un flujo multicast de Dante solo cuando un transmisor deba alimentar a suficientes receptores como para justificar un stream compartido y la red esté preparada para transportarlo. En la Device View del transmisor, elige Create Multicast Flow, selecciona solo los canales necesarios, crea el flujo y después suscribe los receptores con normalidad. Verifica el comportamiento IGMP, cada enlace afectado, la latencia de los receptores y el audio real bajo carga completa. Guarda la línea base y define cómo eliminar el flujo antes de cambiar la producción.

Un flujo multicast cambia el transporte, no el parche de canales

Un canal de transmisión Dante puede transportarse en un flujo unicast para un receptor específico o colocarse en un flujo multicast al que puedan unirse varios receptores. Unicast y multicast pueden coexistir en el mismo dispositivo Dante, y los canales se seleccionan individualmente para la transmisión multicast.

Los receptores siguen suscribiéndose a los canales con nombre del transmisor en la vista Routing. Crear un flujo multicast cambia cómo cruzan la red los canales seleccionados; no sustituye el nombrado de canales, las suscripciones, el clocking, la compatibilidad de formato ni las pruebas del destino.

Capa de decisiónPreguntaEvidencia
Fanout¿Cuántos receptores necesitan la misma fuente?Lista actual y prevista de destinos
Transmisor¿Qué canales exactos entran en el flujo?Selección de canales en Device View
Red¿Qué enlaces de switch transportarán el stream?Topología, contadores, estado IGMP
Receptores¿Puede cada destino recibirlo de forma fiable?Suscripción estable y evidencia de latencia
Recuperación¿Cómo se eliminará o sustituirá el flujo?Línea base guardada y rollback probado

Usa la guía de unicast frente a multicast para elegir el transporte y la guía de ancho de banda multicast para calcular y supervisar su coste enlace por enlace. Esta guía se ocupa del procedimiento operativo de crear, verificar y eliminar.

Decide si un flujo multicast manual está justificado

Multicast puede reducir el uso de flujos del transmisor cuando la misma fuente alimenta a muchos receptores. También puede llevar el stream a enlaces de red donde no hace falta si el control multicast falta o es incorrecto. No conviertas una ruta unicast que ya funciona solo porque multicast parezca más escalable.

Antes de cambiar el transporte, registra:

  • el uso actual de flujos unicast y multicast del transmisor;
  • cada receptor que necesite cada canal seleccionado;
  • número de canales, frecuencia de muestreo, codificación y bitrate esperado;
  • ruta de switch, uplinks, VLAN, querier y estado de IGMP snooping;
  • tipos de receptor hardware y software junto con sus ajustes de latencia;
  • un preset o registro de ruta conocido como correcto para hacer rollback.

El cambio correcto más pequeño suele ser un grupo lógico de programa, no todos los canales del transmisor.

Crea el flujo de transmisión multicast

  1. Reserva una ventana de mantenimiento y notifica a los responsables de la ruta.
  2. Abre el transmisor en la Device View de Dante Controller.
  3. Confirma la identidad del dispositivo, el firmware, el clock, la frecuencia de muestreo y el estado actual de los flujos.
  4. Elige Create Multicast Flow en los controles de flujo del dispositivo.
  5. Selecciona solo los canales de transmisión necesarios para el plan de destino aprobado.
  6. Revisa la selección, crea el flujo y espera a que Controller lo informe.
  7. En la vista Routing, crea o confirma las suscripciones de los receptores a esos canales con nombre.

La capacidad de canales por flujo multicast depende de la implementación y del formato del transmisor. Controller expone la selección válida para el dispositivo; no asumas un número universal. Si el grupo requerido no cabe, usa el menor número posible de flujos deliberados y documenta la división.

Verifica la red antes de aceptar el audio

Sigue cada enlace que transporte el flujo

Mide por separado el acceso del transmisor, los uplinks de switch, los puertos de acceso de los receptores y los tramos redundantes. Compara el tráfico antes y después del cambio. Un puerto del transmisor sano no demuestra que un uplink compartido tenga margen.

Demuestra el comportamiento IGMP en lugar de asumirlo

Todos los switches Ethernet reenvían multicast, pero el comportamiento multicast gestionado depende del diseño. Un IGMP snooping y un querier correctos pueden restringir el tráfico a los puertos que solicitaron el grupo. Una configuración IGMP incorrecta puede interrumpir la entrega; la ausencia de pruning puede extender el stream mucho más de lo necesario. Verifica el estado real del switch y los contadores en la VLAN real.

Prueba cada clase de receptor

Suscribe cada destino hardware y software aprobado, y después envía audio identificable bajo carga de producción completa. Confirma el estado de suscripción, el clock, la latencia, el orden de canales, el nivel y la reproducción continua. Los endpoints de software pueden tener límites de latencia distintos de los hardware; no infieras el comportamiento de una clase a partir de la otra.

ComprobaciónCondición de aprobaciónIndicio de fallo
SuscripciónEstado de ruta estable en cada receptorProblema de formato, acceso, clock o flujo
Reenvío del switchTráfico solo en los enlaces esperados en un diseño con pruningQuerier ausente o pertenencia de snooping incorrecta
Carga del enlaceMargen sostenido bajo tráfico completo de showFlooding inesperado o uplink insuficiente
Latencia del receptorSin paquetes tardíos ni cortesRetardo de ruta, congestión, planificación del software
Identidad del audioCanal correcto en cada destino físicoSelección de fuente incorrecta u orden de canales

Prueba fallo y restauración

Ejecuta solo los fallos que el diseño afirma soportar: desconexión y reconexión del receptor, failover primario/secundario aprobado, reinicio del switch en un diseño redundante y reinicio del transmisor dentro de una ventana de mantenimiento. Observa cómo se recupera la pertenencia multicast y después confirma el audio en cada destino.

No borres contadores ni reinicies dispositivos antes de capturar un fallo. Registra marcas de tiempo, suscripciones, identidad del grupo multicast o del flujo, utilización del enlace, errores, eventos de latencia y eventos de clock. La guía de salud de red Dante explica cómo correlacionar esa evidencia.

Elimina o revierte un flujo multicast

Antes de borrar un flujo, identifica todos los receptores suscritos y protege sus salidas downstream. Guarda la ruta y el estado del dispositivo actuales, elimina o sustituye las suscripciones afectadas según requiera el plan aprobado y después borra el flujo de transmisión multicast previsto desde los controles de flujo del transmisor.

Tras la eliminación, confirma si Controller reconstruye las suscripciones necesarias como unicast y si la capacidad de flujo del transmisor sigue siendo suficiente. Vuelve a pasar audio en cada destino. Una acción de borrado correcta no demuestra que el transporte de sustitución funcione.

Lista de verificación de aceptación del flujo multicast

  • El fanout y el presupuesto de flujos del transmisor justifican multicast.
  • Solo se seleccionan los canales aprobados del transmisor.
  • La agrupación de canales respeta la capacidad de flujo compatible del dispositivo.
  • La topología del switch, la VLAN, IGMP snooping y la propiedad del querier son conocidas.
  • El tráfico antes y después se mide en cada enlace compartido afectado.
  • Los receptores hardware y software superan audio estable a carga completa.
  • Se verifican latencia, clock, orden de canales y destinos físicos.
  • Pasan las pruebas aprobadas de fallo y restauración.
  • La línea base, la identidad del flujo, la lista de rutas, el propietario y el rollback están documentados.

FAQ

¿Cómo creo un flujo multicast en Dante Controller?

Abre la Device View del transmisor, elige Create Multicast Flow, selecciona los canales de transmisión necesarios y crea el flujo. Después crea o confirma las suscripciones normales de los receptores en la vista Routing y verifica la red además del audio real.

¿Cuándo debo usar un flujo multicast de Dante?

Úsalo cuando la misma fuente deba alimentar a suficientes receptores como para que el transporte compartido mejore el presupuesto de flujos del transmisor, y solo después de confirmar que la red puede transportar y controlar el tráfico. Mantén rutas unicast más simples cuando cumplan el requisito.

¿Puede Dante usar unicast y multicast al mismo tiempo?

Sí. Un dispositivo Dante puede usar ambos, y los canales individuales pueden seleccionarse para multicast. Documenta qué canales usan cada transporte para que el diagnóstico y el rollback sigan siendo claros.

¿Cuántos canales puede contener un flujo multicast de Dante?

No existe un número universal seguro para todos los dispositivos y formatos. La capacidad depende de la implementación del transmisor y del formato de funcionamiento. Usa la selección válida de Controller y la documentación actual del fabricante para el punto final exacto.

¿Cómo elimino un flujo multicast de Dante?

Identifica cada receptor dependiente, guarda la línea base, protege las salidas, elimina el flujo de transmisión previsto en Device View y verifica que las rutas necesarias vuelven usando el transporte planificado. Después vuelve a probar el audio real y la carga del enlace.

Pon la propiedad del multicast en el Rider

Registra el transmisor, los canales seleccionados, la lista de receptores, la elección de transporte, la ruta de switch, el propietario de IGMP, la carga medida, la evidencia de latencia, la validación y el rollback en Techrider.live. Invita a los ingenieros de sistemas y de red a editar el mismo rider, guarda el diseño aceptado e inspecciona el historial antes de cambiar el plan multicast.

Guías relacionadas