SonicWall SD-WAN con dos proveedores: cómo usar SLA Probes para elegir el mejor enlace

Tener dos proveedores de Internet puede mejorar considerablemente la disponibilidad de una empresa.

Pero existe una diferencia muy importante entre:

tener dos conexiones

y

tener una estrategia inteligente para decidir cuál utilizar.

Una empresa puede disponer de:

• ISP 1 por fibra
• ISP 2 por fibra, cable, radio o 5G

y aun así experimentar problemas si el firewall solamente comprueba si la interfaz está físicamente activa.

Un enlace puede continuar en estado UP y al mismo tiempo presentar:

• Latencia elevada
• Jitter
• Pérdida de paquetes
• Problemas de routing del ISP
• Degradación parcial
• Mala experiencia en VoIP
• Problemas con videoconferencia

SonicWall SD-WAN permite ir más allá del estado físico de la interfaz.

Mediante SLA Probes podemos medir la calidad de los diferentes caminos WAN y utilizar esa información para seleccionar rutas de manera más inteligente.

En esta guía de la Biblioteca Virtual Sistro 2.0 explicamos cómo funciona SonicWall SD-WAN, qué miden los SLA Probes, cómo diseñar Dual WAN y qué debemos considerar antes de implementar failover en producción.

Consulta Firewalls SonicWall disponibles en Sistro

¿Qué significa Dual WAN en SonicWall?

Dual WAN significa que el firewall dispone de dos enlaces de salida hacia Internet.

Por ejemplo:

WAN1 → ISP principal

WAN2 → ISP secundario

Pero tener dos WAN permite diferentes estrategias.

• Failover
• Load balancing
• SD-WAN
• Routing por aplicación
• Selección según calidad del enlace

La arquitectura correcta depende de la operación de la empresa.

Failover básico

En una configuración sencilla podemos definir:

ISP 1 = principal

ISP 2 = respaldo

Mientras ISP 1 funciona, la operación utiliza ese camino.

Cuando falla, el firewall cambia hacia ISP 2.

Este modelo puede funcionar correctamente para muchas empresas.

Pero aparece una pregunta:

¿qué significa realmente que ISP 1 haya fallado?

Una interfaz UP no significa Internet saludable

Supongamos que el router del proveedor continúa conectado al SonicWall.

Ethernet mantiene enlace físico.

WAN1 aparece como:

UP

Pero existe un problema dentro de la red del proveedor.

Podemos experimentar:

• 10% de pérdida de paquetes
• Latencia de cientos de milisegundos
• Jitter elevado
• Rutas inestables
• Acceso deficiente hacia determinados servicios

Desde el punto de vista físico la conexión sigue activa.

Desde el punto de vista del usuario funciona mal.

Aquí entra SonicWall SD-WAN

SD-WAN permite evaluar diferentes caminos y tomar decisiones utilizando información adicional sobre su comportamiento.

SonicOS utiliza mecanismos como los SLA Probes para obtener métricas dinámicas de los enlaces.

Entre las variables que podemos observar están:

• Latencia
• Jitter
• Packet Loss

¿Qué es un SLA Probe?

Un SLA Probe es una prueba que SonicWall realiza hacia un destino para conocer el comportamiento de un camino determinado.

Podemos imaginar:

SonicWall WAN1 → Probe Target

SonicWall WAN2 → Probe Target

El firewall analiza los resultados de cada ruta.

Esto permite determinar no solamente si existe conectividad.

También podemos conocer qué tan buena es.

ICMP y TCP Probes

SonicOS permite utilizar diferentes tipos de probes, entre ellos ICMP y TCP.

La elección depende de aquello que queremos validar.

ICMP puede ser útil para pruebas generales de reachability y comportamiento.

TCP puede utilizarse cuando queremos comprobar conectividad hacia un servicio específico.

¿Qué es latencia?

Latencia es el tiempo que necesita un paquete para recorrer un camino y obtener respuesta.

Generalmente se mide en milisegundos.

La importancia de la latencia depende de la aplicación.

Un backup puede tolerar una latencia relativamente alta.

Una conversación de VoIP puede ser mucho más sensible.

