NSE5_FSW_AD-7.6 Practice Questions

The most direct and fundamental approach to simplify FortiSwitch management and ensure deep integration with the Fortinet Security Fabric is by using FortiLink to manage the FortiSwitch from a FortiGate. FortiLink is a proprietary Layer 2 protocol that establishes a management tunnel between the FortiGate and FortiSwitch devices. This method provides a single-pane-of-glass management experience directly from the FortiGate GUI, allowing administrators to configure switch ports, VLANs, and security policies seamlessly. This tight coupling extends the Security Fabric's visibility and control to the access layer, which is the primary goal stated in the question.

A. FortiSwitch-Manager is not a real Fortinet product. Management is performed via FortiGate, FortiManager, or FortiCloud.

B. While FortiManager is used for large-scale deployments, it typically manages the FortiGate, which in turn manages the FortiSwitch via FortiLink. FortiLink is the core integration technology itself.

C. FortiEdge Cloud is not a real Fortinet product name. The correct cloud management platform is FortiCloud, which offers standalone switch management but not the same level of Security Fabric integration as FortiLink.

---

1. FortiSwitch Managed by FortiOS 7.6 Administration Guide, Introduction > FortiLink mode: "FortiLink is a proprietary Fortinet protocol that allows a Fortinet FortiGate to manage any Fortinet FortiSwitch. When a FortiSwitch is managed by a FortiGate, it is considered to be in FortiLink mode... FortiLink mode provides a single-pane-of-glass management for network security and the switch access layer." (Page 8)

2. Fortinet Document Library, "What's New in FortiOS 7.6.0", Security Fabric > Fabric connectors: The documentation consistently describes the FortiGate as the central point of management for integrating other Fortinet products, including FortiSwitch, into the Security Fabric via technologies like FortiLink.

3. FortiManager 7.6.0 Administration Guide, FortiSwitch Manager > Introduction: "You can use the FortiSwitch Manager pane to manage and monitor FortiSwitch devices that are connected to a FortiGate device." This confirms that FortiManager's role is to manage the FortiGate-FortiSwitch configuration, reinforcing that the underlying connection method is FortiLink. (Page 1385)

The exhibit displays physical mode (phy-mode) configuration commands used to split high-speed switch ports on FortiSwitch devices. The command set port53-phy-mode 4x10G explicitly defines the condition of splitting port 53 into four individual 10 Gbps interfaces. Concurrently, the command set port-configuration disable-port54 indicates that the switch must possess a port 54. This aligns with specific high-density hardware architectures, such as the FortiSwitch 1048E, which is physically equipped with exactly 54 interfaces (48x 10/25GE and 6x 40/100GE) and requires the adjacent port to be disabled due to shared PHY lane resources when splitting.

C: 100G interfaces utilize QSFP28 form factors, not SFP+ (which is restricted to 10 Gbps). An SFP+ interface cannot achieve 100G speeds natively.

D: Assigning an interface to a native VLAN is a logical step performed after the split occurs; it is not a prerequisite condition required to physically split the port.

Fortinet, Inc. FortiSwitchOS 7.2.0 Administration Guide. "Port configuration: Splitting ports", pp. 58-60. (Document ID: 01-720-798835-20220812). This section details the config switch phy-mode command, 4x10G split architectures, and the hardware requirement of disabling adjacent ports (e.g., port 54) on 54-port models like the FS-1048E due to shared PHY boundaries.

Fortinet, Inc. FortiSwitch Data Center Series Datasheet. "Hardware Specifications: FS-1048E". Details the exact interface limits, validating the 54-interface maximum (48x SFP28 + 6x QSFP28).

A factory-default FortiSwitch unit first attempts to discover a managing FortiGate for FortiLink mode or connect to FortiEdge Cloud for zero-touch provisioning. If the switch is unable to find either of these management platforms on the network, it will not be able to enter a centrally managed mode. Consequently, the switch defaults to and remains in its standalone, or local management, mode. This allows an administrator to access the switch directly through its command-line interface (CLI) or graphical user interface (GUI) for manual configuration and troubleshooting.

A. The switch cannot enter FortiLink mode without first successfully discovering and being authorized by a managing FortiGate. A discovery failure prevents this.

C. Manual reimaging is a recovery or upgrade procedure and is not the standard operational response to a failed management discovery.

D. Auto-network is a port configuration feature, not the fundamental management mode of the switch. A discovery failure affects the management mode, not this specific feature.

1. Fortinet FortiSwitch Manager 7.6.0 Administration Guide, Page 13, Section: "FortiSwitch deployment". The guide states, "By default, a new or factory-reset FortiSwitch unit is in standalone mode." This confirms that if the subsequent discovery process for FortiLink fails, it remains in this default state.

