NSE6_SDW_AD-7.6 Practice Questions

The FortiManager SD-WAN monitor Map View explicitly indicates a total of two monitored devices in the top right corner, consisting of branch1_fgt and branch2_fgt. Furthermore, branch2_fgt displays six IPsec VPN hub interfaces. The green checkmarks signify that five tunnels are operationally up and meeting SLA targets. The orange 'X' icon on HUB1-VPN2 represents a warning state, indicating the tunnel is operationally up but currently failing its configured SD-WAN SLA targets. A down interface displays a red down-arrow.

A: Hub devices can be displayed in Map View if configured with geographic coordinates; the Template View is not strictly required.

B: The orange warning icon indicates the interface is operationally up but failing its SLA targets, not that the SLA is missing.

Fortinet, Inc. FortiManager 7.2 Administration Guide. Document ID: 02-720-795212-20230216. Section: SD-WAN Monitor map view.

Fortinet, Inc. Fortinet NSE 7 - SD-WAN 7.2 Study Guide. Section: Centralized Management, SD-WAN Monitoring Status.

Passive WAN health measurement evaluates link quality using live user traffic rather than relying on synthetic active probes. Because it requires the analysis of packet acknowledgments, sequence numbers, and retransmissions to accurately calculate latency, jitter, and packet loss, the FortiGate exclusively utilizes TCP traffic. In the provided exhibits, the SD-WAN service rule explicitly matches Facebook and YouTube traffic (internet-service-app-ctrl 15832 31077) and enables passive measurement. Consequently, the system calculates the overall health and performance metrics by continuously averaging the data derived specifically from the TCP sessions of these matched applications passing through the assigned members.

Option C: Incorrect because passive measurement operates at the Transport layer (TCP) by tracking sequence and acknowledgment numbers; therefore, payload encryption (like HTTPS/TLS) does not prevent performance measurement.

Option D: Incorrect because passive measurement does not mark a link as dead when traffic stops. Without active user traffic, it simply ceases to update metric values, maintaining the last state.

[1] Fortinet, Inc. "FortiOS 7.2 Administration Guide," Section: SD-WAN > Health Check > Passive health checks. Document ID: FG-OS-72-ADMIN.

[2] Fortinet, Inc. "FortiOS 7.2 Administration Guide," Section: SD-WAN > SD-WAN Rules > Configuring SD-WAN rules with passive measurement. Document ID: FG-OS-72-ADMIN.

For large-scale SD-WAN deployments involving a high number of spokes (1000 in this case), a scalable routing design is critical. The recommended Fortinet best practice is to use BGP peering over loopback interfaces. This approach significantly reduces the number of BGP neighbors the hub must manage, as each spoke establishes only one BGP session with the hub, regardless of the number of overlay tunnels. ADVPN relies on BGP to exchange routes between sites. When a spoke learns a route to another spoke via the hub, this information triggers the dynamic creation of a direct spoke-to-spoke shortcut tunnel, which is the essence of dynamic BGP for ADVPN shortcut routing. This design is also fully compatible with FortiSASE integration.

B: IPsec phase2 selectors define static traffic flows for a tunnel and are not used for the dynamic route exchange and on-demand tunnel creation required by ADVPN.

C: The "BGP per overlay" method is not scalable for 1000 spokes. It would require the hub to maintain a separate BGP session for each spoke on each overlay, leading to excessive resource consumption.

D: While BGP next-hop convergence is a feature used in SD-WAN, the core configuration method proposed, "BGP per overlay," is not suitable for a deployment of this size due to scalability limitations.

1. Fortinet SD-WAN Architecture Guide 7.6.1, Routing design > BGP on loopback, Page 51: This section explicitly contrasts "BGP per overlay" with "BGP on loopback," stating, "For large scale deployments, it is recommended to use the BGP on loopback design to reduce the number of BGP neighbors on the hub." It provides a clear example showing that for 1000 spokes and 2 overlays, BGP on loopback requires 1000 neighbors versus 2000 for BGP per overlay.

