Monitoreo 24/7 de red MikroTik: qué vigilar

Cuando una red de ISP o de una empresa con infraestructura crítica se cae a las 3 de la madrugada, la pregunta no es solo "¿qué falló?", sino "¿por qué nos enteramos por el reclamo de un cliente y no por una alerta?". Ese es exactamente el vacío que llena un buen monitoreo de red MikroTik: dejar de operar a ciegas y pasar a tener visibilidad continua del estado de tus routers, switches y enlaces. RouterOS trae las herramientas para hacerlo bien —SNMP, Netwatch, Traffic Flow, graphing y monitoreo de salud del hardware—, pero la mayoría de las redes las usa a medias o directamente no las tiene configuradas. En este artículo revisamos qué vigilar de forma realista en un esquema 24/7 y con qué mecanismos de RouterOS hacerlo.

Qué significa monitoreo 24/7 en una red MikroTik

Monitorear no es "tener un Winbox abierto". Un esquema 24/7 serio combina tres capas: recolección continua de métricas (para ver tendencias y detectar degradación antes de la caída), detección de eventos (para saber en segundos que un enlace se cayó) y análisis de tráfico (para entender qué consume la red y anticipar la saturación en hora peak). RouterOS no es un NMS por sí solo: su rol es exponer los datos de forma estándar para que un colector externo —Zabbix, LibreNMS, Grafana con Prometheus, o el que uses— los almacene, grafique y dispare alertas.

La decisión de diseño clave es esa separación: el router entrega datos, el colector decide y alerta. Por eso un buen monitoreo de red MikroTik empieza por dejar bien parada la capa de exposición dentro de RouterOS, que es donde nos concentramos aquí.

SNMP: la base del monitoreo de red MikroTik

SNMP es el protocolo que tu NMS usa para consultar a cada equipo de forma periódica (típicamente cada 60 segundos): tráfico por interfaz, CPU, memoria, sesiones, temperatura y decenas de OIDs más. En RouterOS se habilita bajo /snmp y se define una o más comunidades en /snmp/community. Un error habitual es dejar la comunidad public abierta a todo el mundo: en producción conviene restringir por rango de origen y, en equipos expuestos, usar SNMPv3 con autenticación y cifrado.

/snmp
set enabled=yes contact="NOC MikroTik Chile" location="Core Santiago"

/snmp/community
add name=noc-ro addresses=10.10.0.0/24 security=private \
    authentication-protocol=SHA1 authentication-password=CAMBIA-ESTA \
    encryption-protocol=AES encryption-password=CAMBIA-ESTA \
    read-access=yes write-access=no

Con security=private exiges autenticación y cifrado (SNMPv3); read-access=yes y write-access=no dejan la comunidad en solo lectura, que es lo correcto para monitoreo. Para probar sin levantar el NMS completo puedes usar /tool/snmp-get y /tool/snmp-walk desde otro RouterOS y verificar que los OIDs responden.

Un detalle operativo: SNMP recolecta datos de varios servicios internos y, si alguno tarda, RouterOS registra avisos del tipo "timeout while waiting for program" (hasta 30 segundos por servicio, y hasta 5 minutos para el servicio de routing). Si ves esos logs, no es que SNMP esté roto: es un servicio del equipo respondiendo lento, y ahí ya tienes una pista de dónde mirar.

Netwatch: detección de caídas y reacción automática

SNMP te da tendencias, pero para saber en segundos que un host o un enlace murió, la herramienta es Netwatch (paquete advanced-tools). Monitorea el estado de hosts con distintos tipos de sonda: simple e ICMP (ping, con umbrales), tcp-conn (prueba una conexión TCP), http-get/https-get (consulta un servidor) y DNS (verifica que un resolver responda). El campo host es obligatorio en cualquier sonda.

Lo potente es que Netwatch ejecuta scripts según el cambio de estado: up-script cuando pasa a Up, down-script cuando pasa a Down, y test-script en cada prueba. Con eso el router no solo avisa: reacciona —marca una ruta, cambia de gateway, o dispara una notificación—. Un uso típico es monitorear el gateway de tu WAN primaria y, ante caída, gatillar el failover.

/tool/netwatch
add host=200.1.1.1 type=icmp interval=10s \
    down-script=":log warning \"WAN primaria DOWN\"; /ip route enable wan-backup" \
    up-script=":log info \"WAN primaria UP\"; /ip route disable wan-backup"

