FortiGate SD-WAN: Steering by Intent, Health, and Application
SD-WAN becomes much easier to reason about when it is treated as a traffic-selection system rather than a smarter default route. FortiGate can combine multiple WAN members, health measurements, application or destination matching, and steering strategies so different traffic classes choose different paths. The design therefore has two distinct questions: which paths are usable right now, and which usable path best fits this traffic?
For candidates working through the current FortiOS 7.6 Administrator exam, SD-WAN is best understood through the networking and operational decisions behind that chain. A correct SD-WAN rule can still fail if routing, firewall policy, member configuration, or performance SLA assumptions are wrong.
Within the wider Fortinet certification ecosystem, SD-WAN expands into deeper design and troubleshooting topics. For day-to-day administration, however, the most useful mental model is member, health, match, strategy, policy, and route.
This prevents a common mistake: treating every WAN circuit as interchangeable. An MPLS path, broadband circuit, DIA link, and cellular backup can differ in latency, loss, cost, security expectation, and reachability. SD-WAN policy is valuable precisely because those differences can be expressed instead of hidden.
Members define the paths the system can choose
SD-WAN begins with member interfaces that represent candidate WAN paths. Each member has configuration and cost characteristics, but membership alone does not determine which traffic uses it. A path can exist and still be unsuitable for a particular application because of health, policy, or business intent.
Administrators should document what each member actually reaches. Some links provide public internet, some private WAN access, and some both through overlays. A rule that assumes every member can reach the same destination will produce confusing failures when the underlying path does not have equivalent routing.
Performance SLAs turn link status into application-relevant evidence
A link being electrically up does not mean it is good enough for the workload. FortiGate performance SLAs can measure characteristics such as latency, jitter, and packet loss against a target. Those measurements allow SD-WAN to distinguish an available link from an acceptable one.
The quality threshold should reflect the application. Voice, interactive sessions, bulk backups, and software downloads do not have the same sensitivity to delay or loss. One universal SLA can therefore be technically simple while making poor business decisions.
Rules identify the traffic before selecting the path
SD-WAN rules match traffic using criteria such as addresses, internet services, applications, DSCP values, or other information depending on design. More specific business traffic can be handled before generic internet traffic, just as a precise firewall rule usually belongs above a broad catch-all.
This is where “intent” becomes concrete. A collaboration application may prefer the lowest-latency link. A backup flow may prefer the lowest-cost path. A private application may be restricted to an overlay. The rule describes which traffic matters; the strategy describes how the path is chosen.
Steering strategies express different business priorities
FortiGate supports strategies that can prioritize best quality, cost, manual order, load balancing, or other selection behavior. None is universally correct. The strategy should match the traffic objective and the reliability of the measurements used to make the decision.
A low-cost strategy can reduce spend but may be inappropriate for a latency-sensitive workload. A best-quality strategy can improve user experience but may move traffic onto an expensive path more often. SD-WAN engineering is therefore a policy trade-off, not simply a feature toggle.
Application steering depends on classification quality
Application-aware rules can be powerful because they make routing follow the workload rather than only IP prefixes. They also inherit the limits of application identification. If the traffic cannot be classified reliably at the stage where the decision is made, the rule may fall back or behave differently than expected.
Administrators should test both known applications and the edge cases that share infrastructure, CDNs, or encrypted sessions. Application intent should not obscure the basic requirement that routing still needs a valid next hop and firewall policy still needs to permit and inspect the flow.
Firewall policy and SD-WAN policy solve different problems
SD-WAN decides which WAN path should carry the traffic. Firewall policy decides whether the traffic is permitted and which security controls apply. Conflating the two makes troubleshooting difficult because a steering failure and a security-policy failure can produce similar user symptoms.
Use separate evidence for each layer. Confirm the session matched the expected SD-WAN rule and member, then confirm the security policy and inspection. If different WAN zones need different controls, the firewall design should represent that intentionally rather than hoping the steering rule will imply security behavior.
Failover must be tested at the quality boundary, not only link-down
Pulling a cable proves that a physically failed link can be removed from service. It does not prove that the system responds correctly to rising latency, partial packet loss, DNS failure, or upstream reachability problems. Real incidents often degrade before the interface goes down.
Test the performance SLA thresholds and recovery behavior. Confirm which sessions move, which must reconnect, how long health decisions take, and whether returning to the preferred path causes instability. This broader troubleshooting approach is reinforced by Fortinet SD-WAN high-availability troubleshooting material, even though that older article targets a different exam generation.
Historical SD-WAN material is useful only when version context is clear
Concepts such as health checks, overlays, path selection, and application steering remain recognizable across Fortinet releases, but exact workflows change. An older Fortinet SD-WAN 7.2 discussion can help frame the architecture, but current FortiOS 7.6 behavior should be the source of truth for configuration and troubleshooting.
Version discipline matters because administrators often inherit designs built under earlier defaults. Upgrading the platform does not automatically mean the original rule order, SLA assumptions, or operational runbooks are still appropriate.
A good SD-WAN design can explain every path choice
The best test of an SD-WAN policy is whether an operator can explain why a particular session used a particular path at a particular moment. That explanation should name the traffic match, member health, selection strategy, firewall policy, and relevant route. If the answer is “SD-WAN decided,” the design is not observable enough.
This traceability also improves change control. When a new circuit or application is introduced, the team can predict which rule will match, what quality threshold applies, and what fallback behavior should occur. The change is evaluated against an existing decision model rather than added as another exception.
SD-WAN delivers value when path selection reflects business intent and current network conditions at the same time. The feature is not the intelligence by itself. The intelligence comes from the quality of the rules, health measurements, and operational assumptions administrators build around it.
Routing protocol interaction deserves explicit attention because SD-WAN does not operate in isolation from the routing table. BGP or OSPF can change which prefixes are reachable through an overlay, while SD-WAN rules influence which eligible member carries matching traffic. An operator should know whether a decision came from route availability, rule matching, or performance preference. Without that separation, a control-plane route withdrawal can be mistaken for an SLA failure.
Health-check targets must also represent the service being protected. Probing a public resolver may prove internet reachability while saying nothing about a private SaaS edge or datacenter application. Conversely, probing one internal server can mark a healthy internet circuit as failed when only that server is down. The target and protocol should answer the specific availability question the rule depends on.
Brownout testing is especially valuable. Introduce latency or packet loss gradually and observe when a path crosses the SLA threshold, when new sessions move, and whether the original path is selected again after recovery. If thresholds are too tight, ordinary jitter can cause path flapping. If they are too loose, users experience poor quality long before the system reacts.
Cost controls should be visible to application owners. A rule that moves traffic to a premium circuit during degradation may be exactly the right reliability decision, but it can have a measurable financial consequence. The network team should define which applications justify that cost and which can tolerate degraded service on the cheaper path. That makes SD-WAN policy a business-priority model instead of an opaque networking optimization.
Operational dashboards should show the same concepts used in design: member state, SLA measurements, rule matches, application classes, and path changes. When monitoring uses different labels from the policy model, incidents take longer because engineers must translate between views. A good implementation lets the operator move from a degraded application to the responsible SD-WAN rule and current member condition without reconstructing the topology from scratch.
Session persistence is another practical consideration. Existing sessions may stay on the member selected when they were created while new sessions follow a changed health decision. Operators should know whether an application opens many short connections or a few long-lived ones, because user experience during path changes can differ even when the same SD-WAN rule is operating correctly.
DNS can influence the traffic match as well. Cloud applications may resolve to changing endpoints or CDN ranges, while internet-service databases and application signatures can classify traffic differently from static address objects. If a rule depends on destination identity, validate how that identity is derived and how frequently it changes. Otherwise a rule can be correct on paper while missing a large fraction of the real workload.
When troubleshooting, preserve the member and SLA state at the moment of failure. A later healthy dashboard cannot explain why a session selected a poor path ten minutes earlier; historical measurements and logs are needed to reconstruct that decision.