Fortinet FCSS - SD-WAN 7.6 Architect - FCSS_SDW_AR-7.6 Practice Questions

Explanation:

Correct Answers: A, C, E
Three key factors to consider are that member metrics (latency, jitter, packet loss) are only actively measured when referenced by an SD-WAN rule's SLA target, SD-WAN rules leverage SLA targets to verify if preferred members satisfy performance requirements before steering traffic, and rules support selecting multiple SLA targets even from distinct performance SLAs for flexible path selection.

Rule and SLA Interaction
Member performance metrics from health checks trigger only for SD-WAN rules explicitly using SLA targets, optimizing resource usage on FortiGate by avoiding unnecessary probes on unused rules. SD-WAN rules with strategies like Lowest Cost (SLA) or Maximize Bandwidth (SLA) require SLA targets, while Best Quality and Manual strategies treat them as optional. Selecting multiple SLA targets from different SLAs in a single rule allows granular control, such as requiring both low latency AND low packet loss across probes.

Why Other Options Are Incorrect

B: Incorrect, as SLA targets apply beyond Lowest Cost (SLA) to Maximize Bandwidth (SLA) rules too, and optionally to Best Quality for enhanced selection logic. ​

D: Incorrect, since rules cannot mix SLA targets from the same performance SLA; each target must originate from a unique Performance SLA instance to avoid redundancy.

Reference
FortiOS 7.6 SD-WAN Administration Guide: Performance SLA targets under system virtual-wan-link health-check, and SD-WAN rule configuration (config system sdwan > config service). See "SLA Targets" section for CLI examples with multiple targets: config sla edit id set link-cost-factor latency jitter packet-loss.

Explanation:

✅ B. Traffic is load balanced using the algorithm set for the v4-ecmp-mode setting
When traffic hits the implicit SD-WAN rule, it’s handled via ECMP (Equal-Cost Multi-Path) routing based on the configured v4-ecmp-mode. This setting controls how the FortiGate balances traffic across multiple equal-cost SD-WAN members. Common modes include source-destination hashing or round-robin.
Thus, implicit rule traffic follows the general load-balancing algorithm configured.

✅ D. Traffic does not match any of the entries in the policy route table
The implicit SD-WAN rule is used precisely for traffic not matching any explicit SD-WAN rules. These explicit rules form the SD-WAN policy route table.
If traffic matched any policy route, it would be handled according to that rule, not the implicit one.

❌ A. The session information output displays no SD-WAN service id
Traffic going through SD-WAN, even via implicit rule, still has an SD-WAN service ID assigned internally for tracking and policy enforcement. The implicit rule does not mean “no SD-WAN context.”

❌ C. The traffic is distributed, regardless of weight, through all available static routes
Weighting is a core part of SD-WAN routing. Even implicit rule traffic respects weights assigned to members or static routes in SD-WAN. Distribution is not indiscriminate.

❌ E. FortiGate flags the session with may_dirty and vwl_default
These flags are not relevant or standard indicators related to implicit SD-WAN rule handling. They relate more to session handling and video watermarking (VWL), which is unrelated here.

Summary
⇒ Implicit SD-WAN rule catches unmatched traffic.
⇒ That traffic is load balanced according to the configured ECMP mode.
⇒ It doesn’t match any explicit SD-WAN policy route entry.

References
⇒ FortiOS SD-WAN documentation on Implicit SD-WAN rules and ECMP
⇒ Fortinet knowledge base on SD-WAN policy and session handling

Explanation:

Correct Answers:
A. FortiGate continues routing all existing sessions over port2.
D. FortiGate flags the sessions as dirty.

This question tests your understanding of how the FortiGate session table interacts with routing changes and the specific impact of the snat-route-change setting.

1. The Role of snat-route-change (Option A)
The first exhibit shows the command: set snat-route-change enable
By default, when a route changes, FortiGate tries to redirect sessions to the new optimal path. However, for sessions involving Source NAT (SNAT), redirected traffic might be dropped by the next-hop router because the source IP (from the old interface) does not match the new path.
When snat-route-change is enabled, FortiGate is technically capable of rerouting SNAT sessions.

2. Why the sessions are flagged as "dirty" (Option D)
In FortiOS, whenever there is a change in the routing table or an interface configuration (such as changing the priority of an SD-WAN member), the FortiGate does not immediately drop or reroute all traffic. Instead, it marks the existing sessions in the session table as dirty.
Marking a session as dirty serves as a "flag" for the FortiGate to re-evaluate that session against the new routing table and firewall policies when the next packet for that session arrives.

However, the specific behavior in this scenario—where you are simply changing member priority—is that FortiGate prioritizes session persistence for established traffic. Even though the session is flagged as "dirty," FortiGate will continue to route the existing established sessions over the original interface (port2) to prevent session breakage, while new sessions will follow the new priority/routing logic.

Why the other options are incorrect:

B & E: These are incorrect because they imply a forced migration of existing sessions. While new sessions will certainly use the higher-priority path, established sessions are generally maintained on their original egress interface to ensure application stability, especially when SNAT is involved.

C: The "dirty" flag is a standard system behavior for route/policy changes and is not strictly dependent on whether a specific IP pool is assigned; it is triggered by the change in the network topology/priority itself.

