Salud de la red Dante: leer errores, utilización y registros de reloj

TL;DR — La salud de una red Dante no es un único icono verde de suscripción, sino un patrón formado por el estado del enlace, la utilización, los errores de paquetes, las estadísticas de latencia y el historial de reloj. Establece una línea base conocida, inspecciona el dispositivo afectado y su ruta de switch, correlaciona los contadores con marcas de tiempo y eventos del show, y cambia solo un límite cada vez. Trata los errores persistentes, un offset de reloj inestable, paquetes tardíos o una utilización alta sostenida como indicios a investigar antes de que se conviertan en fallos audibles.

Un recorrido saludable necesita más que un check verde

Una suscripción puede establecerse aunque la ruta tenga un cableado marginal, un uplink congestionado, un clocking inestable o una configuración que solo falla con carga completa. Dante Controller expone varias vistas que ayudan a separar problemas de endpoint, enlace, temporización y tráfico.

Usa estas señales juntas. Un contador antiguo sin correlación temporal es una prueba más débil que un contador que sube justo durante el corte.

Crea un flujo de monitorización

1. Captura una línea base conocida

Antes de abrir puertas, construye el estado de routing completo y ejecuta audio realista. Registra las velocidades de enlace primaria y secundaria, la utilización Tx/Rx normal, los ajustes y estadísticas de latencia, el clock leader actual, el estado de sincronía de los followers y los contadores de errores. Una línea base hace visible el cambio posterior.

2. Empieza por el dispositivo afectado

Abre Device View e inspecciona Status del origen y del destino. Confirma el estado conectado, la velocidad de enlace esperada, la dirección IP, la utilización y los recuentos de errores en la interfaz activa. En sistemas redundantes, inspecciona primaria y secundaria por separado; no las promedies en una sola conclusión.

Un enlace de 100 Mbps no es automáticamente defectuoso, pero tiene menos capacidad y puede limitar las opciones de latencia. Compáralo con la especificación del dispositivo y la carga de tráfico diseñada.

3. Sigue la ruta del switch

Comprueba el puerto del endpoint, los trunks intermedios y los uplinks en orden. Busca cambios de velocidad negociada, errores CRC o de capa física, paquetes descartados, congestión de colas, cambios de topología y propagación multicast inesperada. Un contador limpio en el endpoint no demuestra que el uplink esté limpio.

La guía de requisitos de switches de red Dante cubre la selección de switches, EEE, capacidad y pruebas de aceptación.

4. Correlaciona la evidencia de latencia

La latencia del receptor es un búfer frente a la variación del retraso de red. En Dante Controller, inspecciona el historial de latencia y los indicadores de paquetes tardíos del receptor afectado. Los paquetes tardíos sugieren que llegaron después del plazo del búfer configurado; simplemente aumentar la latencia puede ocultar una ruta marginal, así que primero comprueba la velocidad del enlace, los saltos, la utilización, QoS y los errores.

Usa la guía de ajustes de latencia de Dante para distinguir un cambio de búfer válido de un fallo de red.

5. Lee el historial del reloj, no solo el estado actual

Clock Status Monitor registra advertencias, desbloqueos, relocks, mutes y unmutes. Su historial de offset de frecuencia muestra cuánto esfuerzo está haciendo un reloj follower para seguir al leader. Un lock actual estable no borra un desbloqueo anterior durante el incidente reportado.

Un offset distribuido o que cambia rápidamente puede acompañar enlaces sobrecargados, Energy Efficient Ethernet problemática o una fuente de reloj externa imprecisa. Confirma la arquitectura del reloj con la guía del clock leader de Dante.

Interpreta la utilización con margen

La guía de Controller de Audinate usa aproximadamente el 85% de la velocidad del enlace como regla general superior para la utilización Tx o Rx, con el fin de preservar el rendimiento del reloj. Trátalo como un límite de advertencia, no como objetivo de diseño. Las redes de producción necesitan margen para tráfico de control, clocking, ráfagas, backups y cambios de ruta.

