FortiExpert logoFortiExpert
Sign in
← Back to knowledge base
high

Troubleshooting loss of all SD-WAN paths when every member fails the performance SLA

Confirmed 8/8/2026

Problem

A FortiGate with three high-speed Internet links in SD-WAN can lose Internet access when all members are simultaneously marked out of SLA. Equal load balancing does not prevent this condition because member eligibility is determined by the configured performance checks. Rebooting the FortiGate and reconnecting only WAN1 restored connectivity in the reported case, but this was not confirmed as the root-cause resolution.

Symptoms

Internet access stops even though the FortiGate, switches, and upstream routers appear operational. Rebooting the FortiGate and routers may not restore service. Logs show "Member status changed", "Member status changed. Member out-of-sla.", "SDWAN SLA information warning", and "Service disabled caused by no outgoing path." All SD-WAN routes may be down. One affected circuit may continue carrying VoIP while the SD-WAN health check still considers it out of SLA.

Environment

FortiGate 60F (FG60F) with three Internet connections, each rated above 500/500 MB, configured as SD-WAN members with equal load balancing. The implicit SD-WAN rule can be used to distribute 33% of traffic to each connection. The site is a training center running critical online tests.

FortiOS version

7.4.4; the deployment reportedly operated for at least one year on 7.4.3 without this behavior, after which the issue occurred approximately 3–4 times following the upgrade to 7.4.4.

Root Cause

The observed logs indicate that all three SD-WAN members failed to meet the configured SLA targets at the same time. When "Update static route" is enabled, failed members can have their routes withdrawn. If every member is out of SLA, no eligible outgoing path remains and the SD-WAN service is disabled. Continued VoIP operation on one circuit does not prove that the circuit met the specific latency, packet-loss, or probe-reachability criteria used by the FortiGate performance check. A definitive underlying reason for the simultaneous SLA failures was not established in the source discussion, and no confirmed FortiOS defect was identified.

Solution

  1. Review the SD-WAN event logs at the time of the outage. Correlate the following messages across all three members: "Member status changed", "Member status changed. Member out-of-sla.", "SDWAN SLA information warning", and "Service disabled caused by no outgoing path."

  2. Check whether every SD-WAN member failed its performance SLA concurrently. Equal load balancing does not preserve connectivity if all members become ineligible.

  3. Review the SD-WAN performance-check thresholds and make them less restrictive where appropriate. The values suggested in the discussion were a ping interval of 6000 seconds, latency of 100 ms, and packet loss of 10%.

  4. As a temporary workaround, remove the SLA dependency and use only the implicit SD-WAN rule, distributing traffic equally at 33% across each Internet connection. This avoids removing members solely because of SLA results, but it also removes SLA-based path-quality selection.

  5. Alternatively, disable the "Update static route" option so that an SLA failure does not withdraw the associated static route. Be aware that SLA-driven failover will not occur while this option is disabled.

  6. If service is already unavailable, the reported recovery sequence was to reboot the FortiGate, wait 2 minutes, and connect only WAN1. Connectivity returned in that case, after which all SD-WAN members appeared healthy in FortiCloud. Treat this only as an observed recovery action because the source did not confirm that it resolved the underlying cause.

Verification

Confirm that at least one SD-WAN member remains eligible and that the SD-WAN service has an outgoing path. Verify Internet connectivity and review the logs for recurrence of "Member out-of-sla" or "Service disabled caused by no outgoing path." If using the implicit SD-WAN rule without SLA checks, confirm that traffic is distributed 33% to each of the three Internet connections. If "Update static route" was disabled, confirm that routes remain installed while recognizing that SLA-based failover is no longer available.

Rollback

To restore SLA-based path selection after a temporary workaround, reapply the required performance checks. If "Update static route" was disabled, enable it again to restore SLA-driven route withdrawal and failover. Before doing so, ensure the SLA thresholds are suitable so that all three links are not removed simultaneously.

Tags

No tags yet.

Community rating

— / 5 (0)

Discussion (0)

    No comments yet.