To manage a FortiSwitch stack, the FortiGate must be configured as the switch controller. This requires two fundamental steps. First, the Switch Controller feature must be enabled under System > Feature Visibility on the FortiGate, which makes the FortiSwitch management options available in the GUI. Second, a FortiLink interface must be configured on the FortiGate. This dedicated interface is used for the management and data communication between the FortiGate and the connected FortiSwitch stack, enabling the FortiGate to discover, authorize, and manage the switches.

C. Only a hardware-based FortiGate can manage a FortiSwitch stack.

This is incorrect. FortiGate-VM models also support the FortiLink protocol and can function as a switch controller to manage FortiSwitch stacks.

D. FortiSwitch must be operating in standalone mode before authorization.

This is incorrect. A FortiSwitch must be in FortiLink mode to be discovered and authorized by the FortiGate. It automatically enters this mode upon detecting a FortiLink signal from the FortiGate.

---

1. Fortinet, FortiSwitch Manager 7.6.0 Administration Guide, Page 10, "Basic configuration".

This section explicitly states: "Before you can use your FortiGate unit to manage a FortiSwitch unit, you need to enable the Switch Controller feature." This supports answer B.

The same section details the next step: "The FortiLink is a dedicated interface for communication between a FortiGate unit and a FortiSwitch unit." This supports answer A.

2. Fortinet, FortiSwitch Manager 7.6.0 Administration Guide, Page 6, "Introduction".

This section clarifies platform support: "You can use a FortiGate or FortiGate-VM unit to manage the FortiSwitch units." This directly refutes option C.

3. Fortinet, FortiSwitch Manager 7.6.0 Administration Guide, Page 12, "Authorizing a FortiSwitch unit".

This section describes the process: "When you connect a FortiSwitch unit to a FortiGate port that is part of FortiLink, the FortiGate unit automatically discovers the FortiSwitch unit." The discovery and subsequent authorization occur while the switch is in FortiLink mode, not standalone mode, refuting option D.

The switch-controller-dhcp-snooping-verify-mac command is a security feature designed to mitigate DHCP starvation/exhaustion attacks. It accomplishes this by verifying that the source MAC address of the Ethernet frame matches the client hardware address (CHADDR) field within the DHCP request payload, dropping mismatched packets.

Configuration settings for DHCP Option 82, which allows a relay agent to insert circuit-specific information into DHCP requests, are not available in the FortiGate GUI for managed FortiSwitches. These settings, such as enabling Option 82 insertion or trusting incoming Option 82 data, must be configured through the command-line interface (CLI).

A. DHCP snooping restricts DHCP traffic. It forwards client requests received on untrusted ports only to trusted ports where legitimate DHCP servers are connected, not to all servers.

C. By default, all ports are untrusted. DHCP requests from clients on these untrusted ports are forwarded only to trusted ports, not to other untrusted ports.

1. FortiGate CLI Reference 7.6.0, Page 2018, config switch-controller dhcp-snooping.

The documentation for verify-mac states: "Enable/disable verification of source MAC address in DHCP request packets to filter out invalid packets." This confirms the command's purpose is to validate MAC addresses to prevent attacks like DHCP exhaustion, supporting the intent of option B.

The same section lists multiple CLI-only settings for Option 82, such as set dhcp-option82-insertion enable, set dhcp-option82-circuit-id, and set dhcp-option82-remote-id, confirming that these settings are configured via CLI, which supports option D.

2. FortiSwitchOS 7.4.0 Administration Guide, Page 113, "DHCP snooping".

The guide states: "When you enable DHCP snooping on a VLAN, all ports are untrusted by default. You must configure which ports are trusted." and "DHCP client requests are only forwarded on trusted ports." This directly refutes options A and C.

To allow managed FortiSwitch ports and connected PoE endpoints to exchange power information and negotiate requirements, the LLDP profile must be configured to transmit the power management TLV. In FortiOS, the set med-tlvs command dictates which LLDP-MED Type-Length-Values are advertised. Currently, the exhibit shows only network-policy is enabled. By adding power-management to the med-tlvs configuration, the switch will include the Extended Power-via-MDI TLV in its LLDP packets. This enables advanced PoE negotiation and granular power allocation with compatible endpoint devices.

