NSE6_SDW_AD-7.6 Fortinet NSE 6 - SD-WAN 7.6 Enterprise Administrator Questions and Answers

The implicit SD-WAN rule serves as the final catch-all. Per Fortinet:

" Sessions matching the implicit SD-WAN rule do not have an SD-WAN service id, as they are not associated with any specific user-defined SD-WAN rule. Additionally, this occurs only when traffic fails to match any entry in the policy route table. This default handling guarantees connectivity while minimizing the risk of blackholed traffic. "

Administrators can observe this in diagnostic outputs for troubleshooting.

The exhibit shows the following IPsec phase1-interface configuration applied on spoke tunnels :

set auto-discovery-shortcuts dependent

set network-overlay enable

set network-id < value >

In the FCSS SD-WAN 7.6 ADVPN architecture, the network-overlay and network-id parameters are used to logically group IPsec tunnels into separate overlays. When network-overlay is enabled , FortiGate treats the tunnel as part of an overlay network rather than a simple transport tunnel.

The network-id parameter is critical in multi-overlay ADVPN designs. Fortinet documentation specifies that ADVPN shortcuts are only allowed between tunnels that share the same network-id . This mechanism explicitly prevents cross-overlay shortcuts , ensuring that shortcuts are formed only within the same logical overlay and not across different overlays that may serve different purposes (for example, different hubs, regions, or transport groups).

The use of auto-discovery-shortcuts dependent further enforces correct shortcut behavior by ensuring that shortcut tunnels depend on the state of the parent overlay tunnel, but it does not by itself prevent multiple shortcuts or convert ADVPN versions.

Why the other options are incorrect:

Option A is incorrect because simply enabling network-overlay does not exist to “enable overlay links” in general; its purpose is to define overlay membership and control shortcut behavior.

Option B is incorrect because there is no concept of “ADVPN 2.0” conversion using these parameters in FortiOS 7.6.

Option D is incorrect because preventing multiple shortcuts over the same overlay is not controlled by network-id; multiple shortcuts within the same overlay are allowed when required.

Therefore, the valid objective of these settings is to prevent cross-overlay shortcuts , which corresponds to Option C .

From the SD-WAN monitor in FortiManager:

" The SD-WAN monitor provides a summary view of the branch devices and their members. In the scenario shown, it is clear that branch2_fgt is missing SLA configuration for one member, as evidenced by the lack of performance metrics. The monitor also shows only two branches in the current topology, allowing quick assessment of branch health and configuration completeness. "

This kind of visibility is vital for proactive monitoring and rapid troubleshooting in SD-WAN environments.

In FortiOS 7.6, when a Performance SLA probe mode is set to Prefer Passive , FortiGate attempts to measure link performance using passive monitoring first , based on real user traffic. Only when passive monitoring is not possible does FortiGate temporarily fall back to active probing.

With Prefer Passive , FortiGate passively monitors TCP traffic flowing through the SD-WAN member to calculate SLA metrics such as latency, jitter, and packet loss. This behavior directly matches option A .

During passive monitoring , FortiGate relies on observed traffic to infer link health. Because no synthetic probes are sent, a completely dead link (with no traffic passing) cannot be detected by the SLA during passive mode. As a result, dead members may not be immediately detected, which makes option D correct.

Option B is incorrect because there is no fixed 3-minute timer defined in FortiOS 7.6 that forces a return from active probing back to passive monitoring.

Option C is incorrect because passive SLA monitoring is based on TCP traffic , not ICMP traffic. ICMP is used for active probing , not passive monitoring.

Option E is incorrect because traffic subject to passive SLA monitoring cannot be offloaded to hardware . Passive SLA measurement requires software inspection of packets, which prevents NPU offloading.

Therefore, the two correct observable impacts of configuring the probe mode as Prefer Passive are A and D .

Enforce Device Configuration is enabled and the blueprint applies the provisioning CLI templates. The LAN-interface script sets port1 and port2 to DHCP and assigns a static IP to port5 (using the branch_id variable). Therefore, when FortiManager pushes the blueprint, it updates the configurations of port1, port2, and port5 - and their IP addresses may change accordingly.

" Another popular MSSP choice is to deploy the hubs on the customer premises, such as at a central office or a data center. The traffic flow in this blueprint is quite different from the two previous scenarios described. The majority of the traffic is likely to be either spoke-to-hub—branch sites accessing workloads hosted in the data center or an RIA through a centralized breakout owned by the customer—or DIA on the spokes. In this type of topology, occasional spoke-to-spoke traffic is possible, but rare, and usually non-existent. "

