FortiGate SD-WAN Flapping: por qué cambia constantemente de enlace y cómo solucionarlo

¿Tu FortiGate cambia continuamente entre dos proveedores de Internet aunque ambos enlaces estén activos? Aprende a identificar el flapping de SD-WAN, analizar Performance SLA, revisar health-checks y diagnosticar problemas de rutas, sesiones y failover con comandos de FortiOS.

Tu empresa tiene dos proveedores de Internet, ambos enlaces WAN aparecen activos en FortiGate, pero la conexión sigue interrumpiéndose. Las videollamadas se congelan, algunos usuarios pierden la conexión VPN y las aplicaciones corporativas presentan fallas intermitentes.

Cuando revisas el FortiGate, encuentras que el tráfico cambia repetidamente entre WAN1 y WAN2, aunque ninguno de los proveedores ha sufrido una caída completa.

Este comportamiento puede estar relacionado con un fenómeno conocido como SD-WAN flapping: cambios repetidos en el estado de salud de un enlace, su elegibilidad para una regla SD-WAN o las rutas disponibles.

En esta guía de la Biblioteca Virtual SISTRO 2.0 aprenderás cómo identificar este comportamiento mediante Performance SLA, revisar los health-checks, analizar los eventos de failover y diagnosticar los cambios de ruta con comandos CLI de FortiOS.

Alcance: FortiGate con FortiOS 7.4 y 7.6, en escenarios de dos o más enlaces WAN. La sintaxis y los menús pueden variar según la compilación. Los comandos de consulta son ejemplos de diagnóstico; cualquier modificación debe validarse antes de aplicarse en producción.

1. ¿Qué es SD-WAN flapping en FortiGate?

El término flapping describe un cambio repetido e inestable entre estados o rutas.

En una configuración SD-WAN, puede presentarse cuando FortiGate considera que un enlace está disponible, poco después lo declara inadecuado o inactivo y posteriormente vuelve a habilitarlo.

El ciclo puede repetirse varias veces:

  • WAN1 cumple las condiciones de la regla.
  • WAN1 deja de responder correctamente al health-check o incumple el SLA.
  • FortiGate selecciona WAN2 para determinado tráfico.
  • WAN1 vuelve a cumplir las condiciones.
  • Las reglas vuelven a considerar WAN1.
  • El patrón continúa durante el incidente.

No todos estos cambios provocan necesariamente una interrupción. Su impacto depende de las reglas SD-WAN, las rutas, las sesiones existentes, NAT y el comportamiento de las aplicaciones.

Sin embargo, cuando la conmutación se repite, puede producir una experiencia de conectividad inestable.

2. Dos enlaces activos no garantizan estabilidad

Supongamos que una empresa utiliza la siguiente arquitectura:

ComponenteConfiguración ilustrativa
FirewallFortiGate con Secure SD-WAN
WAN1ISP principal, fibra empresarial
WAN2ISP de respaldo, Internet de banda ancha
AplicacionesMicrosoft 365, telefonía, ERP y VPN
SelecciónReglas SD-WAN con Performance SLA

El enlace principal no está completamente caído. Su interfaz Ethernet continúa activa, pero presenta ráfagas de pérdida de paquetes o variaciones importantes de latencia.

Dependiendo de cómo se hayan configurado los health-checks y las reglas, FortiGate puede dejar de seleccionar el enlace principal y después volver a utilizarlo.

El problema no necesariamente se encuentra en el equipo, sino en la calidad real del enlace, los destinos de prueba, los umbrales o los tiempos de detección y recuperación.

3. Diferencia entre interfaz UP, health-check alive y SLA cumplido

Para diagnosticar correctamente, debemos separar tres conceptos.

Interfaz física UP

Significa que la interfaz tiene conectividad de enlace. No demuestra que el proveedor tenga acceso funcional a todos los destinos de Internet.

Health-check alive

Indica que las verificaciones de salud reciben las respuestas necesarias para considerar disponible al enlace.

Performance SLA cumplido