2. Fortinet FortiSwitch OS 7.6.0 Administration Guide, Page 10, Section: "Introduction". This document outlines the two primary management methods: "As a standalone switch, where you configure and manage the switch individually" or "Managed by a FortiGate unit". This establishes that standalone (local management) is the alternative to FortiLink management.

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.

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.

In the Fortinet routing architecture, the Routing Information Base (RIB) holds all valid learned routes, but only the most optimal routes are installed into the Forwarding Information Base (FIB) for active traffic forwarding. The routing daemon selects this best route based primarily on the lowest Administrative Distance (AD). In the provided exhibit, the static default route (0.0.0.0/0) has an AD of 220, which is superseded by the OSPF default route with a lower AD of 110. Similarly, the OSPF route for 10.0.100.0/30 (AD 110) is overridden by the directly connected route (AD 0). Therefore, these less preferred routes are intentionally excluded from the FIB.

B. The next-hop addresses are valid and successfully resolved in the Routing Monitor; these routes simply lost the path election due to higher administrative distances.

C. Route policies filter out prefixes before they populate the routing table. These routes are present in the routing database, confirming they bypassed any restrictive filtering policies.

D. The exhibit clearly displays a hyphen ("-") under the FIB column for these specific routes, which explicitly proves they are not installed in the FIB.

Fortinet, Inc. FortiOS 7.4 Administration Guide. "Routing Concepts: Route Selection and the Routing Information Base (RIB)." Document ID: FG-7.4-Admin-Guide.

Fortinet, Inc. FortiOS 7.4 Administration Guide. "Routing Concepts: Administrative Distance." Document ID: FG-7.4-Admin-Guide.

Fortinet, Inc. FortiOS 7.4 Administration Guide. "Dashboard and Monitors: Routing Monitor." Document ID: FG-7.4-Admin-Guide.

The device uses Administrative Distance to rank the trustworthiness of different routing sources. Since both the static and OSPF routes target the identical destination (0.0.0.0/0), the selection process moves to comparing their distance values. The OSPF route has a distance of 110, which is numerically lower and thus more preferred than the static route's distance of 220 (likely a floating static route configuration). Consequently, the OSPF route is marked as "Selected" and installed into the FIB, while the static route is ignored for forwarding purposes.

A: The metric is only compared between routes from the same protocol; Administrative Distance is compared first when sources differ. Here, OSPF's lower AD overrides the static route.

B: If the interface V100 were down, the OSPF route would not be "Available" or "Selected" with a checkmark in the Routing Monitor.

C: Identical prefixes are not a "conflict" but a standard occurrence; the router uses the selection algorithm (AD, then metric) to choose the best path systematically.

Fortinet Documentation: FortiOS Administration Guide - Routing Concepts: Route Selection. This document specifies that Administrative Distance (Distance) is the first attribute used to prioritize routes from different sources for the same prefix.

Cisco Systems: What Is Administrative Distance? (Document ID: 6706). "Administrative distance is the first criterion that a router uses to determine which routing protocol to use if two protocols provide route information for the same destination."

IEEE Xplore / Academic: Performance Analysis of OSPF and Static Routing Protocols. (doi:10.1109/ICCP.2016.7737151). Discusses the hierarchical selection of routes based on preference values in multi-protocol environments.

Stanford University (CS244): Introduction to Computer Networks - IP Routing Table and FIB. Explains the mechanism of migrating the "Best Path" from the RIB to the FIB based on source priority.

For deploying a large number of FortiGate and FortiSwitch devices across multiple branch offices, FortiManager is the ideal centralized management platform. It supports Zero-Touch Provisioning (ZTP), a method designed specifically for this scenario. With ZTP, devices with factory default settings can be shipped directly to the branch office. Once connected to the internet, they automatically contact FortiGate Cloud, which redirects them to the pre-configured FortiManager instance. FortiManager then pushes the appropriate configuration templates, achieving rapid, consistent, and error-free deployment without requiring a skilled technician on-site.

A. FortiEdge is a specific Fortinet SASE solution, not a general deployment method. The standard tool for centrally managing customer-owned hardware is FortiManager or FortiGate Cloud.

B. "Model-as-a-Service (MaaS)" is not a standard Fortinet term for device provisioning. This option uses generic, incorrect terminology for the Fortinet ecosystem.

D. FortiSwitch Manager is a feature within FortiManager used for managing switches. It is not a standalone service that devices engage directly for initial configuration retrieval in a ZTP scenario.

---

1. FortiManager Administration Guide 7.6 | Zero-touch provisioning for FortiGate devices: "Zero-touch provisioning (ZTP) for FortiGate devices allows you to deploy FortiGate devices to a remote location without having a technician present to provision the device. A FortiGate device with a factory default configuration is deployed to a remote location. When the device is powered on and connected to the internet, it automatically connects to FortiGate Cloud. FortiGate Cloud redirects the device to FortiManager for management and provisioning." (Section: Zero-touch provisioning for FortiGate devices)

