Gestión de flotas MikroTik con Ansible: actualizaciones centralizadas, sin caos y sin scripts chapuceros

El problema que nadie quiere admitir: actualizar routers MikroTik a mano no escala

Si tienes cinco routers MikroTik, actualizarlos uno a uno es molesto pero manejable. Si tienes veinte, ya estás mirando una tarde entera. Con cincuenta o más, estás en territorio de riesgo real: versiones desincronizadas, un router que nadie recuerda haber tocado, y backups que quizás existen o quizás no.

La respuesta habitual es un script Bash que alguien escribió hace tres años, que funciona en condiciones ideales y explota en silencio cuando la salida del comando no es exactamente lo que esperaba. No hay manejo de errores consistente, no hay idempotencia, y cada router que añades al entorno requiere ajustes manuales.

Ansible resuelve exactamente este problema, y la comunidad de administradores de red que trabaja con MikroTik lleva tiempo explorando cómo aplicarlo bien. Este artículo recoge lo que funciona, lo que tiene fricción y cómo estructurar un flujo de trabajo que aguante en producción.

La arquitectura que cambia las reglas: descargar una vez, distribuir a todos

El primer insight práctico, y posiblemente el más valioso, tiene que ver con cómo se distribuyen las actualizaciones de RouterOS.

El comportamiento por defecto cuando sale una nueva versión de RouterOS es que cada router la descarga directamente desde los servidores de MikroTik. Si tienes cincuenta routers y todos intentan descargarse el paquete a la vez, estás contribuyendo a saturar esos servidores — y probablemente obteniendo velocidades de descarga penosas en el proceso.

La alternativa con Ansible es simple y efectiva: el nodo de control descarga el paquete una sola vez y lo distribuye a cada dispositivo vía SSH/SCP. Ventajas inmediatas:

• Un único punto de descarga, sin saturación de servidores externos.
• El paquete queda almacenado localmente, con control de versiones: sabes exactamente qué versión instalaste y cuándo.
• Si necesitas hacer rollback o reinstalar, el archivo ya está disponible sin depender de conectividad externa.
• Los routers en sedes con ancho de banda limitado no tienen que competir entre sí.

Para una empresa con varias sedes distribuidas — un despacho central en Valencia, delegaciones en otras ciudades — esta diferencia es tangible en cada ciclo de actualización.

Qué incluir en un playbook de gestión MikroTik

Un conjunto de playbooks razonable para una flota de producción debería cubrir al menos estas áreas:

• Configuración base de RouterOS: opciones comunes que deben ser iguales en todos los dispositivos — zona horaria, NTP, DNS, parámetros de seguridad básicos.
• Monitoreo SNMPv3: configurar autenticación y cifrado en todos los routers de forma uniforme, sin tener que entrar a cada uno manualmente.
• Gestión de usuarios y claves SSH: añadir, eliminar o rotar credenciales en toda la flota desde un solo playbook.
• Validación previa al cambio: comprobar el estado del dispositivo antes de aplicar cualquier modificación administrativa. Si un router está marcado como problemático, el playbook lo detecta y lo excluye del ciclo.
• Backups automáticos: exportaciones de configuración y copias binarias cifradas, generadas automáticamente como parte del flujo de actualización.
• Actualización de RouterOS y firmware RouterBOARD: el paso más crítico, con la lógica de descarga centralizada descrita antes.

El backup automático merece un énfasis especial. Integrarlo dentro del propio proceso de actualización, no como tarea separada, elimina la tentación de saltárselo cuando hay prisa. Si una actualización falla o produce un comportamiento inesperado, tienes un punto de restauración limpio generado justo antes del cambio.

Desde el punto de vista de trazabilidad — relevante si necesitas demostrar qué cambió, cuándo y bajo qué credencial — el histórico de ejecuciones de Ansible junto con los backups cifrados da una cobertura razonable.

El problema real de la idempotencia en MikroTik

Aquí es donde hay que ser honesto: los módulos Ansible estándar para MikroTik tienen limitaciones. No todos son idempotentes de forma nativa, lo que significa que ejecutar el mismo playbook dos veces no siempre produce el mismo resultado sin efectos secundarios.

La comunidad técnica tiene opiniones divididas al respecto. Hay quien señala que el módulo community.routeros.api_find_and_modify sí es idempotente, junto con algunos otros comandos de la colección. Pero otros administradores con experiencia en entornos reales reportan que los módulos disponibles no siempre se comportan como se espera, especialmente en configuraciones más complejas.

¿Cómo se resuelve esto en la práctica?

• Lógica condicional en el playbook: antes de aplicar un cambio, verificar el estado actual. Si ya está configurado como se desea, saltar el paso. Más trabajo al escribir el playbook, pero resultado predecible.
• Usar la API REST de RouterOS directamente: para operaciones donde los módulos comunitarios se quedan cortos, hacer llamadas a la API da más control y resultados más consistentes.
• Separar playbooks de configuración de playbooks de actualización: los de configuración requieren más cuidado con la idempotencia; los de actualización tienen una lógica más lineal y controlable.