Significa que la calidad medida satisface los umbrales configurados para la regla o el objetivo SLA correspondiente.

Por lo tanto, un enlace puede estar alive y seguir siendo inadecuado para una aplicación sensible a latencia, jitter o pérdida de paquetes.

También puede ocurrir que el monitor declare un enlace dead cuando los probes dejan de responder, aunque la interfaz física continúe UP.

Esta distinción es fundamental para no diagnosticar equivocadamente una caída física cuando el problema es de selección por calidad.

4. ¿Qué síntomas indican un posible problema de flapping?

Entre los síntomas que justifican revisar SD-WAN se encuentran:

  • Videollamadas que se interrumpen en determinados momentos.
  • Telefonía IP que pierde audio o llamadas.
  • Conexiones VPN que se restablecen repetidamente.
  • Aplicaciones SaaS que presentan desconexiones breves.
  • Sesiones de escritorio remoto que se interrumpen.
  • Cambios repetidos de enlace seleccionado.
  • Eventos frecuentes de Performance SLA pass/fail.
  • Rutas que aparecen y desaparecen de la tabla activa.

Estos síntomas no demuestran por sí solos que exista flapping. Es necesario comprobarlos con registros, mediciones y estado de reglas.

5. Primer diagnóstico: revisar los health-checks

Conéctate por CLI al FortiGate y ejecuta:

diagnose sys sdwan health-check

En versiones compatibles también puedes utilizar:

diagnose sys sdwan health-check status

Este comando permite consultar el estado de las verificaciones de salud configuradas.

Un resultado ilustrativo podría presentar:

Health Check(WAN_MONITOR):
Seq(1 wan1): state(alive),
packet-loss(2.000%),
latency(45.000),
jitter(12.000)

Seq(2 wan2): state(alive),
packet-loss(0.000%),
latency(24.000),
jitter(3.000)

Ejemplo ilustrativo, no resultado de una intervención real.

En este escenario ambos miembros están disponibles, pero WAN1 presenta peores mediciones.

Eso podría provocar una selección diferente si las reglas consideran alguno de estos valores y los umbrales configurados.

Comprueba los datos en diferentes momentos del incidente. Un resultado aislado puede mostrar un enlace saludable justo después de que se recuperó.

6. Cómo identificar si el problema está en la pérdida de paquetes

La pérdida de paquetes puede ser temporal o sostenida.

En una red empresarial puede deberse a diferentes causas:

  • Congestión del proveedor.
  • Problemas físicos en el enlace.
  • Errores de interfaz.
  • Degradación de una conexión inalámbrica o celular.
  • Restricciones de los equipos intermedios.
  • Problemas de enrutamiento o peering.
  • Servidores de prueba que limitan las respuestas.

Antes de ajustar un SLA debemos confirmar si el problema ocurre realmente en el camino utilizado por el tráfico empresarial.

También conviene comprobar si el destino de las pruebas ICMP responde de manera consistente.

Un servidor puede limitar las respuestas a ping sin que esto represente exactamente la experiencia de todas las aplicaciones.

7. El destino del health-check puede estar provocando falsos cambios

Una configuración aparentemente correcta puede resultar problemática si utiliza un servidor de prueba poco adecuado.

Imagina que todas las verificaciones dependen de un único destino.

Cuando ese servidor presenta saturación, filtrado o problemas de respuesta, FortiGate puede interpretar los resultados como degradación del enlace.

Por eso debemos revisar:

  • Disponibilidad del destino.
  • Ubicación y distancia de red.
  • Compatibilidad con el protocolo de prueba.
  • Consistencia de las respuestas.
  • Si el destino representa la conectividad que realmente queremos supervisar.
  • Si conviene utilizar destinos redundantes.

Fortinet recomienda considerar múltiples servidores de prueba cuando la versión y la configuración lo permiten, para reducir la dependencia de un solo destino.

No debemos asumir que probar un DNS público garantiza el comportamiento de una aplicación SaaS o una VPN específica.

