Fortinet NSE7_SDW-7.2 Practice Questions

Explanation:
The command diagnose firewall proute list displays the policy route table. This table includes both traditional Policy Routes and SD-WAN Rules, and the output has distinct identifiers for each.

Key Identifiers in the Output:
id=1: A simple numerical ID. This is the format for a traditional Policy Route.
id=2131165185 (0x7f070001): A very large, hex-formatted ID. This is the standard format for an SD-WAN Rule. The wwl_service and wwl_mbr_seq fields are also clear indicators of an SD-WAN rule.

Analysis of Each Option:
A. There is more than one SD-WAN rule configured.
Correct. The output shows three distinct SD-WAN rules with the large-numbered IDs:
id=2131165185 for "Critical-DIA" (using port1 and port2)
id=2131165186 for "Non-Critical-DIA" (using port2)
id=2131165187 for "all_rules" (using port1)

B. The SD-WAN rules take precedence over regular policy routes.
Incorrect. While this statement is generally true in FortiOS path selection logic, this specific output does not prove it. The order of entries in the proute list is not necessarily the order of evaluation. The output shows the traditional policy route (id=1) first, but the SD-WAN rules (which are evaluated first in the data path) are listed afterward. We cannot conclude the precedence order solely from the list. The order of evaluation is a system behavior, not a display property.

C. The all_rules rule represents the implicit SD-WAN rule.
Incorrect. The implicit SD-WAN rule is a system-generated rule that acts as a catch-all. It is not visible in the GUI and is only displayed in the CLI with a specific name. The rule here, id=2131165187, is named all_rules and has manually defined source/destination (0.0.0.0-255.255.255.255). This is a user-configured catch-all rule, not the true, hidden implicit rule. The implicit rule has a fixed ID and different characteristics.

D. Entry 1 (id=1) is a regular policy route.
Correct. This entry has a simple numerical ID (id=1), lacks any SD-WAN-specific fields like wwl_service, and matches the classic structure of a policy route (matching DSCP, protocol, sport, dport, and interface). It is configured to send DNS traffic (protocol 17, dport 53) arriving on interface iif=7 out through port1.

Reference:
Fortinet Documentation / CLI Reference:
The output of diagnose firewall proute list is the definitive source. The difference in ID numbering and the presence of wwl_ (WAN-WAN Link) fields are the key differentiators between a traditional policy route and an SD-WAN rule.

The implicit rule is a specific concept documented in the FortiOS SD-WAN guide, which states it is not a user-created object and has a distinct identifier in the CLI (often related to a high ID and a specific name). The user-created all_rules rule is not it.

Explanation:
This command is the primary tool for verifying the configuration and real-time operational state of SD-WAN rules and their associated members.

Analysis of Each Option:
A. diagnose sys sdwan neighbor
Incorrect. This command is used to display BGP neighbor information specifically for SD-WAN, showing the state of BGP peering sessions over the SD-WAN overlay. It does not show the SD-WAN rules themselves or the general state of member interfaces.

B. diagnose sys sdwan service
Correct. This is the most comprehensive command for viewing SD-WAN rules and member status. Its output typically includes:
SD-WAN Rules: Lists all configured SD-WAN service rules (by ID, name, source, destination, etc.).
Interface/Member Information: Shows each SD-WAN member (e.g., port1, port2, ipsec_tunnel) that is part of the rule.
State: Displays the real-time state of each member for the rule, including:
alive or dead based on SLA probe results.
Latency, jitter, and packet loss metrics.
The selected best path for the rule (indicated with a *). It provides a complete overview of how the SD-WAN policy is being applied.

C. diagnose sys sdwan route-tag-list
Incorrect. This command is used for more advanced routing scenarios where BGP routes are tagged with communities. It displays the list of BGP route-tags and their associated SD-WAN services. It is not used for showing the general state of interfaces or the core SD-WAN rule configuration.

D. diagnose sys sdwan member
Incorrect. While this command shows information about the SD-WAN member interfaces (like their real-time SLA statistics: latency, jitter, packet loss), it does not display the configured SD-WAN rules. It focuses solely on the health and status of the individual links, not on how they are grouped and used by the policy rules.

Reference:
Fortinet Documentation Library:
The FortiOS CLI Reference for SD-WAN commands clearly describes the purpose of each. The diagnose sys sdwan service command is documented as the go-to command for "Displaying SD-WAN rule settings and status," which includes the member state information.
When troubleshooting, the output of diagnose sys sdwan service is the first place to look to see if rules are configured correctly and which members are alive and being selected.