¿Qué es jitter?

Jitter representa la variación en los tiempos de llegada de los paquetes.

Supongamos:

Paquete 1 → 20 ms

Paquete 2 → 25 ms

Paquete 3 → 120 ms

Paquete 4 → 30 ms

La conexión existe.

Pero la variación puede provocar una mala experiencia en aplicaciones en tiempo real.

¿Qué es pérdida de paquetes?

Packet loss significa que una parte de los paquetes enviados no llega correctamente.

Esto puede producir:

• Retransmisiones
• Navegación lenta
• Audio entrecortado
• Video inestable
• VPN degradada
• Aplicaciones que pierden sesiones

Un ISP puede continuar funcionando y aun así tener suficiente pérdida como para afectar la operación.

SLA Probes permiten visualizar estas métricas

SonicOS permite monitorear dinámicamente los valores asociados con los caminos SD-WAN.

Esto ayuda a responder preguntas como:

¿Cuál ISP tiene actualmente menor latencia?

¿Cuál tiene menor jitter?

¿Existe pérdida de paquetes?

¿Qué enlace cumple mejor el SLA de nuestra aplicación?

¿Qué es un Path Selection Profile?

Los Path Selection Profiles permiten utilizar los resultados de los SLA Probes como parte de la estrategia para seleccionar caminos.

Conceptualmente:

Aplicación
↓
Path Selection Profile
↓
SLA Probe
↓
WAN que cumple las condiciones

Esto permite evolucionar desde un failover puramente físico hacia una selección basada en calidad.

No todas las aplicaciones necesitan el mismo SLA

Este punto es fundamental.

No deberíamos utilizar exactamente los mismos umbrales para:

• VoIP
• Teams
• ERP
• Navegación web
• Backup
• Transferencia de archivos

Cada aplicación tiene diferente sensibilidad.

VoIP

La telefonía consume relativamente poco ancho de banda.

Pero necesita estabilidad.

Un enlace de 200 Mbps con buena latencia y jitter puede proporcionar mejor experiencia de voz que un enlace de 1 Gbps degradado.

Videoconferencia

Teams, Zoom, Webex y otras plataformas pueden verse afectadas especialmente por:

• Pérdida
• Jitter
• Latencia

Por eso el enlace con mayor ancho de banda no siempre es el mejor camino.

Backup

Un backup puede priorizar:

• Capacidad
• Disponibilidad

y tolerar mayor latencia que una aplicación interactiva.

Eso permite utilizar diferentes enlaces para diferentes workloads.

Ejemplo de Dual WAN

Supongamos:

ISP 1
1 Gbps de fibra
Enlace principal

ISP 2
500 Mbps
Enlace secundario

Normalmente ISP 1 puede ser el preferido.

Pero si comienza a presentar jitter o pérdida, podemos utilizar las métricas SD-WAN para cambiar determinadas rutas.

Más ancho de banda no significa mejor calidad

Este es uno de los principios más importantes de SD-WAN.

Podemos tener:

ISP A → 1 Gbps con pérdida

ISP B → 300 Mbps estable

Para una llamada de voz, ISP B puede ser claramente mejor.

Load balancing y SD-WAN no son exactamente lo mismo

Load balancing permite distribuir tráfico entre varios enlaces.

Eso puede ayudar a aprovechar la capacidad disponible.

Pero repartir tráfico no necesariamente implica medir la calidad de cada camino.

SD-WAN agrega información sobre el comportamiento del enlace y permite tomar decisiones más inteligentes.

¿Podemos usar ambos ISP simultáneamente?

Sí, dependiendo de la arquitectura.

Podemos diseñar escenarios donde diferentes tipos de tráfico utilizan diferentes enlaces.

Por ejemplo:

ISP 1 → ERP y aplicaciones críticas

ISP 2 → navegación y tráfico secundario

y mantener capacidad de contingencia.

Fibra + 5G

Otra arquitectura interesante para oficinas y sucursales es:

Fibra + LTE/5G

El enlace celular puede utilizarse como contingencia.

Durante esa contingencia podemos priorizar únicamente:

• ERP
• POS
• VPN
• VoIP
• Aplicaciones críticas

