Escenario de referenciaResultado esperado
Continuidad con múltiples conexiones
Una red con dos proveedores, caídas intermitentes y servicios sensibles que no toleran perder la sesión.
- Categoría
- Continuidad y balanceo
- Audiencia
- Empresas
- Actualizado
- Publicado
- MikroTik RouterOS
- Doble WAN
- Failover
- Balanceo
Aviso de transparencia. Este es un escenario de referencia y no representa un cliente ni una implementación ejecutada.
Contexto
Un escenario de referencia habitual: un negocio o una red pequeña con dos proveedores de Internet que sufre cortes intermitentes y que además maneja servicios sensibles, como banca en línea o videollamadas, que se rompen si la sesión cambia de enlace.
Situación inicial
Tener dos enlaces daba una sensación de redundancia que no siempre se cumplía: sin un diseño y pruebas, la caída de un proveedor podía dejar el servicio a medias o cortar las sesiones que exigen persistencia.
Riesgos
- Rutas mal priorizadas que envían el tráfico por donde no debe
- Sesiones bancarias o de pago que se cortan al saltar de enlace
- DNS inconsistente entre proveedores
- NAT que no contempla el segundo enlace
- Falsa sensación de redundancia sin pruebas reales
Enfoque
- Diagnóstico de cómo entrega la conexión cada proveedor
- Priorización del enlace principal y del respaldo
- Failover con detección de caída
- Balanceo cuando el escenario lo justifica
- Excepciones para servicios que necesitan persistencia
- Pruebas de caída y recuperación, con plan de reversión
Pasos de implementación o análisis
- Se analizaría el comportamiento de cada proveedor
- Se definiría la prioridad y la detección de caída
- Se protegerían las sesiones sensibles con excepciones
- Se probaría la caída de cada enlace antes de dar por buena la continuidad
Validación
- Se simularía la caída del enlace principal y del respaldo
- Se comprobaría que los servicios sensibles mantienen su ruta
- Se verificaría la recuperación al volver el enlace principal
Resultados
Resultado esperadoResultado esperado
- Se busca que la caída de un proveedor no deje la red sin salida
- El resultado esperado es que las sesiones sensibles no se corten al conmutar, sujeto a validación
- Un diseño bien probado podría dar continuidad real en lugar de una redundancia solo aparente
Limitaciones
- Es un escenario de referencia, no una implementación ejecutada en un cliente
- El comportamiento real depende de cómo entrega la IP cada proveedor
- Sumar dos enlaces no equivale a sumar su velocidad en una sola descarga
Lecciones
- La redundancia sin pruebas es una suposición, no una garantía
- Las sesiones sensibles deben planificarse desde el diseño
- Documentar qué enlace usa cada servicio evita sorpresas
Servicios relacionados
Preconfiguraciones relacionadas
Balanceo de dos WAN con failover Dos conexiones Starlink balanceadas
¿Quieres evaluar tu propio caso?
Empieza por un diagnóstico: revisamos tu topología, proveedores y prioridades antes de proponer un enfoque.