8. Revisa la configuración SD-WAN desde CLI

Para consultar la configuración completa:

show system sdwan

Busca especialmente:

  • config members: interfaces participantes.
  • config health-check: monitores de salud.
  • config sla: objetivos y umbrales de calidad.
  • config service: reglas SD-WAN.
  • Servidores y protocolos de prueba.
  • Intervalos y tiempos de detección.
  • Miembros asociados a cada health-check.
  • Configuración de actualización de rutas estáticas.

Documenta los parámetros actuales antes de realizar ajustes.

Si el FortiGate pertenece a una infraestructura con VPN, sucursales y rutas específicas, un cambio aparentemente pequeño puede modificar varias decisiones de forwarding.

9. Interval, failtime y recoverytime: los parámetros que debes comprender

Los cambios constantes pueden aparecer cuando la frecuencia de las pruebas y los criterios de cambio de estado no son adecuados para el enlace.

En términos generales:

  • interval: periodicidad de las verificaciones.
  • failtime: número de fallas consecutivas requerido para declarar un estado de falla, según el tipo de verificación.
  • recoverytime: número de comprobaciones exitosas requerido para considerar recuperado el enlace.

Una detección demasiado agresiva puede reaccionar ante interrupciones muy breves.

Una detección excesivamente lenta puede mantener tráfico sobre un enlace degradado durante más tiempo del deseado.

El objetivo no consiste en establecer valores universalmente altos o bajos, sino en definirlos según:

  • Calidad histórica del proveedor.
  • Tiempo aceptable de recuperación.
  • Sensibilidad de las aplicaciones.
  • Características de los enlaces.
  • Comportamiento real de las pruebas.

Advertencia: no copies parámetros de un ejemplo de Internet sin medir primero el comportamiento de tus enlaces.

10. Comprueba qué regla SD-WAN está seleccionando el tráfico

Desde FortiOS 7.4.4, el diagnóstico de reglas SD-WAN distingue entre IPv4 e IPv6.

Para IPv4:

diagnose sys sdwan service4

Para IPv6:

diagnose sys sdwan service6

En compilaciones anteriores puede utilizarse la sintaxis:

diagnose sys sdwan service

Estos comandos permiten observar las reglas y los miembros elegibles o seleccionados, dependiendo de la estrategia utilizada.

Revisa:

  • Identificador de la regla.
  • Modo de selección.
  • Health-check asociado.
  • Miembros participantes.
  • Estado de cada miembro.
  • Preferencias y prioridades.
  • Miembro seleccionado para la regla.

Si la preferencia cambia continuamente durante el incidente, correlaciona esos cambios con los eventos SLA.

Ten presente que una regla puede utilizar diferentes estrategias, como selección manual, mejor calidad, menor costo con SLA o balanceo.

11. Revisa si el health-check modifica las rutas estáticas

Uno de los elementos más importantes es la opción update-static-route.

Cuando está habilitada, un fallo del monitor puede provocar que determinadas rutas estáticas asociadas al miembro dejen de estar activas.

Si el health-check cambia repetidamente de estado, esas rutas pueden retirarse y recuperarse de forma sucesiva.

Para revisar la tabla de rutas:

get router info routing-table all

Y para consultar información adicional de rutas:

get router info routing-table database

Comprueba si los cambios coinciden con los eventos del monitor.

Importante: no deshabilites update-static-route como corrección automática.

Esta opción afecta la relación entre la disponibilidad del miembro y el enrutamiento de otros flujos, incluidos potencialmente túneles y rutas que no están controlados por la misma regla SD-WAN.

Fortinet advierte que debe evaluarse especialmente su impacto cuando existen redes overlay y VPN.

12. ¿Por qué una sesión puede interrumpirse durante el failover?

Una pregunta frecuente es por qué una videollamada o sesión VPN puede caer aunque FortiGate seleccione correctamente el segundo proveedor.

Debemos distinguir entre elegir una nueva ruta y mantener intacta una sesión existente.

