Por qué el log local no alcanza
Por defecto RouterOS loguea a memoria: un buffer chico y volátil. Eso trae tres problemas para un ISP con varios equipos:
- Se borra al reiniciar — justo cuando más lo necesitás (después de una caída).
- El buffer es chico: en un router con tráfico, los eventos viejos se pisan en minutos.
- Está aislado por equipo: no podés cruzar lo que pasó en el router de un nodo con lo de otro para ver un patrón.
La solución es mandar todo a un servidor syslog central por la red. Ahí queda persistido, con retención larga y consultable de una sola vez para toda tu red.
Paso 1 — Tener el servidor que recibe
Cualquier host Linux con rsyslog sirve para empezar. Escucha en UDP/514 y escribe a archivo. Para algo consultable de verdad, el paso siguiente es volcarlo a una base de datos (por ejemplo PostgreSQL) o a un stack de logs, pero para arrancar alcanza con rsyslog a archivo por equipo.
# /etc/rsyslog.d/mikrotik.conf
# Un archivo por IP de origen
$template MikroFile,"/var/log/mikrotik/%FROMHOST-IP%.log"
*.* -?MikroFile
& stopHabilitá la recepción por UDP (o TCP para no perder mensajes en enlaces con pérdida) y reiniciá rsyslog.
Paso 2 — Configurar el Mikrotik
Primero definís la acción remota (a dónde mandar) y después qué topics mandás a esa acción:
# La acción: IP del servidor syslog
/system logging action
add name=remote target=remote remote=10.0.0.20 remote-port=514 src-address=10.0.0.1
# Qué mandar a esa acción
/system logging
add topics=info action=remote
add topics=error action=remote
add topics=warning action=remote
add topics=critical action=remoteReemplazá 10.0.0.20 por tu servidor y src-address por la IP de gestión del router (así el server identifica de qué equipo viene).
Si mandás desde varios routers, poné un src-address de gestión distinto por equipo y mapeá cada IP a su localidad en el servidor. Sin eso, después no sabés qué log es de qué nodo.
Paso 3 — Qué topics enviar (sin ahogar el server)
Mandar todo genera ruido y consume disco. Para un ISP, este set cubre lo que importa — diagnóstico de PPPoE y seguridad — sin exagerar:
| Topic | Para qué sirve |
|---|---|
pppoe, ppp | Levantada/caída de sesiones — clave para flapping |
dhcp | Asignación de direcciones, detectar conflictos |
firewall (vía log rules) | Bloqueos, escaneos, tráfico sospechoso |
system, error, critical | Reinicios, fallos de hardware, cambios de config |
account | Logins al router — auditoría de seguridad |
En equipos con poca memoria, evitá loguear topics muy verbosos (como debug) a memory. Para lo que va a remote no es problema, pero no dupliques todo a memoria local o vas a comerte la RAM.
Paso 4 — Usarlo: de log a diagnóstico
Con el histórico central ya podés hacer lo que antes era imposible:
- Contar caídas por cliente: ¿quién flapeó más veces esta semana? Eso prioriza las visitas técnicas.
- Cruzar localidades: si tres nodos loguean errores a la misma hora, el problema es aguas arriba (upstream), no de cada router.
- Ver intentos de intrusión: logins fallidos repetidos o escaneos quedan registrados para siempre.
- Correlacionar con la óptica: un pico de caídas PPPoE + degradación óptica = problema de fibra confirmado.
Todo esto es la materia prima del diagnóstico de flapping de PPPoE: sin el histórico centralizado, ese diagnóstico no se puede hacer.
Montar el pipeline, mapear localidades y armar los reportes lleva tiempo. Con nuestro servicio de NOC te dejamos syslog central, monitoreo y alertas andando — y lo miramos por vos 24/7.
Ver el servicio de NOC →