Si no defines scripts, igual puedes seguir los cambios de estado en el log habilitando el topic info. Ojo con los permisos: los scripts de Netwatch corren limitados a las políticas read,write,test,reboot; si tu script excede eso, no se ejecuta. Asigna permisos justos en lugar de desactivar el chequeo de permisos, que baja la seguridad del equipo.

Traffic Flow y graphing: ver de dónde viene el tráfico

Saber que un enlace está al 90% no basta; necesitas saber qué lo llena. Traffic Flow exporta estadísticas de flujos (compatible con NetFlow v9 e IPFIX) hacia un colector, donde puedes ver top talkers, protocolos y destinos. Se habilita en /ip/traffic-flow y se apunta a un colector con /ip/traffic-flow/target.

/ip/traffic-flow
set enabled=yes

/ip/traffic-flow/target
add dst-address=10.10.0.5 port=2055 version=9

En equipos de core con mucho tráfico puedes activar packet-sampling para no cargar la CPU muestreando cada paquete. Para un vistazo rápido sin colector externo, RouterOS también tiene /tool/graphing, que genera gráficos históricos de interfaces (ifaces), colas (queues) y recursos del sistema (resource) accesibles desde el propio equipo. No reemplaza a un NMS, pero sirve para un diagnóstico puntual.

Salud del hardware: temperatura, voltaje y CPU

Muchas caídas no empiezan en el software, sino en el equipo físico. RouterOS expone métricas de system health —según el modelo— como temperatura (cpu-temperature, pcb-temperature, sfp-temperature), voltaje de alimentación y estado de ventiladores. Todas son consultables por SNMP, así que vale la pena graficarlas y ponerles umbral. Un detalle a tener en cuenta al leerlas fuera de Winbox: por SNMP y scripts, la temperatura viene multiplicada por 10 y el voltaje en decivolts (dV), no en las unidades "bonitas" de la consola.

La otra métrica crítica es la CPU. Si un equipo de core empieza a subir de uso sostenido, quieres saber qué proceso lo consume antes de que degrade el forwarding. Para eso está /tool/profile, que muestra el porcentaje de CPU por proceso:

/tool/profile cpu=total

Esto te dice si el consumo viene de firewall, routing, encrypting u otro, y evita el diagnóstico a ciegas cuando "el router está lento".

Qué vigilar: checklist mínimo para 24/7

Reuniendo lo anterior, este es el conjunto base que toda red MikroTik en producción debería estar monitoreando, con el mecanismo y el umbral de referencia:

Qué vigilar	Mecanismo RouterOS	Umbral de alerta sugerido
Uso de CPU	SNMP + /tool/profile	> 70% sostenido
Tráfico por interfaz	SNMP / graphing	> 80% de la capacidad del enlace
Estado de WAN / gateways	Netwatch (ICMP)	Cualquier transición a Down
Temperatura del equipo	SNMP (system health)	Según rango del modelo
Voltaje de alimentación	SNMP (system health)	Fuera del rango nominal
Top talkers / anomalías de tráfico	Traffic Flow (NetFlow v9 / IPFIX)	Cambios bruscos de patrón
Sesiones (PPPoE / BGP)	SNMP + logs	Caída de peers o abonados

Con esa base cubres las tres capas —métricas, eventos y tráfico— sin sobre-instrumentar. A partir de ahí, cada red suma lo suyo: cantidad de sesiones PPPoE si eres ISP con abonados por PPPoE, estado de vecindades OSPF/BGP en el core, o latencia de enlaces de última milla. Lo importante es que el diseño del monitoreo siga la topología, no una plantilla genérica.

El monitoreo es tan bueno como quien lo interpreta

Tener SNMP, Netwatch y Traffic Flow configurados es la mitad del trabajo; la otra mitad es definir umbrales que signifiquen algo, evitar el ruido de alertas que nadie mira, y tener a alguien que reaccione cuando la alerta llega de madrugada. Ahí es donde un servicio de monitoreo continuo y de soporte técnico especializado en RouterOS marca la diferencia entre un dashboard bonito y una red que efectivamente se mantiene de pie.

En MikroTik Chile diseñamos, implementamos y operamos esquemas de monitoreo de red MikroTik para ISP y empresas con infraestructura de misión crítica: desde dejar bien parada la exposición de métricas en cada equipo hasta la observabilidad completa con alertas accionables. Si quieres revisar qué estás vigilando hoy y qué te está faltando, conversemos con un ingeniero. Cuéntanos cómo está tu red y armamos el plan de monitoreo que corresponde a tu operación.