Free Fortinet NSE5_FSW_AD-7.6 Practice Exam with Questions & Answers | Set: 3

When transitioning the management of a FortiSwitch from standalone mode to being managed by FortiGate via FortiLink, it is critical to ensure that the existing configurations are preserved. The best practice involves:

FortiGate's Role in Configuration Preservation:FortiGate has the capability to automatically preserve the existing configuration of a FortiSwitch when it is integrated into the network via FortiLink. This feature helps ensure that the transition does not disrupt the network's operational settings.

Configuration Integration:As FortiSwitch is integrated into FortiGate's management via FortiLink, FortiGate captures and integrates the existing switch configuration, enabling a seamless transition. This process involves FortiGate recognizing the FortiSwitch and its current setup, then incorporating these settings into the centralized management interface without the need for manual reconfiguration or the use of additional tools.

Page 452 of 7.2 study guide, specifically states "Although you can use the sniffer command to capture traffic on switch ports, the types of packets capture by the sniffer are very limited.

The use of the sniffer command on FortiSwitch CLI can be unreliable on port 23 for specific reasons related to the nature of traffic on the port:

D.The switch port might be used as a trunk member.When a switch port is configured as a trunk, it can carry traffic for multiple VLANs. If the sniffer is set up without specifying VLAN tags or a range of VLANs to capture, it may not accurately capture or display all the VLAN traffic due to the volume and variety of VLAN-tagged packets passing through the trunk port. This limitation makes using the sniffer on a trunk port unreliable for capturing specific VLAN traffic unless properly configured to handle tagged traffic.

"The tool is a Python script that converts the supported settings in a FortiSwitch standalone configuration file to the equivalent FortiOS settings for a managed switch."Reference: FortiSwitch 7.2 Study Guide, page 349

The correct statement about the quarantine VLAN on FortiSwitch is:

B. Users who fail 802.1X authentication can be placed on the quarantine VLAN.This feature allows network administrators to isolate devices that do not meet the network’s security criteria as determined through 802.1X authentication. Placing these devices in a quarantine VLAN restricts their network access, thereby protecting the network from potential security threats posed by unauthorized or compromised devices.

Option A is incorrect as the presence of a DHCP server in a quarantine VLAN depends on specific network configurations. Option C is incorrect without more context regarding global settings, and option D misstates the functionality of quarantine VLANs, as their primary use is to restrict, not block, devices without additional VLAN configuration changes.

According to theFortiSwitchOS 7.6 Administration Guideand theNSE 5 FortiSwitch 7.6 Administrator Study Guide, FortiSwitch supports a multi-stage ACL pipeline that allows for granular traffic control at different points in a packet's journey through the switch.1The documentation identifies three primary stages for ACL application:Prelookup,Ingress, andEgress.

Prelookup (Option D):This is the earliest stage in the switching pipeline. The documentation explicitly states thatPrelookup ACLsare processedbefore any Layer 2 or Layer 3 lookupsare performed by the switch hardware. This stage is highly recommended for high-performance security actions, such as dropping unwanted traffic immediately upon arrival, because it prevents the switch from wasting internal resources (CPU and ASIC lookup cycles) on frames that are destined to be discarded anyway.

Ingress (Option A):This stage occursafterthe switch has completed its Layer 2 (MAC table) and Layer 3 (routing table) lookups butbeforethe packet is queued for the egress port. While powerful, actions here occur after initial processing has already taken place.

Egress (Option C):This stage is processed just before the frame leaves the switch through the destination port. It is typically used for final modifications or filtering based on the outgoing interface context.

Therefore, to achieve the goal of applying actionsbeforeany Layer 2 or Layer 3 processing occurs, thePrelookupstage is the technically correct and recommended choice in FortiSwitchOS 7.6.Forwarding (Option B)is a general functional stage of a switch but is not a specific ACL stage type in the FortiSwitch configuration hierarchy.

When a FortiSwitch is converted fromstandalone (local) management modetoFortiGate-managed mode using FortiLink, FortiSwitchOS follows a well-defined and protective transition process. According to the FortiSwitchOS 7.6 Administrator Guide, the switchdoes not mergeits existing standalone configuration with FortiLink-managed settings, nor does FortiGate import or preserve the active configuration for reuse.

Instead, when the management mode change occurs, the FortiSwitchsaves the current standalone configuration internallyand thenresets its operational configuration to the default FortiLink configuration. This default configuration is required so the switch can correctly establish FortiLink control-plane communication with the FortiGate, including CAPWAP-based management, VLAN 4094 usage, and dynamic policy provisioning.

Once the FortiSwitch is under FortiGate management,all configuration is controlled centrally by the FortiGate, including VLANs, port policies, security features, and firmware management. The previously saved standalone configuration is retained only as a backup reference on the switch and isnot actively usedunless the switch is later reverted back to standalone mode.

This behavior ensures configuration consistency, prevents conflicts between local and centralized policies, and aligns the switch with the FortiGate-centricSecurity Fabric architecture. It also avoids unpredictable results that could occur if legacy standalone settings were merged with FortiLink-managed profiles.