2. FortiOS Administration Guide 7.6.1, SD-WAN > ADVPN, Page 1019: This section describes the ADVPN mechanism, explaining, "BGP is used to advertise the networks behind the spokes... When a spoke wants to communicate with another spoke, the hub forwards the BGP information to the spoke, and the spoke uses that information to establish a direct IPsec tunnel (a shortcut) to the other spoke." This confirms the use of dynamic BGP for shortcut routing.

3. FortiSASE Administration Guide (24.1), Configuration > Connectors > Secure Private Access > FortiGate SD-WAN Integration: This guide details the integration of on-premise FortiGate SD-WAN with FortiSASE. The configuration examples consistently show the use of an IPsec tunnel with BGP for routing between the on-premise hub and the FortiSASE security PoP, reinforcing that BGP is the standard routing protocol for such integrations. A scalable BGP design like "BGP on loopback" is essential for the on-premise portion of this architecture.

In the FortiOS GUI, the color of the icon next to an SD-WAN zone serves as a visual indicator of its member status. A green icon signifies that the SD-WAN zone contains at least one assigned member interface. Conversely, a red icon denotes that the zone is completely empty and currently has no members assigned to it. In the provided exhibit, the overlay-factories zone displays a red icon, similar to the empty default virtual-wan-link zone. Based on this standard Fortinet GUI behavior, we can definitively conclude that the overlay-factories zone contains no members.

Option A: The exact distribution of the 7 total members across the zones is not visible; we cannot definitively deduce that the underlay zone contains exactly three members.

Option B: The virtual-wan-link zone is a built-in, implicit system zone in FortiOS that serves as the default SD-WAN zone and cannot be deleted by the user.

Option D: You cannot definitively conclude that this move is possible without verifying first whether the HUB1-VPN3 interface is individually restricted by existing firewall policy references.

Fortinet, FortiOS 7.0 Administration Guide, Section: "SD-WAN Zones" (Document ID: 03-700-664495-20210511).

Fortinet, NSE 7 SD-WAN 7.0 Study Guide, Module 2: "SD-WAN Configuration", Paragraph: Zone and Member GUI Indicators.

The FortiOS SD-WAN routing logic follows a specific order of operations. First, the device checks for a matching policy route. If one is found, the SD-WAN rules are bypassed. If no policy route matches, the device then evaluates SD-WAN rules. However, SD-WAN rules are only considered if the best route to the destination, as determined by the Forwarding Information Base (FIB), is through an SD-WAN member interface. If the best route is not via an SD-WAN member, the rules are skipped. Finally, when an SD-WAN rule is being processed, it will only consider member interfaces that have a valid, active route to the packet's destination.

A. SD-WAN rules have precedence over the standard routing table, which includes directly connected routes.

C. SD-WAN rules are evaluated before static routes in the standard routing table lookup process.

1. Fortinet FortiOS 7.6.0 SD-WAN Administration Guide, SD-WAN routing, Page 16: "FortiOS checks for a matching policy route first. If one is found, the device routes the packet according to the policy route's settings. If no matching policy route is found, FortiOS checks for a matching SD-WAN rule." This supports option B.

2. Fortinet FortiOS 7.6.0 SD-WAN Administration Guide, SD-WAN routing > Implicit rule, Page 17: "If the best route to the destination is not an SD-WAN member, SD-WAN rules are skipped and the packet is routed based on the routing table." This supports option D.

3. Fortinet FortiOS 7.6.0 SD-WAN Administration Guide, SD-WAN routing, Page 16: "For a member to be selected to route traffic, it must have a route to the destination." This supports option E.

4. Fortinet FortiOS 7.6.0 SD-WAN Administration Guide, SD-WAN routing, Page 16: The documented packet flow shows SD-WAN rules are checked after policy routes but before the routing table lookup (which includes static and connected routes), making options A and C incorrect.

For FortiGate SD-WAN to successfully steer traffic, three core components must be configured. First, physical or virtual Interfaces must be configured and added as members to the SD-WAN zone. Second, Routing, typically static routes such as default routes, must be in place for each member interface to provide reachability to the next-hop gateways. Finally, Firewall policies are required to permit the traffic, with the outgoing interface set to the SD-WAN virtual interface. These policies are what actually direct the traffic to the SD-WAN engine for path selection based on the configured SD-WAN rules. Without these three elements, traffic cannot be processed or steered by the SD-WAN feature.

