MSSP SD-WAN Template Drift Across 150 Devices
An MSSP manages 150 FortiGate 60F and 100F devices with FortiManager and FortiAnalyzer. SD-WAN is delivered from a central SD-WAN template with metadata variables for two WAN interfaces, a health check to 203.0.113.10, and two rules: voice over WAN1 and business over WAN2. After a FortiManager upgrade, 30 devices report the WAN2 member as dead and voice stops failing over from WAN1. The template installs without errors. On one affected device, diagnose sys sdwan health-check status shows probe timeouts, and diagnose sys sdwan service shows the voice rule in manual mode with only WAN1. The customer wants one central fix, an audit trail, and no per-device CLI. A hardware refresh also changed the secondary WAN interface name on 10 of the 30 devices.
1. Separate the two faults and describe the confirmation steps.
Read the worked answer
Fault one is the health check: the probe target 203.0.113.10 is in the TEST-NET-3 documentation range and is not routable on the internet, so WAN2 is marked dead. Fault two is the service rule: it is in manual mode and lists only WAN1, so even a healthy WAN2 would not be used and no SLA failover can occur. Confirm with diagnose sys sdwan health-check status, diagnose sys sdwan service, a packet capture on WAN2, and get system sdwan for the actual config. On FortiManager, use install preview and the policy diff to see what the template actually pushes. The interface rename on 10 devices is a third, separate mapping issue; check the per-device metadata and the normalized interface list.
2. What is the central fix, and how do you prevent drift?
Read the worked answer
Change the template health check to a reachable target per member, for example the provider PE or a public anycast DNS, and set the source to the member interface. Change the voice service to SLA mode, reference the SLA, and include WAN1 and WAN2 in the correct priority. For the renamed interfaces, update the metadata variables or per-device mappings and reinstall from the template, not by CLI. Use install preview, then install to a pilot group, then the rest. Keep the FortiManager revision and install log as the audit trail; FortiAnalyzer keeps the SD-WAN SLA logs. Add a post-install check that compares diagnose sys sdwan health-check status on a sample of devices and flags dead members. Do not use a CLI script to patch 30 devices unless it is stored as a template so it is repeatable.
3. How do you validate failover end-to-end after the fix?
Read the worked answer
On a pilot device, force WAN1 down and confirm that the voice rule moves to WAN2 in diagnose sys sdwan service and that the health check marks WAN1 dead within the intended interval. Generate a voice call and confirm the session survives or re-establishes cleanly, then restore WAN1 and confirm failback. Check FortiAnalyzer for SD-WAN SLA and traffic logs showing the member change, and compare the FortiManager install history with the device revision to prove the template was applied. Repeat the test on one device with the renamed secondary interface to prove the mapping fix. Only then roll the template to the remaining affected devices.