mientras reducimos tráfico no esencial.

El segundo ISP no tiene que ser idéntico al primero

Una empresa puede tener:

1 Gbps principal

y

300 Mbps de respaldo.

El enlace secundario no necesariamente necesita soportar el 100% de la actividad normal.

Debe soportar la operación crítica definida para una contingencia.

Esto puede reducir considerablemente el costo

Durante failover podemos priorizar:

• Sistemas administrativos
• Correo
• ERP
• Telefonía
• VPN

y restringir temporalmente:

• Streaming
• Actualizaciones
• Backups
• Tráfico recreativo

Cuidado con failover demasiado agresivo

Internet presenta variaciones normales.

Una respuesta perdida no necesariamente significa que el proveedor haya fallado.

Si configuramos condiciones demasiado agresivas podemos provocar cambios constantes entre enlaces.

Eso se conoce comúnmente como flapping.

Failback también debe diseñarse

Cuando el ISP principal vuelve a cumplir las condiciones debemos decidir cuándo volver a utilizarlo.

No queremos:

WAN1 → WAN2 → WAN1 → WAN2

cada pocos segundos porque el proveedor está en el límite.

La estabilidad puede ser más importante que regresar inmediatamente.

Los destinos de prueba también importan

Un SLA Probe necesita medir contra un destino.

Si elegimos un único destino que presenta problemas propios, podemos interpretar incorrectamente que nuestro ISP está degradado.

Por eso debemos diseñar cuidadosamente aquello que mediremos.

No pruebes solamente algo que no representa la aplicación

Una buena respuesta hacia un servidor genérico no garantiza una buena ruta hacia:

• Microsoft 365
• Data center corporativo
• Proveedor VoIP
• ERP cloud
• Aplicación SaaS

El probe debería representar razonablemente aquello que necesitamos proteger.

Dual WAN y VPN

En empresas con sucursales también debemos analizar las VPN.

No basta con que la navegación pueda cambiar de ISP.

Las conexiones hacia otras oficinas y data centers también deben formar parte de la estrategia de resiliencia.

Consulta SonicWall para oficinas remotas

Dual WAN no sustituye High Availability

Supongamos:

ISP 1 + ISP 2 → un solo SonicWall

Tenemos redundancia WAN.

Pero si falla el firewall, ambas conexiones quedan afectadas.

Son problemas diferentes.

Una arquitectura crítica puede necesitar:

dos proveedores + dos firewalls en HA + switching redundante.

El switch puede seguir siendo un Single Point of Failure

Una arquitectura de alta disponibilidad debe revisarse de extremo a extremo.

No sirve de mucho tener:

• Dos ISP
• Dos firewalls

si toda la operación depende de un único switch sin redundancia.

SonicWall SD-WAN y DPI-SSL

También debemos recordar que el firewall sigue procesando servicios de seguridad.

La capacidad WAN no debería compararse únicamente contra Firewall Throughput.

Si habilitamos:

• DPI-SSL
• IPS
• Gateway Anti-Virus
• Application Control
• Capture ATP

el workload aumenta.

Consulta nuestra guía SonicWall DPI-SSL

Speedtest tampoco cuenta toda la historia

Un resultado de Speedtest no representa necesariamente el rendimiento completo de la infraestructura.

Debemos considerar:

• Ruta
• Servidor utilizado
• Servicios de seguridad
• CPU del firewall
• Inspección TLS
• Aplicaciones
• Concurrencia

Por eso el troubleshooting debe revisar la red completa.

Escenario 1: despacho con dos fibras

Tenemos:

• ISP 1 de 500 Mbps
• ISP 2 de 300 Mbps
• 60 usuarios
• Microsoft 365
• VoIP
• VPN

Podemos utilizar ISP 1 normalmente y cambiar aplicaciones sensibles cuando deja de cumplir los valores esperados.

Escenario 2: sucursal con fibra + 5G

Tenemos:

• Fibra de 300 Mbps
• 5G de contingencia
• POS
• ERP
• VoIP

Durante una falla podemos permitir solamente las aplicaciones críticas a través del enlace celular.

Escenario 3: empresa con varias sucursales

