Fortinet FCSS_EFW_AD-7.6 Practice Questions

Explanation:
The topology shows two separate ADVPN networks (Overlay 1 and 2) connected via an eBGP peering between Hub A (AS 65100) and Hub B (AS 65200). The IP addresses 10.255.255.1 and 10.255.255.2 are tunnel IPs, meaning the BGP peers are not on a directly connected physical subnet.

A. ebgp-enforce-multihop enable:
This is mandatory because, by default, eBGP requires peers to be directly connected. Since the hubs communicate over a logical tunnel interface, this command is necessary to allow the eBGP session to form across this multi-hop path.

B. next-hop-self enable:
This is mandatory to ensure proper routing between the two overlay networks. When Hub A advertises a route from one of its spokes to Hub B (eBGP), the BGP NEXT_HOP attribute remains the original spoke's tunnel IP. When Hub B propagates this route to its own spokes (iBGP), the spoke in Overlay 2 sees a next-hop IP from Overlay 1, which is unreachable. Configuring next-hop-self on the hub's BGP sessions (typically on the iBGP sessions to its spokes) forces the hub to rewrite the NEXT_HOP to its own tunnel IP, which is a reachable gateway for all local spokes.

Why the Other Options Are Incorrect

C. set ibgp-enforce-multihop advpn:
This command is non-standard and unnecessary. iBGP does not have a direct-connected requirement; it can peer with any reachable IP address by default. The multihop requirement in this design is exclusively for the eBGP session between the two different autonomous systems.

D. set attribute-unchanged next-hop:
This command would break connectivity. It tells BGP to preserve the original next-hop. In this cross-overlay scenario, preserving the next-hop from one overlay in the other is the core problem, as it results in unreachable routes. Using this command would prevent the next-hop-self fix from working.

Reference

Fortinet Documentation: The FortiOS BGP configuration guide explicitly covers the need for ebgp-multihop when peering across tunnel interfaces. It also details the use of next-hop-self in hub-and-spoke VPN designs to resolve next-hop reachability issues for downstream peers. This is a fundamental BGP design pattern for this specific network topology.

Explanation:

The requirement has three critical parts:
Direct Spoke-to-Spoke Communication: Traffic should not hairpin through the hub.
Multiple Internet Connections per Spoke: The solution must handle multiple paths.
Automatic Detection & Optimal Link Utilization: The solution must be dynamic and intelligent.
Only ADVPN 2.0 meets all these requirements. It is specifically designed for this purpose:

Dynamic Direct Tunnels: Spokes initially connect to the hub via an IPsec tunnel. When a spoke needs to send traffic to another spoke, it uses the ADVPN protocol to request a shortcut. The hub provides the necessary routing and security information, allowing the two spokes to dynamically establish a direct IPsec tunnel between themselves, bypassing the hub entirely.

Automatic Link Optimization (with Multiple Paths):
ADVPN 2.0 integrates with SD-WAN. Each spoke can have multiple internet connections in an SD-WAN zone. When initiating a direct tunnel, the spokes can use SD-WAN logic to automatically select the best-performing path (e.g., lowest latency, jitter) for that specific spoke-to-spoke tunnel. If the quality of that link degrades, the SD-WAN can seamlessly switch the tunnel to the next-best available internet connection.

Why the Other Options Are Incorrect

A. Set up OSPF routing over static VPN tunnels between spokes:
This is not scalable. It requires a full mesh of manually configured, permanent IPsec tunnels between every spoke. This creates a massive configuration burden (n*(n-1)/2 tunnels) and does not automatically optimize the path based on real-time link quality; the tunnels are static.

C. Establish static VPN tunnels between spokes with predefined backup routes:
Similar to A, this relies on a manual, full-mesh configuration. While backup routes can provide redundancy, they do not provide automatic optimal link utilization. The primary and backup paths are fixed by the administrator and cannot dynamically switch based on real-time performance metrics like latency or jitter.

D. Implement SD-WAN policies at the hub to manage spoke link quality:
This solution keeps the hub as the central traffic chokepoint. While SD-WAN at the hub can optimize the path between the spoke and the hub, it does not enable direct spoke-to-spoke communication. All inter-spoke traffic would still be forced to go through the hub, violating the primary requirement.

