Staff

Technical Tip: Configuring FortiLink over 3rd party switches with L2 connectivity with the FortiGate

Forum|Forum|2 months ago
March 17, 2026
3 replies
1834 views

Description

This article describes a generic procedure to be used when there are 3rd party switches directly connected to the FortiGates acting as Tier-1. It does not require VxLAN, so it could be used for any FortiSwitch model.

Scope

Tested with the following versions, but it could also serve for earlier FortiSwitch OS versions if they support FortiLink over HTTPS.

FortiOS: v7.4.11 and v7.6.6 GA.
FortiSwitch OS: v7.6.6 GA.

For this scenario, only FortiLink over HTTPS was considered for both: inline management and out-of-band management.

Solution

This is the scenario used for this purpose. Ideally, each Tier will be connected after having configured the previous one, but it is not a mandatory requirement: all switches can be connected from the start and then the configuration modified as described below.

Picture 1.png

Tier-1 (3rd party switches).

Tier-1 switches are 3rd party switches, and their configuration will not be part of this KB article entry, to keep it vendor agnostic.

The following considerations must be taken into account:

Native VLAN on the trunks towards the FortiGate and the Tier-2 FortiSwitch must be set to 4094 (default management VLAN for FortiLink. If the default FortiLink settings happened to have been modified with a different one, set the VLAN ID accordingly).
Allowed VLANs: allow ALL VLANs (more permissive but also simpler) or the ones used in the FortiLink configuration, on the trunks towards the FortiGate and the Tier-2 switches. If the latter is followed, then remember that every time a new VLAN is created/deleted under FortiLink, this configuration will need to be modified on the 3rd party switches.
Spanning tree priority: these switches must be the root for the topology: set a priority value below 24576.

Tier-2 (FortiSwitch): discovery phase.

With this procedure, the Zero-Touch-Configuration of FortiLink is broken, so the configuration must be done manually on the FortiSwitch. The internal inline management path will be used for the following configuration.

For each Tier-2 FortiSwitch, configure the following: (this article shows the process for the 648F switches only. The configuration of the second Tier-2 follows the same steps, modifying the ports and trunks).

Set FortiLink mode to HTTPS.

config switch-controller global

set mgmt-mode https

end

Configure the IP of the FortiLink interface configured on the FortiGate.

Note: At this point, there is still no connectivity with the FortiGate.

config system flan-cloud

set name [FortiLink_IP]

set service-type fortilink-https

end

Configure auto-network to use VLAN 4094 for FortiLink management.

config switch auto-network

set mgmt-vlan 4094

end

Create the _FlInK1_MCLAG0_ trunk manually with the ports towards the 3rd party Tier-1 switches as members.

Set the trunk to static.

config switch trunk

edit "_FlInK1_MLAG0_"

set mode lacp-active

set auto-isl 1

set static-isl enable

set mclag enable

set members "port55" "port56” --- these must be the ports facing the 3rd party switches.

Force a DHCP renewal of the IP of the internal interface: it should get an IP from the FortiLink range from the FortiGate, and it can now reach the FortiGate and be discovered and authorised.

execute interface dhcpclient-renew internal

To check:

get system interfac

execute ping [FortiLink_IP]

The FortiSwitch should now appear on the FortiGate GUI requesting Authorisation (if auto-authorisation is not enabled).

Authorise them.

Automatic trunks towards the Tier-3 FortiSwitch might have been configured/detected if all switches were connected from the beginning:

Trunk members could be detected wrongly; verify that the correct ports are assigned to the trunks.
Configure auto-ISL-groups manually: configure the auto-isl-port-group towards the Tier-3 FortiSwitch. If a previous trunk was auto-formed, wait for some minutes for the switch to update the trunk after having configured the auto-isl-group.
Set the trunk to static.

config switch auto-isl-port-group

edit "Tier-3-1"

set members "port53" "port54" ---> These must be the ports facing the Tier-3 FortiSwitch.

config switch trunk

edit "Tier-3-1"

set mode lacp-active

set static-isl enable

set auto-isl 1

set members "port53" "port54"

Configure the ICL manually:

It may have formed an automatic trunk with a different name: set the members of that trunk to other (dummy) ports that are not used.
Create the _FlInK1_ICL0_ trunk and add the correct ports.
Enable mclag-icl.
Set the trunk to static.
Delete the auto-formed trunk with the dummy ports.

edit _FlInK1_ICL0_

set mode lacp-active

set static-isl enable

set mclag-icl enable

set auto-isl 1

set members "port51" "port52"

Check the switch interfaces associated with the ISL and ICL trunks that have been configured. They should have a similar configuration as below (snmp-index may vary)

config switch interface

edit "_FlInK1_MLAG0_"

set native-vlan 4094

set allowed-vlans 1-4094

set dhcp-snooping trusted

set edge-port disabled

set snmp-index 63

set native-vlan 4094

set allowed-vlans 1-4094

set dhcp-snooping trusted

set edge-port disabled

set snmp-index 61

set native-vlan 4094

set allowed-vlans 1-4094

set dhcp-snooping trusted

set edge-port disabled

set snmp-index 60

Now, the STP priorities must be set statically.

Disable the auto-stp-priority.

config switch global

set auto-stp-priority disable

end

Set the priority to 24576: for Tier2, this should be higher than the 3rd party Tier-1.
ISLs and ICLs should have a cost set to 1. Even if forced to a different value, after they synchronise with the FortiGate, they will be set to 1, as per FortiLink automatic configuration.

config switch stp instance

edit "0"

set priority 24576

config stp-port

edit "_FlInK1_MLAG0_”

set cost 1

[…]

edit "15"

set priority 24576

config stp-port

edit "internal"

set cost 1

set vlan-range 4094

Run the general checks for the MCLAG peers' consistency and STP status. Root should be the 3rd-party Tier-1 switches in a standard implementation. Use the following commands:

diagnose switch mclag peer-consistency-check

diagnose stp instance list

Tier-3+ (FortiSwitch).

For the Tier-3 FortiSwitch, there is no need to enable FortiLink over HTTPS; they will be discovered automatically via LLDP and FortiLink, and they should get the configuration of the trunks automatically, but some configuration must still be done:

Set the trunks to static.
Check that the switch interface has the right settings (similar as shown for the Tier-2).
Enable MCLAG-ICL if they are forming an MCLAG pair.
Modify the STP priorities as detailed below:

Disable the auto-stp-priority.

config switch global

set auto-stp-priority disable

end

Set the priority to 28672 --- for Tier3, this should be higher than the Tier-2 priority
ISLs and ICLs should have a cost set to 1. Even if forced to a different value, after they synchronisation with the FortiGate, they will be set to 1, as per FortiLink automatic configuration.

config switch stp instance

edit "0"

set priority 28672

config stp-port

edit "_FlInK1_MLAG0_”

set cost 1

[…]

edit "15"

set priority 28672

config stp-port

edit "internal"

set cost 1

set vlan-range 4094

Run the general checks for the MCLAG peers' consistency and STP status. Root should be the 3rd-party Tier-1 switches in a standard implementation. Use the following commands:

diagnose switch mclag peer-consistency-check

diagnose stp instance list

The representation on the FortiGate GUI shows that all Tier-2 FortiSwitches are directly connected to the FortiGate, but there are the 3rd party switches in between:

With this scenario, there are some FortiLink features that may not work.

FortiLink features tested.

Working:

NAC/DPP detection and policies.
Device detection.

Partially working: Block Intra VLAN traffic, only if there is only one Tier-2 pair; if there are more than one Tier-2 stacks, then traffic among the different stacks will flow.

Features that will not work: NAC LAN Segments: requires the VLAN translation at the Tier-1 level.

Using out-of-band management interfaces.

Basically, it is required to follow similar steps to configure the FortiLink over HTTPS, but now it is needed to configure the route to reach the FortiLink interface of the FortiGate via the management (mgmt) port of the FortiSwitch.

Additionally, a policy to allow that flow must be in place on the FortiGate.

If the FortiSwitch can reach the FortiLink interface, then the first (Tier-2 in this case) switches will be represented as connected to the FortiGate with the links and the cloud icon, meaning they reach the FortiGate via layer 3 routing.

Apart from that, all related comments and features would work the same, as long as the VLANs are allowed through the 3rd party switches between the FortiGate and the FortiSwitch.