HA Pair Stops Syncing After a New Tenant VDOM
Two FortiGate 200F appliances run FortiOS 7.6 in active-passive HA. The cluster carries six VDOMs, including a management VDOM and five customer VDOMs, with inter-VDOM links between each customer VDOM and a shared internet VDOM. Heartbeat is configured on port1 and port2, which are also the main inside and outside data interfaces; there is no dedicated heartbeat link. The primary has been up 214 days. After an engineer created a seventh VDOM named tenant7 on the primary and added its inter-VDOM link, the secondary GUI still shows only six VDOMs. HA status reports out of sync, and event logs show repeated HA heartbeat losses on port1 during backup windows. Both units are on the same firmware build and have valid licenses. The customer needs tenant7 available within two hours, but the team is reluctant to reboot either unit.
1. What should you check first to explain why tenant7 did not synchronize, and how do you confirm each cause?
Read the worked answer
Treat this as a synchronization failure, not a VDOM-creation failure. First verify the cluster view: diagnose sys ha status should show one primary, one secondary, and the correct group ID; diagnose sys ha checksum cluster shows per-VDOM checksums and quickly reveals whether tenant7 exists only on the primary. Confirm both units run the same firmware and VDOM mode with get system status, and confirm tenant7 is within the model's maximum VDOM count. Then check config system ha: heartbeat is on port1 and port2, the same ports that carry backup and user data. Heartbeat loss under load can cause config changes to be missed, so a new VDOM created during a heartbeat gap will not replicate. Also check whether the secondary was down or HA was disabled when tenant7 was created. If tenant7 is absent from the secondary's config vdom output, the cause is almost certainly missed sync, not a per-VDOM permission issue.
2. What heartbeat and synchronization design changes do you recommend for this cluster?
Read the worked answer
Separate HA control traffic from data. Use two dedicated heartbeat interfaces, directly cabled between the units, and configure them under config system ha with set hbdev port3 50 port4 50 or equivalent unused ports. Do not use ports that carry user or backup traffic. Keep at least two heartbeat paths so one cable or SFP failure does not split the cluster. Where the design allows, use a dedicated session-sync interface so session pickup does not compete with heartbeat. Review priority and override: leave override disabled unless preemption is required, because unnecessary preemption causes churn. After changing heartbeat, verify diagnose sys ha status shows both heartbeat devices up and no missed heartbeats. Then confirm config checksums match across all VDOMs before adding more objects.
3. Outline a low-risk procedure to bring tenant7 into sync without rebooting both units.
Read the worked answer
Back up both configurations and schedule a short window. On the primary, correct any local issue, then compare diagnose sys ha checksum cluster; do not trigger a full sync while the secondary has unique local objects that must survive. Confirm the secondary has no local-only policies or certificates. From the primary, run execute ha synchronize start and watch diagnose sys ha status and the checksum output until all VDOMs match. If the secondary still lacks tenant7, fail traffic to the secondary only if it is healthy, or rebuild the secondary from the primary backup; reboot one unit at a time, never both. After sync, verify tenant7 appears, its inter-VDOM link is up, and a test policy passes traffic. Document that future VDOM creation must be done while HA status is healthy.