Reference

Fortinet Documentation: The FortiOS VPN guide has a dedicated section on ADVPN, explaining how shortcut tunnels are dynamically negotiated. The integration with SD-WAN is a key feature of ADVPN 2.0, allowing for optimal path selection for these dynamic tunnels based on real-time performance SLAs. This combination is the definitive solution for scalable, self-optimizing meshed VPN networks.

Explanation:
In the topology shown, there are two OSPF areas: Area 0.0.0.0 (the backbone) and Area 0.0.0.1, which connects to it through an Area Border Router (ABR). To optimize the OSPF database, the goal is to minimize unnecessary LSAs inside Area 0.0.0.1. In typical enterprise OSPF deployments, areas that do not need to receive external routes (Type-5 LSAs) or detailed inter-area LSAs can be configured as stub areas to significantly reduce the size of the OSPF LSDB and the amount of LSA flooding.

A Stub Area replaces many external LSAs with a single default route, reducing the number of entries in the LSDB. This directly decreases CPU utilization, memory consumption, and SPF computation frequency. Since Area 0.0.0.1 is a leaf area (not redistributing external routes), it does not require Type-5 LSAs. Converting it to a stub is the simplest and most effective way to optimize the OSPF database without affecting routing reachability.
When configured as a stub, FortiGate automatically installs a default route pointing to the ABR. All external and inter-area LSAs are suppressed. Devices in Area 0.0.0.1 only maintain local routes plus the summarized default-route advertisement. This improves stability and convergence in the area by keeping LSDB contents small and controlled.
This behavior is fully aligned with OSPF design best practices: use stub areas to reduce LSDB size, optimize routing state, and reduce LSA processing overhead.
Therefore, Option B is the correct choice.

❌ Why the other options are incorrect

A. Set a route map in the AS boundary FortiGate.
Route maps are used for route redistribution, filtering, and attribute modification. They do not reduce the OSPF LSDB size inside an OSPF area. Even when filtering external routes during redistribution, Type-5 LSAs generated by other routers would still be flooded into the area unless the area is converted to a stub. Thus, using route maps does not achieve the goal of optimizing the OSPF database for the entire area.

C. Set an access list in the AS boundary FortiGate.
Access lists (ACLs) regulate packet forwarding or traffic matching, not OSPF control-plane behavior. ACLs do not influence the LSDB, do not filter LSAs, and cannot reduce LSA flooding. Therefore, ACLs are not a mechanism for OSPF optimization and provide no benefit for LSDB reduction.

D. Set the area 0.0.0.1 to the type NSSA in the area border FortiGate.
An NSSA still allows Type-7 LSAs, which are used for external route advertisements within the area. These LSAs must be generated, flooded, and translated by the ABR into Type-5 LSAs when necessary. This behavior increases LSDB size rather than reducing it. NSSA is intended for areas that must redistribute external routes—not for minimizing OSPF complexity.
Thus, NSSA does not meet the requirement of optimizing the database.

📘 References
FortiOS Routing Guide – OSPF Areas (Stub & NSSA)
FortiOS Handbook – OSPF Configuration
NSE 4 / NSE 5 Training – OSPF Area Types
Fortinet Documentation Library – OSPF Design and LSA Types

Explanation:
In the given topology, FortiGate B connects to a RIP network on one side and to OSPF Area 0.0.0.1 on the other. FortiGate A connects Area 0.0.0.1 to the OSPF backbone area (0.0.0.0). The administrator wants routers in the OSPF backbone to learn routes from the external RIP network. For OSPF Area 0.0.0.0 to detect external networks that originate from RIP, those RIP routes must first be imported (redistributed) into OSPF. Only then can they propagate through Area 0.0.0.1 and reach Area 0.0.0.0.
This redistribution must occur at the point where RIP and OSPF meet—FortiGate B. Without redistribution, RIP routes remain local to the RIP domain and are never introduced into the OSPF LSDB, meaning no OSPF router in Area 0.0.0.0 would ever learn them.
When the administrator enables RIP → OSPF redistribution on FortiGate B, these RIP routes are converted into Type-5 External LSAs and injected into the OSPF LSDB. These LSAs then propagate across Area 0.0.0.1, reach FortiGate A, and eventually appear in Area 0.0.0.0. This is the correct and necessary mechanism to allow OSPF to detect routes that originate outside the OSPF domain.
Redistribution is a fundamental requirement whenever two different routing protocols interoperate, which is what is happening here: RIP on one side, OSPF on the other. Therefore, option A is the only answer that ensures external detection in the OSPF backbone.