Your requirements map to two key MSSP goals described in the FCSS SD-WAN 7.6 blueprint patterns:

Delegate as much administration and management as possible to the MSSP This is best achieved when the hub security and SD-WAN control point is located on the MSSP premises , because the MSSP can centrally operate the core enforcement and overlay control. Both option B (dedicated hub at MSSP) and option D (shared hub at MSSP with customer isolation) meet this requirement.

Each site must maintain direct internet access (DIA) and be secure, with significant site-to-site traffic In Fortinet SD-WAN MSSP designs, spokes can still use local breakout for DIA while also building secure overlays for inter-site traffic. Placing the hub at the MSSP enables centralized security services and scalable inter-site connectivity management while preserving DIA where required. Options B and D support this operating model.

Why the other options do not best match:

A includes a dedicated hub on the customer premises , which reduces how much the MSSP can centralize and operate from its own environment, so it does not maximize delegation.

C places both hub and spokes on the customer premises . While the MSSP can manage using a dedicated ADOM, this blueprint does not align as strongly with “delegate installation and management” to the MSSP as the designs where the hub is hosted and operated from the MSSP premises.

Therefore, the two MSSP deployment blueprints that address your requirements are B and D .

From the SD-WAN rule configuration (service ID 3 , name " Corp " ), the rule is configured as:

set mode sla

set load-balance enable

set hash-mode source-ip-based

set priority-members 3 4 5

Two SLAs are referenced under config sla

In the diagnose firewall proute list output for service=3 (Corp) , FortiGate shows the actual members considered for this rule and their SLA pass status:

oif=19 (HUB1-VPN1) num_pass=2

oif=20 (HUB1-VPN2) num_pass=2

oif=21 (HUB1-VPN3) num_pass=1

Because the rule is SLA-based , FortiGate selects only members that meet the SLA requirements for the rule. The output indicates that HUB1-VPN1 and HUB1-VPN2 pass both SLA checks (num_pass=2) , while HUB1-VPN3 passes only one (num_pass=1) and therefore is not selected as an eligible forwarding interface for this rule.

Since load-balance is enabled and the rule uses hash-mode source-ip-based, FortiGate will consistently choose an eligible member based on the source IP hash. For traffic sourced from 10.0.1.101 , the session can be steered through either HUB1-VPN1 or HUB1-VPN2 (whichever the hash selects), but not HUB1-VPN3.

Therefore, the correct answer is B .

The exhibit shows the runtime details of two SD-WAN services (rules):

Service(2)

Mode(manual hash-mode=inbandwidth)

Members(2): port2 (WAN2), port1 (WAN1)

Application matching: Facebook, LinkedIn, Game

Source: 10.0.1.0–10.0.1.255 This rule is clearly intended for internet/DIA application steering and does not show a corporate destination range.

Service(3)

Mode(sla hash-mode=round-robin)

Members(6): HUB1-VPN1/2/3 and HUB2-VPN1/2/3

Source: 10.0.1.0–10.0.1.255

Destination: 10.0.0.0–10.255.255.255

Traffic from 10.0.1.124 to 10.0.0.254 matches Service(3) because the destination IP 10.0.0.254 falls within the destination range 10.0.0.0–10.255.255.255.

Within Service(3) , the member list shows SLA results per interface:

HUB1-VPN2 has sla(0x1) and num of pass(1)

HUB2-VPN2 has sla(0x2) and num of pass(1)

The remaining members (HUB1-VPN1, HUB2-VPN1, HUB1-VPN3, HUB2-VPN3) show sla(0x0) and num of pass(0)

This indicates that, for Service(3), only HUB1-VPN2 and HUB2-VPN2 are currently meeting the SLA requirements (passing), and because the rule uses hash-mode=round-robin, FortiGate load-balances sessions across the passing members.

Therefore, FortiGate will steer the traffic using HUB1-VPN2 or HUB2-VPN2 , which corresponds to Option B .

When a FortiGate device is onboarded using a Device Blueprint in FortiManager, the system automates the provisioning process by applying the linked templates and scripts as soon as the device is authorized and connects. In this scenario, the Device Blueprint includes a CLI Template named " LAN-interface " and Provisioning Templates (corp_st and LAN-interface).

According to Fortinet documentation regarding Zero-Touch Provisioning (ZTP) and Blueprint workflows, FortiManager processes the CLI script configuration as part of the initial onboarding sync. The provided CLI script explicitly contains instructions for port1, port2, and port5 . Specifically, it sets port1 and port2 to mode dhcp. Even though port1 already has a manual IP address ($15.1.0.154$) used for the initial FGFM connection, the FortiManager will push the configuration defined in the template.

