Análisis de Syslogs: Identificando patrones de micro-cortes en la OLT
Para un proveedor de servicios de internet (ISP), la estabilidad de la última milla en redes ópticas pasivas con capacidad de gigabit (GPON) es el pilar fundamental de la satisfacción del cliente. Sin embargo, los técnicos de Nivel 1 y Nivel 2 a menudo se enfrentan a un enemigo silencioso e intermitente: los micro-cortes. Un abonado que experimenta caídas de conexión de apenas unos segundos o minutos rara vez muestra alarmas permanentes en el sistema de gestión de red (NMS). Cuando el ticket llega a soporte, la ONT (Optical Network Terminal) suele estar online y con niveles ópticos aparentemente normales.
¿Cómo resolver un problema que desaparece antes de que podamos medirlo? La respuesta no está en realizar pruebas de ping interminables, sino en el análisis predictivo y forense de los Syslogs de la OLT. Cada vez que una ONT pierde la sincronización, cambia de estado o experimenta degradación, la OLT genera un registro preciso del evento. El desafío radica en saber filtrar el ruido y diferenciar con absoluta certeza si la desconexión se debe a un corte de energía eléctrica domiciliaria, a problemas físicos en la acometida de fibra, o al comportamiento destructivo de una Rogue ONT (ONT intrusa o maliciosa).
1. Configuración Esencial: Enviando los Logs de la OLT al Servidor Central
Antes de poder identificar patrones de comportamiento en los eventos de red, es obligatorio garantizar que la OLT no esté sobrescribiendo sus propios registros debido a la memoria volátil limitada de las tarjetas de control. Dependiendo de la densidad de clientes en el chasis, los buffers locales de la OLT pueden almacenar apenas unas pocas horas de historial si se presenta una tormenta de alertas.
La mejor práctica en la arquitectura de un ISP consiste en redirigir los eventos hacia un servidor centralizado mediante el protocolo Syslog estándar de forma inmediata. A continuación, se detallan los comandos de aprovisionamiento base para las dos marcas de OLT con mayor presencia en el mercado latinoamericano:
Configuración en OLT Huawei (VRP CLI)
En los sistemas de este fabricante, es crítico activar el canal de log y asignar el nivel de severidad correcto (se recomienda a partir de informational para capturar estados de transición de las ONTs):
OLT_Huawei(config)# sysman server syslog 192.168.100.25 port 514 OLT_Huawei(config)# log configuration syslog 192.168.100.25 facility local0 OLT_Huawei(config)# log-match rule 1 facility local0 severity informational format standard
Configuración en OLT ZTE (ROS CLI)
Para equipos de esta infraestructura, el proceso requiere habilitar el servicio de logs de manera global y especificar el destino de la siguiente forma:
OLT_ZTE(config)# logging server 192.168.100.25 OLT_ZTE(config)# logging level informational OLT_ZTE(config)# logging facility local0

2. El Patrón de Falta de Energía: Interpretando el «Dying Gasp»
Cuando un usuario apaga la ONT intencionalmente o se produce un corte en el suministro eléctrico de la zona residencial, el equipo no se desconecta de manera abrupta sin previo aviso. Las ONTs modernas cuentan con un circuito interno compuesto por capacitores que almacenan una pequeña reserva de energía residual. Esta reserva es suficiente para mantener el microprocesador encendido durante unos milisegundos adicionales, permitiéndole enviar una última ráfaga de datos hacia la OLT conocida técnicamente como la alarma Dying Gasp (el último suspiro).
Si en tus registros de Syslog identificas de forma consecutiva la recepción del Dying Gasp seguido de la pérdida de señal (LOS), estás ante un problema ajeno a la infraestructura de fibra óptica del ISP. Es un corte eléctrico local.
Estructura de un Log por Falta de Energía
En un servidor Syslog centralizado, el registro típico se muestra con las siguientes cadenas específicas:
2026-05-21T14:22:10-05:00 OLT_HUAWEI_01 GPON/4/NOTIFY: [GPON] ONT 0/1/2/15 lost notification, reason: dying-gasp. 2026-05-21T14:22:11-05:00 OLT_HUAWEI_01 GPON/3/ALARM: ONT 0/1/2/15 Optical Network Unit (ONT) Los of Signal (LOS) alarm occurred.
Nota cómo el evento de dying-gasp se registra un segundo antes o exactamente al mismo tiempo que la alarma de pérdida de señal (LOS). Esto confirma que el hardware se apagó de forma controlada por falta de alimentación eléctrica.
3. El Patrón de Fibra Dañada o Atenuación Estructural
A diferencia del apagado por energía, un corte físico en el cable drop de la acometida, un conector sucio en la caja NAP (Network Access Point) o una macrocurvatura severa por viento producen un patrón de logs radicalmente distinto. En este escenario, la ONT pierde la sincronización de manera inmediata y violenta o empieza a registrar fluctuaciones constantes en los estados de transmisión de tramas ópticas.
La OLT reportará una pérdida de señal (LOS) o una pérdida de tramas (LOFI – Loss of Frame of ONT) sin haber recibido un aviso previo de Dying Gasp. La ausencia de este aviso es la firma inconfundible de un fallo en la capa física.

