FCSS_SDW_AR-7-4 Practice Questions

ADVPN 2.0 integrates the creation of on-demand shortcut tunnels directly into SD-WAN policy routing. The primary configuration change to enable ADVPN 2.0 on an existing ADVPN topology is to modify the SD-WAN rules on the branch (spoke) devices. Specifically, the advpn-shortcut option must be enabled within the SD-WAN rules that are intended to trigger the creation of a shortcut tunnel. This allows for granular, policy-based control over which traffic sessions can establish direct spoke-to-spoke tunnels, which is the core enhancement of ADVPN 2.0. The hub's IPsec configuration remains fundamentally the same.

A. Update the IPsec tunnel configurations on the hub: The hub's core IPsec configuration for auto-discovery does not change significantly between ADVPN 1.0 and 2.0. The primary change is on the branches.

C. Update the IPsec tunnel configuration on the branches: While the IPsec tunnel is used, the specific setting that enables ADVPN 2.0 functionality (advpn-shortcut) is configured within the SD-WAN rules, not the IPsec tunnel settings.

D. Delete the existing ADVPN configuration and configure ADVPN 2.0: This is incorrect. ADVPN 2.0 is an enhancement, and an existing ADVPN 1.0 deployment can be migrated by modifying the branch SD-WAN configuration, not by starting over.

1. Fortinet SD-WAN Architecture for Enterprise 7.4 Guide

Chapter: ADVPN

Section: ADVPN 2.0.

"ADVPN 2.0 moves the shortcut logic from the IPsec tunnel to the SD-WAN rule. This allows for more granular control over which traffic can create shortcuts." (This directly supports the explanation).

The guide shows the configuration steps: "On the spokes

enable advpn-shortcut in the SD-WAN rule." This confirms the change is made to the SD-WAN configuration on the branches (spokes).

2. FortiOS 7.4.0 Administration Guide

Section: VPN > IPsec VPN > Auto-Discovery VPN (ADVPN).

The guide details the configuration for ADVPN 2.0

showing the CLI command set advpn-shortcut enable under config system sdwan > config rule. This explicitly places the configuration within the SD-WAN rule set on the spoke devices.

The exhibits provide three key pieces of information: the SD-WAN rule, the performance SLA status, and the SD-WAN routing decision. While the SD-WAN rule and performance SLA indicate that the logical member HUB1-VPN1 should be chosen due to better performance (lower latency), the get router info sd-wan-service command shows the final, effective routing decision made by the FortiGate for the specified traffic. This command output explicitly states that for traffic from the source IP 10.0.1.101, the egress interface is port1. This command simulates the complete SD-WAN forwarding lookup and provides the most precise answer for which interface is actually used to steer the traffic.

A. port4: There is no information in any of the exhibits to suggest that port4 is involved in the traffic path.

B. HUB1-VPN1: This is the logical SD-WAN member selected by the rule based on the SLA. However, it is not the final physical egress interface, which is shown by the routing lookup to be port1.

D. port2: There is no information in any of the exhibits to suggest that port2 is used for this traffic flow.

1. FortiOS 7.4.0 SD-WAN Deployment Guide

Page 48

Section: "Verifying the configuration". This section explains the use of the get router info sd-wan-service command to "see the SD-WAN routing table and verify which member is selected for a specific destination." This confirms that the command output in the exhibit is the definitive source for the final routing decision.

2. FortiOS 7.4.0 CLI Reference

Page 1391

Command: get router info sd-wan-service. The command description states

"Use this command to display the SD-WAN service routing table." The output fields

including the interface (dev or interface)

show the result of the SD-WAN engine's decision.

3. FortiOS 7.4.0 Administration Guide

Page 1130

Section: "SD-WAN routing". This section details how SD-WAN rules and member status are used to populate the SD-WAN routes

which are then consulted for forwarding decisions. The exhibit shows the result of this process.

When auxiliary-session is enabled (config system settings → set auxiliary-session enable), FortiGate builds an additional “helper” session for SD-WAN traffic. This causes reverse-direction packets to perform a fresh SD-WAN member lookup instead of being pinned to the interface that handled the first packet. DC-1 can therefore choose the member that currently shows the best SLA (T1) for the reply flow.

A. snat-route-change only updates established sessions that use source NAT after a routing change; it does not influence SD-WAN member selection for return traffic.

B. No reply-session knob exists in config system sdwan; therefore it cannot alter path choice.

