FortiGate SD-WAN — Performance SLAs, 5 Rule Strategies, and Path Selection in 11 Minutes

Why this matters — the Google Maps analogy

Imagine you're driving to a customer site in Bangalore. You open Google Maps. It checks every road — Outer Ring Road, Sarjapur, Hosur — sees the live traffic colour (green / yellow / red), and picks the fastest right now. Halfway through, an accident closes one road; Maps reroutes you in seconds. FortiGate SD-WAN does the same thing for your packets: it watches every WAN link's latency, jitter and loss in real time, decides per-session (and sometimes per-flow) which one to use, and reroutes when one degrades.

The part that catches L1 candidates: SD-WAN is not a routing protocol. It sits on top of routing — you still need a default route on every member. SD-WAN just picks which route to prefer for each session.

Three terms every interviewer will test

SD-WAN zone is the logical container. Member is each WAN link inside the zone (wan1, wan2, the IPsec to HQ). Performance SLA is the live health check on each member.

The biggest L1 trap: candidates conflate zone with member. A firewall policy with srcintf=lan, dstintf=overlay-zone covers every member inside that zone. You don't write three policies for three WAN links — that's the whole point.

Performance SLA — the heartbeat that decides everything

Every SD-WAN decision depends on one signal: is this member in SLA right now? If yes, it's a candidate. If no, the rule strategy may dump it for another member. So performance SLA tuning is where 70% of real-world SD-WAN problems live.

The defaults you'll see in config system sdwan / config health-check are latency ≤ 5 ms · jitter ≤ 5 ms · packet-loss ≤ 0%. These are absurdly tight for any path that touches the internet — even a clean fibre to AWS Mumbai will fail the 5 ms target. Always tune them per app.

Real config — a tuned SLA for Microsoft 365

Aman opens his branch FG-100F and writes a fresh performance SLA for M365:

config system sdwan
    config health-check
        edit "M365-Health"
            set server "outlook.office.com"
            set protocol http
            set http-get "/api/health"
            set members 1 2
            set sla-id-redistribute 1
            config sla
                edit 1
                    set latency-threshold 80
                    set jitter-threshold 30
                    set packetloss-threshold 1
                next
            end
            set interval 500
            set failtime 5
            set recoverytime 10
        next
    end
end

Health Check(M365-Health):
Seq(1 wan1): state(alive), packet-loss(0.000%) latency(22.140), jitter(7.911) sla_map=0x1
Seq(2 wan2): state(alive), packet-loss(0.000%) latency(18.302), jitter(3.144) sla_map=0x1

Both members show state(alive) and sla_map=0x1 meaning they both meet SLA 1. The rule engine will pick between them — for Lowest-Cost-SLA, wan2 wins on jitter; for Best Quality, it picks whichever is best right now.

The 5 rule strategies — which to pick and why

FortiGate SD-WAN gives you five strategy modes. Each is a different answer to the same question: "when more than one member is eligible, which do I use?" Get this matrix straight and 30% of your interview SD-WAN round is over.

Real config — Aman's three-rule layout

Here's exactly how Aman should have written it on day 1:

config system sdwan
    config service
        edit 1
            set name "ERP-pin-MPLS"
            set dst "ERP-servers-HQ"
            set src "internal-lan"
            set mode manual
            set priority-members 3
        next
        edit 2
            set name "M365-LowestCostSLA"
            set internet-service enable
            set internet-service-name "Microsoft-365"
            set src "internal-lan"
            set mode sla
            config sla
                edit "M365-Health"
                    set id 1
                next
            end
            set priority-members 1 2
        next
        edit 3
            set name "General-Internet-LoadShare"
            set dst "all"
            set src "internal-lan"
            set mode load-balance
            set priority-members 1 2
        next
    end
end

Service(1): Address Mode(IPV4) flags=0x200 use-shortcut-sla
  Tie break: cfg
  Members(1): 1: Seq_num(3 ipsec-MPLS), alive, selected
Service(2): Address Mode(IPV4) flags=0x4200 use-shortcut-sla
  Internet Service(327681): Microsoft-365.0(327681,0,0)
  SLA(1): jitter 3 latency 18 packet-loss 0.000% (member 2)
  Members(2): 2: Seq_num(2 wan2), alive, selected · 1: Seq_num(1 wan1), alive
Service(3): Address Mode(IPV4) flags=0x0 load-balance
  Members(2): 1: Seq_num(1 wan1), alive · 2: Seq_num(2 wan2), alive

Debug a bad path — settle every SD-WAN argument in 90 seconds

Vikram, an L3 at an Indian security firm, doesn't open the GUI to debug SD-WAN. He runs three commands. You should too.

# 1. What is each member's live SLA?
diagnose sys sdwan health-check

# 2. Which rule matched and which member is selected?
diagnose sys sdwan service

# 3. Which member did a given session land on?
diagnose sys session list | grep -E 'policy|sdwan'

Health Check(M365-Health):
Seq(1 wan1): state(alive), packet-loss(0.000%) latency(22.140), jitter(7.911) sla_map=0x1
Seq(2 wan2): state(alive), packet-loss(0.000%) latency(18.302), jitter(3.144) sla_map=0x1
Seq(3 ipsec-MPLS): state(alive), packet-loss(0.000%) latency(8.011), jitter(1.022) sla_map=0x1

If a member shows state(dead) or sla_map=0x0, that's your culprit — the rule won't pick that member until probes recover. If all members are dead, your probe target is the problem (firewall rule blocking 8.8.8.8, ISP DNS hijacking your health-check URL).

ADVPN vs SD-WAN — when which?

This is a high-level L3 question. Both ADVPN and SD-WAN solve "smart overlay across multiple paths", but they live at different layers. ADVPN is the transport — it builds a dynamic mesh of IPsec tunnels so spokes can shortcut through each other instead of hairpinning via HQ. SD-WAN is the steering brain — it chooses which of those tunnels (or which raw internet member) a session uses based on live SLA. Real production setups run SD-WAN on top of ADVPN: ADVPN gives many encrypted paths; SD-WAN picks the best one per app per moment.