Internet redundante para empresas: primario + backup que sí funciona
Cómo armar redundancia real de internet en una PYME: dual WAN, failover automático, BGP, SD-WAN y los errores más comunes al implementarlo.
Internet redundante para empresas: primario + backup que sí funciona
“Tenemos dos internet” no significa nada por sí solo. Si el segundo enlace está enchufado pero nadie lo configuró para tomar el control cuando se cae el primero, no hay redundancia: hay un cable extra. Este post explica cómo se arma redundancia de internet que efectivamente funciona cuando hace falta.
Por qué no alcanza con “un internet bueno”
La disponibilidad típica de un servicio empresarial razonable es 99.5% a 99.9%. Eso son entre 8 y 44 horas anuales de caída. Para una operación que factura 24/7 —e-commerce, soporte, central VoIP— esas horas son caras.
Wikipedia define alta disponibilidad (High Availability) como “una característica de un sistema que apunta a asegurar un nivel de performance operacional acordado, usualmente uptime, por un período mayor al normal” (fuente). Se logra eliminando puntos únicos de falla (SPOF), no comprando un servicio “más confiable”.
Niveles de redundancia
Nivel 0 — Un solo enlace
El más común. Todo en un solo proveedor, un solo medio. Si se rompe la fibra en la cuadra, se cae la operación. Es lo más barato y lo más frágil.
Nivel 1 — Dual WAN, mismo proveedor
Dos enlaces del mismo carrier (típicamente fibra + 4G/5G del mismo). Soluciona fallas locales (corte de cable, problema de equipamiento del cliente) pero no protege contra fallas de backbone del proveedor. Si se cae el carrier, se caen ambos enlaces.
Nivel 2 — Dual WAN, dos carriers diferentes
Dos enlaces de proveedores distintos, idealmente con medios físicos distintos (uno fibra, otro radio o fibra de otro tendido). Esta es la redundancia mínima seria para una PYME que depende del servicio.
Nivel 3 — Multi-WAN con BGP
La empresa tiene su propio AS (Autonomous System) y bloque IP (mínimo /24 para anunciar globalmente). Con BGP anuncia su prefijo a varios proveedores y, ante caída de uno, el tráfico fluye por otro conservando las IPs públicas (Wikipedia BGP). Caro y técnicamente exigente; reservado a operaciones grandes o con requisitos específicos (e.g., servidores expuestos con DNS apuntando a IP fija).
Failover: lo que separa la teoría de la práctica
Tener dos enlaces no sirve si el equipo no detecta cuándo conmutar. El failover puede ser:
Manual
Alguien levanta el teléfono, se da cuenta que se cayó internet, y va al rack a desconectar un cable. Es lo que pasa en la mayoría de las “redundancias” que veo en relevamientos. No cuenta como redundancia.
Automático por estado de interfaz
El router conmuta cuando el link físico se cae. Sirve si el problema es el cable o el equipo del cliente. No detecta cuando el enlace está “up” pero el carrier no rutea (problema upstream).
Automático con health-check
El router envía pings o consultas DNS a destinos confiables (8.8.8.8, 1.1.1.1, hosts del cliente). Si fallan, conmuta. Es el estándar mínimo serio. MikroTik lo implementa con netwatch y rutas con check-gateway=ping (RouterOS docs).
Automático con SD-WAN
SD-WAN (Software-Defined WAN) según Cisco “aplica los principios de las redes definidas por software al ámbito WAN, abstrayendo la red subyacente y centralizando la política” (fuente). Mide latencia, jitter y packet loss en tiempo real, y rutea cada flujo por el mejor enlace disponible —no solo conmuta, balancea por aplicación.
Topologías típicas
Activo-pasivo
Un enlace primario maneja todo el tráfico; el secundario solo se usa cuando el primario falla. Simple, predecible, fácil de troubleshootear. Es lo recomendable para la mayoría de PYMEs.
Activo-activo
Ambos enlaces transportan tráfico simultáneamente. Aprovecha capacidad agregada, pero requiere balanceo cuidadoso porque las conexiones TCP no pueden cambiar de IP a mitad de sesión sin SD-WAN o BGP. MikroTik documenta el método PCC (Per-Connection Classifier) para hacer balanceo persistente por flujo (MikroTik docs).
Hot-standby con NHRP / VRRP
Dos routers (no solo dos enlaces): uno activo, uno en espera. Si el primero muere por hardware, el segundo toma su rol. Para sucursales críticas que necesitan tolerancia ante falla del propio CPE.
Errores comunes
”Compré un router con dos puertos WAN, ya tengo redundancia”
No. El router tiene la capacidad de hacer redundancia, pero hay que configurarla. Sin reglas de mangle, marca de rutas, recursive routing y health-check, los dos puertos no se usan.
”Tengo fibra y 4G del mismo proveedor”
Es algo, pero compartís backbone. Un problema de ruteo upstream del carrier te deja sin servicio en ambos. Mejor: dos carriers distintos.
”El backup nunca se probó”
Frecuentísimo. Hay backup, está configurado, pero nunca se simuló una caída controlada. El día que pasa de verdad, descubrimos que el firewall del carrier secundario bloquea VPN, o que la IP fija del backup nunca se cargó en la lista blanca del banco.
Regla: probar el failover trimestralmente, en horario de baja actividad, midiendo el tiempo real de conmutación.
”El secundario es el peor servicio que conseguimos”
Si el primario se cae, el negocio queda corriendo sobre el secundario. Si el secundario es 4G compartido CGNAT, eso significa que durante la caída se cae también la VPN, el ERP en la nube, las cámaras y la VoIP. El backup tiene que estar dimensionado para sostener el negocio, no solo para que “haya internet”.
”No documentamos las IPs”
Cuando el backup toma servicio, todo el tráfico saliente sale por una IP pública distinta. Si el ERP, el banco o un proveedor externo tiene whitelist por IP, hay que cargarles también la IP del enlace secundario. Y mantenerla actualizada.
Configuración mínima viable (PYME)
Recomendación honesta para una PYME de 20 a 100 empleados:
- Dos enlaces de carriers distintos, idealmente medios distintos (fibra + radio, o dos fibras de tendidos diferentes).
- Router con dual WAN y health-check (MikroTik CCR/RB, FortiGate, pfSense/OPNsense, Ubiquiti).
- Failover activo-pasivo automatizado, con netwatch o equivalente apuntando a destinos confiables.
- VPN site-to-site redundante (si hay sucursales), con peers configurados sobre ambas IPs públicas.
- Documentación: IPs públicas de ambos enlaces, contactos de los dos NOCs, procedimiento de reclamo escrito.
- Pruebas trimestrales de failover con métrica del tiempo de conmutación.
Cuándo justifica BGP
BGP propio justifica cuando:
- La empresa hostea servicios con DNS que apuntan a IP fija propia (mail, web, ERP).
- Tiene tres o más enlaces de proveedores distintos.
- Opera multi-sitio con tráfico simétrico significativo entre sedes y carriers.
- Hay un equipo de IT con conocimiento de routing dinámico (o un partner con guardia 24/7).
Para todo lo demás, dual WAN bien configurado alcanza.
Conclusión
Redundancia no es comprar dos cosas: es diseñar para que la operación siga funcionando cuando una de ellas falla, y probarlo. Un dual WAN bien armado es accesible para una PYME. SD-WAN o BGP son pasos siguientes que dependen del tamaño y la criticidad del negocio. Lo que no tiene sentido es decir “tenemos backup” sin haberlo probado.
Fuentes y referencias
- MikroTik RouterOS docs
- Cisco — What is SD-WAN?
- Wikipedia — High availability
- Wikipedia — Border Gateway Protocol
Fuentes
Posts relacionados
Cómo medir si tu internet anda mal: latencia, jitter y MTR
Migración de ADSL a FTTH: qué cambia y qué hay que tener en cuenta