Reference:
FortiOS 7.6 Administration Guide - Hardware Acceleration and Session Management: Explains that the dirty flag is used to trigger a session re-evaluation without immediately purging the session table.
FortiGate CLI Reference: The snat-route-change command is specifically designed to control whether SNATed sessions should be redirected when a better route becomes available.

Explanation:

SIA (Software Internet Access) is the Fortinet-specific term for the feature that allows branch offices to directly and securely access the internet through a local internet breakout, instead of backhauling all traffic through a central hub. It integrates Secure Web Gateway (SWG), DNS filtering, application control, and anti-malware services locally on the branch FortiGate to ensure secure direct internet access.

Why the other options are incorrect:

A. Remote Breakout & B. Local Breakout: These are general networking concepts describing where internet traffic exits the network (at a remote hub vs. the local branch). SIA is the Fortinet solution that enables secure local breakout.

D. Secure Internet Authorization: This is a distractor; the correct term is "Access," not "Authorization."

Reference
In Fortinet documentation and training (NSE 6 - Secure SD-WAN), SIA is consistently defined as Software Internet Access, emphasizing its role in providing secure, local internet egress with integrated security services.

Explanation:

Let's trace through what happens:

1. Router Policy Check (First):
The router policy is evaluated first:
set src "10.0.1.128/255.255.255.128"
set dst "128.66.0.0/255.255.255.0"
set action deny

Source IP: 10.0.1.130
Subnet: 10.0.1.128/25 (covers 10.0.1.128 - 10.0.1.255)
Does 10.0.1.130 match? YES

Destination IP: 128.66.0.125
Subnet: 128.66.0.0/24 (covers 128.66.0.0 - 128.66.0.255)
Does 128.66.0.125 match? YES

Action: DENY
Since both source and destination match the router policy rule, and the action is "deny", FortiGate drops this traffic immediately. The packet never reaches the SD-WAN processing stage.

2. SD-WAN Services are Never Evaluated:
The diagnose output shows two SD-WAN services (Service 1 and Service 4), but they're irrelevant here because:
Router policies are processed before SD-WAN route selection
Once denied by router policy, the packet is dropped - no further processing occurs

Why other answers are wrong:

B is wrong: The traffic doesn't get to FIB lookup. Router policy denies it first.

C is wrong: No load balancing happens. The traffic is denied before reaching SD-WAN member selection. (Also, the exhibit shows port1 and port2, not port7 and port8.)

D is wrong: Same reason - traffic is dropped before any steering decision. Also, there's no port7 in the SD-WAN member configuration shown (Members show port1 and port2).

Reference: FortiOS SD-WAN documentation - Router policies are evaluated before SD-WAN service rules. When action is "deny", traffic is dropped immediately.

Explanation:

✅ B. The session 3-tuple did not match any of the existing entries in the ISDB application cache.
Before test traffic, GoToMeeting’s IP/port/protocol wasn’t cached in ISDB. FortiGate couldn’t instantly identify it as the target app, so initial packets didn’t match rule ID 1 and hit the implicit rule instead. Later packets populate the cache, allowing better matches on new sessions. This explains why some logs show implicit hits.

✅ D. No configured SD-WAN rule matches the traffic related to the collaboration application GoToMeeting.
Service(1) lists Microsoft.Portal, Salesforce, and broad “Collaboration,” but GoToMeeting (ID 16354) isn’t explicitly included or perfectly covered. Even after detection, if the rule doesn’t recognize it precisely, traffic falls to the implicit rule. The exhibit shows no exact match, so some sessions never qualify for rule ID 1.

❌ A. Full SSL inspection is not enabled on the matching firewall policy.
SSL inspection helps with encrypted payloads, but SD-WAN app steering often uses ISDB (IP/port-based) or basic signatures first—GoToMeeting can be identified without full decryption. The logs already show the app detected, so missing inspection isn’t blocking the rule match here. Common misconception: assuming all app-ID needs deep inspection.

❌ C. FortiGate could not refresh the routing information on the session after the application was detected.
FortiGate can re-evaluate sessions mid-flow once the app is identified, but the issue is upstream: initial packets didn’t match any rule because of cache absence or config mismatch. The logs show detection happened, yet steering stayed implicit for some flows—pointing to no initial match, not a refresh failure.

Explanation:

Correct Answer: A, C
When configuring SD-WAN load balancing with link quality consideration in Fortinet FortiGate (version 7.6), FortiGate evaluates performance SLAs to monitor metrics like latency, jitter, and packet loss across SD-WAN members. ​

✅ Option A
FortiGate load balances traffic across all eligible SD-WAN members that pass the configured SLA targets, ensuring optimal path selection based on real-time link health. This applies when load balancing is enabled in SD-WAN rules alongside SLA verification. ​

✅ Option C
The "lowest cost (SLA)" strategy prioritizes the cheapest member meeting SLA requirements while permitting load balancing among qualifying members, factoring in costs assigned to interfaces. This balances performance and expense in multi-link setups. ​

❌ Why Not B or D
Option B is inaccurate because "best quality" prioritizes the single highest-quality link (lowest latency/jitter/loss) without distributing load. Option D is false as best quality supports multiple load balancing modes like source-IP or session, not just round-robin.