La utilización Rx puede incluir tráfico multicast o broadcast no destinado al dispositivo. Por tanto, una carga de recepción inesperada puede revelar un problema de pruning multicast o de VLAN incluso cuando ese endpoint suscribe pocos canales.

Diagnostica por patrón de evidencias

No borres logs ni reinicies dispositivos hasta haber capturado la evidencia. Reiniciar restablece contadores útiles y puede convertir un fallo intermitente en una historia sin documentar.

Ejecuta una prueba de aceptación controlada

1. Carga todas las rutas del show y los flujos multicast.
2. Ejecuta tráfico de audio y control representativo.
3. Observa la utilización de endpoints y uplinks.
4. Confirma que los contadores de errores de paquetes permanecen estables.
5. Revisa las estadísticas de latencia de los receptores.
6. Fuerza el fallo aprobado del primary o del uplink.
7. Confirma que el reloj, el audio, el control y la redundancia se recuperan.
8. Guarda marcas de tiempo, capturas de las vistas de datos cuando sea apropiado para registros internos y la línea base final.

El contenido público de Learn y los riders deben contener evidencia textual, no capturas sensibles de la red. Mantén las exportaciones diagnósticas detalladas en la documentación controlada de la producción.

Lista de comprobación de salud de red

• El routing completo del show y el tráfico están activos durante la prueba.
• Las interfaces primaria y secundaria se inspeccionan por separado.
• Se confirma la velocidad de enlace esperada de extremo a extremo.
• La utilización Tx/Rx tiene margen operativo.
• Los contadores de errores son estables, no solo pequeños.
• Las estadísticas de latencia del receptor no muestran paquetes tardíos.
• Se revisan las advertencias de reloj, el offset, los mutes y los cambios de leader.
• Se registran el fallo, la recuperación, las marcas de tiempo, el responsable y la línea base.

FAQ

¿Cómo compruebo la salud de una red Dante?

Inspecciona el estado y la velocidad del enlace, la utilización Tx/Rx, los contadores de errores, las estadísticas de latencia del receptor y el historial de Clock Status. Compáralos con una línea base conocida y en carga completa, junto con la ruta del switch.

¿Qué significan los errores de paquetes Dante?

Indican que paquetes o tramas no se han gestionado correctamente en una interfaz o en una ruta. Comprueba si el recuento aumenta durante el fallo y luego inspecciona cableado, puertos, ópticas, negociación, congestión y contadores del switch.

¿Cuánta utilización de red Dante es demasiado alta?

La guía de Controller trata aproximadamente el 85% de la velocidad del enlace como regla general superior, pero un diseño de producción debe mantenerse cómodamente por debajo de ese valor y preservar margen para reloj, control, ráfagas y fallos.

¿Cómo leo el monitor de estado del reloj de Dante?

Revisa las advertencias con marca temporal, los desbloqueos, relocks, mutes y unmutes, y después inspecciona el historial de offset de frecuencia del follower. Correlaciona la hora del evento con cambios de tráfico, de enlace y de reloj externo.

¿Qué debo registrar al solucionar cortes de Dante?

Registra la hora exacta, la ruta afectada, el dispositivo y la interfaz, la velocidad de enlace, la utilización, los errores cambiantes, la evidencia de latencia, los eventos de reloj, la ruta del switch, los cambios recientes, la acción correctiva y el resultado.

Convierte la monitorización en una entrega compartida

Una línea base solo ayuda cuando el siguiente ingeniero puede encontrarla. Mantén las velocidades de enlace aprobadas, la carga de routing, la latencia, el responsable del reloj, la prueba de fallo y las notas de escalado en Techrider.live junto con el rider técnico actual para que los colaboradores puedan editar, guardar e inspeccionar el historial desde una única fuente mantenida.