Tres Starlink en un router, pero internet intermitente: no es la antena, es tu diseño

Cuando cae la fibra, o simplemente no hay fibra, todos corren a comprar antenas Starlink. Pocos entienden por qué, al conectar dos o más antenas en un mismo router, la red entera se cae. Este es el patrón que separa a los que improvisan de los que saben configurar un balanceo de carga adecuado.

Deja que adivine cómo llegaste hasta aquí.

No fibra en la zona. Alguien consiguió no una, sino tres antenas Starlink y te las puso en la mesa con una sola instrucción: "únelas en el MikroTik y que balancee".

Las conectaste. Configuraste tres clientes DHCP. Le diste check-gateway a cada una. Y en lugar de tener el triple de internet… tuviste cero. O peor: tuviste un balanceo fantasma que se cae solo, corta las sesiones de banca y nunca conmuta cuando una antena muere.

Aquí viene la parte incómoda: no fallaron los equipos. Falló el diseño.

La mayoría de las caídas de multi-WAN que veo en campo no son de hardware. Son de arquitectura. Y una vez que ves el patrón correcto, no lo vas a poder dejar de ver.

Vamos a eso.

El problema de raíz que casi nadie nombra

Tres antenas Starlink distintas. ¿Sabes qué tienen en común?

Entregan exactamente la misma red. Cada una entrega 192.168.1.0/24 y gateway 192.168.1.1. Y no siempre lo puedes cambiar.

Piénsalo un segundo. Le estás pidiendo a RouterOS que enrute hacia tres salidas… que se llaman igual, viven en la misma subred y comparten el mismo next-hop.

Cuando armas eso sin diseño, siempre pasa lo mismo:

• Rutas en conflicto. Tres conectadas a 192.168.1.0/24 se solapan en la tabla de enrutamiento main.
• Next-hop ambiguo. RouterOS no sabe por qué interfaz salir hacia 192.168.1.1.
• check-gateway o script inútil. Le haces ping a la antena, que responde aunque el satélite esté caído.
• Failover decorativo. La ruta primaria nunca se marca inactiva, así que nunca conmuta.
• Reparto inestable. Las sesiones saltan de IP pública y rompen banca, portales y cualquier cosa que valide sesión.
• Caída total. Un error de diseño y las tres WAN quedan inservibles al mismo tiempo.

Ese es el villano. No es Starlink. Es la tabla de enrutamiento colapsando porque le pediste que decidiera lo indecidible.

Y aquí está otro detalle que casi todo el mundo se salta:

La antena en si, no es internet vivo

Si tu detección de caída es ping = 192.168.1.1, ya perdiste. La antena responde al ping aunque el enlace satelital esté muerto o cortado por mora. La ruta primaria nunca se desactiva → el failover jamás se dispara.

La única forma de saber si tienes internet de verdad es sondear una IP pública real -y confiable- que obligue al tráfico a cruzar el satélite:

ping → 4.2.2.1 / 4.2.2.2 / 4.2.2.3

Si el uplink cae, la sonda deja de responder y la ruta se marca inactiva. Eso es failover real. Todo lo demás es teatro.

Guarda esa idea. Es el hilo del que cuelga todo el diseño.

Modo router o modo bypass: la decisión que define el patrón

Antes de tocar una sola regla, define en qué modo operan tus Starlink. De aquí sale si usas recursividad tradicional o VRF.

Regla simple: si las tres antenas entregan la misma red y el mismo gateway, tu herramienta es VRF. Si cada enlace trae su propia subred, la VRF sobra y el diseño se simplifica (más sobre esto al final).

Pieza 1 — Balanceo con PCC: lo que reparte y lo que NO

El Per-Connection Classifier (PCC) es la pieza que reparte carga. Y aquí es donde tengo que ser honesto contigo, porque el 90% de los problemas de expectativa nacen de no entender esto:

PCC balancea conexiones, no ancho de banda.

Toma un atributo de cada conexión nueva (IP y/0 puerto de origen/destino), lo mete en una función hash, saca un resto y pega esa conexión a una WAN. Todo el flujo viaja por la misma salida → las sesiones no se rompen.

• SÍ se reparte: el número total de conexiones se divide entre las WAN disponibles.
• NO se suma: los anchos de banda no se agregan. Una sola descarga o video de Netflix nunca supera la velocidad de un enlace.

