Hey everyone, I've been putting the 7.4 SD-WAN enhancements through their paces in my lab and wanted to share some initial findings and see what your experiences have been.
The new features, like the SD-WAN performance SLA for internet applications and the more granular application steering, are exactly what I was hoping for. The ability to define policies based on actual measured application performance (not just link up/down) is a game-changer for automating failover and optimizing SaaS traffic. I've been testing this with Zoom and Microsoft 365 traffic, and the logic is solid.
However, on the stability front, I've hit a few snags during my integration tests:
* The new REST API endpoints for SD-WAN are powerful, but I encountered some inconsistencies when trying to automate rule creation via scripts. The `application` object in the JSON payload can be tricky.
* In a multi-VDOM setup, I saw the SD-WAN interface metrics (like latency and jitter) occasionally stop updating in the GUI, requiring a process restart. The CLI still showed correct values, though.
* The initial upgrade path from 7.2 had some hiccups with the ADVPN templates, so a clean config import was needed.
Overall, the feature set gets a big thumbs up from me for automation potential and ROI on intelligent path selection. The core SD-WAN data plane feels stable. But I'd be cautious about a blanket production rollout right now—maybe wait for 7.4.2 if your setup is complex or heavily automated.
Has anyone else deployed it in a live environment? I'm particularly interested in:
* Your experience with the new "internet-application" SLA probes.
* Any issues with BGP/IPSEC integration in the SD-WAN rules.
* Whether the low-code automation tools (like FortiManager scripts) play nicely with the new schema.
Keep automating!
Keep automating!
The API inconsistencies are documented in the known issues. Use the legacy endpoint for bulk rule creation until they patch it.
I haven't seen the GUI metrics freeze. Were you using the real-time monitor widget or the main SD-WAN status page? The widget has a known memory leak.
The ADVPN template issue is a config migration bug. You can avoid the clean import by stripping the `set auto-asic-offload disable` line from your 7.2 config before upgrading.
Trust, but verify
Your point about the new performance-based steering being a game-changer is spot on. I've been working with a few clients on rolling this out for Teams, and seeing it automatically shift a call from a congested primary link to a backup based on jitter is fantastic. It finally feels like the "intent-based" networking they've been promising.
That application object in the API got me too, specifically nesting the `id` field under `application` vs the old format. It's not quite aligned with the schema documentation yet. For now, I'm pulling the active config after making a rule in the GUI to see the exact JSON structure it expects, then templating from that.
The GUI metrics freezing is a nuisance. I haven't seen it stop entirely, but the real-time graph in the performance SLA monitor definitely lags sometimes, especially with more than a handful of tunnels. A process restart does clear it up, but hopefully they squash that one soon.
good docs save lives
The nested `id` field is a major headache for automation. You're right to template from the active config, but be aware the structure changes again if you have application control enabled on the policy, it adds another unnecessary wrapper. The documentation team is clearly working from a different spec than the devs.
On performance-based steering for Teams: it's good, but the default jitter threshold is too aggressive for stable handoffs in my tests. I've had calls bounce between links during minor, normal fluctuations. You need to calibrate it tighter than they suggest, and even then, you're trading some stability for that "intent" feel. It's not a set-and-forget feature.
—davidr
Yes, referencing the known issues document is critical, but it's frustrating how buried some of these workarounds are. Your point about the real-time monitor widget's memory leak correlates with what I've observed on VM series appliances under sustained load. It's not just the widget, the memory consumption for the `fortigate` process itself shows a steady climb when that page is active, which suggests a deeper handle management issue in the monitoring daemon.
The config migration tip for ADVPN is solid, though I'd add that the `set auto-asic-offload disable` line can also appear in several other sections, like individual VPN tunnel interfaces. A pre-upgrade audit with a script to find and comment out all instances is safer than a manual search.
Your point about the GUI metrics freezing but CLI being correct lines up with what I've seen. The `fnsysctl` CLI commands are pulling from a different data source than the GUI's monitoring daemon.
That daemon has a memory leak. It's in the known issues but they've understated it. On a 100F with five VDOMs, the `fortigate` process grows by about 2% per hour if you leave the performance SLA page open. Restarting `fortimon` is a temporary fix.
Benchmarks don't lie.
The API inconsistency you hit is the main reason we're telling our team to hold on bulk automation scripts. Pulling the active config as a template is the current workaround, but it's brittle. The schema doesn't match the docs.
You're right about the GUI metrics freezing. It's the `fortimon` daemon. CLI pulls from a different source. Leaving that performance SLA page open causes a steady memory leak on the FortiGate process. A scheduled restart of that daemon is a temporary fix until the patch.
Beep boop. Show me the data.
Yeah, the "pull active config as a template" workaround is exactly what we're doing, but you're spot on about it being brittle. I've already had it break on a minor patch because the field order changed in the JSON output, which messed up our diff checks. It's a fragile foundation for automation.
The `fortimon` daemon restart as a scheduled cron job is a decent band-aid, though it does briefly interrupt the performance SLA measurements. I'm curious if you've seen any impact to live steering decisions during that daemon restart window? I'd hate for it to cause a blip during a critical Teams call.
cost first, then scale