That's really smart to keep a template. I'm trying to wrap my head around SD-WAN for voice traffic. How detailed do you get with the custom jitter/latency SLA? Like, what thresholds are you actually measuring against?
The VoIP jitter issue with SD-WAN is a classic case of probes not matching actual traffic. Setting a custom SLA for RTP is the right move, but you also need to verify the application policies. An SD-WAN rule for voice needs to be placed above any generic "all traffic" rule, or it won't be evaluated. Also, check if `set shortest-path` is enabled for that rule, which can sometimes bypass performance-based decisions.
Commit early, deploy often, but always rollback-ready.
Good point about rule order. It's an easy miss in the GUI when you're dragging rules around.
> check if `set shortest-path` is enabled
That's the killer. It'll pick the lowest cost route every time, ignoring all your jitter and latency thresholds. Took me a full day to realize that was why calls were still dropping.
metrics not myths
Ah, the "on paper" deployment. We've all been there. Your VPN mesh pain is a rite of passage - that template you wish you had? Write it now, even after the fact. It'll save you during the next hardware refresh or when you inevitably have to rebuild a spoke.
For the SD-WAN and VoIP jitter, everyone's chasing the custom SLA, but the real culprit is often simpler. Did you actually create a dedicated traffic shaping policy for the voice VLAN, or just rely on the SD-WAN rule? The firewall needs explicit instructions to queue that traffic as real-time, otherwise it gets dumped in the generic bucket with everything else.
Absolutely. That config snippet for VPN parameters is a lifesaver. I've been burned by mismatched DH groups between sites more times than I care to admit.
> tie it to a performance rule, and ensure its path preference overrides the general rule
This is the critical step. I've seen setups where the custom SLA was perfect, but the SD-WAN rule for "all traffic" sat above it in the list. The firewall just never got around to checking the voice rule.
Do you keep your templates in a git repo or use FortiManager?
Data is the new oil - but it's usually crude.
The mismatched DH groups point is a perfect example of why we treat VPN parameters as a single, immutable object. We actually compile them into a JSON template that gets injected during site provisioning, so the phase1 and phase2 definitions are atomic. If you edit one, you're forced to regenerate the entire block.
>Do you keep your templates in a git repo or use FortiManager?
Both, but they serve different purposes. FortiManager is for the operational deployment and drift detection, but we keep the canonical source templates in Git. This gives us versioning, pull requests for changes, and the ability to run a basic syntax check before anything hits a device. The key is the sync process; we have a pipeline that pushes approved changes from a Git tag to a specific ADOM in FortiManager, which then handles the staged rollout.
That said, even with FortiManager, rule order evaluation is still sequential and left-to-right in the GUI. Our CI pipeline now includes a validation step that parses the generated config to ensure any SD-WAN rule with a performance SLA sits higher in the list than any generic "all" rule. It catches ordering mistakes before they can cause an outage.
— Harper
Right, the inherited test config is such a sneaky problem. It's not just about the connection to the hub, it can create an invisible asymmetry where Spoke A can talk to the hub and Spoke B, but Spoke B can't initiate back to Spoke A because of a mismatch in their P2 proposals.
That policy order fix seems simple, but it gets overlooked because the GUI shows the shaper is attached correctly. You really have to train yourself to check the policy list view first.
Oh, the policy list view. That's something I wouldn't have known to check. It makes sense that the GUI might show everything attached correctly in one place, but the actual order of processing is somewhere else.
When you talk about an invisible asymmetry between spokes, is that something a basic ping test would even catch, or does it only show up with specific traffic?