A. LLDP-MED application types (like voice or streaming-video) classify traffic for QoS policies, not for defining hardware-level PoE negotiation parameters.

B. Creating a completely new profile is unnecessary; the current profile can simply be modified by appending the required TLV to the existing med-tlvs list.

C. The LLDP-MED location ID is utilized to transmit civic addresses or coordinates (such as for emergency E911 services) and has no functionality for power protocols.

Fortinet. (n.d.). FortiSwitchOS Administration Guide. "LLDP-MED configuration."

Fortinet. (n.d.). FortiOS CLI Reference. "config switch-controller lldp-profile" (Section: med-tlvs).

IEEE. (2016). IEEE Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery (IEEE Std 802.1AB-2016). Section 10: LLDP-MED TLVs.

When a FortiSwitch operating in Layer 3 mode receives a packet, it first examines the destination IP address. The switch then performs a lookup in its hardware routing table, which is programmed by the forwarding information base (FIB). The FIB itself is populated by the control plane from configured static routes, connected interfaces, and dynamic routing protocols. If a matching route is found in the hardware table, the packet is forwarded out the corresponding interface at wire speed. If no match is found, the packet is dropped.

A. Hardware-based routing is offloaded to specialized ASICs for high-speed forwarding. The CPU's role is in the control plane, managing routing protocols and programming the hardware, not handling the actual packet forwarding.

B. ASIC hardware routing is not limited to dynamic routes. The hardware forwarding table is populated with all types of routes (static, connected, and dynamic) learned by the control plane.

D. This behavior describes a FortiSwitch operating as a Layer 2 extension in FortiLink mode. In standalone mode, a FortiSwitch is fully capable of making its own routing decisions locally.

1. Fortinet. (2024). FortiSwitchOS 7.6.0 Administration Guide (Standalone Mode). Fortinet Document Library. Page 121, "Routing" section.

The document states: "When a packet is received on an interface, the FortiSwitch unit gets the destination IP address. The FortiSwitch unit looks up the destination IP address in the hardware routing table and then the forwarding information base (FIB). If a matching entry is found, the FortiSwitch unit forwards the packet to the corresponding interface. If no matching entry is found, the FortiSwitch unit drops the packet." This directly supports the process described in answer C.

A full mesh topology, where every FortiSwitch connects to every other FortiSwitch, inherently creates multiple redundant Layer 2 paths. Without a loop-prevention mechanism, this design would lead to broadcast storms and MAC address table instability, rendering the network unusable. The Spanning Tree Protocol (STP) is the industry-standard protocol designed specifically to address this issue. STP identifies redundant links and logically blocks them to create a single, loop-free path between any two network devices. It maintains the physical redundancy, allowing a blocked path to become active if the primary path fails, thus ensuring both connectivity and a loop-free environment.

A. Multichassis link aggregation group (MCLAG) is a feature for device-level redundancy, typically between two core switches, not a general loop-prevention protocol for a full mesh topology.

C. Full mesh high availability (HA) describes the physical network design and its goal, not the specific protocol or feature configured to prevent loops within that design.

D. A link aggregation group (LAG) bundles multiple physical links into a single logical link for bandwidth and redundancy but does not prevent loops formed between separate switches.

1. Fortinet FortiSwitchOS 7.6.0 Administration Guide, Page 101, "Spanning Tree Protocol (STP)" section: "The Spanning Tree Protocol (STP) is a link-management protocol that provides path redundancy while preventing undesirable loops in a network. For an Ethernet network to function properly, only one active path can exist between any two stations. STP prevents loops by blocking redundant links." This directly confirms STP's role in preventing loops in redundant topologies.