Ejemplo sin anestesia: 3 enlaces de 100 Mbps no le dan 300 Mbps a una descarga. Pero 30 usuarios se reparten ~10 Mbps por enlace, y si una antena cae, las otras sostienen el servicio.

Si alguien te promete que tres antenas = el triple para un solo flujo, está vendiéndote humo. Lo que sí te da PCC es capacidad agregada con tráfico concurrente + redundancia. Eso es oro en una contingencia. Pero se llama por su nombre.

La decisión clave del PCC: estabilidad o granularidad

per-connection-classifier=both-addresses:3/0     # estabilidad
per-connection-classifier=both-addresses-and-ports:3/0   # granularidad

• both-addresses → reparte por par origen–destino. Cada host-destino queda en una sola WAN. Banca, portales y sesiones no se cortan. Recomendado para Starlink + CGNAT.
• both-addresses-and-ports → reparto más uniforme, pero una misma app puede saltar de IP pública. Prioriza reparto sobre estabilidad.

Con Starlink detrás de CGNAT, elige both-addresses. Siempre.

Pieza 2 — Aislamiento con VRF: cómo hacer que la misma red exista tres veces

Aquí está el truco que resuelve el problema de raíz.

Una VRF (Virtual Routing and Forwarding) crea varios "routers lógicos" dentro del mismo MikroTik, cada uno con su propia tabla de ruteo (FIB) aislada. Lo que rutea una no afecta a las otras.

vrf-SL1 → 192.168.1.0/24 @ ether1
vrf-SL2 → 192.168.1.0/24 @ ether2
vrf-SL3 → 192.168.1.0/24 @ ether3

La misma red vive tres veces sin colisionar, porque cada VRF la considera "suya". El gateway 192.168.1.1 se desambigua dentro de su VRF, y de golpe check-gateway recupera sentido: dentro de cada VRF, el ping sale por un solo puerto.

Un equipo. Muchos routers. Cero hardware extra.

Pieza 3 — Failover real: detectar la caída del satélite, no de la antena

No hay un método único. La topología decide:

• Recursividad → cuando cada enlace tiene red y gateway distintos (multi-WAN clásico). La default se apoya en una sonda /32 y conmuta sola. Estándar y documentadísimo.
• Netwatch + marcas → cuando hay VRF y subredes idénticas (nuestro caso Multi-Starlink con la misma LAN). La VRF aísla las subredes, pero rompe la recursividad clásica → te apoyas en Netwatch y marcas de ruta.

Netwatch trae su propio motor de sondeo. El mecanismo:

1. Netwatch sondea 4.2.2.1/2/3 cada pocos segundos, con motor propio.
2. La /32 es permanente. La sonda sale por su ruta /32, que nunca se apaga. El sondeo sobrevive al failover.
3. Down/Up script. Al caer, apaga las defaults de esa WAN. Al volver, las reactiva.

La jugada fina: la /32 de sonda es más específica que la default. El failover apaga solo la 0.0.0.0/0 — la /32 sigue viva, así que Netwatch nunca pierde la capacidad de medir. Funciona incluso con dos WAN caídas.

Pieza 4 — Las dos cosas que casi todos olvidan

Puedes tener PCC, VRF y failover perfectos… y que el router se quede mudo. Faltan dos piezas:

NAT por salida. Una regla de masquerade por cada enlace, para que el tráfico salga con la IP correcta de cada antena:

/ip firewall nat add chain=srcnat action=masquerade out-interface=ether1

El tráfico del propio router. DNS, NTP, updates y —sobre todo— las sondas de Netwatch. El tráfico originado por el router usa main, que por defecto no tiene salida. Por eso las sondas necesitan reglas de mangle en la cadena output con sus marcas de ruta. Sin esto, Netwatch no puede monitorear IPs públicas y todo el failover se desmorona.

El patrón completo, de punta a punta

Tres Starlink → VRF por enlace → PCC en main → failover recursivo/Netwatch → NAT por salida.

Aquí está la configuración real. Cuatro bloques. Este es el mapa que la mayoría paga semanas de prueba y error por descubrir.

1 · Base: VRF, tablas y enlaces

rsc

