Actualizar RouterOS v7: parche de seguridad y migración

Si administras un core de ISP o la red de una empresa con equipos MikroTik que todavía corren RouterOS v6, cada semana que pasa es deuda técnica acumulada. RouterOS v6 ya no recibe features y las correcciones de seguridad relevantes viven en la rama v7. Actualizar RouterOS v7 dejó de ser un experimento de laboratorio: con la llegada de la rama long-term (LTS) a la serie 7, la migración es la opción conservadora, no la arriesgada. El problema es que un upgrade mal ejecutado en un router de borde o en el BNG puede convertirse en una ventana de indisponibilidad para cientos de abonados. Este artículo ordena el proceso real: release chains, comandos, bootloader, el salto desde v6 y el plan de rollback.

Por qué actualizar RouterOS v7 es una decisión de seguridad, no de features

La conversación sobre versiones suele girar en torno a funciones nuevas —BGP reescrito, WireGuard nativo, contenedores—, pero para un responsable de infraestructura el driver principal es otro: el firmware que expone tu red a internet debe estar parchado. Un router de borde con Winbox, API o el servicio web alcanzables desde una interfaz WAN, corriendo una versión antigua, es superficie de ataque. Mantener la rama v6 significa quedarse sin las correcciones que MikroTik solo publica hacia adelante.

Actualizar no reemplaza a un buen diseño de firewall RouterOS: los servicios de administración deben estar filtrados por address-list y limitados a tu red de gestión, versión nueva o no. Pero el parche y el filtrado trabajan juntos. La versión te cierra las vulnerabilidades conocidas; el firewall reduce quién puede siquiera intentar explotarlas. Tratar el upgrade como parte de tu postura de seguridad —y no como una tarea opcional de "cuando haya tiempo"— es lo que separa a una red operada de una red simplemente encendida.

Entender las release chains antes de tocar nada

RouterOS se publica en cuatro cadenas de release, y elegir la correcta es la primera decisión al actualizar RouterOS v7. No todas las versiones están disponibles en todas las cadenas, y el canal define qué te ofrece el router al consultar el servidor de MikroTik.

Release chain	Frecuencia	Uso recomendado
Long term (LTS)	Rara; solo fixes críticos	Core, BNG y borde de producción donde la estabilidad manda
Stable	Cada pocos meses	Features probadas; equipos donde necesitas funcionalidad nueva
Testing	Cada pocas semanas	Solo lab; testeo interno básico, no para producción
Development	Cuando es necesario	Entusiastas y pruebas de features crudas

Un dato clave para operadores conservadores: la serie 7 ya tiene versiones con estatus long-term. Es decir, máxima estabilidad y una rama pensada para redes donde la fiabilidad va primero. Sobre el numbering, ojo con la trampa clásica: los puntos no son decimales. La v7.2 es más antigua que la v7.18, porque el 18 es una revisión posterior, no "menos que 2". Comparar versiones a ojo, asumiendo posición decimal, es una fuente real de errores al planificar la ventana.

El flujo real de actualización con check-for-updates

El mecanismo estándar hace que el router mismo —no tu PC— se conecte al servidor de descargas de MikroTik vía HTTPS y consulte si hay una versión nueva en el canal seleccionado. Esto tiene una implicancia operativa concreta: el equipo necesita salida HTTPS y debes permitir el puerto TCP 443 en cualquier firewall que esté delante de él. Si tu red de gestión bloquea salida, el check falla y no es un bug.

El flujo por CLI, que es el que recomendamos por ser reproducible y auditable, es directo:

/system/package/update/set channel=long-term
/system/package/update/check-for-updates
# Revisa installed-version, latest-version y status:
/system/package/update/print

# Si status = "New version is available":
/system/package/update/download
/system/reboot

El comando download deja los paquetes en el equipo y exige un reboot manual para aplicar; install descarga y reinicia automáticamente. En un equipo crítico, separar descarga y reboot te da control sobre cuándo ocurre la interrupción. Si tienes paquetes extra instalados (por ejemplo el paquete de User Manager o de contenedores), el descargador los toma en cuenta y baja todo lo necesario. Cuando un paquete específico ya no está disponible o quieres omitirlo, existe /system/package/update/install ignore-missing, que instala solo el paquete principal de RouterOS.

Automatizar con el scheduler (con criterio)

Se puede automatizar consultando el servidor y disparando el upgrade solo si hay versión nueva:

/system/package/update/check-for-updates
:delay 3s;
:if ( [/system/package/update get status] = "New version is available") do={ /system/package/update/install }

Útil para una flota de CPE homogéneos, peligroso en el core: un reboot automático no coordinado en un router de agregación es exactamente lo que no quieres a las 20:00 en hora peak. Automatiza el borde de acceso; agenda el core.

