FortiGate SD-WAN: Path Loss Detection Threshold & Failover Timing

FortiGate SD-WAN relies on active health monitoring to detect link degradation and trigger failover before user traffic stalls. Path loss detection threshold and failover timing are two separate but interdependent mechanisms. Understanding how they work together is essential for designing reliable multi-WAN deployments that meet SLA requirements without false positives or excessive convergence delays.

How FortiGate Detects Path Loss and Link Failure

FortiGate SD-WAN members send probe packets (ICMP or UDP) to configurable health-check destinations. Each member tracks latency, jitter, and packet loss on each WAN link independently. When a metric crosses a threshold, the member flags that link as degraded or down. The SD-WAN controller (or local policy engine on standalone units) then recalculates path selection and redirects traffic to healthy links.

Path loss detection is not binary. FortiGate measures loss as a percentage of probe packets that fail to return within the timeout window. A single lost probe does not trigger failover; instead, the system accumulates loss statistics over a measurement interval (typically 10 seconds by default) and compares the aggregate loss rate against the configured threshold.

Configuring Path Loss Threshold and Detection Interval

Path loss thresholds are set per SD-WAN member link using the health-check object. The key parameters are:

• →Threshold: percentage of lost probes (default 5%, range 0-100%)
• →Timeout: milliseconds to wait for probe response (default 500ms)
• →Interval: seconds between probe transmissions (default 10s)
• →Failtime: number of consecutive failed intervals before link is marked down (default 5)
• →Recoverytime: number of successful intervals before link is marked up (default 5)

The failtime and recoverytime parameters prevent flapping. If failtime is set to 5 and interval is 10 seconds, the link must fail health checks for at least 50 seconds before failover occurs. This hysteresis is critical in unstable network conditions.

config system sdwan
  config members
    edit 1
      set interface "wan1"
      config health-check
        edit "primary-check"
          set server "8.8.8.8"
          set protocol ping
          set interval 10
          set timeout 500
          set threshold 5
          set failtime 5
          set recoverytime 5
        next
      end
    next
  end
end

Understanding Failover Timing and Convergence

Failover timing is the elapsed time from the moment a link fails until traffic is rerouted to a backup path. This is NOT the same as path loss detection threshold. Detection identifies the problem; failover timing measures how quickly the system responds.

In the example above, if failtime is 5 and interval is 10 seconds, the minimum failover latency is 50 seconds (5 failed intervals times 10 seconds per interval). However, the actual convergence time also includes the time to update routing tables, update SD-WAN policy, and flush connection state. Total failover time typically ranges from 50 to 100 milliseconds after the last failed health check.

To reduce failover time, decrease the interval and failtime values. However, aggressive settings (interval 2s, failtime 2) increase probe traffic and CPU load, and may cause false positives on congested or high-jitter links. The trade-off is always between detection speed and stability.

Best Practices for Production Deployments

• →Use multiple health-check destinations (primary and secondary DNS, cloud gateway IPs) to avoid single-point-of-failure in the probe path
• →Set path loss threshold based on application tolerance; VoIP typically requires threshold <= 3%, general data 5-10%
• →Monitor health-check statistics in real time using 'diagnose sys sdwan health-check' to validate probe behavior before production cutover
• →Test failover manually by blocking probe traffic or shutting down the WAN link to confirm expected behavior and timing
• →Document failover timing requirements in your SD-WAN design document and validate against SLA commitments