Cada sucursal tiene:

• Dos enlaces
• VPN
• Aplicaciones cloud

Aquí SD-WAN puede ayudar a estandarizar el comportamiento de cada ubicación.

Escenario 4: ISP rápido pero inestable

ISP 1 proporciona más Mbps.

ISP 2 proporciona mejor estabilidad.

La decisión debería considerar la aplicación y no solamente el ancho de banda contratado.

Errores comunes al implementar SonicWall SD-WAN

1. Revisar solamente el estado físico

UP no significa saludable.

2. Utilizar los mismos SLA para todo

Cada aplicación tiene requerimientos diferentes.

3. Usar un probe target deficiente

Puede provocar falsos positivos.

4. Hacer failover demasiado rápido

Podemos generar flapping.

5. Ignorar el failback

Regresar demasiado pronto también puede generar inestabilidad.

6. Confundir load balancing con SD-WAN

Distribuir tráfico y medir calidad son problemas diferentes.

7. No probar las VPN

La contingencia debe contemplar también conectividad entre sedes.

8. Pensar que dos ISP equivalen a HA completa

Firewall, switching y energía siguen siendo relevantes.

9. No dimensionar el firewall

Las funciones de seguridad consumen recursos.

10. No realizar pruebas reales

El failover debe comprobarse antes de una contingencia.

Checklist antes de implementar Dual WAN

• Modelo SonicWall
• Versión SonicOS
• Velocidad ISP 1
• Velocidad ISP 2
• Tipo de enlace
• Aplicaciones críticas
• VPN
• VoIP
• Videoconferencia
• ERP
• SaaS
• SLA esperado
• Latencia
• Jitter
• Packet Loss
• Probe targets
• Failover
• Failback
• HA
• Switching

Artículos relacionados

SonicWall DPI-SSL

SonicWall Capture ATP y RTDMI

SonicWall NSa 2800 vs NSa 3800

Productos SonicWall en Sistro

Firewalls SonicWall
https://sistro.net/firewalls-sonicwall

Catálogo SonicWall
https://sistro.net/sonicwall

Recomendación final

Dos proveedores de Internet mejoran la resiliencia únicamente cuando existe una estrategia clara para utilizarlos.

SonicWall SD-WAN y SLA Probes permiten evolucionar desde:

“¿la interfaz está UP?”

hacia:

“¿este camino ofrece actualmente la calidad necesaria para esta aplicación?”

Medir latencia, jitter y pérdida de paquetes permite tomar decisiones mucho más útiles que revisar únicamente conectividad física.

Pero el éxito depende de diseñar correctamente probes, umbrales, failover, failback y aplicaciones.

La mejor WAN no siempre es la que tiene más Mbps.

Es la que proporciona la experiencia que necesita la aplicación.

¿Quieres implementar SonicWall SD-WAN?

En Sistro Networks podemos ayudarte a revisar tus enlaces, SonicWall, aplicaciones, VPN, SLA y requerimientos de disponibilidad.

Podemos diseñar Dual WAN, failover y SD-WAN de acuerdo con la operación real de tu empresa.

Consulta soluciones SonicWall en Sistro Networks

Preguntas frecuentes

¿SonicWall soporta SD-WAN?

Sí. SonicOS incorpora funciones SD-WAN que permiten trabajar con diferentes caminos y utilizar métricas de rendimiento para apoyar la selección de rutas.

¿Qué mide un SLA Probe?

Puede proporcionar información dinámica relacionada con latencia, jitter y pérdida de paquetes.

¿Dual WAN es lo mismo que SD-WAN?

No. Dual WAN significa disponer de varios enlaces. SD-WAN agrega inteligencia para decidir cómo utilizarlos.

¿Puedo utilizar dos proveedores diferentes?

Sí. Incluso pueden tener velocidades o tecnologías distintas.

¿Puedo utilizar 5G como respaldo?

Sí, siempre que se validen conectividad, rendimiento y comportamiento necesario para las aplicaciones críticas.

¿SD-WAN reemplaza High Availability?

No. SD-WAN protege principalmente la conectividad. HA protege frente a determinadas fallas del firewall.