2. Fortinet FortiSwitchOS 7.6.0 Administration Guide, Page 113, "Multichassis Link Aggregation (MCLAG)" section: This section describes MCLAG as a feature to provide redundancy by allowing a client to connect to two different FortiSwitch units. While it has loop-prevention mechanisms for its specific topology, it is not the fundamental protocol for a generic full mesh. The guide states, "STP is still required to provide a loop-free topology with other switches in the network." This highlights that STP is the underlying requirement.

Classification is the Quality of Service (QoS) mechanism responsible for inspecting incoming (ingress) traffic and categorizing it based on specific criteria. On a FortiSwitch, a QoS policy classifies packets by matching their existing Class of Service (CoS) or Differentiated Services Code Point (DSCP) markings. Based on this classification, the policy then maps the packet to a specific egress queue for prioritized transmission. This entire decision-making process of reading the markings and assigning a queue happens upon ingress.

A. Queuing for egress traffic: Queuing is the process of buffering packets in their assigned queues before transmission; it is the result of classification, not the mapping mechanism itself.

C. Rate limiting for egress traffic: Rate limiting (policing) controls the maximum rate of traffic by dropping excess packets. It does not map packets to queues based on their markings.

D. Marking for ingress traffic: Marking is the process of altering the CoS or DSCP value of a packet. The question asks about using existing markings for mapping, not changing them.

---

1. Fortinet FortiSwitch OS 7.6.0 Administration Guide, Page 178, "Quality of Service" chapter.

The guide states, "You can configure a quality of service (QoS) policy to classify, police, and mark incoming traffic." It further details the classification criteria: "You can classify incoming traffic by matching the 802.1p priority, the IP precedence, or the DSCP value." The action taken after classification includes set queue , which explicitly maps the classified traffic to an egress queue. This confirms classification happens on ingress to map to an egress queue.

FortiSwitch, when managed by FortiGate in a FortiLink configuration, uses "FortiSwitch Security Policies" to enable and configure 802.1X on switch ports. This policy is then assigned to the desired ports.

FortiSwitch supports multiple 802.1X modes. One of these is port-based authentication. In this mode, once a single device successfully authenticates on a port, the port state is set to authorized, and all traffic from any device connected to that same port (for example, through a downstream unmanaged switch) is permitted onto the network. This behavior is described in option A.

C. FortiSwitch 802.1X configurations can use external RADIUS servers for authentication. A local user database on the FortiGate is an option but is not mandatory.

D. FortiSwitch supports features like MAC Authentication Bypass (MAB) specifically for devices that do not have an 802.1X supplicant, allowing them to be authenticated based on their MAC address.

1. FortiSwitch™ Managed by FortiOS 7.6 Administration Guide, Page 111, "Configuring 802.1X port-based authentication".

Reference for B: The guide states, "You can configure 802.1X port-based authentication by creating a security policy and then applying the policy to one or more FortiSwitch ports." This directly supports option B.

Reference for A: The same section describes the behavior: "You can configure port-based network access control to block traffic from a client on a specific port until the client is authenticated. After one client is authenticated, any traffic from other clients on the same port is allowed." This confirms option A.

Reference for C: On page 112, Step 4 of the configuration process instructs to "Select one or more RADIUS servers from the User Groups list," demonstrating that external RADIUS servers are used, invalidating the claim that a local database must be used.

Reference for D: On page 112, a configuration option is "MAC authentication bypass (MAB)," which is explicitly for devices that do not support 802.1X, proving option D is false.

Remote Switched Port Analyzer (RSPAN) functions by encapsulating mirrored traffic into a dedicated VLAN to transport it between switches. The best practice is to create and use a VLAN exclusively for this RSPAN traffic. This isolates the potentially high-volume mirrored data from regular production traffic, preventing network congestion, performance degradation on user VLANs, and security complications. This dedicated VLAN is then trunked between the source, transit, and destination switches to deliver the mirrored packets to the monitoring device.

A. Use the same VLAN already configured for regular data traffic.

This is incorrect because mixing high-volume mirrored traffic with production data can cause network congestion and performance issues for users on that VLAN.

C. Use a dynamic VLAN that includes all switch ports.

