System Configuration And Setup practice questions

TCP Echo

Why it fails: TCP Echo is not offered as a Performance SLA probe type; FortiGate SD-WAN supports ICMP, UDP Echo, HTTP, HTTPS, DNS, and TWAMP. It is tempting because TCP-based probes exist elsewhere, and TCP Echo would be the choice only if the platform actually exposed it.

HTTP

Why it fails: HTTP is a valid protocol for SaaS application monitoring.

ICMP

Why it fails: ICMP is a valid and commonly used protocol.

The system selects the one with the highest bandwidth capacity.

Why it fails: Bandwidth is not the primary driver for SLA Target strategy.

The system selects the member with the best performance (e.g., lowest latency).

Why it fails: It dynamically selects the best performer.

Traffic is sent through all of them simultaneously.

Why it fails: This would require load balancing.

A FortiManager instance.

Why it fails: FortiManager is optional.

A subscription to FortiGuard SD-WAN service.

Why it fails: SD-WAN is a core feature of FortiOS.

An external load balancer.

Why it fails: FortiGate handles load balancing internally.

show system sdwan

Why it fails: This displays the configuration, not the dynamic routing table.

get router info routing-table all

Why it fails: This shows the general routing table, not the specific SD-WAN logic.

diagnose sys route list

Why it fails: This is for traditional static routes.

8

Why it fails: This is not the limit.

2

Why it fails: This would be too restrictive.

4

Why it fails: This is not the limit.

FTP

Why it fails: Not a standard probe protocol.

DHCP

Why it fails: Not a probe protocol.

The FortiGate restarts automatically.

Why it fails: No restart occurs.

The interface automatically reverts to a WAN port.

Why it fails: It remains an interface but without SD-WAN configuration.

All firewall policies referencing the zone are deleted.

Why it fails: They aren't deleted, just potentially broken.

Enabling SD-WAN in the Feature Visibility menu.

Why it fails: This is usually enabled by default.

Updating the FortiGuard database.

Why it fails: Optional.

Configuring a BGP peer.

Why it fails: Optional.

Policy routes

Why it fails: Policy routes can direct traffic based on criteria like source or destination, but they do not monitor link health. They are static and would not automatically react to link degradation. Without integration with a health-check mechanism, policy routes alone cannot steer traffic away from a failed link in real time.

Static route with distance

Why it fails: Static routes with distance only influence initial path selection and do not provide continuous health checking. They cannot detect link degradation after the route is installed, so traffic would not be steered away automatically when the link fails. This option lacks the dynamic monitoring required for SD-WAN automatic failover.

Link Health Monitor

Why it fails: Link Health Monitor is a legacy feature used in older FortiOS versions for basic link failover, but in SD-WAN it has been replaced by Performance SLA. It does not support the granular SLA metrics and integration with SD-WAN rules that Performance SLA provides, so it would not meet the requirement for automatic dynamic steering.

Enable the member's 'Source IP' option and specify the desired public IP.

Why it fails: FortiGate SD-WAN members do not have a 'Source IP' option in the member configuration. Source IP for IPsec is typically determined by the phase 1 local gateway or routing. This setting does not exist, so it cannot satisfy the requirement.

Set the member's Gateway to the desired public IP address.

Why it fails: The Gateway setting defines the next-hop for the member, not the source IP used for the overlay. Changing it to the desired public IP would break routing because the gateway must be on the same subnet as the interface. It does not control the tunnel source address.

Configure the member's 'Interface' to a loopback interface that holds the desired public IP.

Why it fails: Using a loopback as the member interface is not supported for SD-WAN members; members must be physical or tunnel interfaces. A loopback cannot carry the underlay traffic, and it would not provide the required connectivity. This approach fails to meet the design.

Bandwidth threshold

Why it fails: Bandwidth threshold is not a standard parameter in FortiGate Performance SLA. Performance SLA measures latency, jitter, and packet loss; it does not measure available bandwidth. While bandwidth is important, it is not part of the SLA probe metrics. Therefore, this option is incorrect for defining SLA thresholds.

Packet loss threshold

Why it fails: Packet loss threshold is also a valid SLA parameter, but the question asks for two parameters that must be configured to define SLA thresholds. While packet loss is important, it is not one of the two required in this context because the question specifies business-critical traffic where latency and jitter are primary. However, in reality, packet loss is often included; but here, the focus is on latency and jitter as the key thresholds for quality.

MTU threshold

Why it fails: MTU threshold is not a Performance SLA parameter. MTU is related to packet size and fragmentation, but it is not monitored by SLA probes. The SLA focuses on latency, jitter, and packet loss. Configuring an MTU threshold would not affect SLA status and is not a valid setting in this context.

