Hey everyone! 👋 We've been running FortiSASE for about six months now to secure our hybrid and remote teams. The SD-WAN piece is a big reason we chose it, especially the promise of automatic failover based on link performance. But I've always been a bit of a "trust, but verify" person when it comes to failover claims.
So last weekend, I finally carved out some time to *simulate* a full branch internet circuit failure to see if the SLA-based routing would kick in as advertised. I wanted to share the quick walkthrough and results because it was actually pretty smooth!
**My Setup:**
* A "branch" (really just a test office) with two internet connections: a primary business fiber line and a backup 5G wireless link.
* FortiSASE client on the test devices.
* SD-WAN SLA health check configured to ping `8.8.8.8` and measure latency/jitter.
**What I Did:**
1. In the FortiSASE portal, I went into the SD-WAN rules for that location.
2. I set the performance SLA for the primary link to a *very* strict threshold (e.g., max latency of 1ms) that I knew it would immediately fail.
3. Applied the change and then simulated the "failure" by simply unplugging the primary WAN cable to see how the system would react to a hard down scenario.
**The Good:**
* The switch to the backup 5G link was seamless for ongoing VoIP calls and video streams—no drops that the users would notice. The session persistence worked great.
* The portal dashboard updated the link status visually within about 30 seconds, which is good for admin awareness.
**A Quick Gotcha:**
* The pre-configured health check intervals are a bit conservative. For a truly mission-critical app, you'll want to tighten those up (more frequent pings) to fail over faster. It took about 90 seconds for the system to declare the link "dead" based on SLA, whereas the hard down was detected in ~15 seconds. Something to consider in your own rules.
Overall, I'm really pleased. This test gave me much more confidence in the setup for our actual remote locations. Has anyone else run similar "what-if" scenarios? I'm curious if you've tweaked the SLA settings for specific apps like Teams or your HRIS.
—Emma
Excellent approach! This "trust but verify" mentality is exactly what separates a stable SD-WAN deployment from a problematic one. I've found that simulating failure during a maintenance window is good, but you should also consider testing under *load* sometime.
One nuance I'd add: setting an impossible SLA threshold (like 1ms latency) is perfect for a clean test. But in production, remember that this kind of immediate, hard failover can cause session drops for things like VoIP or live database connections. For real-world rules, you might want to combine that strict SLA with a "degraded" threshold that triggers failover more gracefully, or use a probe failure count of, say, 3 out of 5 packets before declaring the link dead.
Did you notice any brief hiccups in the user experience on the test devices during the cutover, or was it seamless from their perspective? That's often the real proof.
You're spot on about testing under load. A clean maintenance window test is step one, but seeing how failover behaves during a 4pm Zoom crush is another.
> Did you notice any brief hiccups in the user experience
For our test, it was seamless for web browsing and SSH. But I agree, the real test is stateful apps. I'm planning a follow-up with a persistent video call and some large file transfers to see if those sessions hold. The probe failure count tweak you mentioned is a good call for that.
Setting that impossible SLA threshold was great for proving the mechanism works, but you're right, it's a sledgehammer. Production rules need a scalpel.
Ship fast, measure faster.
Stateful app testing is good, but you're still measuring the wrong thing. The real test isn't the failover event, it's the cost impact of routing over that backup 5G link.
Have you checked what your bandwidth charges are on the 5G line versus your primary fiber? You could have a perfectly seamless failover for that video call, then get a bill with a 300% overage because the 5G plan has brutal per-GB fees. A scalpel for performance but a sledgehammer to your budget.
Show me the line item cost difference for an hour of simulated 4pm Zoom crush traffic over each circuit. That's the SLA that matters.
show me the bill