Redundancia de enlaces de internet en MikroTik

Un enlace de internet caído es, en la práctica, una operación detenida: se cae la facturación, el PBX VoIP, el CRM en la nube y el enlace hacia el datacenter. Para un ISP significa clientes reclamando y SLA comprometidos; para una empresa, sucursales aisladas y personas sin trabajar. La redundancia de enlaces MikroTik es la disciplina que convierte "se cayó el proveedor" en un evento invisible: el tráfico migra a un segundo carrier en segundos y nadie levanta el teléfono. En este artículo revisamos cómo se hace de verdad en RouterOS v7, con los mecanismos que trae el sistema y los errores clásicos que dejan el failover "configurado, pero sin funcionar".

Qué problema resuelve la redundancia de enlaces

El objetivo es simple de enunciar y difícil de ejecutar: que la caída de un uplink no interrumpa el servicio. Pero "caída" tiene muchas formas y ahí está la trampa. No es lo mismo que se apague el puerto Ethernet (link down, fácil de detectar) a que el proveedor siga entregando enlace físico pero sin salida a internet (el next-hop responde, pero más allá no hay ruta). Un diseño de redundancia serio tiene que cubrir los tres niveles:

• Falla de capa física: se cae el puerto, el SFP o el medio. RouterOS marca la interfaz como down y la ruta asociada se desactiva sola.
• Falla del gateway inmediato: el enlace está arriba pero el router del proveedor no responde. Aquí entra check-gateway.
• Falla "más allá" del gateway: el ISP te ve, pero perdió su tránsito. Este es el caso que más failovers mal armados dejan pasar, y se resuelve con rutas recursivas apuntando a un destino en internet.

Diseñar redundancia de enlaces en MikroTik es, sobre todo, elegir qué señal de falla vas a monitorear y en cuánto tiempo. Todo lo demás es sintaxis.

Failover con rutas y check-gateway

El mecanismo base del multi-WAN en RouterOS es la distancia administrativa de las rutas. Instalas dos rutas por defecto hacia el mismo destino 0.0.0.0/0, cada una con un gateway distinto y una distance diferente. RouterOS solo usa la ruta activa de menor distancia; si esa ruta se desactiva, la siguiente toma su lugar automáticamente.

Para que la ruta se desactive cuando el proveedor deja de responder (y no solo cuando se cae el puerto), se usa la propiedad check-gateway. En RouterOS v7 acepta los valores arp, ping y bfd (además de none): el router sondea periódicamente al gateway y, si deja de contestar, marca la ruta como inactiva y provoca el failover.

/ip route
add dst-address=0.0.0.0/0 gateway=192.0.2.1 distance=1 check-gateway=ping comment="WAN1-primario"
add dst-address=0.0.0.0/0 gateway=198.51.100.1 distance=2 check-gateway=ping comment="WAN2-respaldo"

Con esto, si 192.0.2.1 deja de responder al ping, la ruta de distancia 1 se desactiva y el tráfico sale por WAN2. Cuando el primario vuelve, RouterOS lo reactiva y el tráfico regresa solo (failback). El detalle fino: check-gateway solo verifica el gateway inmediato. Si tu proveedor mantiene vivo su router pero perdió el tránsito aguas arriba, el ping al gateway sigue contestando y el failover nunca se dispara. Para eso necesitas monitorear un destino real de internet.

Rutas recursivas: detectar la caída "más allá" del proveedor

La ruta recursiva resuelve exactamente ese punto ciego. En lugar de chequear al gateway del ISP, chequeas la alcanzabilidad de una IP pública estable (por ejemplo 8.8.8.8 o 1.1.1.1). Se instala una ruta hacia ese host con check-gateway a través del gateway del proveedor, y se limita su alcance con scope y target-scope para forzar la resolución recursiva:

/ip route
# Sonda: ¿tengo salida real a internet por WAN1?
add dst-address=8.8.8.8/32 gateway=192.0.2.1 scope=10 check-gateway=ping comment="sonda-WAN1"
# Default recursiva: se activa solo si la sonda 8.8.8.8 es alcanzable
add dst-address=0.0.0.0/0 gateway=8.8.8.8 target-scope=11 distance=1 comment="WAN1-recursiva"
# Respaldo directo por WAN2
add dst-address=0.0.0.0/0 gateway=198.51.100.1 distance=2 comment="WAN2-respaldo"

Ahora el failover no depende de que el proveedor apague su router: si 8.8.8.8 deja de ser alcanzable por WAN1 —aunque el gateway del ISP siga vivo— la ruta por defecto de distancia 1 pierde su next-hop, se desactiva y el tráfico pasa a WAN2. Esta es la diferencia entre un failover que se ve bien en el laboratorio y uno que aguanta la realidad de un tránsito degradado.

Redundancia de gateway en la LAN: VRRP

Todo lo anterior protege la salida a internet, pero deja un punto único de falla: el propio router. Si tienes dos equipos de borde y quieres que la LAN no note cuál está activo, el protocolo es VRRP (Virtual Router Redundancy Protocol). Dos o más routers comparten una IP virtual que los clientes usan como gateway; uno actúa como master según su priority y el resto queda en espera. Si el master falla, el backup asume la IP virtual y la MAC asociada sin que los hosts cambien su configuración.

