Teams Quality Collapse Under SaaS-First SD-WAN Policy
A financial-services firm has a branch with a 100 Mbps MPLS circuit and a 300/50 Mbps broadband circuit. The branch runs a latency-sensitive trading application, Microsoft 365, and guest Wi-Fi. SD-WAN policy is ordered: (1) SaaS applications to broadband, (2) business applications to MPLS, (3) default to broadband. The path quality profile uses latency 150 ms, jitter 50 ms, and loss 3% thresholds. Users report that Microsoft Teams calls are poor even though the broadband circuit shows 120 ms latency, 70 ms jitter, and 1.5% loss; MPLS shows 60 ms latency, 5 ms jitter, and 0.1% loss. The SD-WAN monitor shows Teams matching the SaaS rule and staying on broadband. The MPLS circuit has ample capacity. The CIO wants a policy change that improves Teams without moving all SaaS traffic to MPLS.
1. Why does the current policy keep Teams on broadband, and what changes would you make to the policy and path quality profile?
Read the worked answer
Teams stays on broadband because the policy order matches the SaaS rule first and that rule effectively pins Teams to broadband. A path-quality profile does not override a rule that permits only one path; it only influences selection among paths the rule allows. In addition, the profile's jitter threshold of 50 ms is too loose for Teams, and the measured 70 ms should have excluded broadband-if the profile was actually attached to the SaaS rule. Check rule hit counters and the profile attachment before assuming the profile is active.
Make a Teams-specific rule above the general SaaS rule. Match Teams and other real-time media, allow both MPLS and broadband, and attach a stricter profile: latency 80 ms, jitter 20 ms, loss 0.5%. Use best available path rather than force-broadband. Keep general SaaS on broadband with its own profile so MPLS is not flooded. Add a failback hold time of 10–15 minutes to avoid flapping when broadband momentarily improves.
2. How would you prevent the change from shifting all SaaS traffic to MPLS and causing congestion?
Read the worked answer
Use application granularity, not a blanket SaaS rule change. Create a custom application or application filter that covers only real-time Teams media and put it above the general SaaS rule. Leave the general SaaS rule on broadband, but attach a path-quality profile that excludes broadband only when it violates the threshold. This keeps bulk SaaS-such as updates and file synchronization-on the larger broadband circuit while giving Teams the stable MPLS path.
Also check MPLS capacity and QoS. Reserve bandwidth for the trading application and Teams, and verify that the sum of business-critical traffic does not exceed the MPLS commit rate. If MPLS is 100 Mbps and already carries trading traffic, moving all SaaS would be unsafe; moving only Teams is manageable. Monitor per-application utilization and policy hit counts after the change.
3. What verification would you perform after the policy change?
Read the worked answer
Verify in this order:
- Policy match: Confirm Teams matches the new rule and the general SaaS rule's hit count drops only for Teams traffic.
- Path selection: Confirm Teams uses MPLS under normal conditions and moves to broadband only when MPLS violates the profile.
- Quality: Check path-quality graphs for latency, jitter, and loss before and after the change, and run test calls during a simulated broadband jitter spike.
- Capacity: Check MPLS utilization and QoS drops; ensure the trading application is not degraded.
- Failback: Confirm Teams returns to MPLS after the hold time when MPLS is healthy again.
If Teams still uses broadband, check rule order, application identification, and whether the Teams rule is in the correct policy scope.