La prueba que nunca debe estrenarse durante una venta
Un router celular o una segunda conexión puede estar encendido durante meses sin que nadie confirme cómo se comporta cuando falla el internet principal. La luz verde ayuda, pero no responde cuánto tarda el cambio, qué aplicaciones vuelven solas ni si el equipo regresa correctamente a la conexión normal.
La prueba útil es corta y controlada. Se hace fuera de horas pico, con tres tareas esenciales, una forma clara de revertir el cambio y una bitácora que otra persona pueda entender.
Guía para probar una segunda ruta sin improvisar
- La prueba que nunca debe estrenarse durante una venta
- Respuesta rápida: usa una ventana corta y un plan de regreso
- Define qué debe sobrevivir antes de tocar la WAN
- Ejecuta una prueba controlada y mide el retorno
- No confundas failover con continuidad perfecta
- Documenta el resultado y corrige una cosa a la vez
- Una prueba breve vale más que una promesa
- Preguntas frecuentes
- Referencias
Categoría principal: Internet Continuity
Respuesta rápida: usa una ventana corta y un plan de regreso
- Ideal para: negocios pequeños que ya tienen dos conexiones de internet o un router celular configurado como respaldo.
- Idea principal: prueba el failover fuera de horas pico, con una lista corta de servicios esenciales y una forma clara de regresar a la conexión principal.
- Tiempo recomendado para la primera prueba: entre 25 y 45 minutos.
- Mejor resultado razonable: confirmar cuánto tarda el cambio, qué tareas recuperan conexión y si el router vuelve a la WAN principal sin intervención.
- Cuándo no hacerlo por tu cuenta: si procesas pagos críticos, dependes de telefonía continua, tienes varias VLAN, VPN complejas o no sabes identificar la conexión WAN principal.
El objetivo no es tumbar toda la oficina para demostrar que existe un respaldo. El objetivo es simular una sola falla, observar el comportamiento y volver a la normalidad con evidencia clara.
Define qué debe sobrevivir antes de tocar la WAN
“Failover” es el cambio desde la conexión principal hacia una ruta alterna cuando la primera deja de funcionar. “Failback” es el regreso a la conexión principal cuando vuelve el servicio. Algunos equipos hacen ambos cambios automáticamente. Otros requieren configuración adicional o intervención manual.
UniFi describe el failover como un modo que prioriza una WAN y usa las demás cuando hacen falta. Cisco Meraki documenta monitoreo de conexión para decidir cuándo cambiar de uplink y cuándo regresar. La idea es parecida, pero el comportamiento exacto depende del equipo, firmware y configuración.
Cuatro términos que conviene tener claros
- WAN principal: la conexión fija que normalmente usa el negocio.
- WAN secundaria: la conexión alterna, como otro proveedor o una ruta LTE o 5G.
- Failover: el cambio hacia la ruta alterna cuando falla la principal.
- Failback: el retorno hacia la ruta principal cuando recupera servicio.
Escoge tres tareas esenciales
No intentes validar todo el negocio en la primera prueba. Escoge tres tareas que representen la operación mínima:
| Tarea | Qué confirma | Qué anotar |
|---|---|---|
| Abrir correo o mensajería | Navegación básica y resolución de nombres | Si abre y cuánto tarda |
| Acceder a una aplicación prioritaria | Continuidad de una tarea real | Si reconecta o requiere iniciar sesión otra vez |
| Procesar una prueba no financiera o abrir una página interna autorizada | Ruta funcional para una operación concreta | Resultado y cualquier mensaje de error |
No hagas una transacción real solamente para “ver si pasa”. Usa una prueba autorizada, una pantalla de estado o un flujo que no afecte clientes ni inventario.
Escenario práctico: el respaldo existía, pero nadie había medido el cambio
Una oficina pequeña tiene fibra como WAN principal y un router celular como respaldo. El equipo fue instalado meses atrás y muestra luces normales. Durante una falla, el correo vuelve después de unos minutos, pero el sistema de llamadas requiere reconexión manual.
La instalación no era inútil. La expectativa estaba incompleta. Una prueba programada habría revelado qué servicio vuelve solo, cuál necesita un paso adicional y cuánto tiempo debe comunicar el personal a los clientes.
Ejecuta una prueba controlada y mide el retorno
Programa la prueba en una ventana de bajo impacto. Evita horas de cobro, citas, cierre de caja o una videollamada importante. Avisa a las personas afectadas y guarda un número de contacto para detener la prueba si aparece un problema inesperado.
Cisco Meraki publica una secuencia específica para probar failover celular en ciertos equipos: confirmar primero que el enlace celular esté disponible, desconectar la conexión WAN Ethernet y verificar conectividad. Esa secuencia sirve como ejemplo de una prueba controlada. Para tu equipo, sigue su documentación y no desconectes cables que no hayas identificado.
Antes de comenzar
- Confirma que la WAN secundaria aparece activa o disponible en el panel del router.
- Verifica que el plan móvil o segundo proveedor esté vigente.
- Anota la hora y toma una captura del estado normal.
- Escoge una sola laptop para las pruebas.
- Cierra transferencias grandes, actualizaciones y sincronizaciones innecesarias.
- Avisa que habrá una ventana corta de revisión.
- Define cómo revertirás el cambio si algo no sale como esperabas.
Simulación de 15 minutos
- Identifica el cable Ethernet de la WAN principal usando la documentación del equipo.
- Desconecta solamente esa WAN si el fabricante permite esa prueba.
- No desconectes corriente, no abras el router y no muevas fibra.
- Inicia un cronómetro.
- Revisa cuándo la laptop recupera navegación.
- Abre correo o mensajería.
- Prueba una aplicación prioritaria con un flujo autorizado.
- Anota si hubo que refrescar, reconectar o iniciar sesión nuevamente.
- Mantén la ruta alterna activa durante 10 a 15 minutos.
- Reconecta la WAN principal.
- Mide cuánto tarda el retorno.
- Confirma que la ruta secundaria vuelva a modo de espera cuando corresponda.
Tabla de resultados
| Resultado | Qué significa | Próximo paso |
|---|---|---|
| El cambio ocurre y las tareas esenciales vuelven | La ruta alterna cubre una interrupción limitada | Documenta tiempos y repite periódicamente |
| Navegación vuelve, pero una aplicación no | La aplicación puede requerir reconexión, DNS, VPN o una regla específica | Escala la revisión antes de depender del respaldo |
| El router nunca cambia a la WAN secundaria | La configuración, plan o enlace alterno no está listo | Revisa panel, plan y documentación |
| La WAN secundaria funciona, pero el retorno falla | El failback necesita ajuste o intervención manual | Documenta el procedimiento de regreso |
| La red alterna se degrada con varios equipos | La capacidad o el plan pueden ser insuficientes | Limita dispositivos y evalúa prioridades |
No confundas failover con continuidad perfecta
Una segunda conexión reduce el impacto de una falla, pero no elimina todos los cortes. Algunas sesiones pueden interrumpirse cuando cambia la ruta. Una VPN, una llamada o una aplicación web puede necesitar reconexión.
El retorno también importa. Cisco Meraki documenta opciones de failover y failback “Immediate” y “Graceful” en ciertos equipos. Eso demuestra por qué no debes asumir que toda caja regresa de la misma forma ni con el mismo tiempo.
Lo que no debes prometer al equipo
| Frase demasiado optimista | Expectativa más útil |
|---|---|
| “Nadie notará la falla” | “La ruta alterna debe recuperar tareas esenciales dentro de un tiempo medido” |
| “Todo seguirá funcionando igual” | “Algunas sesiones pueden requerir reconexión” |
| “El router celular resuelve cualquier apagón” | “La segunda ruta también necesita señal, plan activo y energía local” |
| “Si encendió una vez, ya está probado” | “Hay que comprobar cambio, operación mínima y retorno” |
Puerto Rico exige pensar en dos capas
El Programa de Banda Ancha de Puerto Rico ha documentado retos de telecomunicaciones relacionados con tormentas frecuentes y confiabilidad de la red eléctrica comercial. Sus proyectos buscan fortalecer energía e infraestructura en instalaciones clave.
Ese trabajo ocurre del lado de la red. En el negocio, todavía necesitas confirmar la capa local: router, segunda WAN, plan activo, UPS y procedimiento de prueba. Un failover bien configurado no ayuda durante un apagón si el router y la conexión alterna pierden energía.
Cuándo detener la prueba
Detén la simulación y regresa a la WAN principal si:
- El sistema de cobro o una aplicación crítica queda inestable.
- El router muestra alertas nuevas o comportamiento inesperado.
- La segunda conexión consume datos de forma anormal.
- La oficina pierde telefonía sin una alternativa.
- No puedes confirmar qué cable o interfaz estás manipulando.
Documenta el resultado y corrige una cosa a la vez
Una prueba útil deja una bitácora. No basta con decir “funcionó”. Necesitas tiempos, tareas probadas, fallas observadas y responsable del próximo ajuste.
Ready.gov indica que la recuperación de tecnología debe formar parte del plan de continuidad del negocio. Para una oficina pequeña, una hoja de una página ya mejora mucho la conversación con soporte o con el técnico que mantendrá la red.
Hoja de prueba para copiar
| Dato | Resultado |
|---|---|
| Fecha y hora | |
| WAN principal | |
| WAN secundaria | |
| Equipo usado para probar | |
| Hora de desconexión de WAN principal | |
| Tiempo hasta recuperar navegación | |
| Tareas esenciales probadas | |
| Aplicaciones que requirieron reconexión | |
| Consumo observado en la ruta alterna | |
| Hora de reconexión de WAN principal | |
| Tiempo hasta completar failback | |
| Alertas o errores | |
| Próximo ajuste y responsable |
Frecuencia razonable
Haz una primera prueba al instalar el equipo. Repítela después de cambiar proveedor, SIM, plan, router, firmware o reglas importantes. Para un negocio que depende de la ruta alterna, una revisión periódica corta ayuda a descubrir planes vencidos, contraseñas olvidadas y configuraciones que cambiaron en silencio.
No cambies varias cosas después de una prueba fallida. Corrige una variable, repite la secuencia y anota el nuevo resultado.
Una prueba breve vale más que una promesa
El failover de internet no se valida mirando una luz verde. Se valida cuando una falla simulada activa la segunda ruta, las tareas esenciales vuelven dentro de un tiempo medido y el router regresa a la WAN principal de forma entendible.
Escoge una ventana corta, prueba con una sola laptop y registra lo que ocurrió. Si la red es compleja o el negocio no tolera pausas, convierte la prueba en una tarea técnica programada, no en un experimento durante horas pico.
Preguntas frecuentes
¿Debo desconectar el cable de internet para probar el failover?
Solo cuando hayas identificado correctamente la WAN principal y la documentación del equipo permita esa prueba. No muevas fibra, no desconectes corriente y no abras cajas selladas. En una red compleja, programa la revisión con apoyo técnico.
¿Cuánto debe tardar el cambio hacia la WAN secundaria?
Depende del router, monitoreo configurado, proveedor y tipo de conexión. No asumas un número universal. Mide el tiempo real desde que simulas la falla hasta que una laptop recupera navegación y una tarea prioritaria vuelve a funcionar.
¿Failover significa que las llamadas y VPN nunca se caen?
No. Algunas sesiones pueden necesitar reconexión cuando cambia la ruta. La prueba debe confirmar qué servicios regresan automáticamente y cuáles requieren un paso adicional.
¿Cada cuánto debo repetir la prueba?
Hazla al instalar el equipo y después de cambios en proveedor, SIM, plan, router, firmware o reglas importantes. Si el negocio depende de la ruta alterna, incorpora una revisión periódica corta.
Por: Marcus Irizarry
Por qué confiar en esta guía: Esta guía organiza documentación oficial de Cisco Meraki, Ubiquiti, Ready.gov y el Programa de Banda Ancha de Puerto Rico en una prueba controlada para pequeños negocios.
Última actualización: 2026-06-12
Divulgación: Ninguna colocación pagada influyó en este contenido.
Alcance de esta guía
Esta guía cubre una prueba básica y de bajo impacto para una red de negocio pequeña. No sustituye la documentación del fabricante, una evaluación técnica ni un plan profesional para operaciones que no toleran interrupciones.
Referencias
- Cisco Meraki Documentation — “Connection Monitoring for WAN Failover.” https://documentation.meraki.com/SASEandSD-WAN/MX/DesignandConfigure/ConfigurationGuides/FirewallandTrafficShaping/ConnectionMonitoringforWANFailover
- Cisco Meraki Documentation — “3G/4G Cellular Failover with USB Modems.” https://documentation.meraki.com/SASEandSD-WAN/Cellular/DesignandConfigure/ConfigurationGuides/3G%2F%2F4GCellularFailoverwithUSBModems
- Ubiquiti Help Center — “WAN Failover, Load Balancing and Port Remapping on UniFi Gateways.” https://help.ui.com/hc/en-us/articles/360052548713-WAN-Failover-Load-Balancing-and-Port-Remapping-on-UniFi-Gateways
- Ready.gov — “IT Disaster Recovery Plan.” https://www.ready.gov/business/emergency-plans/recovery-plan
- Programa de Banda Ancha de Puerto Rico — “Resilient Power and Hardening of Telecommunications Facilities Across Puerto Rico – Round 2.” https://www.smartisland.pr.gov/rfps/resilient-power-and-hardening-of-telecommunications-facilities-across-puerto-rico-round-2