NSE7 Part 5: Enterprise SD-WAN Fundamentals: DIA and Monitoring

16 August 2026 NSE7Fortinet

NSE4 Part 9 covers building an SD-WAN configuration: zones, members, performance SLAs, and rules. This post assumes that’s already familiar and stays at the level the blueprint’s “Deploy an enterprise SD-WAN setup” task actually sits at: architecture components, direct internet access as a specific design pattern with its own best practices, and how you tell whether a live SD-WAN deployment is actually working.

SD-WAN’s Basic Components, Restated as Architecture

Four pieces, and the exam cares about the relationship between them more than any one in isolation:

  • Zones group physical or virtual WAN interfaces that share a role, typically one zone per transport type (MPLS, broadband, LTE) or, in a hub-and-spoke ADVPN design, a zone for underlay members and a separate zone for overlay/tunnel members.
  • Members are the individual interfaces inside a zone, each with a configured or auto-detected cost and, critically, a performance SLA binding.
  • Performance SLAs define what “healthy” means for a member: a probe (ping, HTTP, TWAMP, DNS) against a target, with latency/jitter/packet-loss thresholds. A member without a bound SLA has no health signal SD-WAN can act on, and rules referencing that member’s health will behave unpredictably.
  • Rules (SD-WAN rules, formerly “SD-WAN rules” versus the older “load balancing” nomenclature) decide which member or members carry a given traffic class, evaluated top-down. Part 10 of this series goes deep on rule design specifically; this post treats rules only as the fourth architecture component that everything above feeds into.

Direct Internet Access: Topologies

DIA means a branch or spoke site breaks out to the internet locally rather than backhauling all internet-bound traffic to a hub or data center first. The blueprint separates this into its own named task, which reflects how central the DIA-versus-backhaul decision is to SD-WAN design generally; this site’s earlier local-breakout post covers a worked multi-VRF guest Wi-Fi example, while this section treats the topology choice itself.

Three shapes come up repeatedly in the blueprint’s framing:

Full DIA: every internet-bound flow breaks out locally at the branch, full stop. Lowest WAN cost and lowest latency for internet-bound SaaS traffic, but every branch inherits full responsibility for its own internet-edge security posture (UTM, web filtering, IPS all need to run at the branch, not just centrally).

Selective/partial DIA: internet-bound traffic for approved, typically well-known SaaS destinations (Microsoft 365, specific SaaS IP ranges via ISDB) breaks out locally, while everything else, including anything security policy doesn’t have high confidence in, backhauls to a hub for centralized inspection. This is the shape most enterprise SD-WAN designs actually land on, because it captures most of DIA’s latency benefit (the traffic that actually benefits most from local breakout: real-time SaaS, video, voice) without pushing full internet-edge security responsibility onto every branch.

No DIA / full backhaul: every flow, internet-bound or not, routes to a hub first. Highest WAN cost and worst SaaS latency, but the simplest security model, since only the hub’s egress needs full UTM stack and only the hub’s internet posture needs auditing. Still a legitimate choice for compliance-heavy verticals where centralized inspection of literally everything is a hard requirement rather than a preference.

A few settings matter enough to specific DIA behavior that the exam treats them as their own facts rather than general SD-WAN knowledge:

Local-out traffic (traffic originating from the FortiGate itself, such as DNS queries, FortiGuard updates, and NTP) needs its own explicit consideration in a DIA design. By default local-out traffic follows the regular routing table, which in a hub-backhaul design can mean a branch FortiGate’s own management traffic makes an unnecessary round trip to the hub and back for something as simple as a FortiGuard rating lookup. set source-ip and SD-WAN rules with internet-service-app-ctrl or explicit local-out rule matching let local-out traffic use local DIA even when general traffic backhauls.

Health check target selection for internet-bound SLAs matters more than it sounds like it should: probing a single, potentially unreliable internet host as the SLA target for a DIA member means that member’s health status is only as good as that one host’s own uptime, independent of whether the branch’s actual internet circuit is fine. Fortinet’s own guidance (and the exam’s framing) is to probe multiple, geographically-diverse, high-reliability targets and require SLA failure across the set, not a single target, before marking a member down.

Application steering criteria matter more under DIA than backhaul, because a misrouted flow under DIA doesn’t just take a suboptimal path, it can take a path that bypasses required inspection entirely if the SD-WAN rule’s matching criteria are looser than intended. A DIA rule that’s supposed to steer only well-known SaaS traffic locally but is written against an overly broad ISDB category will send more than intended around the security stack a backhaul-and-inspect design assumed was in the path.

SD-WAN Monitoring

The blueprint’s monitoring task is deliberately practical: not “how do you configure SD-WAN” but “given a live deployment, how do you tell what it’s actually doing right now.” Three surfaces:

SD-WAN Widgets

The GUI’s SD-WAN monitor (Network > SD-WAN > SD-WAN Monitor, or the dashboard widget) shows per-member status, current SLA measurements against configured thresholds, and which members are currently selected by which rules. This is the first place to look when troubleshooting “traffic isn’t going where I expect,” because it answers the health-status half of the question before you go anywhere near rule logic.

SD-WAN Traffic Distribution and Member Health

diagnose sys sdwan health-check status <sla-name> returns the live measured latency/jitter/loss per member against that SLA’s configured thresholds, which is the CLI equivalent of the widget and the command you actually reach for during a live troubleshooting session rather than the GUI. diagnose sys sdwan sla-log <sla-name> shows historical SLA measurement, useful for the “was this actually failing an hour ago or is this a new problem” question.

diagnose sys sdwan health-check status hub1-sla
diagnose sys sdwan service
diagnose sys sdwan sla-log hub1-sla

diagnose sys sdwan service lists every configured SD-WAN rule and the currently-selected member for each, which is the direct answer to “which path is this rule actually using right now” without needing to reason through the rule logic manually.

SD-WAN Traffic Logs and Events

Traffic logs (config log ... set sdwan enable or the equivalent GUI logging toggle) can be configured to record which SD-WAN member and rule handled each logged session, turning ordinary traffic logs into an audit trail of SD-WAN steering decisions over time, not just a snapshot of current state. Event logs record member up/down transitions and rule reevaluation events, which matter for the “how many times did this circuit actually flap today” question that a live SLA snapshot alone can’t answer; FortiAnalyzer’s role in aggregating this across a fleet is worth reading alongside this section for the observability picture at scale rather than a single box.

The Design Judgment This Domain Is Testing

Every piece of this post exists to answer one exam-shaped question: given a described branch requirement (cost sensitivity, latency sensitivity, compliance posture, existing WAN contracts), which DIA shape fits, and once it’s deployed, which specific command or widget confirms it’s actually behaving that way. Getting the DIA topology decision right on paper and then being unable to confirm it in a live diagnostic session is exactly the gap this domain is built to catch.

Part 6 moves from a single site’s SD-WAN configuration to managing many of them at once: zero-touch provisioning and SD-WAN Manager on FortiManager.