Explanation:
The core issue is that the SD-WAN rule is configured correctly and sees both members as "alive," yet the traffic is being routed according to the routing table (get router info routing-table) which points solely to T_INET_1_0. This happens due to a fundamental SD-WAN principle.

Key SD-WAN Path Selection Principle:
Before the SD-WAN rule engine selects a member, the underlying Routing Information Base (RIB) must have a valid route to the destination through that specific member interface. The SD-WAN rule then chooses from among the members that pass this initial route check.

Analysis of the Output:
diagnose sys sdwan service 1: This shows the SD-WAN rule is healthy.
It matches traffic from 10.0.1.0/24 to 10.0.0.0/8.
Both members T_INET_0_0 (seq 3) and T_INET_1_0 (seq 4) are "alive" and "selected" by the SD-WAN logic.
get router info routing-table all: This reveals the real decision-maker.
The output shows: 10.0.0.0/8 [1/0] via T_INET_1_0 tunnel 100.64.1.9
This is a static route with an Administrative Distance of 1. This is a very high-priority route.
Crucially, there is NO route for 10.0.0.0/8 via T_INET_0_0 in the routing table.

Why is this happening?
The SD-WAN rule is being skipped. The fundamental principle from a previous question applies here: "By default, SD-WAN rules are skipped if the best route to the destination is not an SD-WAN member." In this case, the best route is an SD-WAN member (T_INET_1_0), but the rule requires multiple valid members to make a choice. Since the routing table only has a valid route via one member (T_INET_1_0), the SD-WAN rule does not need to be invoked; traffic simply follows the single best route.

Analysis of Each Option:
A. The traffic matches a regular policy route configured with T_INET_1_0 as the outgoing device.
Incorrect. While a policy route could cause this, the exhibit shows the reason definitively. The get router info routing-table command shows that a static route (with AD=1) is directing the traffic to T_INET_1_0. The problem is in the routing table, not a policy route.

B. T_INET_1_0 has a lower route priority value (higher priority) than T_INET_0_0.
Correct. The routing table shows a static route with an Administrative Distance of 1 via T_INET_1_0. If the route for T_INET_0_0 had a higher AD (a less preferable value, like 10 or 250), it would not appear in the routing table. The route via T_INET_1_0 wins because it has the lowest (best) AD.

C. T_INET_0_0 does not have a valid route to the destination.
Correct. This is the most direct explanation. For the SD-WAN rule to load-balance or choose between members, each member must have a valid route to the destination. The exhibit proves that T_INET_0_0 has no route to 10.0.0.0/8 in the routing table. Therefore, even though the SD-WAN health check marks it "alive," it is skipped for traffic selection because it fails the fundamental route lookup.

D. T_INET_1_0 has a higher member configuration priority than T_INET_0_0.
Incorrect. The diagnose sys sdwan member output shows the opposite. T_INET_0_0 has a priority: 10, while T_INET_1_0 has a priority: 0. In FortiOS SD-WAN, a lower priority number is more preferred. So, T_INET_1_0 (priority 0) is actually configured as higher priority than T_INET_0_0 (priority 10). However, this SD-WAN member priority is irrelevant in this scenario because the routing table decision is overriding the SD-WAN process entirely.

Reference:
Fortinet Documentation Library:
The FortiOS SD-WAN guide on "Path Selection" clearly states the prerequisites for an SD-WAN member to be considered, including having a valid route to the destination in the RIB.
It also explains that the best route from the RIB must point to an SD-WAN interface zone for the SD-WAN rule to be activated. If only one member has a valid route, that member is used without invoking the rule's load-balancing logic.

Explanation:
To solve this, we need to understand how the SD-WAN rule is configured and how the system state meets that configuration.

1. Analyze the SD-WAN Rule Configuration (Exhibit A):
Rule 3 ("Corp") is set to mode sla. This means it will select the best-performing member based on Performance SLA targets.
It has priority-members 3 4 5. These are the member sequence numbers (T_INET_0_0, T_INET_1_0, T_MPLS_0). The order (3, 4, 5) might imply a manual priority, but in sla mode, this list simply defines the pool of members eligible for SLA comparison. The cfg_order seen in the diagnostics is what reflects this sequence.
It has two SLA targets configured: "VPN_PING" and "VPN_HTTP". The rule will compare members based on their performance against these targets.

2. Analyze the SD-WAN Service Status (Exhibit B - diagnose sys sdwan service 3):
This is the most critical output. It shows the real-time status and SLA compliance of each member for this specific rule.