wan1 is already assigned to a different SD-WAN zone.

Why it fails: If wan1 were already a member of another SD-WAN zone, it would not appear in the selection list for a new zone. However, in a typical initial setup, the interface is not yet assigned to any zone. The issue is more likely due to the interface being referenced elsewhere, such as in a static route or firewall policy, which prevents it from being added.

wan1 does not have an IP address assigned.

Why it fails: An interface can be added to an SD-WAN zone even if it does not have an IP address, as long as it is not referenced elsewhere. The absence of an IP address is not a blocking factor for SD-WAN membership. The interface must be administratively up, but an IP is not required for zone membership.

wan1 is configured as a DHCP client.

Why it fails: Configuring an interface as a DHCP client does not prevent it from being added to an SD-WAN zone. In fact, many SD-WAN deployments use DHCP on WAN interfaces. The blocking factor is typically existing references in the configuration, not the addressing mode.

Set the Gateway on wan1 to the next-hop address of the remote peer.

Why it fails: The Gateway field defines the next-hop used to reach the member and is required for correct health-check probing, but it does not influence which interface a returning packet uses. Return-path selection is handled by the member's role in the SD-WAN configuration, not by its gateway value. Changing the gateway here would not prevent asymmetric egress and ingress.

Set the wan2 member's cost to a higher value than wan1.

Why it fails: Adjusting member cost affects which member is selected for new egress sessions, but it does not bind return traffic to the same member. A lower-cost wan2 route could still be chosen for the returning direction, producing asymmetry. Cost tuning is a selection input, not a return-path enforcement mechanism, so the requirement remains unmet.

Enable the 'Preserve Session' option on the wan1 member.

Why it fails: There is no 'Preserve Session' toggle on an SD-WAN member; session stickiness is a consequence of the rule strategy rather than a member attribute. The scenario requires that return traffic for a session use the same member as the outbound traffic, which is enforced by designating a preferred member for ingress, not by a session-preservation flag. This option describes a nonexistent setting.

The SD-WAN rule is placed below a more general rule that matches all traffic.

Why it fails: SD-WAN rules are evaluated in order, and a more general rule above the specific one would indeed take precedence. However, the scenario states that the rule matches the application signature, implying the rule itself is correct. The more likely cause is that the application is not being identified at all due to missing application control, so the rule cannot match.

The performance SLA is disabled on the member.

Why it fails: A disabled performance SLA affects health checking and failover, but it does not prevent an SD-WAN rule from matching traffic based on application. The rule would still match and attempt to steer, though it might not have SLA information. The failure to match at all is more indicative of missing application identification.

The interface is not assigned to an SD-WAN zone.

Why it fails: If the interface were not in an SD-WAN zone, the member would not exist and the rule would not function at all. Since the rule is configured and presumably other traffic is steered, this is not the most likely cause. The specific failure to match an application points to identification, not zone membership.

Configure the rule to use 'Best Quality (SLA)' and assign costs to each member.

Why it fails: Best Quality (SLA) is a different strategy that selects a single best member based on a composite metric. It does not load-balance across multiple members. Assigning costs is relevant for Lowest Cost (SLA), not for the Manual strategy. This does not meet the load-balancing requirement.

Enable 'Load Balance' mode and set the method to 'Source IP'.

Why it fails: The Manual strategy does not have a separate 'Load Balance' mode or method. Load balancing in Manual is achieved by including multiple members with equal priority. Adding a source IP method is not part of the Manual strategy configuration and would not achieve the desired behavior.

Set the rule's action to 'Maximize Bandwidth (SLA)' and enable both members.

Why it fails: Maximize Bandwidth (SLA) selects the member with the highest available bandwidth that meets the SLA; it does not load-balance. It would use only one member at a time. This strategy does not provide the required distribution across both members when they are healthy.

Create an SD-WAN rule with strategy 'lowest-cost (SLA)' and enable 'implicit failback'.

Why it fails: Lowest-cost (SLA) selects the member with the lowest cost that meets the SLA, which could be either link and does not guarantee prioritization of wan1. Implicit failback only controls whether traffic returns to the preferred member once it recovers, but it does not provide a fallback to the primary when both links fail the SLA. Therefore, this does not meet the requirement of allowing traffic on the primary if both fail.

Create an SD-WAN rule with strategy 'priority' and set wan1 as the highest priority, wan2 as lower priority, and enable 'link-cost-factor' with 'SLA'.

Why it fails: Link-cost-factor is used to adjust the cost of a member based on SLA status, but it does not provide a fallback to the primary when both links fail. Priority strategy with link-cost-factor would still not allow traffic if no member meets the SLA. The requirement to allow traffic on the primary when both fail is not addressed, so this fails.

