Failover Dual-WAN MikroTik para ISPs

Resumen El failover dual-WAN de MikroTik mantiene un sitio en línea moviendo automáticamente el tráfico a un enlace de respaldo cuando el enlace primario falla. RouterOS te da tres bloques de construcción — routing recursivo con check-gateway, Netwatch y NAT por WAN — y la combinación correcta depende de cuán rápida y cuán inteligente debe ser tu detección. Para flotas de ISP, el problema más difícil no es el fragmento de configuración, sino confirmar, en cientos de sitios remotos detrás de CGNAT, que el failover realmente funcionó. Esta guía cubre ambos.

¿Qué Es el Failover Dual-WAN de MikroTik?

El failover dual-WAN de MikroTik es una configuración de RouterOS que da a un router dos enlaces de internet — uno primario y uno de respaldo — y desplaza automáticamente el tráfico al respaldo cuando el primario deja de pasar paquetes, y luego lo devuelve cuando se recupera. No es lo mismo que el balanceo de carga: el failover mantiene un enlace inactivo como seguro, mientras que el balanceo reparte el tráfico entre ambos. El objetivo es la continuidad, no el ancho de banda extra, y por eso es el patrón de redundancia por defecto para sitios que simplemente no pueden quedarse a oscuras.

El mecanismo se apoya en la selección de rutas. RouterOS elige la ruta por defecto activa por la menor distancia administrativa, así que das al primario una distancia menor y al respaldo una mayor. Todo el diseño se reduce entonces a una pregunta: ¿cómo decide el router que el primario está “caído” y degrada su ruta? Acierta esa decisión — lo bastante rápida, pero sin nerviosismo — y el failover será fiable. Fállala y harás la conmutación demasiado lenta o oscilarás entre enlaces con cada paquete perdido.

Paso 1 — Mapea las dos WAN antes de tocar una ruta

Empieza por anotar qué es realmente cada enlace. Un primario de fibra fija o PPPoE con un gateway estático o asignado por PPP se comporta de forma diferente a un respaldo Starlink o LTE que está detrás de Carrier-Grade NAT y te entrega una dirección dinámica. Esto importa porque el routing recursivo solo funciona con gateways de IP estables, no con tipos de interfaz dinámicos como PPPoE o DHCP donde la dirección puede cambiar (Documentación de MikroTik — Failover (WAN Backup)). Decide qué enlace es primario, cuál es de respaldo y si alguno cambia su IP al reconectarse — ese único hecho dicta qué método de detección puedes usar.

Paso 2 — Añade rutas por defecto recursivas con check-gateway

El enfoque clásico usa routing recursivo: en lugar de apuntar la ruta por defecto directamente a un siguiente salto, la apuntas a un objetivo de sondeo (por ejemplo, un resolvedor público conocido) y añades una ruta estática que le dice a RouterOS que alcance ese objetivo solo a través de un gateway WAN específico. Luego creas dos rutas por defecto resueltas recursivamente sobre esos objetivos — la primaria con una distancia menor y check-gateway=ping habilitado, y la de respaldo con una distancia mayor (Scoop — Basic ISP Failover with MikroTik).

El comportamiento que hay que planificar es el tiempo. Check-gateway desactiva una ruta tras dos comprobaciones fallidas consecutivas, y las comprobaciones se ejecutan aproximadamente cada 10 segundos, así que la conmutación real ronda los 20 a 30 segundos — y no reacciona a la pérdida intermitente de paquetes, solo a un gateway totalmente muerto (Documentación de MikroTik — Failover (WAN Backup)). Para muchos sitios de clientes de ISP eso es aceptable. Para terminales de voz o de pago a menudo no lo es, y ahí es donde entra el Paso 4.

Paso 3 — Configura el NAT para ambos enlaces