The other options are incorrect because FortiSwitch does not register with FortiSwitch Cloud automatically, does not merge configurations, and FortiGate does not back up the standalone configuration during onboarding.

Therefore, the correct and fully documented answer isC. FortiSwitch saves the standalone configuration and changes to the default FortiLink configuration.

According to theFortiSwitchOS 7.6 Administration Guideand theFortiSwitch 7.6 Study Guide, DHCP snooping is a security feature that acts as a firewall between untrusted hosts and trusted DHCP servers. It validates DHCP messages from untrusted sources and filters out invalid messages.

The provided debug output reveals specific configuration details that support the correct answers:

Option 82 Support (Option C):The output line option82-enabled-vlans : 10 explicitly indicates that DHCP Option 82 is active for that specific VLAN. When Option 82 is enabled on a VLAN, the FortiSwitch (acting as a relay agent or snooping device) inserts information about the physical port and VLAN into the DHCP request packet before it is forwarded to the server. This allows the server to apply location-based IP address allocation policies.

Broadcast Traffic Handling (Option D):In the "DHCP Global Configuration" section, theDHCP Broadcast Modeis set toAll. In FortiSwitchOS 7.6, the default behavior for DHCP snooping is to forward DHCP broadcast traffic to all ports in the VLAN unless explicitly restricted. Setting the mode to "All" means the switch does not limit the propagation of DHCP broadcast packets solely to trusted interfaces; instead, they are flooded to both trusted and untrusted ports within the broadcast domain. To restrict broadcasts, the mode would need to be changed to "Trusted-Only".

Regarding the incorrect options:Option Ais false because the output shows snoop-enabled-vlans : 10, confirming it is active.Option Bis incorrect because the trusted ports list includes port2, FlInK1, and MLAG0, meaning multiple interfaces are trusted, not just port2.

According to theFortiSwitchOS 7.6 Administration Guide(specificallyPage 178) and theFortiSwitch 7.6 Study Guide, the Spanning Tree Protocol (STP) is the fundamental protocol used to manage redundant paths in a Layer 2 network. In the scenario described, where every FortiSwitch connects to every other FortiSwitch, afull Layer 2 meshis created. This architecture inherently produces multiple physical switching loops that, if left unmanaged, would cause catastrophic broadcast storms.

STP is responsible for detecting these loops by exchangingBridge Protocol Data Units (BPDUs). It then mathematically calculates a loop-free logical topology by placing redundant ports into ablocking (discarding)state while keeping primary paths in aforwardingstate. WhileMCLAG (Option A)provides node-level redundancy and eliminates STP delays by allowing two switches to appear as one, it is not a standalone solution for a global full-mesh topology. In fact, Fortinet MCLAG explicitly relies on STP through the mclag-stp-aware feature to detect and prevent loops caused by connections outside the Inter-Chassis Link (ICL).

Therefore, although MCLAG and LAG increase bandwidth and availability,STPremains the required underlying mechanism to maintain network stability in any highly redundant mesh environment. "Full mesh HA" (Option C) is not a defined feature in FortiSwitchOS 7.6.

In a hierarchical network model, the role of a device functioning simultaneously as both the distribution and core is most accurately described as "FortiGate managing FortiSwitch (B)." In this setup, FortiGate acts as the central unit managing multiple FortiSwitch units, thereby functioning both as a distribution layer—handling traffic between network segments—and as a core layer—managing traffic within the network on a broader scale. This setup is typical in medium-sized networks where a single device is capable enough to handle both roles effectively.

In FortiSwitchOS 7.6,Loop Guardis a Layer 2 loop detection mechanism primarily designed to protect access ports from unintended network loops. In itsoriginal implementation, Loop Guard only detected loops on thenative VLAN, which limited its effectiveness in environments using multiple tagged VLANs. To address this limitation, Fortinet enhanced Loop Guard by introducing theMAC move detection feature, as documented in the FortiSwitchOS 7.6 Administrator Guide.

TheMAC move optioninstructs the FortiSwitch to monitor for repeated MAC address flapping events across ports or VLANs. Such MAC movement is a strong indicator of a Layer 2 loop. However, this enhanced detection mechanism isdisabled by defaultand must be explicitly enabled by configuring aMAC move threshold greater than zero.

According to the FortiSwitchOS 7.6 Administrator Guide (page 164), enabling MAC move allows Loop Guard to detect loops beyond the native VLAN. Furthermore, the guide explicitly states (page 166) thata MAC-Move value of 0 indicates that the MAC move feature is not enabled. This means the switch is not monitoring MAC address movement as part of its loop detection logic, even though Loop Guard itself may still be enabled on the port.

Therefore, a MAC-Move value of 0 does not indicate that Loop Guard is disabled or inactive, nor does it imply VLAN-wide port shutdown behavior. It strictly confirms thatMAC move detection has not been enabled, makingOption Cthe correct and fully verified answer based on FortiSwitchOS 7.6 documentation.