No te olvides del bootloader (RouterBOOT)

Este es el paso que más se omite y que MikroTik recomienda explícitamente en cada upgrade. Cada versión de RouterOS trae incluida una nueva versión de RouterBOOT (el firmware del RouterBOARD), pero no se aplica sola: hay que ejecutarla a mano tras actualizar el sistema operativo. Para verificar el estado, compara dos valores:

/system/routerboard/print
# current-firmware: 7.18.2   <- RouterBOOT en uso
# upgrade-firmware: 7.19.3   <- disponible, incluido en el RouterOS ya instalado

/system/routerboard/upgrade
Do you really want to upgrade firmware? [y/n]
/system/reboot

Si upgrade-firmware muestra una versión más alta que current-firmware, hay un bootloader nuevo esperando. Tras el reboot, vuelve a hacer print y confirma que ambos valores coinciden. Saltarse este paso no rompe nada de inmediato, pero deja el equipo con un bootloader viejo que puede afectar arranque, recuperación y compatibilidad de hardware a futuro. Es trabajo de cinco minutos que cierra el ciclo del upgrade correctamente.

Migrar desde v6: el salto que no es directo

Aquí está el error que más caídas provoca. No puedes saltar de v6.x a la última v7 en un solo paso usando check-for-updates. Aunque selecciones el canal de upgrade de major release, el router solo te ofrecerá una versión intermedia (por ejemplo v7.12.1). Debes actualizar primero a esa versión intermedia y recién entonces, repitiendo el check-for-updates, aparecerán las releases v7 más nuevas. Planificar la migración asumiendo un único reboot cuando en realidad son dos es cómo una ventana de mantenimiento de 20 minutos se transforma en una emergencia.

Antes de migrar un equipo v6 a v7, considera además:

• Respalda la configuración con un backup binario y un export legible. El binario restaura el estado exacto; el export en texto te deja auditar y reconstruir si algo cambia de sintaxis entre versiones.
• Verifica la arquitectura en System → Resource antes de cualquier upgrade manual. Los paquetes son específicos por arquitectura (arm, arm64, tile, x86) y un paquete cruzado no aplica.
• Revisa cambios de comportamiento: el stack de routing de v7 (BGP, OSPF) se reescribió respecto de v6. Una config que "funcionaba" puede requerir ajustes. Esto es especialmente sensible en equipos con sesiones BGP o transporte MPLS.
• device-mode: desde v7.17 existen políticas que restringen ciertas transiciones y funciones. Si una operación queda bloqueada tras migrar, revisa /system/device-mode.

Para un core de ISP con full table BGP o MPLS/VPLS en producción, la migración v6→v7 no es "apretar upgrade": es un proyecto con laboratorio previo, ventana coordinada y rollback definido. Si ese es tu escenario, en nuestra consultoría de ingeniería MikroTik planificamos y ejecutamos ese tipo de migración sin apostar la red.

Ventana, respaldo y rollback: cómo actualizar sin apostar la red

Ningún upgrade responsable se hace sin un camino de vuelta. RouterOS lo permite: la misma herramienta de actualización sirve para downgrade cambiando el canal a uno que ofrezca una versión anterior más estable, y existe además /system/package/downgrade para volver a una versión previa presente en el equipo. Tu checklist mínimo antes de tocar producción:

• Backup binario + export descargados fuera del equipo, no solo guardados en él.
• Acceso fuera de banda (consola serial, otro enlace de gestión) por si el equipo no vuelve tras el reboot.
• Ventana en horario valle, nunca en hora peak, con aviso al NOC.
• Un equipo primero: valida en un router no crítico o en un par redundante antes de tocar el resto de la flota.
• Criterio de éxito verificable: sesiones BGP levantadas, rutas presentes, tráfico cursando y current-firmware igual al RouterOS instalado.

La combinación de HA (par redundante o failover) con upgrades escalonados es lo que permite actualizar RouterOS v7 en una red de misión crítica sin ventana visible para el usuario final: actualizas el equipo en standby, conmutas, validas y luego el otro. Diseñar la red para poder parchar sin dolor es, en sí mismo, una decisión de arquitectura.

En MikroTik Chile hacemos exactamente esto todos los días: planificar y ejecutar migraciones a RouterOS v7 en ISPs y empresas, con laboratorio previo, ventanas coordinadas y rollback definido, respaldados por un equipo certificado y por un Entrenador y Consultor Oficial MikroTik. Si tienes core o borde todavía en v6, o quieres ordenar tu política de parcheo, conversemos: cuéntanos tu caso en soporte y operación o revisa nuestra consultoría MikroTik.