Cuando un cliente sale a Internet mediante WAN1, normalmente utiliza una dirección pública o una traducción NAT asociada a esa conexión.

Si el tráfico pasa a WAN2, la dirección pública visible puede cambiar.

Algunas aplicaciones toleran el cambio o restablecen su comunicación automáticamente. Otras pueden necesitar una nueva sesión.

Por tanto, tener failover no garantiza que todas las sesiones sobrevivan sin interrupción.

La continuidad depende de:

  • Diseño de NAT.
  • Direcciones públicas utilizadas.
  • Tipo de sesión y protocolo.
  • Comportamiento del servidor remoto.
  • Reglas y selección SD-WAN.
  • Enrutamiento de retorno.
  • Arquitectura VPN, cuando corresponda.

Antes de prometer continuidad transparente para aplicaciones críticas, deben realizarse pruebas reales de conmutación.

13. Revisa los logs de SD-WAN antes de modificar parámetros

Desde la interfaz gráfica revisa:

Log & Report → System Events → SD-WAN Events, o la ubicación equivalente disponible en tu versión.

Busca eventos repetidos relacionados con:

  • Cambios de estado de Health Check.
  • SLA pass y fail.
  • Miembros que dejan de cumplir las condiciones.
  • Reinstalación o retiro de rutas.
  • Cambios de disponibilidad de enlaces.

Registra la hora exacta de cada transición.

Después compara esos eventos con las interrupciones reportadas por los usuarios.

Por ejemplo, si una videollamada falló a las 10:15 y los eventos muestran cambios repetidos en el health-check de WAN1 durante ese intervalo, existe una relación que merece investigarse.

Una coincidencia temporal es evidencia útil, aunque todavía no demuestra por sí sola la causa definitiva.

14. Caso práctico ilustrativo: llamadas que se cortan cada pocos minutos

Consideremos la siguiente instalación:

  • FortiGate con dos enlaces ISP.
  • WAN1 preferida para aplicaciones corporativas.
  • WAN2 como alternativa.
  • Performance SLA para latencia, jitter y pérdida.
  • Usuarios que realizan videollamadas diariamente.

Los usuarios reportan que las llamadas se interrumpen de forma intermitente.

El administrador verifica:

diagnose sys sdwan health-check status
diagnose sys sdwan service4
show system sdwan

Durante el periodo investigado observa que las mediciones del monitor asociado a WAN1 se aproximan repetidamente a los límites configurados.

Los registros también muestran cambios frecuentes de estado SLA, y las reglas dejan de considerar temporalmente ese enlace para determinados flujos.

Hipótesis inicial: los parámetros del SLA son demasiado sensibles para las variaciones reales del proveedor o existe una degradación intermitente que debe corregirse.

Antes de modificar la configuración, el administrador comprueba la calidad del enlace, el destino de prueba y los tiempos de detección.

Posteriormente podrá decidir si corresponde ajustar los parámetros, cambiar el servidor de monitoreo o levantar un incidente con el proveedor.

Este escenario es un ejemplo didáctico, no una intervención real atribuida a SISTRO.

15. Procedimiento de diagnóstico recomendado

Paso 1. Documenta el problema

Identifica qué aplicaciones fallan, desde qué redes y a qué horas.

Paso 2. Verifica las interfaces

Comprueba que los enlaces físicos estén operativos y revisa errores o pérdida de conectividad.

Paso 3. Consulta los health-checks

diagnose sys sdwan health-check status

Registra las métricas varias veces durante el incidente.

Paso 4. Revisa la configuración

show system sdwan

Identifica los servidores, protocolos, objetivos SLA, intervalos y miembros.

Paso 5. Comprueba las reglas

diagnose sys sdwan service4

Determina qué miembro utiliza cada regla y por qué.

Paso 6. Revisa las rutas

get router info routing-table all
get router info routing-table database

Investiga cambios relacionados con el estado de los monitores.

Paso 7. Correlaciona eventos

Compara logs de SD-WAN con las interrupciones reales de las aplicaciones.