C. Security profiles: These are applied to firewall policies for traffic inspection. While crucial for security, they are not a prerequisite for the SD-WAN steering mechanism itself to function.

D. Traffic shaping: This feature manages bandwidth and prioritizes traffic. It is complementary to SD-WAN and can be applied via firewall policies, but it is not required for path selection.

1. Fortinet FortiOS 7.6.0 SD-WAN Administration Guide, Page 13, "Basic configuration". The guide explicitly lists the required steps: "1. Configure the SD-WAN interface and members. 2. Configure SD-WAN rules. 3. Configure a static route. 4. Configure a firewall policy." This directly confirms the necessity of Interfaces (members), Routing (static route), and Firewall policies.

2. Fortinet FortiOS 7.6.0 Administration Guide, Page 710, "Policies". This section details firewall policy configuration, showing that the source, destination, and outgoing interface (which would be the SD-WAN interface) are mandatory fields, while security profiles are optional additions.

3. Fortinet FortiOS 7.6.0 Networking Guide, Page 10, "Static routing". This document explains the fundamental role of static routes in directing traffic to a next-hop router. For SD-WAN, a route is required for each member interface to establish reachability, which is a prerequisite for the SD-WAN logic to select it as a valid path.

In FortiOS, the Internet Service Database (ISDB) contains dynamically updated IP addresses, ports, and protocols for well-known cloud applications and internet services. The exhibit shows the SD-WAN rule configuration GUI where the "Internet service" field is actively available under the Destination parameters. To steer traffic specifically for Facebook and LinkedIn, the administrator can simply select these services directly from the ISDB drop-down list within the "Internet service" field. This method relies on predefined destination IP ranges rather than Layer 7 application control, providing an efficient and immediate way to route traffic for major platforms using the currently available GUI options.

A: A special license is not required to unlock destination fields in the GUI. ISDB definitions are natively integrated into FortiOS and updated via standard FortiGuard services.

C: There is no independent "feature visibility" setting specifically named "applications as destinations of the SD-WAN rule" to toggle this behavior.

D: Standalone FortiGate devices are fully capable of utilizing both internet services and applications as routing destinations within SD-WAN rules.

Fortinet, Inc. FortiOS 7.2 Administration Guide. Section: "SD-WAN Rules" -> "Creating SD-WAN rules". Document ID: 01-720-749449-20230620. (Details the configuration steps for specifying destinations using the Internet Service Database in SD-WAN rules).

Fortinet, Inc. FortiOS 7.2 Administration Guide. Section: "Policy and Objects" -> "Internet Service Database". (Explains how the ISDB maps well-known public services like Facebook and LinkedIn to specific IP addresses and ports for routing and policy enforcement).

In FortiOS, specific administrative features are hidden by default within the Graphical User Interface (GUI) to simplify the administrative experience. To route SD-WAN traffic based on specific applications (application steering), the FortiGate relies on its Application Control engine. If the "Application Control" feature is disabled in the GUI visibility settings, the option to select an application as a destination in an SD-WAN rule will not appear. An administrator must navigate to System > Feature Visibility and toggle "Application Control" on. Once enabled, the "Application" and "Application Group" selection fields will dynamically appear in the SD-WAN rule configuration page.

A. Application-based routing is fully supported and highly recommended in Direct Internet Access (DIA) setups to intelligently steer specific SaaS or web applications over optimal ISP links.

B. FortiGate natively supports the configuration of application-based SD-WAN rules in both the Command Line Interface (CLI) and the GUI, provided the feature is set to visible.

C. You do not need to enable GUI feature visibility via the CLI. The standard and intended method to expose hidden GUI elements is through the System > Feature Visibility GUI menu.

Fortinet, Inc. FortiOS 7.2 Administration Guide. Section: System > Feature Visibility. (Details the hiding and exposing of advanced security profiles, including Application Control, in the web interface).

