FortiOS and Security Fabric Architecture
The FortiOS and Security Fabric Architecture domain tests the operating system underneath every FortiGate and the way the Fabric links FortiGate, FortiSwitch, FortiAP, FortiAnalyzer, FortiManager, FortiClient EMS and FortiSandbox into one topology that shares telemetry, ratings and automated responses. At FCX level these are design and troubleshooting questions, not definition recall: which unit is root, where an automation actually runs, and why a device joined the Fabric yet contributes nothing.
FortiOS internals that shape design
- FortiOS separates the management plane (CLI, GUI, config daemons) from the data plane. NP7 network processors offload established sessions while CP9 content processors handle encryption and pattern matching, which is why threat-protection throughput is always lower than firewall-only throughput.
- VDOMs give each tenant its own routing table, policies and administrators, joined by inter-VDOM links. FGCP HA fails over the whole cluster at once, so VDOM design and HA design are decided together.
- FGCP active-passive is the standard HA design; FGSP exists for external load balancers that need session mirroring without a shared cluster.
Security Fabric membership
- The Fabric has one root FortiGate. Root election uses the Fabric priority in
config system csf- the lowest value wins, with serial number breaking ties - so a default-128 headquarters pair can lose the root role to a branch unit someone gave a low priority. - Downstream FortiGates point at the root and must be authorized on it. FortiSwitch and FortiAP units managed over FortiLink appear as Fabric coworkers, not as independent CSF members.
- Fabric Connectors are the integration layer. External connectors (FortiClient EMS, FortiSandbox, FortiAnalyzer, cloud SDN, syslog) pull tags, inventory and verdicts; internal connectors expose local objects such as EMS tags as firewall addresses.
- Automation stitches pair a trigger (log event, schedule, fabric event) with actions (email, webhook, CLI script). A stitch fires only where it is configured, so fabric-wide events are normally handled by stitches on the root.
Worked example
A fabric holds HQ-1 (priority 128, FG-1801F), HQ-2 (priority 128, FG-1801F) and BR-1 (priority 20, FG-40F). BR-1 becomes root because 20 is lowest. Consequences: fabric topology views, FortiAnalyzer fabric logging and root-side automation now depend on a 40F with a small session table and no local log disk. The fix is to raise BR-1 to priority 200 or set HQ-1 to 10, then confirm FortiAnalyzer still receives logs from the new root serial.
Traps that cost marks
Confusing FortiLink management with Fabric membership; assuming the largest model is always root; forgetting the root must authorize joiners; expecting Security Rating to work without FortiAnalyzer or FortiGate Cloud; placing a stitch on a branch unit and expecting it to fire on headquarters events.