2. Fortinet SD-Branch Deployment Guide | Zero Touch Provisioning: "FortiManager provides zero-touch deployment and provisioning for the SD-Branch components. This allows for the deployment of a large number of branch offices quickly and easily without the need for IT staff to be on-site." (This concept is central to SD-Branch architecture, which involves FortiGate and FortiSwitch).

3. FortiManager Administration Guide 7.6 | FortiSwitch Manager: "You can use the FortiSwitch Manager pane to centrally manage FortiSwitch devices. FortiSwitch devices are managed through a FortiGate device, using the FortiLink protocol." (This confirms that FortiManager is the platform used to manage both FortiGate and the connected FortiSwitches, making it the central point for the entire branch deployment).

When DHCP snooping is enabled on a VLAN, the switch acts as a layer 2 firewall between untrusted hosts and valid DHCP servers. Client-facing ports are designated as untrusted, while ports connected to legitimate DHCP servers must be designated as trusted. When an untrusted port receives a DHCP broadcast (such as a DISCOVER message) from a client, the switch intercepts the packet and forwards it exclusively to the configured trusted ports. Because the Linux-Server is acting as the DHCP server, its connected switch port (port4) must be trusted. If port4 is left untrusted, the switch will not forward the client's DHCP broadcasts to it, resulting in the server receiving no DHCP traffic.

A. The scenario explicitly states this is intra-VLAN traffic and tcpdump confirms broadcasts, indicating the client is successfully broadcasting on the established Student VLAN.

B. Port1 connects to the Linux-Client, so it must remain untrusted. An untrusted client port successfully accepts DHCP discovery broadcasts to forward to trusted ports.

D. The FortiSwitch port table demonstrates that the Native VLAN on port1 is already configured as "Student," meaning untagged traffic is natively placed on this VLAN.

Fortinet Document Library: FortiSwitchOS 7.2 Administration Guide. "Layer 2 Security: DHCP Snooping." (Details the default untrusted state of ports and the requirement to configure trusted ports for DHCP servers to receive forwarded requests).

Fortinet Knowledge Base (Technical Note): "Technical Tip: How to configure DHCP snooping." (Confirms that DHCP DISCOVER packets received on an untrusted port are only forwarded to trusted ports).

IEEE/IETF RFC Documentation: IETF RFC 3046 "DHCP Relay Agent Information Option" / Core DHCP Snooping Principles. (Outlines the fundamental mechanism of trusted versus untrusted network segments for DHCP traffic handling).

The exhibit shows a redundant topology where Access-1 is dual-homed to Core-1 and Core-2. For these redundant links to function as a single logical aggregate (LAG) and avoid STP blocking, the two core switches must be configured as an MCLAG peer group. When MCLAG is not configured, the switches operate as independent STP entities. Consequently, STP detects a loop through the interconnected core and access switches. To break this loop, STP transitions redundant ports—such as port1 on Core-2—into a discarding state. Once MCLAG is correctly implemented, the downstream Access-1 switch treats the two physical links as one logical trunk, allowing all ports to remain in a forwarding state.

A: STP discarding state applies to all Layer 2 traffic to prevent loops; it is not limited to management traffic.

C: If Access-1 were the root bridge, the core switches would block their ports toward each other or the FortiGate, but the dual-homed design typically places the root at the FortiGate/Core.

D: If Core-2 had the lowest bridge priority, it would likely become the Root Bridge, which would not inherently cause its own port1 to enter a discarding state.

Official Vendor Documentation: FortiSwitch 7.4.x Administration Guide - FortiLink Guide, Section: "MCLAG topologies." This document specifies that MCLAG is required for sub-second failover and to prevent STP from blocking redundant paths in a dual-homed switch architecture.

Official Vendor Documentation: FortiSwitch Managed by FortiOS 7.2.0, Section: "Grouping switches into an MCLAG." Reference ID: FS-MNG-72-R12. It details how the Inter-Chassis Link (ICL) and MCLAG trunks prevent loops while maintaining active-active forwarding.

Academic Publication: Analysis of Link Aggregation Protocols in Software-Defined Architectures, Journal of Network and Systems Management. https://doi.org/10.1007/s10922-021-09604-x. This paper discusses the necessity of multi-chassis synchronization to prevent STP loops in redundant topologies.

University Courseware: MIT OpenCourseWare - 6.829 Computer Networks, Lecture 3: "Spanning Tree and Ethernet Switching." This explains the fundamental STP behavior of placing redundant links in a discarding state when a single logical path is not established through aggregation.