Resumen

  • La presentación de LACNIC 46 estima 23 minutos hasta la primera queja y otros 67 de diagnóstico manual después de un corte ilustrativo de 14 segundos.
  • La solución propuesta concentra syslog, datos de RouterOS v7, sesiones RADIUS y topología para que un operador consulte una base local mediante SQL de solo lectura.

La primera señal de una falla puede ser una llamada de un abonado. En la cronología que mostraron Joaquín Tadeo Riedmaier y Santiago Agustín Zualet, ese reclamo llega 23 minutos después de un corte de enlace de 14 segundos. Encontrar la causa consume 67 minutos más. La suma da unos 90 minutos para explicar una interrupción que terminó casi al instante.

El reloj aparece en una presentación del grupo de trabajo IMWG, en LACNIC 46 · LACNOG 2026, celebrado en Mendoza. Los autores, de la Facultad de Ingeniería de la Universidad Nacional de Misiones, califican el recorrido como una estimación típica para un evento crítico y aclaran que los horarios son ilustrativos. El dato fuerte no es una promesa de reparación: es la distancia entre el corte y una explicación que el operador pueda sostener con registros.

Su propuesta busca cerrar esa distancia con una tubería local. Syslog por UDP empuja cambios de estado, errores, flapping de enlaces y desconexiones PPPoE/RADIUS. La API REST de RouterOS v7 aporta tráfico, errores y descartes por interfaz o VLAN, CPU y memoria, tablas ARP y seguimiento de conexiones. RADIUS suma el estado de las sesiones activas por NAS. Al juntar esos registros con la topología, el equipo puede mirar al mismo tiempo la interfaz que cayó y los servicios que dependían de ella.

El diseño coloca la recolección dentro del ISP, en un nodo Docker. Django recibe los eventos y consulta la API; un proceso Python filtra ruido, normaliza y deduplica; PostgreSQL organiza los datos en vistas preparadas para preguntas. Un modelo local convierte una consulta del operador en SQL sobre esas vistas. El esquema se aplana para reducir uniones y el usuario de base de datos solo permite SELECT. La diapositiva dice que el modelo se probó con 32 GB de RAM, pero no nombra modelo, carga de trabajo ni tiempo de respuesta.

La demostración incluye una consulta por caídas en las últimas cuatro horas. La respuesta de ejemplo asigna siete eventos de ether2 a NAS 6 y menciona 23 sesiones PPPoE afectadas. La propia presentación lo etiqueta como ilustrativo. En otra escena, errores L2/L3, connection tracking, RADIUS y PPPoE coinciden a las 12:04; el diagnóstico de una falla física también es un escenario con datos simulados. Los ejemplos muestran cómo se vería una explicación vinculada a varias fuentes, no una caída real documentada.

Hay dos trabajos distintos en la arquitectura. Los umbrales deberían avisar antes de que llegue la queja; el tablero y la consulta en lenguaje corriente ayudan a reconstruir el incidente. Si los eventos no se retienen, las interfaces no comparten reloj o una consulta mezcla la sesión equivocada, el texto fluido del modelo solo hace más convincente un diagnóstico débil. La materia prima sigue siendo syslog oportuno, medidas API con edad conocida y relaciones correctas entre router y abonado.

La presentación llama estimación al recorrido de 90 minutos y efecto esperado al objetivo de 18, pero no publica un conjunto de incidentes ISP, frecuencia de consulta API, tiempos medidos antes y después, falsos positivos ni un método para su meta de ≥95 %; un informe piloto por incidente cambiaría la valoración.

Ese es el siguiente paso que importa. El proyecto localiza el trabajo perdido entre logs dispersos y contexto de abonados; un ensayo debe mostrar qué señal detectó el microcorte, cuándo apareció la alerta y cuándo un técnico confirmó la causa. Con esa secuencia, un proveedor podría decidir si el sistema recorta trabajo o solo cambia las preguntas que hace en pantalla.

Fuentes: agenda oficial de LACNIC 46; presentación original del IMWG.