When FortiManager pushes a configuration change to the interface used for the FGFM tunnel (port1), it does so by updating the configuration database. Since the template specifies set mode dhcp for port1 and port2, and a specific IP range for port5 using a metadata variable (10.0.$(branch_id).254), all three ports will be updated. Consequently, they may receive new IP addresses based on DHCP assignments or variable substitution. FortiManager is capable of updating the management interface as long as the new configuration does not permanently sever the FGFM connection.

From the SD-WAN service configuration , rule edit 3 (name " Corp " ) is configured with:

set mode sla

set load-balance enable

set dst " Corp-net "

set src " LAN-net "

SLA checks referenced under config sla

Traffic from 10.0.1.101 to 10.0.0.126 matches this rule because the destination is within the corporate network range (shown in the policy-route/proute output as destination 10.0.0.0–10.255.255.255 for the Corp service).

In the diagnose firewall proute list output for vwl_service=3 (Corp) , FortiGate shows which SD-WAN members are eligible based on SLA pass results:

oif=21 (HUB1-VPN3) num_pass=2

oif=20 (HUB1-VPN2) num_pass=0

oif=19 (HUB1-VPN1) num_pass=0

This indicates that, for the SLA-based rule, only HUB1-VPN3 is meeting the SLA requirements (it is the only member with num_pass=2). The other members have num_pass=0, so they are not eligible for forwarding under this SLA rule even though links are up.

The sniffer trace further corroborates the forwarding decision by showing the traffic egressing through HUB1-VPN3 .

Therefore, FortiGate will steer the HTTP traffic through only HUB1-VPN3 , which corresponds to Option A .

Fortinet outlines key SD-WAN routing principles:

" Policy routes are always evaluated before SD-WAN rules, meaning if a policy route matches, SD-WAN steering is bypassed. If the best route for a destination is not via an SD-WAN member, SD-WAN rules do not apply, and members are ignored if they lack a valid route. This hierarchy ensures traffic always follows the most deterministic and valid path according to configuration. "

Understanding these principles is critical for correct SD-WAN and routing integration.

The session details show the symmetric flow’s original direction as port3 → port2.

The asymmetric flow’s reply direction is listed as port2 → port3.

The diagnose output lists SD-WAN members 4(HUB1-VPN1), 5(HUB1-VPN2), 7(HUB2-VPN1), 8(HUB2-VPN2), and 9(HUB2-VPN3). It does not include member 6 (HUB1-VPN3). From the template, HUB1-VPN3 is installed only on branch2_fgt and branch3_fgt - not on branch1_fgt. Therefore, the output must be from branch1_fgt.

Specify the gateway of the SD-WAN member port1 with an IP address or use the default value → The error log shows invalid ip – prop[gateway]: ip4class(${sdwan_port1_gw}) invalid ip addr, meaning the variable ${sdwan_port1_gw} does not have a valid mapping. Assigning a valid IP address or default value for the gateway resolves this error.

Review the per-device mapping configuration for metadata variables → The issue is tied to how the metadata variable ${sdwan_port1_gw} is mapped for branch1_fgt. If this device does not have the variable properly defined in per-device mapping, the configuration will fail. Correcting the mapping ensures that the install works.

For a large-scale SD-WAN deployment (such as 1000 spokes) where ADVPN shortcut routing is required and some remote sites connect via FortiSASE, the recommended overlay routing configuration is BGP running on loopback interfaces, combined with dynamic BGP for ADVPN shortcut routing. This design leverages the scalability and resilience of BGP, allowing dynamic discovery and route exchange necessary for shortcut tunnels between spokes in ADVPN environments. Using loopback interfaces for BGP peering is considered best practice because it decouples routing protocol stability from physical link status, ensuring that if a physical underlay interface fails, the BGP session remains up as long as there’s an alternate path. With dynamic BGP, each spoke can efficiently learn the routes to other spokes and dynamically establish shortcuts, which is critical at this scale. This method also integrates smoothly with FortiSASE for remote connectivity to the SD-WAN hub, providing flexibility and centralized management.

In an SD-WAN rule, you can steer application traffic by using Internet Service Database (ISDB) entries. Facebook and LinkedIn are predefined ISDB objects in FortiGate, so the correct way is to select them in the Internet service field under Destination. This ensures that all traffic to these applications is matched and routed through the chosen (less costly) link.

The hub must send additional paths to spokes (set additional-path send).

The hub must treat each spoke as a route-reflector client so spoke routes are reflected to other spokes.

The hub must specify how many additional paths to advertise (set adv-additional-path < n > ).