Paso 8. Identifica la causa raíz

Separa los problemas del proveedor de los parámetros incorrectos del monitor o de una política de selección inadecuada.

Paso 9. Ajusta únicamente lo necesario

Después de obtener evidencia, define una modificación autorizada y documenta los valores anteriores.

Paso 10. Valida la recuperación

Comprueba durante un periodo representativo que las rutas, los health-checks y las aplicaciones se mantienen estables. Realiza pruebas de falla real y recuperación controlada.

16. Matriz rápida de diagnóstico

SíntomaQué investigar primero
WAN1 está UP, pero no sale tráficoHealth-check, reglas y rutas
Los enlaces cambian repetidamenteEventos de SLA, failtime y recoverytime
Solo falla una aplicaciónRegla SD-WAN, destino y política
El monitor alterna alive/deadProbes, destino, conectividad y pérdida
El enlace está alive pero no se seleccionaUmbrales SLA, prioridades y rutas
Las VPN se interrumpen en failoverNAT, IP pública, transporte y sesiones
El enlace se recupera y vuelve a fallarEstabilidad ISP y criterios de recuperación
Las rutas aparecen y desaparecenupdate-static-route y estado del health-check

17. Errores comunes al intentar corregir SD-WAN flapping

Modificar todos los umbrales al mismo tiempo

Cuando se cambian múltiples parámetros simultáneamente, resulta difícil identificar cuál de ellos resolvió realmente el problema.

Utilizar un destino que no representa la aplicación

Una verificación hacia un servidor público no necesariamente refleja la conectividad hacia una plataforma empresarial específica.

Deshabilitar el health-check

Puede ocultar un problema de supervisión, pero también elimina información necesaria para detectar determinadas fallas.

Forzar siempre WAN1

Puede reducir cambios visibles, pero también enviar tráfico crítico a un enlace realmente degradado.

Confundir pérdida de SLA con caída física

Un enlace puede estar disponible a nivel físico y no cumplir un objetivo de calidad.

No comprobar las sesiones

El cambio de ruta no garantiza que sesiones existentes continúen intactas cuando cambia la dirección pública o las condiciones de NAT.

No revisar el proveedor

En ocasiones el FortiGate está detectando correctamente una conexión inestable. El problema necesita resolverse con el ISP y no modificando las políticas del firewall.

18. Checklist técnico para administradores Fortinet

  • ☐ Modelo exacto de FortiGate.
  • ☐ Versión y compilación de FortiOS.
  • ☐ Interfaces WAN activas.
  • ☐ Estado físico y errores de interfaces.
  • ☐ Miembros de la zona SD-WAN.
  • ☐ Health-checks configurados.
  • ☐ Destinos y protocolos de prueba.
  • ☐ Latencia medida por enlace.
  • ☐ Jitter medido por enlace.
  • ☐ Porcentaje de pérdida.
  • ☐ Estado alive/dead.
  • ☐ Cumplimiento de objetivos SLA.
  • ☐ Configuración de interval, failtime y recoverytime.
  • ☐ Reglas SD-WAN y miembros seleccionados.
  • ☐ Tabla de rutas activa.
  • ☐ Configuración update-static-route.
  • ☐ Eventos históricos de cambios SLA.
  • ☐ NAT y comportamiento de sesiones.
  • ☐ Comportamiento real de las aplicaciones.
  • ☐ Prueba documentada de failover y recuperación.

19. Cómo diseñar una SD-WAN más estable

Una implementación confiable debe considerar tanto la disponibilidad de Internet como la calidad requerida por las aplicaciones.

Recomendamos evaluar:

  • Dos proveedores con diversidad real cuando sea posible.
  • Monitoreo adecuado para cada tipo de enlace.
  • Destinos de prueba confiables.
  • Objetivos SLA basados en mediciones.
  • Reglas específicas para aplicaciones críticas.
  • Priorización adecuada de tráfico.
  • Control de la recuperación después de una falla.
  • Políticas de firewall y NAT coherentes.
  • Monitoreo de eventos y tendencias.
  • Pruebas periódicas de conmutación.