Create an SD-WAN rule with strategy 'priority' and set wan1 as the highest priority, wan2 as lower priority, and enable 'implicit failback'.

Why it fails: Priority strategy selects the highest-priority member that meets the SLA. If both fail the SLA, the rule would not select any member unless a fallback is configured. Implicit failback is for returning to a higher-priority member after it recovers, not for allowing traffic when all members fail. Thus, this configuration would drop traffic when both links fail their SLA, violating the requirement.

The interface must be assigned to a virtual domain (VDOM).

Why it fails: All interfaces on a FortiGate are already part of a VDOM (the root VDOM by default). SD-WAN zones are created within a VDOM, and interfaces from that VDOM can be added. There is no separate VDOM assignment step for SD-WAN membership; the interface is already in the VDOM, so this is not a prerequisite.

The interface must have a gateway defined.

Why it fails: A gateway is not required for an interface to be added to an SD-WAN zone. While a gateway is often configured for routing, SD-WAN can function with interfaces that obtain a gateway dynamically (e.g., DHCP). The gateway can be overridden per SD-WAN member, but it is not a prerequisite for zone membership.

The interface must have an IP address assigned.

Why it fails: An interface does not require an IP address to be added to an SD-WAN zone. In fact, interfaces with DHCP or PPPoE can be members. The IP address is not a prerequisite; the interface can obtain an IP dynamically or be unnumbered. The key requirements are that it is not referenced elsewhere and is administratively up.

Set the 'Gateway' field to the remote FortiGate's public IP address.

Why it fails: The Gateway field identifies the next-hop IP used to reach the SD-WAN member's network, such as the ISP default gateway for a static WAN link. It does not identify the remote tunnel peer, and on a dynamic 5G/LTE interface the carrier gateway is learned automatically. Populating this with the remote FortiGate address would misdirect outbound traffic and break the overlay.

Configure the member with a 'Dynamic gateway' and enable 'Detect' to learn the peer.

Why it fails: Dynamic gateway detection helps the FortiGate learn the local next-hop on a dynamic interface, but it does not identify the remote FortiGate peer for overlay tunnels. Detect is used for link health monitoring, not peer identification. Neither setting supplies the remote endpoint information required when the local 5G/LTE address changes each time the modem reconnects.

Set the 'Interface' to the modem and add a static route to the remote peer.

Why it fails: Selecting the modem as the SD-WAN member interface is necessary, but adding a static route to the remote peer does not solve address discovery. The remote peer's public address may itself be dynamic, and the local side still needs a way to publish its changing address. A static route cannot express the changing source address required for the overlay.

You must create a static route for each interface pointing to the SD-WAN zone, which automatically adds the interfaces to the zone.

Why it fails: Static routes are used to direct traffic to the SD-WAN zone, but they do not add interfaces to a zone. The zone is a logical grouping of member interfaces, and members must be defined under 'config system sdwan' first. Creating a static route to the zone without members would result in an incomplete configuration and the interfaces still would not appear.

You must assign the interfaces to a virtual wire pair before they can be used in an SD-WAN zone.

Why it fails: Virtual wire pairs are used for transparent mode deployments and are not a prerequisite for SD-WAN zones. SD-WAN zones operate in NAT/route mode and require interfaces to be configured as SD-WAN members. Assigning a virtual wire pair would actually prevent the interfaces from being used as routed WAN links for SD-WAN.

You must enable SD-WAN on the FortiGate by running the command 'config system sdwan' and then 'set status enable'.

Why it fails: SD-WAN is enabled by default when you configure it via the GUI or CLI; there is no separate global 'status enable' command under system sdwan. The absence of interfaces in the zone list is not caused by SD-WAN being disabled. Instead, the interfaces must have a gateway and be referenced in the SD-WAN member configuration before they can be added to a zone.

Server

Why it fails: The 'Server' parameter specifies the destination IP address or hostname that the SLA probe will monitor. It does not determine the protocol; it only defines the target. While you need to set the server for the probe to work, it is not the parameter that selects HTTP as the protocol.

Interval

Why it fails: The 'Interval' parameter defines how often the SLA probe is sent, such as every 5 seconds. It controls the frequency of the health checks but does not specify the protocol. Changing the interval affects the responsiveness of the SLA but not the type of probe used.

Probe Type

Why it fails: Probe Type defines the method used for the health check, such as ping, tcp-echo, http, or dns. However, in the context of Performance SLA, the specific parameter that selects the protocol is often referred to as 'Protocol' in the CLI, but in the GUI it is part of the probe settings. The term 'Probe Type' might be ambiguous; the precise parameter is 'Protocol' under the SLA settings.