FortiLink Devices Missing from the Root Fabric View
An enterprise runs a FortiGate 400F at headquarters with multi-VDOM enabled: root and CORP. The FortiLink interface is a 40G aggregate in CORP, connected to two FortiSwitch 424D switches in MCLAG; 18 FortiAP 231F access points are managed from that same interface. A branch FortiGate 60F joins the Security Fabric over an IPsec tunnel terminated in root and is authorized. The administrator expects one topology view in root: HQ switches, APs, branch FortiGate, and FortiClient endpoints from EMS. Instead, root shows only the branch FortiGate; the switches and APs appear only when the administrator logs into CORP. FortiClient endpoints are absent everywhere. CORP has no EMS connector; root has a FortiClient EMS connector using HTTPS 443 with a valid certificate and shows the connector as connected. The administrator disabled fabric authorization globally during a troubleshooting session and re-enabled it. Users report no outage. The task is to restore a single-pane fabric view without moving production VLANs.
1. Root does not display the CORP FortiLink switches and APs, even though the branch FortiGate is visible. What is the most likely scope issue, and what are the trade-offs of moving FortiLink to root?
Read the worked answer
In FortiOS multi-VDOM, FortiLink management and the devices learned on a FortiLink interface are scoped to the VDOM where that interface is configured. The root fabric view is also VDOM-local; it does not automatically inherit another VDOM's FortiLink topology. The branch FortiGate appears because its IPsec tunnel terminates in root.
Moving the FortiLink aggregate to root would place the switches and APs in the root fabric, but it also moves Layer 2 management and potentially the VLAN interfaces into root. That can break CORP segmentation, MCLAG references, management access, and policy/route assumptions. Safer options are to keep FortiLink in CORP and use FortiManager or FortiAnalyzer for cross-VDOM visibility, or to build a dedicated management VDOM that owns FortiLink and serves as the operational fabric view. If a single topology is mandatory, schedule a maintenance window, move the FortiLink interface and its VLANs, reauthorize switches and APs, and verify MCLAG and HA before cutover.
2. What checks would you perform before concluding that the fabric authorization toggle caused the endpoint visibility problem?
Read the worked answer
Check authorization state rather than assuming the global toggle caused everything. In CORP, confirm the FortiSwitch is authorized under Managed FortiSwitch and that each FortiAP is authorized under Managed FortiAP. In root, confirm the branch FortiGate is authorized and that fabric authorization is enabled. Verify the EMS connector in root is connected and that EMS telemetry is allowed; check which VDOM owns the client subnets and whether endpoint sharing is enabled there. Confirm endpoints are registered to the same EMS tenant and have synced recently, and that the FortiGate connector certificate is trusted. Review event logs and the connector status page for sync errors.
Re-enabling authorization does not retroactively authorize devices. An unauthorized switch or AP can remain invisible even after the global setting is restored, because authorization is per device and per VDOM. Also check that the FortiClient EMS connector is not configured only in root while the endpoints are learned in CORP.
3. What are the operational risks of moving FortiLink from CORP to root, and how would you sequence the change?
Read the worked answer
Risks include loss of switch and AP management, loss of VLAN interfaces, MCLAG split, inconsistent HA failover, and management traffic being caught by the wrong policy or route. The FortiLink aggregate may also carry management access that is intentionally isolated in CORP.
Sequence: back up the configuration and FortiManager revision; confirm out-of-band console access; document the FortiLink aggregate, allowed VLANs, MCLAG, and switch/AP authorization; schedule a maintenance window; remove CORP references to FortiLink; create the FortiLink interface in root with the same aggregate and allowed VLANs; move or recreate VLAN interfaces; reauthorize switches and APs; validate MCLAG, AP SSIDs, DHCP, and management access; then clean up old CORP objects. Keep a rollback configuration ready and test HA synchronization before declaring success.