Fortinet, Inc. FortiOS 7.2 Administration Guide. Section: SD-WAN > SD-WAN Rules. (Documenting the prerequisite of enabling Application Control visibility to utilize application steering in priority rules).

The placement of the SD-WAN hub is determined by the network's traffic "center of gravity." When an MSSP manages the infrastructure, the decision to place the hub at the customer premises rather than the MSSP's data center is driven by traffic efficiency and performance. If the majority of traffic is internal to the customer's network—either between branches (spoke-to-spoke) or from branches to a central corporate data center—placing the hub at the customer's data center is the most logical design. This co-locates the hub with the destination resources, minimizing latency and avoiding the inefficient routing of internal traffic through the MSSP's external infrastructure.

A. This scenario, requiring Secure Internet Access (SIA) with a centralized breakout, is a primary reason to host the hub within the MSSP infrastructure, not the customer's.

C. This option is too general. The optimal path for VoIP traffic depends on its destination (e.g., another branch, a corporate PBX, or a cloud service), which is better addressed by options B and D.

1. Fortinet SD-WAN Design and Deployment for MSSPs Guide:

In the section on "Hub deployment models," the guide explicitly contrasts the two main scenarios. It states, "Hub in customer data center: This model is suitable for customers who have a large amount of traffic between their branches and their data center, or between the branches themselves. Placing the hub in the customer's data center reduces latency and improves performance for this traffic." This directly validates options B and D.

Conversely, it notes, "Hub in MSSP PoP: This model is suitable for customers who require centralized internet breakout with security services provided by the MSSP," which invalidates option A.

2. Fortinet SD-WAN Architecture Guide 7.6:

Chapter: "Deployment Topologies," Section: "Hub-and-Spoke." The guide describes the hub as the central point where services and applications are hosted. It states, "The hub is typically a FortiGate located in a data center that provides spokes with access to corporate resources." This supports the principle that if the corporate resources (data center) are the main traffic destination, the hub should be located there (Option D). It also explains that spoke-to-spoke traffic traverses the hub, making its location critical for performance when that traffic volume is high (Option B).

When traffic does not match any explicitly configured SD-WAN rule, it is processed by the implicit SD-WAN rule (ID 0). The function of this rule is to revert to standard routing behavior. Consequently, the session created for this traffic will have an sdwanserviceid of 0, which can be interpreted as no specific user-defined SD-WAN service. Furthermore, the FortiGate session is marked with specific flags: vwldefault to signify it is handled by the default virtual-wan-link logic (i.e., the routing table), and maydirty, which indicates the session can be re-evaluated if the underlying routing information changes.

B. The implicit rule defers to the routing table; it does not perform load balancing itself. ECMP load balancing only occurs if the routing table has multiple equal-cost routes for the destination.

C. Traffic is routed based on the single best path in the routing table (or ECMP paths if available), honoring administrative distance and metrics. It is not distributed across all available static routes.

D. The SD-WAN rule check occurs before the policy route check. Matching the implicit SD-WAN rule causes the packet to be passed to the routing engine, which then checks policy routes.

1. FortiOS SD-WAN Administration Guide 7.6.0, Page 33, Section: Implicit rule: "The implicit rule is the last rule in the list. It has a Rule ID of 0... Traffic that does not match any other SD-WAN rule is handled by the implicit rule. The implicit rule forwards traffic based on the best route in the routing table." This supports the core behavior and explains why options B and C are incorrect. The sdwanserviceid in session diagnostics corresponds to this Rule ID, confirming option A.

2. Fortinet FortiOS 7.2 Study Guide, Page 319, Section: SD-WAN Troubleshooting: "If a session matches the implicit SD-WAN rule, the output of the diagnose sys sdwan session list command shows the rule ID as 0." This directly validates answer A.

3. Fortinet Knowledge Base Article FD50232, Technical Tip: FortiGate session flags: This article describes various session flags. The vwldefault flag is specifically associated with sessions matching the implicit SD-WAN rule. The maydirty flag indicates the session is subject to re-evaluation, which is the case for sessions dependent on the dynamic state of the routing table. This confirms option E.