Scripting MikroTik: automatiza tu red RouterOS

Si operas una red MikroTik de cierto tamaño —un ISP con cientos de PPPoE, un core con multi-WAN, decenas de sitios remotos— sabes que la operación manual no escala. Tarde o temprano alguien olvida el respaldo nocturno, un enlace se cae a las 3 de la madrugada y nadie se entera hasta que suena el teléfono, o una tarea repetitiva se hace distinta en cada router. El scripting MikroTik existe para cerrar ese hueco: RouterOS trae un lenguaje propio que te permite convertir esas rutinas frágiles en tareas que el equipo ejecuta solo, siempre igual, con registro de lo que pasó. En este artículo repasamos cómo funciona de verdad, con los menús y comandos reales de RouterOS v7, sin humo.

Por qué el scripting MikroTik cambia tu operación

RouterOS incluye un intérprete de scripts integrado. No necesitas un servidor externo ni instalar nada: el código vive dentro del router, en /system/script, y se puede disparar por horario, por evento o a mano. Esto marca una diferencia frente a operar solo desde la consola: en vez de escribir los mismos comandos noche tras noche, defines la lógica una vez y el equipo la repite sin desviaciones.

Las tres piezas que vas a usar todo el tiempo son el script (el bloque de código), el scheduler (el disparador por horario) y netwatch (el disparador por estado de un host). Combinadas cubren la mayoría de la automatización que un NOC necesita en el día a día.

Mecanismo	Menú RouterOS	Cuándo se ejecuta	Uso típico
Script	/system/script	Bajo demanda o llamado por otro	Lógica reutilizable, respaldos, reportes
Scheduler	/system/scheduler	Por horario o intervalo	Tareas periódicas (backup diario, limpieza)
Netwatch	/tool/netwatch	Al cambiar el estado de un host	Failover, alertas de caída de enlace

Anatomía de un script en RouterOS

Un script se guarda en /system/script con un name, un cuerpo source y una policy que define qué permisos tiene ese código al correr (read, write, test, ftp, reboot, policy, entre otros). El lenguaje tiene los elementos que esperarías: variables, condicionales, bucles y funciones de registro. Estos son los comandos base que vas a reconocer:

• :global — declara una variable global, visible entre scripts y persistente en /system/script/environment.
• :local — variable acotada al script actual.
• :if / :foreach — condicionales y bucles sobre resultados de find.
• :log info / warning / error — deja rastro en el log del sistema.
• :set, :put — asigna valores e imprime a consola.

Un patrón que aparece en casi todo script real es recorrer objetos filtrados con find. Por ejemplo, detectar interfaces caídas y registrarlas:

:foreach i in=[/interface/find where running=no] do={
    :log warning ("Interfaz caida: " . [/interface/get $i name])
}

El bloque [/interface/find where running=no] devuelve los IDs que cumplen la condición, y :foreach itera sobre ellos. Ese mismo esquema sirve para recorrer secretos PPPoE, direcciones de firewall address-list, colas o cualquier menú.

Un detalle que conviene entender temprano es la diferencia entre variables locales y globales. Una :local muere cuando termina el script; una :global queda registrada en /system/script/environment y sigue disponible para otros scripts o para la siguiente ejecución del scheduler. Eso te permite, por ejemplo, guardar en una global el estado del último enlace conmutado y que el próximo ciclo del script sepa de dónde viene, sin escribir nada a disco. Con esa base —variables con alcance claro, find bien filtrado y :log en los puntos críticos— ya puedes construir prácticamente cualquier rutina que hoy haces a mano.

Automatizar tareas reales con scheduler y netwatch

Un script suelto no hace nada hasta que algo lo dispara. El caso más común es el respaldo automático. Primero defines el script que genera el backup binario y el export legible, con la fecha en el nombre:

/system/script
add name=backup-diario policy=read,write,ftp,test dont-require-permissions=no source={
    :local fecha [/system/clock/get date]
    /system/backup/save name=("auto-" . $fecha)
    /export file=("config-" . $fecha)
    :log info ("Respaldo generado: " . $fecha)
}

Luego el scheduler lo ejecuta cada día a las 03:00. Fíjate en on-event, que apunta al nombre del script, e interval, que define la periodicidad:

/system/scheduler
add name=respaldo-0300 start-time=03:00:00 interval=1d \
    on-event=backup-diario policy=read,write,ftp,test

El scheduler expone además propiedades de solo lectura muy útiles para auditar: run-count (cuántas veces corrió), next-run (próxima ejecución) y owner. Con start-time=startup puedes incluso disparar un script en cada arranque del equipo.

El otro disparador clave es netwatch, que vigila un host y ejecuta un script cuando cambia de estado. Es la base de un failover simple entre enlaces: si el gateway primario deja de responder, se apaga su ruta y el tráfico toma la secundaria.

/tool/netwatch
add host=8.8.8.8 type=icmp interval=10s \
    up-script="/ip route enable [find comment=wan-primaria]" \
    down-script={
        /ip route disable [find comment=wan-primaria]
        :log warning "WAN primaria caida: conmutando a respaldo"
    }

Las propiedades up-script y down-script reciben el bloque de código a correr en cada transición. El mismo mecanismo, apuntando a un /tool/fetch hacia una API o un webhook, te permite avisar a Telegram, a tu sistema de tickets o a una plataforma de monitoreo cuando algo cambia, sin depender de que alguien esté mirando la pantalla.

Casos donde el scripting MikroTik paga solo

Más allá del respaldo, estos son escenarios donde automatizar rinde de inmediato en una red ISP o de empresa:

• Failover y sondeo de enlaces: netwatch con up-script/down-script para conmutar rutas o cambiar distancias sin intervención.
• Address-lists dinámicas: scripts que pueblan listas de firewall (bloqueo de escáneres, geo-bloqueo, allow-lists) leyendo fuentes con /tool/fetch.
• Reportes programados: un scheduler que recolecta uso de CPU, temperatura o tráfico y lo envía por correo o a un colector.
• Provisión repetible: plantillas de configuración aplicadas igual en cada CPE o router de borde, reduciendo el error humano.
• Mantención: limpieza de logs, rotación de archivos de export, verificación de certificados próximos a vencer.

En todos estos casos la ganancia no es solo ahorrar tecleo: es consistencia. La tarea corre igual en el router de Arica y en el de Punta Arenas, y queda registrada en el log para cuando necesites reconstruir qué pasó. También cambia la naturaleza de las guardias: en vez de esperar a que un cliente reporte la caída, el propio router detecta el evento, actúa y avisa; el ingeniero llega a un incidente ya mitigado, no a apagar el incendio desde cero.

Vale una advertencia honesta: el scripting es potente, pero no reemplaza el diseño. Un failover por netwatch resuelve un caso simple de dos rutas, no sustituye a BGP con múltiples upstreams ni a un esquema de alta disponibilidad bien pensado. La automatización rinde cuando se apoya sobre una arquitectura sólida; encima de una red mal diseñada, solo automatiza el desorden.

Buenas prácticas para scripting MikroTik en producción

Automatizar mal es peor que no automatizar: un script con permisos de más o mal probado puede tumbar un core. Algunas reglas que aplicamos siempre:

• Policy mínima: asigna en policy solo los permisos que el script realmente usa. Uno que solo lee no necesita write ni reboot.
• Prueba con test y logs antes de actuar: valida la lógica con :put y :log antes de ejecutar comandos destructivos; usa find con where específico para no tocar objetos de más.
• Nombres y comentarios claros: apoya tus find en comment estables (como comment=wan-primaria) en vez de en IDs, que cambian.
• Control de versiones: guarda los /export fuera del equipo para tener historial de configuración y poder revertir.
• Revisa run-count y el log: un scheduler cuyo contador no avanza es una tarea que dejó de correr sin que nadie lo note.

El scripting es una de esas capacidades de RouterOS que separan una red que se opera a mano de una que se opera con criterio de ingeniería. Y como todo en MikroTik, la mejor forma de dominarlo es con base sólida: en nuestros cursos oficiales MikroTik partimos del fundamento y llegamos a la automatización aplicada a producción.

Conversemos

En MikroTik Chile diseñamos, implementamos y operamos redes MikroTik para ISP y empresas, y el scripting es parte central de cómo las mantenemos estables y auditables. Si quieres llevar tu operación de tareas manuales a automatización real —respaldos, failover, alertas, provisión— cuéntanos tu caso y lo revisamos de ingeniero a ingeniero. Conversemos sobre tu red.