Un router dual-WAN necesita una regla de masquerade (o src-nat) separada por interfaz WAN para que el enlace que esté activo traduzca correctamente el tráfico saliente; una única regla ligada a una interfaz romperá silenciosamente la conectividad en el momento en que el failover mueva el tráfico al otro enlace. Añade una regla de masquerade en la cadena srcnat para la out-interface primaria y una segunda para el respaldo. Si publicas algún servicio entrante, recuerda que las reglas dst-nat ligadas a la dirección del primario dejan de funcionar cuando ese enlace — y su IP pública — desaparece. Esa fragilidad de entrada es la misma trampa arquitectónica que cubre nuestro caso de cambios de IP en Starlink, y por eso el acceso anclado en la salida escala mejor que el reenvío de puertos. Para los fundamentos de NAT, consulta nuestra guía para configurar NAT en MikroTik.

Paso 4 — Usa Netwatch cuando necesites una detección más rápida o más inteligente

Cuando 20–30 segundos es demasiado lento o necesitas actuar sobre enlaces degradados-pero-vivos, Netwatch es la herramienta más flexible. En RouterOS v7, Netwatch ganó un parámetro type que puede sondear con icmp, tcp-conn, http-get, https-get o simple, y puedes fijar tu propio intervalo de comprobación en lugar de vivir con la cadencia fija de check-gateway (Documentación de MikroTik — Failover (WAN Backup)). Cada host tiene un script up y uno down, así que puedes deshabilitar la ruta por defecto primaria, lanzar una alerta o registrar el evento en la transición.

Muchos operadores combinan ambos: el routing recursivo se ocupa de la muerte limpia del enlace, mientras que Netwatch cubre los casos más enredados y envía notificaciones. Un largo hilo de la comunidad debate exactamente este compromiso y vale la pena leerlo antes de estandarizar un método en toda una flota (Foro de MikroTik — netwatch instead of recursive routing). Elijas lo que elijas, mantén la configuración idéntica en cada sitio — una flota de scripts de failover a medida es por sí misma una caída esperando a ocurrir.

Paso 5 — Verifica el failover en cada sitio remoto

Aquí está la parte que los tutoriales de configuración se saltan. Añadir las rutas en un router de banco es fácil; probar que el failover funciona en cientos de CPEs desplegados es el verdadero problema del ISP — y se vuelve más difícil cuando el enlace de respaldo es Starlink o LTE detrás de CGNAT, porque el dispositivo a menudo no tiene una IP pública accesible para gestionarlo después de conmutar. Si solo puedes confirmar el failover esperando a que llame un cliente, en realidad no tienes failover; tienes un script que esperas que se ejecute.

Aquí es donde la gestión centralizada cambia la economía. MKController mantiene cada router accesible a través de un túnel saliente autenticado, así que puedes confirmar que la ruta de respaldo está transportando tráfico, observar la transición de failover en la monitorización y enviar una configuración corregida — sin depender de una IP pública que puede no existir en el enlace de respaldo. Combina eso con telemetría: nuestras guías sobre monitorizar MikroTik de forma remota con Zabbix y monitorización SNMP para MikroTik muestran cómo alertar sobre el propio evento de failover, para que un cambio silencioso al costoso enlace de respaldo nunca pase desapercibido.

Consejos

• Mantén la sonda check-gateway del enlace de respaldo apuntando a un objetivo que alcances a través de ese enlace, no del primario, o tu prueba carecerá de sentido.
• Etiqueta las transiciones de failover en tu monitorización para que un sitio que lleve días funcionando con su enlace de respaldo genere un ticket — un failover que nadie nota es un coste recurrente, no un salvamento.
• Prueba el cable real, no solo la ruta: desconecta el conector del primario y cronometra la conmutación real.

Lleva el failover a un único plano de control

El failover dual-WAN en un solo MikroTik es un problema resuelto. Hacerlo de forma fiable en toda una flota — con configuración consistente y la capacidad de probar que el respaldo funciona en un router al que no puedes llegar por IP pública — es donde la mayoría de los operadores pierde dinero. La gestión centralizada, anclada en la salida, cierra esa brecha.

Comienza tu prueba gratuita de MKController