Member 3 (T_INET_0_0): alive, sla(0x0)
Member 4 (T_INET_1_0): alive, sla(0x1)
Member 5 (T_MPLS_0):alive, sla(0x3)

The sla(0x...) value is a bitmask indicating which SLA targets the member is passing.
sla(0x0) = Passes 0 out of 2 SLA targets. (Fails all)
sla(0x1) = Passes 1 out of 2 SLA targets.
sla(0x3) = In binary, this is 11, meaning it passes both bit 0 and bit 1 – which corresponds to 2 out of 2 SLA targets. (Passes all)

3. Apply the SD-WAN Logic for sla Mode:
In sla mode, the FortiGate selects the member with the highest number of passed SLA targets. If there's a tie, it then uses the priority (lower number is better) and cfg_order (lower number is better) to break it.

In this case:
T_MPLS_0 passes 2 SLAs. (Winner)
T_INET_1_0 passes 1 SLA.
T_INET_0_0 passes 0 SLAs.
T_MPLS_0 is the only member that meets all the required performance criteria. Therefore, it will be selected for all traffic matching this rule.

Analysis of Each Option:
A. The traffic will be load balanced across all three overlays.
Incorrect. Load balancing occurs in manual mode when members have equal cost, or in sla mode if multiple members have the same (highest) number of passed SLAs. Here, the members have different levels of SLA compliance, so one is clearly the best.

B. The traffic will be routed over T_INET_0_0.
Incorrect. T_INET_0_0 is failing all SLA checks (sla(0x0)). It will not be used as long as another member is passing more SLAs.

C. The traffic will be routed over T_MPLS_0.
Correct. As explained, T_MPLS_0 is the only member that is passing all configured SLA targets (sla(0x3)), making it the best-performing path according to the rule's criteria.

D. The traffic will be routed over T_INET_1_0.
Incorrect. While T_INET_1_0 is passing one SLA, it is inferior to T_MPLS_0, which is passing both. The rule in sla mode will always choose the member with the highest SLA pass count.

Reference:
Fortinet Documentation Library:
The FortiOS SD-WAN guide explains the "sla" mode algorithm: "The FortiGate... compares the SLA of the priority members and chooses a member that meets the SLA target. If more than one member meets the SLA target, the FortiGate chooses the member with the best SLA."
The diagnose sys sdwan service command output is key for troubleshooting, where the sla(0x...) bitmask directly shows compliance. A value of 0x3 (binary 11) indicates the first two SLA targets in the list are being met.

Explanation:
This question tests the understanding of the set snat-route-change enable command and its interaction with the routing table.

1. Understanding the Initial State (Exhibit B):
The routing table has two default routes.
via 192.2.0.2, port2 has an Administrative Distance (AD) of 1.
via 192.2.0.10, port1 has an Administrative Distance (AD) of 10.
In routing, a lower AD is preferred. Therefore, all new sessions will egress via port2.

2. Understanding the Configuration (Exhibit A):
set snat-route-change enable is a critical global setting.
When this is enabled, the FortiGate will dynamically update the NAT and routing information for existing sessions if a better route becomes available. Without this setting, existing sessions would continue on their original path even if a better route appears.

3. Analyzing the Change: "Increases the static route priority on port2 to 20"
In FortiOS, "priority" for static routes refers to the Administrative Distance (AD).
Increasing the AD from 1 to 20 makes the route less preferable.
After this change, the routing table will look like this:
via 192.2.0.2, port2 [20/0]
via 192.2.0.10, port1 [10/0]
Now, the route via port1 has the better (lower) AD and becomes the new best route for new sessions.

4. The Impact on Existing Sessions with snat-route-change enable:
Because snat-route-change is enabled, the FortiGate will not let existing sessions stay on the now-inferior path (port2). It will take the following actions:

Flag Sessions as Dirty:
The FortiGate identifies all existing sessions that are using the now-less-preferred route (port2). It marks these sessions as "dirty" in the session table, indicating they need to be re-evaluated.
Perform a New Route Lookup: For these "dirty" sessions, the FortiGate performs a new route lookup. This lookup will now find the best route is via port1.

Update Session Information:
The session table is updated with the new egress interface (port1) and, crucially, the SNAT IP address will be changed to an IP address belonging to port1 (or its associated IP pool). The session is then routed out the new interface.

Analysis of Each Option:
A. FortiGate flags the sessions as dirty.
Correct. This is the initial step in the process of updating existing sessions when snat-route-change is enabled and a better route is found.

B. FortiGate continues routing the sessions with no SNAT, over port2.
Incorrect. This would be the behavior if snat-route-change was set to disable (the default). The exhibit shows it is enable, so the sessions will not continue over port2.