This is a severe misconfiguration. Including all switch ports would unnecessarily flood the entire network with mirrored traffic, causing a broadcast storm and network outage.

D. Use the RSPAN VLAN as a native VLAN on all trunk ports.

This is incorrect. The RSPAN VLAN carries tagged traffic across trunks. Designating it as the native VLAN is for untagged traffic and is not the standard or recommended RSPAN configuration.

---

1. FortiSwitch OS 7.4.0 Administration Guide, Page 168, "Port mirroring" section.

The documentation explicitly states: "RSPAN uses a dedicated VLAN to transport the mirrored traffic between the switches." This directly supports the use of a dedicated VLAN (Answer B) and contradicts using an existing data VLAN (Answer A).

2. FortiSwitch OS 7.4.0 Administration Guide, Page 169, "Configuring RSPAN" section.

The configuration example demonstrates creating a new, dedicated VLAN for RSPAN: config system interface, edit "rspanvlan", set vlanid , set remote-span enable. This procedure confirms that the standard method is to create a new, dedicated VLAN for this purpose.

In the FortiOS graphical user interface under the "FortiSwitch Ports" section, a specific visual indicator is used for Inter-Switch Links (ISLs). When a managed FortiSwitch port is connected to an adjacent managed FortiSwitch, the FortiGate automatically forms a trunk for the ISL. To quickly visually identify this topology, the GUI replaces the standard Native VLAN text with a link icon alongside the serial number of the adjacent FortiSwitch. Therefore, the presence of the serial number "S424DPTF20000027" and the link icon on port23 confirms that this port connects directly to a neighboring managed FortiSwitch bearing that specific serial number.

A: The port is not a dedicated management interface. Management interfaces utilize specific VLANs but do not automatically display adjacent device serial numbers with a link icon in this column.

C: The displayed serial number belongs to the adjacent connected switch. It does not belong to the local Access-1 switch, which possesses a distinctly different serial number ending in 29.

D: Standalone unmanaged switches do not form FortiLink ISLs. The link icon and adjacent serial number confirm the connected device is a managed FortiSwitch participating in the FortiLink topology.

Fortinet Document Library. "FortiSwitch Manager Administration Guide 7.2.5." Operation and Maintenance: Port List Display, pp. 149-150.

Fortinet Document Library. "FortiSwitchOS 7.4.1 FortiLink Guide." Devices Managed by FortiOS: Managed FortiSwitch Display.

The exhibit displays the current state of the DHCP snooping database and its global configuration on a FortiSwitch. Option B is correct because the trusted ports list explicitly includes _FlInK1_, which is the system-generated interface name for the FortiLink trunk. This indicates the FortiSwitch is configured to trust inbound DHCP server replies (such as DHCPOFFER and DHCPACK) arriving over the FortiLink interface from the FortiGate. Option D is correct because, under the DHCP Global Configuration section, the DHCP Broadcast Mode is set to All. According to Fortinet documentation, this setting instructs the switch to flood DHCP broadcast packets (like DHCPDISCOVER) to all ports in the VLAN, rather than restricting them exclusively to trusted ports (forward-to-server mode).

A: The "Max Client Database Entries: 2000" represents a fixed system or hardware limit for stored snooping bindings, not a value dynamically derived from the DHCP server's available IP pool range.

C: "Client Database: 1" simply indicates there is currently one active, dynamically learned IP-MAC binding lease being tracked by the switch, not a statically configured "trusted" client limitation.

Fortinet, Inc. FortiSwitchOS 7.2.0 Administration Guide. "DHCP snooping and IP source guard", pp. 268-270. Document ID: 04-720-798835-20220811. (Provides conceptual validation that FortiLink ports are trusted by default to allow DHCP server traffic from the FortiGate controller).

Fortinet, Inc. FortiOS 7.2.0 CLI Reference. "config switch global -> set dhcp-broadcast", p. 1145. (Explicitly defines the all parameter as forcing the switch to forward DHCP broadcast packets to all ports in the VLAN).