D. Statement is inaccurate: with auxiliary-session enabled, FortiGate can select a different egress than the original ingress interface.

1. FortiOS 7.4.0 Administration Guide

“SD-WAN auxiliary session feature”

p. 562–563.

2. FortiOS 7.4.0 CLI Reference

“config system settings → set auxiliary-session”

p. 355: “Enable to create auxiliary session so return traffic is routed according to SD-WAN service performance.”

3. Fortinet Technical Note FD-72830 “Achieving symmetric paths with SD-WAN auxiliary sessions”

2023

§2.

The FortiManager SD-WAN overlay template automates the creation of the underlying network infrastructure, such as IPsec tunnels and BGP peering. However, it does not configure the traffic management logic or security enforcement. After the template is successfully run, the administrator must perform two mandatory post-run tasks for the SD-WAN to be functional:

1. Configure SD-WAN rules: These rules are essential for defining how traffic is steered across the member interfaces based on performance SLAs or other criteria.

2. Create policy packages: Firewall policies are required to permit and control traffic flowing through the newly created SD-WAN interfaces. These are managed in policy packages and must be assigned to the devices.

A. Configure routing through the overlay tunnels created by the SD-WAN overlay template.

The template itself configures dynamic routing (typically BGP) over the overlay, making this part of the template's automated task, not a manual post-run task.

C. Assign a hub id metadata variable to each hub device.

Assigning metadata variables is a prerequisite task that must be completed before running the template, as the template uses these variables to generate the configuration.

E. Assign an sdwanid metadata variable to each device (branch and hub).

Similar to option C, assigning metadata variables like sdwanid is a preparatory step performed before the template is run, not after.

1. Fortinet. (2023). FortiManager Administration Guide 7.4.0. "SD-WAN overlay template"

Page 645

"Post-run tasks". The document explicitly states: "After running the SD-WAN overlay template

you must complete the following tasks: 1. Configure SD-WAN rules. 2. Configure firewall policies." This directly supports options B and D.

2. Fortinet. (2023). FortiManager Administration Guide 7.4.0. "SD-WAN overlay template"

Page 638

Workflow Diagram. The diagram shows that "Configure SD-WAN Rules" and "Configure Firewall Policies" are distinct steps that occur after "Run SD-WAN Overlay Template".

3. Fortinet. (2023). FortiManager Administration Guide 7.4.0. "To create an SD-WAN overlay template:"

Page 639

Step 1. This section details the creation and assignment of metadata variables as a preliminary step

confirming that options C and E are pre-run tasks.

4. Fortinet. (2023). FortiManager Administration Guide 7.4.0. "To run an SD-WAN overlay template:"

Page 642. The BGP configuration is shown as part of the template's settings

confirming that routing configuration (Option A) is handled by the template run itself.

The provided configuration shows that fail-detect is enabled and fail-alert-interfaces is set to port5. The fail-detect command enables a feature that monitors the status of all SD-WAN members. If all members fail their health checks and are considered dead, FortiGate takes the action specified by the fail-alert-interfaces command. In this configuration, the specified action is to administratively bring down port5. This mechanism is typically used to signal an upstream or downstream device that the path is unavailable, allowing it to reroute traffic.

A: The interface is brought down administratively; the configuration does not specify that it should be "bounced" (brought down and then back up).

B: While bringing down a monitored interface might trigger an HA failover, this is a secondary consequence, not the direct action configured within the SD-WAN settings.

C: The fail-alert-interfaces command changes the administrative state of the port to down; it does not send alert messages through the port.

1. FortiOS 7.4.0 CLI Reference: In the config system sdwan section

the documentation for fail-alert-interfaces states: "Select the interfaces that will be brought down if all members in the SD-WAN are down." This directly supports the chosen answer. (Fortinet Document Library

FortiOS 7.4.0 CLI Reference

p. 2038).

2. FortiOS SD-WAN 7.4.1 Administration Guide: The "Link-down failover" section explains this feature: "When all SD-WAN member interfaces are down

FortiGate can bring down monitored interfaces to notify the upstream device to reroute traffic." It then provides the exact CLI commands shown in the exhibit: set fail-detect enable and set fail-alert-interfaces . (Fortinet Document Library

FortiOS SD-WAN 7.4.1 Administration Guide

p. 101).

When traffic does not match any explicitly configured SD-WAN rule, it is processed by the implicit SD-WAN rule (rule ID 0). The primary action of this rule is to forward the traffic using the standard routing table (FIB).