❌ Why the other options are incorrect

B. Configure a distribute-route-map-in on FortiGate B.
A distribute-route-map-in is used to filter incoming OSPF routes, not to inject external ones. It does not redistribute RIP into OSPF. Instead, it would restrict routes, which is the opposite of the intended goal. It cannot make Area 0.0.0.0 detect RIP routes.

C. Configure a virtual link between FortiGate A and B.
A virtual link is used to reconnect an OSPF area to the backbone if it becomes discontiguous. In this topology, Area 0.0.0.1 is already properly connected to Area 0.0.0.0 through FortiGate A. A virtual link does nothing to advertise or inject RIP routes. It plays no role in external route propagation.

D. Set area 0.0.0.1 to stub on FortiGate A and B.
A stub area blocks external Type-5 LSAs, which means RIP-learned routes would not propagate into Area 0.0.0.1 or Area 0.0.0.0. Making the area a stub would actively prevent external route detection. This option contradicts the goal.

📘 References

FortiOS Routing Guide → Route Redistribution (RIP ↔ OSPF)
Shows requirement for explicit redistribution between different protocols.
FortiOS Handbook – OSPF External Routes (Type-5 LSAs)
Explains how redistributed external routes are propagated.
NSE 4 & NSE 5 Training Modules → OSPF Redistribution Concepts
Recommends redistribution at the protocol boundary device.

Explanation:
The BGP status output shows the FortiGate’s BGP neighbor (100.65.4.1) is stuck in the Idle state. One key detail in the exhibit is the line:

“Not directly connected EBGP”
“Update source is Loopback”

This indicates the administrator has configured the update-source as a loopback interface. When BGP uses a loopback as the source, the session becomes multihop, because the loopback IP is not directly connected to the remote peer. By default, eBGP requires the neighbor to be directly connected, meaning TTL = 1. When the update source is loopback, TTL = 1 is insufficient, so the BGP session never progresses past the Idle state.
To allow an eBGP session between loopback interfaces or across intermediate hops, FortiGate requires explicitly enabling:
set ebgp-enforce-multihop enable
This command allows the FortiGate to initiate an eBGP session beyond a single hop—necessary when using loopback update sources or when the neighbors are not physically adjacent. Once this setting is applied, the FortiGate sends BGP packets with a higher TTL, allowing the session to reach the remote peer and move beyond Idle into Active/Established.
Because the exhibit clearly states the update source is loopback and that the session is “Not directly connected EBGP,” enabling multihop is the correct and required next step.

❌ Why the other options are incorrect

A. Configure a static route to 100.65.4.1.
A missing route would cause the BGP state to remain Idle, but the exhibit does not show unreachable status or missing next-hop. The key clue is the use of a loopback update source, not a reachability problem. The session would show error messages related to adjacency failure if routing was the issue. Here, the problem is TTL enforcement, not routing.

B. Configure the local AS to 65300.
The output already shows: Remote AS 65300, Local AS 65200 These AS numbers are correct and intentional. Changing the local AS to 65300 would create an iBGP session instead of eBGP, altering routing design and not fixing the Idle state. AS mismatch is not the cause here; the cause is the loopback-based multihop requirement.

C. Contact the remote peer administrator to enable BGP.
If the remote peer had not enabled BGP, the local FortiGate would typically move to Active state (sending connection attempts). Remaining in Idle occurs before attempting TCP connection, and the "not directly connected" line indicates the problem is configuration—not a remote BGP shutdown. There is no evidence in the output that the remote router is misconfigured or unreachable.

References:
FortiOS BGP Guide → eBGP multihop configuration
FortiOS CLI Reference → set ebgp-enforce-multihop
NSE 4 / NSE 5 Routing Modules → eBGP multihop and loopback update-source behavior
FortiOS Troubleshooting BGP → Idle state diagnostics