C. FortiGate performs a route lookup for the original traffic only.
Incorrect. The phrase "original traffic only" is ambiguous and misleading. The FortiGate performs a new route lookup for the existing sessions that were flagged, not just for the initial packet. Furthermore, this action is part of the process but is not a complete description of the outcome on its own.

D. FortiGate updates the gateway information of the sessions with SNAT so that they use port1 instead of port2.
Correct. This accurately describes the final result of the process. The session's egress interface and SNAT IP are updated to match the new best route via port1.

Reference:
Fortinet Documentation Library:
The FortiOS CLI reference for config system global describes the snat-route-change option: "Enable/disable the ability to change the source NAT (SNAT) IP address when a link fails or the route changes... If enabled, the source NAT IP address is updated when a link failure or route change causes the egress interface to change."
This behavior is crucial for SD-WAN and multi-WAN deployments to ensure seamless failover for existing TCP sessions and UDP streams.

🔍 Explanation:
The exhibit shows multiple BGP routes for the same prefix (10.0.2.0/24), each with identical administrative distance and metric ([200/0]), but different next-hop IPs and tunnels. This behavior is only possible when BGP additional-path is enabled, allowing the device to install and retain multiple paths for the same prefix — even if they’re not used for forwarding.

C. Additional-path is enabled ✔️ Correct:
The presence of multiple BGP entries for the same prefix confirms that the device is configured to receive and store additional paths via IBGP. This is a feature explicitly enabled under BGP configuration.

D. You can run the get router info routing-table database command to display the additional paths ✔️ Correct:
This command shows all learned routes, including non-best paths retained due to additional-path. It’s the correct diagnostic tool to verify additional-path behavior.

❌ Incorrect options:
A. Each BGP route is three hops away from the destination ⛔ Incorrect:
The [3] in the output refers to the number of multipath entries, not hop count. Hop count is not shown in this output, and recursive next-hop resolution via VPN tunnels makes hop count ambiguous.

B. ibgp-multipath is disabled ⛔ Incorrect:
The presence of multiple equal-cost BGP routes suggests ibgp-multipath is enabled or additional-path is active. Without explicit config output, we cannot confirm that ibgp-multipath is disabled.

📚 Reference:
Fortinet KB: Understanding BGP Additional Path

Explanation:
FortiManager provides centralized management for Fortinet devices. Its primary benefits are related to operational efficiency, consistency, and oversight, not direct data plane performance.

Analysis of Each Option:
A. It simplifies the deployment and administration of SD-WAN on managed FortiGate devices.
Correct. This is a core function of FortiManager. It allows network administrators to define SD-WAN templates, zones, rules, and performance SLAs in a central location and push them out to dozens or hundreds of FortiGate devices. This eliminates the need to configure each device individually, drastically simplifying deployment and ongoing administration.

B. It improves SD-WAN performance on the managed FortiGate devices.
Incorrect. FortiManager handles the configuration and policy management of SD-WAN. The actual performance of the SD-WAN data path (latency, jitter, packet loss) is determined by the underlying WAN links, the FortiGate's local processing, and the results of its local performance SLA probes. FortiManager does not directly impact these real-time performance metrics.

C. It sends probe signals as health checks to the beacon servers on behalf of FortiGate.
Incorrect. Performance SLA probes (health checks) are generated directly by the individual FortiGate devices themselves. This is a local function critical for the FortiGate to make real-time path selection decisions. FortiManager does not originate these probes.

D. It acts as a policy compliance entity to review all managed FortiGate devices.
Correct.FortiManager includes powerful policy and configuration compliance tools. It can perform audits to check if managed devices are compliant with the central policy definition. It can identify configuration drift (where a device's config has been changed locally and differs from the central template) and report on or remediate those differences, ensuring security and configuration consistency across the entire network.

E. It reduces WAN usage on FortiGate devices by acting as a local FortiGuard server.
Incorrect. This function is performed by FortiGuard Anycast or a dedicated FortiManager with a specific license and role for local FortiGuard distribution. A standard FortiManager used for device configuration management does not inherently act as a local FortiGuard server to cache and serve security updates (IPS, AV, Web Filtering databases). This is a separate, specialized role.

Reference:
Fortinet Documentation Library:
The FortiManager Administration Guide emphasizes its role in "centralized management," "template-based deployment," and "policy and object management," which directly supports options A and D.
The guide on SD-WAN management with FortiManager specifically details how to create and push SD-WAN configurations to multiple devices from a single pane of glass.