# Una VRF por cada Starlink (aísla la subred idéntica)
/ip vrf add name=vrf-SL1 interfaces=ether1
/ip vrf add name=vrf-SL2 interfaces=ether2
/ip vrf add name=vrf-SL3 interfaces=ether3

# Una routing-table (FIB) por WAN
/routing table add fib name=rtab-SL1
/routing table add fib name=rtab-SL2
/routing table add fib name=rtab-SL3

# IP fija por WAN (misma IP en las 3, aisladas por VRF) + LAN
/ip address add address=192.168.1.2/24 interface=ether1
/ip address add address=192.168.1.2/24 interface=ether2
/ip address add address=192.168.1.2/24 interface=ether3
/ip address add address=10.10.0.1/24 interface=ether4

2 · Mangle: PCC y sondeo del Core

rsc

# El Core sondea cada IP pública por su WAN (salida marcada)
/ip firewall mangle add chain=output protocol=icmp \
    dst-address=4.2.2.1 action=mark-routing new-routing-mark=rtab-SL1
    # … idem 4.2.2.2 -> rtab-SL2  y  4.2.2.3 -> rtab-SL3

# No balancear el tráfico hacia la LAN
/ip firewall mangle add chain=prerouting action=accept \
    in-interface=ether4 dst-address=10.10.0.0/24

# PCC: reparte las conexiones nuevas del cliente en 3
/ip firewall mangle add chain=prerouting in-interface=ether4 \
    action=mark-connection new-connection-mark=SL1_conn \
    per-connection-classifier=both-addresses:3/0
    # … 3/1 -> SL2_conn  y  3/2 -> SL3_conn

# Cada conexión marcada va a su tabla
/ip firewall mangle add chain=prerouting connection-mark=SL1_conn \
    action=mark-routing new-routing-mark=rtab-SL1 passthrough=no

3 · Rutas: cascada, sondas y NAT

rsc

# Sintaxis de gateway sobre VRF:  IP % interface @ vrf
/ip route add dst-address=0.0.0.0/0 routing-table=rtab-SL1 \
    gateway=192.168.1.1%ether1@vrf-SL1 distance=1

# Cascada de 3 niveles por tabla (sobrevive a doble caída)
#   rtab-SL1: SL1(d1) -> SL2(d2) -> SL3(d3)   … idem SL2, SL3, main

# Sonda /32 permanente: NUNCA se apaga, mantiene el sondeo vivo
/ip route add dst-address=4.2.2.1/32 routing-table=rtab-SL1 \
    gateway=192.168.1.1%ether1@vrf-SL1 scope=10

# Retorno a la LAN en cada tabla
/ip route add dst-address=10.10.0.0/24 gateway=ether4 routing-table=rtab-SL1

# NAT por interfaz (out-interface-list NO matchea sobre VRF)
/ip firewall nat add chain=srcnat action=masquerade out-interface=ether1
    # … idem ether2 y ether3

4 · Failover con Netwatch

rsc

# Netwatch monitorea la sonda de cada WAN con su motor propio.
# down-script: apaga TODAS las defaults de esa WAN (foreach por
#   gateway de destino). El filtro 0.0.0.0/0 NO toca las /32 de
#   sonda -> el sondeo nunca muere.

/tool netwatch add host=4.2.2.1 interval=10s timeout=1s \
  down-script={
    :foreach r in=[/ip route find where \
        gateway~"ether1" dst-address="0.0.0.0/0"] do={
      /ip route set $r disabled=yes }
    :log warning "SL1 SIN INTERNET" } \
  up-script={
    :foreach r in=[/ip route find where \
        gateway~"ether1" dst-address="0.0.0.0/0"] do={
      /ip route set $r disabled=no }
    :log info "SL1 OK" }

# Repetir para 4.2.2.2 (ether2) y 4.2.2.3 (ether3)

La variante: ¿y si cada enlace trae su propia red?

El caso Multi-Starlink es especial precisamente porque las tres WAN comparten red y gateway. El multi-WAN clásico es distinto: cada ISP entrega su propia subred y gateway. Ahí la VRF sobra y el diseño se simplifica.

Config de la variante (sin VRF):

rsc

# Cada WAN con su propia red/gateway (ejemplo)
/ip address add address=192.168.10.2/24 interface=ether1  # GW .1
    # … 192.168.20.2 (ether2)  y  192.168.30.2 (ether3)