Consequently, the session is not associated with any user-defined SD-WAN service, which is what is meant by the session information displaying "no SD-WAN service id" (A).

Furthermore, the FortiOS order of operations dictates that policy routes are evaluated before SD-WAN rules. Therefore, for traffic to reach the SD-WAN rule evaluation stage and subsequently match the implicit rule, it must not have matched any entry in the policy route table (D).

B: This action is conditional. The implicit rule directs traffic to the FIB; ECMP is only used if multiple equal-cost routes to the destination exist in the FIB. It is not a guaranteed outcome.

C: This is incorrect. The implicit rule uses the best path(s) from the routing table, respecting administrative distance and metric. It does not simply use all available static routes regardless of their attributes.

E: The specific session flag vwldefault is not a documented flag in FortiOS for this behavior. While sessions may be flagged as maydirty, the combination with the non-standard vwldefault makes this option incorrect.

1. Fortinet FortiOS SD-WAN Architecture Guide 7.4.1

Page 11: "If traffic does not match any of the SD-WAN rules

it matches the implicit SD-WAN rule. The implicit rule forwards traffic based on the routing table." This supports the fallback mechanism and implies no specific SD-WAN service is applied (supporting A).

2. Fortinet FortiOS Handbook - Order of Operations 7.4.0

Page 7: This document outlines the packet flow

showing that "Policy-based routing" is checked before "SD-WAN." This confirms that for traffic to be evaluated by SD-WAN rules

it must not have matched a policy route (supporting D).

3. Fortinet FortiOS Handbook - Networking 7.4.0

Page 539: Describes Equal Cost Multi-Path (ECMP) routing. This section clarifies that ECMP is a function of the routing table when multiple equal-cost paths are available

confirming that its use is conditional

not absolute (refuting B).

4. Fortinet FortiOS CLI Reference 7.4.1

Page 1791 (diagnose sys sdwan session): The output for the implicit rule shows ruleid(0)

indicating it is tracked by an ID but corresponds to the default

non-service-specific rule (supporting the interpretation of A).

The final event log entry explicitly details a change in traffic steering for the SD-WAN rule named "voice". The log message msg="SD-WAN rule (voice) route ... changed" combined with the fields newmember="HUB1-VPN3" and reason="sla" provides direct evidence. This indicates that due to a performance SLA trigger, the FortiGate has rerouted the traffic matching the "voice" rule to now use the HUB1-VPN3 tunnel as its preferred path. The other log entries simply show various tunnel interfaces becoming active members of the SD-WAN.

A. The master tunnel HU82-VPN3 cannot accept ADVPN shortcuts.

The logs do not contain information about ADVPN roles (master/shortcut) or capabilities. This statement is an unsupported assumption.

C. The VPN tunnel HUB1-VPN10 is a shortcut tunnel.

The logs identify HUB1-VPN10 only as an SD-WAN member. There is no specific field or message to confirm it is a dynamically created ADVPN shortcut.

D. There is one shortcut tunnel built from master tunnel VPN4.

The logs show a member named HUB2-VPN4, not "VPN4". Furthermore, the logs provide no evidence of any shortcut tunnels being created.

1. FortiOS 7.4.0 Log Message Reference

Page 711

Log ID 0108043003. This reference details the log message for an SD-WAN rule change. The description for the newmember field confirms it indicates the "New member name" selected for the route

directly supporting the correct answer.

2. FortiOS 7.4.2 SD-WAN Administration Guide

Page 10

"SD-WAN rules". This section explains that "FortiGate uses SD-WAN rules to control how to route traffic through the SD-WAN." The log demonstrates this process in action

where the "voice" rule steers traffic to a new member.

3. FortiOS 7.4.2 SD-WAN Administration Guide

Page 110

"Monitoring SD-WAN". This section states

"Event logs are generated for SD-WAN events

such as member status changes and SLA failures." The reason="sla" in the log is a direct example of this

triggering the rule change.

When a zone is specified as the outgoing interface in a static route configuration, FortiGate creates and installs a distinct static route in the routing table for each interface that is a member of that zone. All these generated routes will share the same destination, administrative distance, and priority. If these parameters are identical, FortiGate can then use them for Equal-Cost Multi-Path (ECMP) load balancing across all member interfaces of the zone.

A: This is incorrect because FortiGate installs routes for all members of the zone, not just the first two.

B: This is incorrect because FortiGate actively creates and uses the static routes for the zone members; it does not ignore them.

