Skip to main content
Staff
July 3, 2026

Troubleshooting Tip: Troubleshooting intermittent route changes caused by SD-WAN health-check flapping

  • July 3, 2026
  • 0 replies
  • 386 views

Description

This article describes how to identify and resolve intermittent routing changes on a FortiGate caused by SD-WAN performance SLA (health-check) flapping.

Scope

FortiGate.

Solution

Symptoms typically include sessions briefly switching between WAN interfaces, short traffic interruptions, VoIP call drops, and event logs showing repeated 'Health Check status changed' or 'static route removed/added' messages.

When a performance SLA is configured with 'update-static-route enable', a health-check failure withdraws the static routes tied to the member interface. If the SLA state oscillates between alive and dead, routes are repeatedly removed and reinstalled, causing intermittent path changes.

  1. Confirm the flapping in the event logs:

Under Log & Report -> System Events, filter results for mentions of 'Health Check'. Look for repeated transitions such as the following:

Health Check 'WAN_HC' of member 1(wan1) SLA status changed to fail
Health Check 'WAN_HC' of member 1(wan1) SLA status changed to pass

 

  1. Check the current SLA state and packet loss/latency/jitter values:


diagnose sys sdwan health-check status


Example output:

Health Check(WAN_HC):

Seq(1 wan1): state(alive), packet-loss(2.000%) latency(38.126), jitter(9.517)
Seq(2 wan2): state(alive), packet-loss(0.000%) latency(21.480), jitter(1.201)


Values close to the configured SLA thresholds indicate the link is marginal rather than hard-down.

  1. Review the health-check configuration:


show system sdwan


Key parameters:

  • 'interval' and 'failtime'/'recoverytime': aggressive values (for example, interval 500 ms with failtime 3) make the check sensitive to short bursts of loss.

  • 'update-static-route': when enabled, SLA failure removes the member's static route, affecting all traffic, not only SD-WAN rules.

  • 'server': a distant or rate-limited probe target (for example, a public DNS server that deprioritizes ICMP) can fail even when the link is healthy.


  1. Verify which SD-WAN rule and member the affected traffic is using during an incident:


diagnose sys sdwan service


Check whether the selected member list changes between outputs.

 

  1. Recommended adjustments:

  • Increase 'failtime' and 'recoverytime' (for example, failtime 5, recoverytime 10) so transient loss does not trigger a state change.

  • Increase 'interval' if sub-second probing is not required.

  • Use a reliable, close probe target, ideally an Anycast service with consistent ICMP/HTTP response, or configure 'protocol http' or 'protocol tcp-connect' instead of ping if ICMP is deprioritized upstream.

  • If routes for non-SD-WAN traffic must remain stable, consider 'set update-static-route disable' so only SD-WAN rule decisions are affected by SLA state, while static routing is preserved.

  • Where the link genuinely has marginal quality, adjust the SLA thresholds ('latency-threshold', 'jitter-threshold', 'packetloss-threshold') to reflect achievable values, and investigate the underlying circuit with the ISP.

 

  1. After tuning, monitor for stability.


diagnose sys sdwan health-check status
diagnose sys link-monitor status


Confirm the event log no longer shows repeated SLA transitions.