Para comprender los fundamentos, consulta nuestras guías anteriores:

La guía actual complementa esos contenidos con procedimientos para identificar problemas operativos después de la implementación.

20. Firewalls Fortinet y servicios de implementación en SISTRO

Una configuración SD-WAN estable requiere diseño, monitoreo y administración. La compra del firewall es solamente una parte de la solución.

En SISTRO.NET puedes encontrar:

Antes de recomendar un modelo o servicio, es importante revisar la cantidad de usuarios, los enlaces existentes, las aplicaciones críticas, las VPN y el rendimiento requerido con inspección de seguridad activa.

Una auditoría de SD-WAN puede ayudar a identificar problemas de configuración, rutas inestables y oportunidades para mejorar la continuidad de la conectividad.

21. Preguntas frecuentes

¿Qué significa SD-WAN flapping en FortiGate?

Describe cambios repetidos de estado o selección relacionados con enlaces, health-checks, objetivos SLA o rutas. Puede provocar conmutaciones frecuentes y afectar determinadas sesiones.

¿Por qué mi FortiGate cambia de WAN si Internet funciona?

Porque las reglas SD-WAN pueden considerar la calidad medida y no solamente el estado físico de la interfaz. Un enlace puede estar UP pero incumplir un objetivo SLA.

¿Qué comando revisa los health-checks de FortiGate?

En FortiOS 7.4 y 7.6 puedes consultar diagnose sys sdwan health-check y, en versiones compatibles, diagnose sys sdwan health-check status.

¿Qué diferencia existe entre alive y SLA cumplido?

Alive indica disponibilidad según las respuestas del monitor. El cumplimiento del SLA expresa que las mediciones satisfacen los umbrales configurados para un objetivo determinado.

¿Cómo reviso qué WAN está seleccionando FortiGate?

Para reglas IPv4 en FortiOS 7.4.4 y posteriores utiliza diagnose sys sdwan service4. Analiza el miembro seleccionado y la estrategia de la regla.

¿Debo desactivar update-static-route?

No necesariamente. Su funcionamiento debe evaluarse según la arquitectura de routing, VPN y SD-WAN. Cambiarlo sin análisis puede provocar efectos sobre rutas que no corresponden a la aplicación investigada.

¿Por qué se corta una llamada durante el failover?

Porque el nuevo enlace puede utilizar una dirección pública distinta y modificar el comportamiento de NAT. Algunas sesiones necesitan restablecerse, aunque el firewall haya seleccionado correctamente una ruta alternativa.

¿Puedo utilizar cualquier servidor DNS para los health-checks?

No es recomendable elegir destinos arbitrariamente. Conviene validar su estabilidad, respuesta al protocolo configurado y representatividad respecto de los servicios supervisados.

¿Este diagnóstico aplica a FortiOS 7.6?

Sí, la metodología aplica a configuraciones habituales de FortiOS 7.6. Las opciones específicas deben comprobarse contra la documentación de la compilación instalada.

22. Documentación oficial de Fortinet

Conclusión: el problema no siempre es el proveedor, pero tampoco siempre es FortiGate

Cuando una empresa presenta interrupciones intermitentes con dos enlaces de Internet, debemos identificar si el problema se encuentra en la calidad del circuito, los destinos de monitoreo, los parámetros SLA, la selección de rutas o el comportamiento de las sesiones.

FortiGate Secure SD-WAN ofrece herramientas para investigar estos escenarios sin depender exclusivamente del estado UP/DOWN de las interfaces.

La secuencia recomendada es: interfaces → health-checks → SLA → reglas SD-WAN → rutas → sesiones → validación de aplicaciones.

El objetivo no es impedir que SD-WAN cambie de enlace, sino conseguir que lo haga por razones correctas y con el comportamiento esperado.

Continúa consultando la Biblioteca Virtual SISTRO 2.0 y conoce las soluciones Fortinet FortiGate de SISTRO.NET.