Prueba de failover de redundancia Dante: comprueba las rutas primaria y secundaria

TL;DR — Un sistema Dante redundante solo queda demostrado cuando cada ruta funciona por separado y la pérdida controlada de una ruta no interrumpe el audio aceptado. Mapea redes primaria y secundaria físicamente separadas, establece una línea base de ambas, aísla una ruta en un límite documentado, observa audio y eventos, restáurala y repite en la otra dirección. Nunca conectes entre sí ambas redes ni consideres redundantes dos puertos dentro de un único dominio de fallo compartido.

La redundancia son dos rutas independientes

En modo redundante, los dispositivos Dante compatibles envían tráfico duplicado por las redes primaria y secundaria. El receptor puede continuar por la ruta superviviente cuando falla una de ellas. La protección depende de la separación: fabrics de switching independientes, cableado, puertos, alimentación cuando sea necesaria y ausencia de conexiones cruzadas accidentales.

Usa la guía de modo redundante vs conmutado para elegir y cablear el modo de puerto. Esta guía se centra en la verificación operativa del failover y el aislamiento de fallos.

Construye una prueba que identifique el límite fallado

1. Dibuja ambas rutas antes de tocar un cable

Mapea cada interfaz de dispositivo, switch de acceso, uplink, tramo de fibra o cobre, fuente de alimentación y límite que vayas a monitorizar. Etiqueta primary y secondary de forma consistente. Confirma que las redes no comparten un switch no gestionado, un puente VLAN, un parche accidental ni un uplink combinado.

2. Establece una línea base del sistema en buen estado

Registra suscripciones, estado de líder y seguidor, velocidad de interfaz, errores de enlace, evidencia de paquetes y latencia, firmware y hora del log de eventos. Envía audio de programa representativo a cada destino crítico. Un resultado de failover solo es significativo frente a una línea base conocida y limpia.

3. Demuestra la ruta secundaria por sí sola

En el límite de prueba previsto, desconecta o deshabilita la ruta primaria sin cambiar rutas. Monitoriza de forma continua el audio crítico. Guarda la secuencia de eventos y confirma que los enlaces secundarios, el comportamiento del reloj, la entrega de paquetes y las suscripciones se mantienen sanos durante el tiempo de permanencia acordado.

4. Restaura la primaria y observa la recuperación

Vuelve a conectar la ruta y permite que la negociación de enlace y el estado de red se estabilicen. Confirma que la interfaz restaurada está sana y que no aparece ningún evento recurrente de enlace, reloj o suscripción. No des por hecho que la continuidad del audio por sí sola demuestra que la ruta recuperada es utilizable.

5. Repite con la secundaria retirada

Vuelve a una línea base limpia, aísla secondary en el mismo límite lógico y repite la observación. Probar en ambas direcciones detecta una ruta secundaria que nunca ha transportado tráfico válido y una ruta primaria cuya recuperación es inestable.

Interpreta los fallos por patrón

No cambies varios cables, switches y ajustes a la vez. Conserva el primer evento, aísla el primer límite común, cambia una sola condición y repite la misma prueba de aceptación.

Define la aceptación antes de la prueba

• Las rutas primary y secondary están separadas física y lógicamente.
• Cada dispositivo crítico muestra dos enlaces sanos antes del aislamiento.
• El audio representativo llega a cada destino crítico.
• Retirar cualquiera de las rutas no provoca mute, clic o dropout inaceptable.
• La evidencia de reloj, paquetes, latencia y suscripción de la ruta superviviente sigue sana.
• La ruta fallada es visible en la monitorización y en el log de eventos.
• Restablecer la ruta produce un estado sano y estable.
• Ambas direcciones de prueba superan el tiempo de permanencia documentado.
• La configuración guardada y las etiquetas coinciden con el sistema probado.

Si el fallo incluye errores de paquetes o llegadas tardías, sepáralos con la guía de errores de paquetes Dante frente a errores de latencia. Si el evento está relacionado con el reloj, sigue el flujo de trabajo de solución de problemas de sincronización de reloj.

Documenta el resultado del failover

Registra la fecha, el operador, el firmware del dispositivo y del switch, la revisión de la topología, el punto de aislamiento, los tiempos de inicio y recuperación, un extracto del log de eventos, los destinos monitorizados, la aceptación del audio, los defectos restantes y el estado de rollback. Fotografiar un cable desconectado no basta; el artefacto útil es un resultado específico de ruta que otro ingeniero pueda repetir.

En Techrider.live, adjunta las notas de redundancia a la misma fuente de verdad que la hoja de patch y el plano de escenario. Invita a colaboradores a editar el mismo rider, guarda la revisión aceptada, inspecciona el historial y exporta un PDF para el recinto o para el traspaso de gira.

FAQ

¿Cómo pruebo la redundancia de Dante?

Establece una línea base de ambas rutas en buen estado, aísla primary en un límite documentado, verifica el audio y la evidencia de red en secondary, restaura y confirma la recuperación, y luego repite con secondary aislada.

¿Qué pasa cuando falla la red primaria de Dante?

En un sistema redundante correctamente configurado, los receptores siguen usando el tráfico duplicado desde secondary. La monitorización debería seguir mostrando la ruta primaria fallada para que pueda repararse en lugar de ignorarse.

¿Por qué Dante secondary muestra un error?

Las causas comunes incluyen un cable desconectado, un puerto de switch deshabilitado o mal configurado, un modo de dispositivo incorrecto, redes compartidas o cruzadas, negociación de velocidad o un uplink secundario fallado. Diagnostica el primer límite común.

¿Pueden Dante primary y secondary usar el mismo switch?

Eso no proporciona redundancia a nivel de switch y puede crear una topología inválida si las redes están puenteadas. Usa rutas de red realmente separadas según el diseño del dispositivo y del sistema.

¿Cómo verifico que Dante recuperó el failover?

Confirma que el enlace restaurado es estable, que los errores dejan de aumentar, que las suscripciones y el estado del reloj siguen sanos, que el audio real pasa y que no aparecen eventos repetidos de fallo/recuperación durante el periodo de permanencia documentado.