VRRP se configura sobre la interfaz LAN y trabaja bien en conjunto con el failover de rutas: cada router de borde mantiene sus propios uplinks con check-gateway y rutas recursivas, y VRRP decide cuál de los dos equipos presenta el gateway a la red interna. Una advertencia de arquitectura para entornos con switches CRS: VRRP no es una función con offload por hardware (L3HW), así que planifica su ubicación pensando en que se procesa en CPU.

Balanceo de carga vs. redundancia: no son lo mismo

Es un error frecuente confundir ambos objetivos. Redundancia es usar un enlace y tener el otro listo para asumir. Balanceo es usar los dos enlaces a la vez para sumar capacidad. RouterOS permite las dos cosas, y muchas veces conviene combinarlas.

Escenario	Mecanismo en RouterOS	Qué buscas
Failover puro (activo/pasivo)	Rutas con distance + check-gateway	Continuidad ante caída de un carrier
Failover contra tránsito degradado	Rutas recursivas (sonda a IP pública)	Detectar caída "más allá" del gateway
Sumar ancho de banda entre carriers	PCC (Per Connection Classifier) en mangle	Repartir sesiones entre dos WAN
Redundancia del router de borde	VRRP en la LAN	Gateway sin punto único de falla
Agregar puertos hacia un mismo vecino	Bonding (802.3ad/LACP, balance-xor, active-backup)	Más caudal o respaldo a nivel de enlace L2

Si tu meta es aprovechar los dos enlaces en producción y no dejar uno ocioso, el camino es PCC, que reparte conexiones entre las WAN de forma consistente por sesión. Es un tema con suficiente profundidad propia —marcado de conexiones, rutas por tabla, NAT por salida— que tratamos aparte en nuestra guía de balanceo de carga. Un detalle importante de convivencia: PCC usa múltiples tablas de ruteo con reglas de mangle, y hay servicios que asumen la tabla main por defecto (por ejemplo el Hotspot), lo que obliga a ordenar bien el orden de evaluación de las reglas.

Bonding: redundancia a nivel de enlace, no de proveedor

Conviene aclarar dónde encaja bonding, porque suele mezclarse con el multi-WAN. El bonding agrupa varios puertos físicos hacia el mismo vecino (otro switch o router) en un solo enlace lógico, con failover automático entre miembros. Los modos 802.3ad (LACP), balance-xor y active-backup tienen offload por hardware en los switches con chip Marvell Prestera. Es excelente para el core y para troncales entre switches, pero no reemplaza al failover de WAN: bonding te da redundancia de cables hacia un mismo extremo, no de proveedores distintos. Para dos carriers independientes, el mecanismo correcto sigue siendo rutas con distancia o PCC.

Errores frecuentes al montar redundancia de enlaces MikroTik

La mayoría de los failover que "no funcionan cuando de verdad se caen" repiten los mismos patrones. Vale la pena revisarlos antes de dar por cerrada una implementación de redundancia de enlaces MikroTik:

• Confiar solo en check-gateway: detecta la caída del gateway inmediato, no la del tránsito del proveedor. Sin rutas recursivas, un ISP con salida degradada te deja "arriba" pero sin internet.
• NAT mal armado por interfaz: si el masquerade apunta a una WAN fija en vez de out-interface dinámica, el tráfico que migra al respaldo sale con IP de origen equivocada y se rompe.
• No probar la caída real: apagar el puerto en el escritorio no equivale a un tránsito caído. Hay que simular ambos: link down y pérdida de alcanzabilidad hacia una IP pública.
• Olvidar el DNS: si el resolver apunta a una IP del carrier primario, al caer ese enlace la resolución se cuelga aunque el ruteo ya migró. Usa resolvers públicos o del propio router.
• Failback agresivo: un primario que sube y baja hace oscilar el tráfico (flapping). Conviene amortiguar con temporizadores y monitoreo antes de devolver el tráfico automáticamente.

Cada uno de estos puntos es la diferencia entre una redundancia que figura en el diagrama y una que responde a las 3 de la mañana cuando el carrier principal se cae. Si estás operando enlaces PPPoE hacia el proveedor, además hay que cuidar cómo interactúa la reconexión del túnel con las rutas de respaldo, algo que vemos en profundidad en nuestro servicio de soporte.

Cómo lo abordamos en un proyecto real

En un diseño de misión crítica no basta con pegar los comandos: hay que definir qué se monitorea, con qué tiempos de convergencia, cómo convive el failover con el NAT y las tablas de ruteo, y cómo se prueba de forma controlada sin cortarle el servicio al cliente. Ese trabajo de arquitectura —dimensionar los enlaces, decidir entre failover puro y PCC, sumar VRRP donde el router de borde no puede ser punto único de falla, y dejar todo documentado— es exactamente lo que hacemos en un proyecto de consultoría de red.

En MikroTik Chile diseñamos, implementamos y operamos redundancia de enlaces para ISPs y empresas con infraestructura que no se puede caer. Si estás armando un multi-WAN, no estás seguro de que tu failover aguante una caída real, o quieres pasar de "configurado" a "probado y documentado", conversemos tu caso. De ingeniero a ingeniero, revisamos tu topología y te decimos qué mejorar.