# Tablas por WAN (sin vrf) + FastTrack OFF (rompe el marcado)
/routing table add fib name=rtab-SL1   # … SL2, SL3
/ip firewall filter disable [find action=fasttrack-connection]

# Redes locales que NO deben balancearse (LAN + WANs)
/ip firewall address-list add list=local address=10.10.0.0/24
    # … agregar 192.168.10/20/30.0/24 a la lista 'local'

# Saltar destinos locales ANTES del PCC (retorno LAN/VPN)
/ip firewall mangle add chain=prerouting action=accept \
    in-interface=ether4 dst-address-list=local

# PCC: solo tráfico NO-local (dst-address-type=!local)
/ip firewall mangle add chain=prerouting in-interface=ether4 \
    action=mark-connection new-connection-mark=SL1_conn \
    dst-address-type=!local per-connection-classifier=both-addresses:3/0
    # … 3/1->SL2_conn, 3/2->SL3_conn, luego mark-routing a cada tabla

# NAT por lista (sin VRF, la lista SÍ matchea)
/ip firewall nat add chain=srcnat action=masquerade out-interface-list=WAN

Lo que vemos fallar en campo (casi todo sale de esta lista)

• Sondear la antena (192.168.1.1): el failover nunca conmuta.
• No usar % y @: hay que especificar interfaz y VRF en el gateway.
• Olvidar la LAN: las tablas marcadas no heredan la conectada de main. Repite la ruta a tu red en cada tabla.
• Sin salida del router: el router no tiene salida verificable a internet (falta la cadena output).
• Sin NAT por WAN: falta el masquerade en algún enlace.
• Marcar conexiones locales: el tráfico LAN/VPN no debe pasar por las reglas de PCC.

Seis errores. Si evitas estos seis, ya estás por delante de la mayoría.

Seis hábitos para un multi-WAN que aguanta en producción (no solo en la demo)

1. Sondas públicas — una IP pública real y distinta por enlace.
2. both-addresses — prioriza estabilidad de sesión con CGNAT.
3. Repite la LAN — ruta a tu red en cada tabla marcada.
4. Distancias claras — orden de preferencia explícito en main.
5. Documenta las marcas — comentarios por regla y por tabla.
6. Prueba — simula la caída con un drop a la sonda.

Balanceo ≠ bonding (y por qué decírtelo es un acto de respeto)

Ya que estamos siendo honestos, cerremos la expectativa de una vez:

PCC te da capacidad concurrente y redundancia. El bonding real —donde un solo flujo suma varios enlaces— exige controlar los dos extremos del enlace, y con Starlink + CGNAT eso no está sobre la mesa. Quien te diga lo contrario, no ha diseñado esto en producción.

Las tres decisiones que separan un multi-WAN que aguanta

Si te llevas solo tres cosas de todo esto, que sean estas:

01 · Aísla con VRF. Las redes idénticas conviven en tablas separadas. Sin esto, la tabla principal colapsa. Señal de mal diseño: "que balancee y ya".

02 · Sondea internet. Ping contra IP pública real, no contra la antena. Ahí vive el failover de verdad. Señal de mal diseño: "la antena responde, está bien".

03 · Sé honesto con el ancho. PCC agrega capacidad y da redundancia; no suma la velocidad de un solo flujo. Señal de mal diseño: "tres antenas = el triple".

De entenderlo a dominarlo

Esto fue el mapa. El terreno se camina con laboratorio: recrea el esquema con equipos físicos o virtuales, rompe cosas a propósito y observa cómo se recupera. Cuando lo hayas roto tres veces y lo hayas visto volver solo, va a ser tuyo.

Y si prefieres saltarte las semanas de prueba y error: una conversación técnica de 30 minutos suele ahorrar más tiempo del que crees. Revisamos tu esquema multi-WAN actual, señalamos los tres puntos críticos y salimos con un plan concreto de PCC + VRF + failover.

Video en Youtube

Luis Aguilar · CTO Ekoinos · Instructor certificado MikroTik 📱 WhatsApp: +58 412-356-4673 · ✉️ luis.aguilar@ekoinos.com

¿Te sirvió? Compártela con el colega que anda peleándose con tres antenas en este momento. Los próximos cursos están en la bio de nuestro instagram @ekoinos.