C: This describes the behavior of SD-WAN rules, which use performance SLAs to select a path. A standard static route does not perform this function.

FortiOS 7.4.0 Administration Guide

Page 911

Section: "Static routes". The guide states: "When an interface zone is selected as the outgoing interface

a static route is created for each member interface in the zone."

FortiOS 7.4.0 Networking Guide

Page 218

Section: "Zones". The guide explains that a zone is a group of interfaces

and when used in policies or routes

it applies to all member interfaces. This implies that a route pointing to a zone will resolve to routes for its individual members.

When an administrator attempts to delete an SD-WAN member directly from the FortiGate GUI while it is still assigned to an SD-WAN zone, the action will fail. FortiGate's configuration management prevents the deletion of objects that have dependencies. In this case, the SD-WAN member is an object in use by the SD-WAN zone configuration. Therefore, FortiGate will display an error message indicating the object is in use. While it is possible to first remove the member from the zone in the GUI and then delete it, the direct deletion fails, and the CLI offers a powerful and alternative method for managing such configuration changes.

A. FodiGate accepts the deletion and removes routes as required.

This is incorrect. FortiGate will block the deletion because the SD-WAN member is still part of a zone, which constitutes a configuration dependency.

C. FortiGate displays an error message. SD-WAN zones must contain at least two members.

This is incorrect. While plausible for redundancy, there is no explicit rule in the official documentation stating that an SD-WAN zone must always contain a minimum of two members. The error is due to the dependency, not a minimum member count rule.

D. FortiGate accepts the deletion and places the member in the default SD-WAN zone.

This is incorrect. The deletion action is blocked and fails. FortiGate does not move objects to a default location upon a failed deletion attempt.

1. FortiOS 7.4.0 Administration Guide - SD-WAN > Deleting an SD-WAN member:

The guide states

"An SD-WAN member cannot be deleted if it is being used in an SD-WAN rule

a performance SLA

or a static route. You must remove the SD-WAN member from all configurations before deleting it." Being a member of an SD-WAN zone is considered being "used in a configuration

" which creates a dependency and prevents direct deletion

thus generating an error.

2. FortiOS 7.4.0 CLI Reference - system sdwan:

The CLI reference documents the commands under config system sdwan to manage members and zones. Specifically

config zone

edit

and unselect member can be used to remove the dependency

and config member

delete can be used to delete the member. This confirms the CLI is a valid and robust tool for this operation.

For FortiGate to steer traffic using SD-WAN, a specific sequence of configurations is required. First, the underlying network interfaces that will participate in the SD-WAN (such as physical WAN links or VPN tunnels) must be configured and then added as members to the SD-WAN zone. Second, routing must be configured, typically a static route, to direct traffic towards the SD-WAN virtual interface. This step is crucial for the FortiGate to consider the SD-WAN engine for path selection. Finally, firewall policies must be created to permit the traffic, using the SD-WAN virtual interface as the outgoing interface. These three elements—interfaces, routing, and firewall policies—are the fundamental prerequisites for SD-WAN traffic steering.

C. Security profiles: These are applied to firewall policies for traffic inspection (like antivirus or IPS). They are not required for the SD-WAN path selection and steering mechanism itself to function.

D. Traffic shaping: This feature manages bandwidth and prioritizes traffic. While it can be used with SD-WAN, it is a separate function and not a mandatory prerequisite for basic traffic steering.

1. FortiOS SD-WAN Administration Guide 7.4.1

"Basic setup" section

page 23: This section outlines the essential steps for a basic SD-WAN deployment

which explicitly include: 1. Create SD-WAN members (which are based on configured Interfaces)

4. Create a static route

and 5. Create firewall policies. This demonstrates that these three are core requirements.

2. FortiOS SD-WAN Administration Guide 7.4.1

"Packet flow for SD-WAN" section

page 19: The packet flow diagram and description show that after a packet arrives

the FortiGate performs a routing lookup. If the route points to the SD-WAN interface

a firewall policy check is performed. Only then are the SD-WAN rules evaluated to steer traffic over a member interface. This confirms the dependency on these three elements.

3. FortiOS Administration Guide 7.4.1

"Policies" chapter

page 619: This chapter details the necessity of firewall policies to allow any traffic to pass through the FortiGate. It states

"A firewall policy is a set of instructions that the FortiGate unit uses to control traffic." This applies to SD-WAN traffic as well

which must be explicitly permitted.