Una idea que circula en la comunidad es hacer un factory reset y reconstruir la configuración completa desde un archivo almacenado en flash. Teóricamente garantiza atomicidad total. En la práctica, el requisito de reinicio lo hace inviable para la mayoría de entornos productivos donde el downtime tiene coste real.

Ansible vs. scripts Bash: no es una guerra de egos

Hay una razón por la que los administradores que han trabajado con ambos enfoques prefieren Ansible para flotas de cierto tamaño, y no es solo estética de código.

Los scripts Bash para gestionar routers acumulan deuda técnica rápidamente. El problema más común es el manejo de la salida de comandos: RouterOS devuelve texto con un formato que cambia entre versiones, y parsear eso de forma robusta en Bash es frágil. Un cambio menor en la salida de un comando puede romper silenciosamente toda la lógica.

Ansible abstrae ese problema. La gestión de errores es consistente, el inventario de dispositivos es declarativo, y los playbooks se pueden probar, versionar y reutilizar entre proyectos. Quien ha visto un script Bash de quinientas líneas para gestionar RouterOS reconoce inmediatamente el valor de esto.

Dicho esto, Ansible tampoco es magia. Requiere conocer bien tanto la herramienta como RouterOS para escribir playbooks que realmente funcionen. El punto de partida más útil es estudiar proyectos reales extraídos de producción, adaptarlos al entorno propio y construir sobre esa base.

Escalar a flotas grandes: cuándo Ansible no es suficiente solo

Para flotas de decenas o pocos centenares de routers, Ansible bien configurado cubre perfectamente las necesidades. Pero hay un umbral — en el orden de miles de dispositivos — donde la arquitectura tiene que evolucionar.

En ese rango, la comunidad con más experiencia en escala habla de sistemas custom que incluyen:

• Una cola de prioridades que determina qué dispositivos se actualizan primero.
• Un sistema central de aprobación de actualizaciones — no todo lo que publica MikroTik va a producción automáticamente.
• Gestión de descargas con failover: si el servidor principal no está disponible, los routers buscan en una fuente alternativa.
• Límites de velocidad de actualización para evitar que miles de dispositivos reinicien simultáneamente.
• Ventanas de mantenimiento programables por zona geográfica o tipo de cliente.

Este nivel de complejidad no es necesario para la mayoría de empresas. Pero conocer que existe ayuda a tomar decisiones de arquitectura correctas desde el principio, antes de que la flota crezca y el sistema heredado se convierta en un problema.

Testing antes de tocar producción: GNS3 y EVE-NG

Uno de los riesgos más reales al automatizar cambios de red es aplicar una configuración incorrecta en producción sin haberla validado antes. La solución es tener un entorno de laboratorio virtual.

Tanto GNS3 como EVE-NG permiten virtualizar routers MikroTik con RouterOS real, crear una topología que refleje la de producción, y conectar ese entorno a través de NAT con el nodo de control de Ansible. El flujo de trabajo entonces es:

• Desarrollar y probar el playbook contra el laboratorio virtual.
• Verificar que el comportamiento es el esperado, incluyendo casos de error.
• Aplicar en producción con confianza — y con el backup automático como red de seguridad adicional.

Este paso se omite con frecuencia por falta de tiempo, y es el origen de la mayoría de incidentes evitables en cambios de red.

¿Y si no tienes experiencia DevOps en el equipo?

Ansible tiene una curva de aprendizaje real. Si el equipo técnico no tiene experiencia previa con la herramienta o con la gestión de infraestructura como código, empezar con playbooks complejos para RouterOS puede ser frustrante.

Para flotas de entre veinte y cien dispositivos, herramientas con interfaz gráfica orientadas específicamente a MikroTik ofrecen una alternativa válida: actualizaciones centralizadas con consciencia del estado de los puertos PoE, monitoreo de vulnerabilidades conocidas, y ejecución de comandos en lotes. No tienen la flexibilidad de Ansible, pero el umbral de entrada es mucho más bajo.

La decisión depende del perfil del equipo y del volumen de la flota. Lo que no es sostenible en ningún caso es seguir gestionando routers individualmente cuando ya tienes más de cinco o diez.

El ROI de automatizar tu flota MikroTik

Con una flota de entre diez y cincuenta routers, la diferencia entre actualizar manualmente y hacerlo con Ansible puede ser fácilmente de tres a cinco horas por ciclo. Si publicas actualizaciones de RouterOS con cierta regularidad — algo que en los últimos tiempos ha sido frecuente — eso se acumula rápido.

Más allá del tiempo, está el factor de consistencia: cuando el proceso es manual, cada administrador lo ejecuta de forma ligeramente diferente. Los backups a veces se hacen y a veces no. La versión instalada en cada router puede variar. Con Ansible, el proceso es idéntico en cada ejecución, auditable y documentado.

Si gestionas infraestructura de red para varias sedes o para clientes propios, vale la pena dedicar un tiempo a pensar cómo está estructurado ese proceso hoy — y si resistiría bien la pregunta de qué pasó exactamente la última vez que se tocó la configuración de un router concreto.