Estructura de un Log por Degradación de Fibra
2026-05-21T15:45:32-05:00 OLT_HUAWEI_01 GPON/3/ALARM: ONT 0/1/5/32 Loss of frame (LOFI) occurred. 2026-05-21T15:45:35-05:00 OLT_HUAWEI_01 GPON/3/ALARM: ONT 0/1/5/32 Los of Signal (LOS) alarm occurred.
Si realizamos una auditoría de estos registros en un bloque de tiempo de 24 horas, el patrón de micro-cortes por fibra dañada o atenuación se caracteriza por eventos intermitentes de desconexión y reconexión automática (flapping) con variaciones drásticas en la potencia recibida (Rx Power) que la OLT registra periódicamente.
4. La Pesadilla del ISP: Identificando una Rogue ONT
Una Rogue ONT (también conocida como ONT intrusa o alienígena) representa una de las fallas más complejas de diagnosticar en soporte de segundo nivel si no se analizan los syslogs de forma matemática. En las redes GPON, se utiliza la tecnología TDM (Time Division Multiplexing) en sentido de subida (Upstream). Esto significa que la OLT le asigna a cada ONT un turno específico de tiempo en microsegundos para encender su láser e inyectar datos en la fibra común, evitando colisiones.
Una Rogue ONT es un dispositivo cuyo hardware o firmware se ha degradado, provocando que su láser de 1310 nm permanezca encendido de forma continua (Continuous Mode) o fuera de su ventana asignada. Al hacer esto, cega por completo el puerto PON de la OLT, destruyendo las comunicaciones de todas las demás ONTs que comparten ese mismo hilo de fibra, sin importar que sus niveles ópticos sean perfectos.

Patrón Forense en los Syslogs ante una Rogue ONT
Cuando este comportamiento destructivo inicia, el Syslog no mostrará un problema aislado en un solo cliente. El patrón característico es una caída masiva, simultánea e intermitente de múltiples ONTs en el mismo puerto PON, las cuales reportan alarmas del tipo SDF (Signal Degraded Frame) o SDOF (Signal Degraded ONT Frame).
2026-05-21T16:10:01-05:00 OLT_HUAWEI_01 GPON/3/ALARM: The OLT detected a Rogue ONT on Port 0/1/3. 2026-05-21T16:10:02-05:00 OLT_HUAWEI_01 GPON/4/NOTIFY: ONT 0/1/3/2, 0/1/3/3, 0/1/3/4, 0/1/3/5 state changed to offline due to upstream signal degradation.
Si observas que al caerse la ONT de la posición 3, automáticamente el resto de las ONTs de esa misma rama PON (del mismo puerto) empiezan a registrar desconexiones masivas sin registrar un Dying Gasp, tienes una Rogue ONT activa en el segmento. Las OLTs modernas de gama alta aíslan el puerto automáticamente si la función de detección está activa, pero en modelos estándar requerirás una intervención manual de apagado secuencial de puertos ópticos para dar con el equipo defectuoso.
5. Matriz Comparativa para Diagnóstico Rápido en Soporte
Para optimizar los tiempos de resolución (MTTR – Mean Time To Resolution) en el centro de operaciones de red (NOC), los operadores de soporte pueden guiarse por la siguiente tabla analítica de patrones lógicos basados exclusivamente en la recolección de Syslogs:
| Causa Raíz de la Falla | Alarma Primaria en Syslog | Presencia de Dying Gasp | Comportamiento de la Red |
|---|---|---|---|
| Falta de Energía en ONT | dying-gasp / LOS | SÍ (Obligatorio) | Evento aislado por abonado. Sigue cortes de luz locales. |
| Fibra Dañada / Atenuación | LOS / LOFI / LOKI | NO | Micro-cortes frecuentes (Flapping). Pérdida abrupta de sincronía. |
| Rogue ONT (Láser Continuo) | SDF / SDOF / Rogue Detection | NO | Afectación masiva. Caída en cadena de clientes en el mismo puerto PON. |

6. Automatización del Filtrado: Scripts de Extracción Rápida
Revisar millones de líneas de log de forma manual es inviable en entornos reales de ISP con miles de usuarios activos. Para agilizar el proceso de diagnóstico de micro-cortes, el equipo de soporte de infraestructura debe apoyarse en herramientas de automatización integradas en Linux o scripts en entornos de backend.
Filtrado Eficiente mediante Consola (Grep)
Si tienes acceso directo por consola SSH al archivo de registros centralizado del servidor Syslog (usualmente ubicado en rutas como /var/log/network.log), puedes ejecutar comandos avanzados utilizando expresiones regulares para extraer conclusiones en segundos.
Por ejemplo, para listar únicamente los clientes que han sufrido caídas por problemas de hardware o fibra en el día de hoy, descartando de forma limpia aquellos que simplemente se quedaron sin suministro eléctrico, se ejecuta el siguiente comando de exclusión en cascada:
grep "LOS" /var/log/network.log | grep -v "dying-gasp"
Este comando devolverá en pantalla únicamente aquellas líneas donde existió una pérdida de señal real (LOS) pero que no fueron antecedidas por la notificación de falta de energía. De esta manera, el equipo de soporte técnico de Nivel 2 obtiene de forma inmediata una lista de cables drops dañados, conectores inestables o problemas físicos críticos en las fusiones de la red de distribución óptica.
Conclusión y Siguientes Pasos
El análisis sistemático de los syslogs de la OLT transforma el soporte de red de un modelo puramente reactivo —donde dependemos de la llamada molesta del cliente— a un modelo predictivo de alta eficiencia técnica. Interpretar la secuencia de alertas de manera exacta permite despachar a las cuadrillas de planta externa únicamente cuando se comprueba un fallo real en la fibra, ahorrando cientos de horas operativas y optimizando drásticamente los recursos logísticos del ISP en toda la región.