Explanation:
In the exhibit, FortiGate_1 is peering with an ISP in AS 30 and must advertise a modified MED (Multi-Exit Discriminator) value. MED is a BGP path attribute used to influence inbound traffic from an external AS by indicating the preferred entry point into your AS. To change the MED sent to the external BGP neighbor, you must apply a route-map in the outbound direction.
On FortiGate, modifying BGP path attributes—including MED—requires attaching a route-map-out to the BGP neighbor configuration. The route-map can match prefixes and then set attributes such as:

set metric → modifies MED
set local-preference
set community
set weight, etc.

Since the requirement is specifically to modify MED advertised from FortiGate_1 toward AS 30, a route-map-out is the correct mechanism. This ensures that the ISP receives routes with the desired MED (in this case, 200), which then influences the ISP’s inbound traffic decision.
The FortiGate BGP process uses route-maps for all attribute manipulation in outbound advertisements, making option A the correct and necessary configuration step.

❌ Why the other options are incorrect

B. network-import-check
This setting controls whether FortiGate requires a matching route in the routing table before advertising a BGP network statement. It has no ability to modify BGP attributes such as MED. It affects advertisement eligibility, not attribute manipulation.

C. prefix-list-out
A prefix list can only permit or deny matched prefixes—it cannot modify BGP path attributes. Prefix lists are used to filter prefixes being advertised but have no function related to MED, local-preference, weight, or any path-attribute changes. Therefore, it cannot implement the required MED modification.

D. distribute-list-out
A distribute list is applied to filter routes, not modify their attributes. Distribute lists use ACLs or prefix lists to control which routes are advertised or accepted. They provide no mechanism for setting MED or other attributes. Thus, they cannot accomplish the task described in the question.

📘 References

FortiOS BGP Configuration Guide → Route-maps
States that route-maps are used to set BGP attributes including MED.
FortiOS CLI Reference → config router route-map
Describes set metric for modifying MED.
Fortinet NSE 4/5 Routing Training
Defines MED manipulation as an outbound attribute adjustment requiring a route-map.
FortiOS BGP Neighbor Configuration
Shows applying set route-map-out to influence attributes sent to peers.

Explanation:
Fortinet HA clusters use virtual MAC addresses derived from a predictable pattern. The MAC shown in the question:
e0:23:ff:fc:00:86
belongs to Fortinet’s OUI range (e0:23:ff) and matches the pattern used by FGCP HA virtual MACs, especially when VDOMs and vclusters are enabled.

✔️ Why Answer A is Correct

A. The suspicious packet is related to a cluster that has VDOMs enabled.
FortiGate clusters operating with VDOMs and vclusters generate additional virtual MAC addresses.
These MACs follow the pattern based on the Fortinet OUI e0:23:ff.
When VDOMs are enabled, each vcluster uses its own MAC addressing scheme.
Therefore, a MAC beginning with e0:23:ff:fc strongly indicates HA activity within a VDOM-enabled cluster.

✔️ Why Answer C is Correct

C. The suspicious packet is related to a cluster with a group-id value lower than 255.
The HA group-id (also called cluster-id) is encoded into the last byte(s) of the virtual MAC address.
For FGCP, group-id must be < 255.
The MAC address:
e0:23:ff:fc:00:86
contains the value 0x86 (decimal 134) → a valid group-id inside the <255 range.
This confirms the packet originates from an FGCP cluster using a valid group-id.

❌ Why the Other Options Are Incorrect

B. The network includes FortiGate devices configured with the FGSP protocol.
FGSP does NOT use virtual MAC addresses.
FGSP does session synchronization only, with no shared MAC and no failover.

Therefore this MAC cannot be attributed to FGSP.

D. The suspicious packet corresponds to port 7 on a FortiGate device.
Fortinet MACs do not encode interface numbers in their MAC addresses.
The last byte (0x86) is related to group-id, not to a physical port.

📚 References
FortiOS Handbook – HA Guide (FGCP Virtual MAC Address Format)
NSE Training – FortiGate High Availability Module
Fortinet OUI allocations (e0:23:ff)