SDWSCS Part 10: Cloud OnRamp for SaaS

5 August 2026 CiscoSDWSCSSDWANCloud

Part 9 gave you the evidence that SaaS paths differ in quality; this part deploys the feature that acts on it. Cloud OnRamp for SaaS continuously probes the candidate exits a site could use to reach a SaaS application, scores each, and steers the application’s traffic onto the winner — per app, per site, automatically re-evaluated. I covered the architecture in the deep dive Part 6; this is the deployment pass the syllabus wants.

The problem, precisely

A site typically has more than one way to reach Microsoft 365: straight out the local broadband (DIA), out a second DIA circuit, or across the overlay to a gateway site (regional hub with premium peering) and out from there. Which is best differs per application — the path that wins for Salesforce may lose for Teams — and changes with time of day, ISP weather, and Microsoft’s own front-door routing. Static routing policy can’t track that; OnRamp for SaaS is the closed loop that does.

How the scoring works

For each enabled application and each candidate path, the edge (or gateway edge) sends periodic probes — HTTP pings to the application’s well-known endpoints — measuring loss and latency. These roll into the vQoE score, 0–10, computed per application per path. The best-scoring path gets the traffic; the decision is re-made continuously, with hysteresis so a marginal score difference doesn’t flap the exit.

Edge# show sdwan cloudexpress applications
APPLICATION   EXIT TYPE  INTERFACE   LATENCY  LOSS  VQE SCORE
office365     gateway    <via hub>   38       0     9
salesforce    local      GigE0/0/1   22       0     10
Edge# show sdwan cloudexpress local-exits
Edge# show sdwan cloudexpress gateway-exits

The three verification commands above are the whole operational surface: what did it score, what did it choose, and why.

Exit types

  • Local (DIA) exit — probe and break out from the site’s own transport(s). Needs NAT/DIA configured (ENSDWI Part 9) — OnRamp chooses among paths that already exist; it doesn’t create breakout.
  • Gateway exit — traffic rides the overlay to a designated gateway site and breaks out there. The gateway probes the SaaS side; the overlay leg’s quality is measured by the existing BFD/app-route machinery, and both legs contribute to the end-to-end score.
  • Client access / interface-specific variants cover the narrower topologies (e.g. sites that must use a specific transport for a specific app).

Design guidance that survives contact: make your regional hubs gateways (they have the peering and the security stack), enable local exits wherever Parts 2–5 built a secure DIA posture, and let the scores arbitrate. If a site has no local breakout by policy, OnRamp still earns its keep choosing which hub to gateway through.

The Microsoft 365 telemetry integration

For M365 specifically, probing gets an upgrade. Enable the Microsoft integration (vManage Cloud OnRamp for SaaS → enable Office 365, plus the telemetry opt-in with your Azure app registration) and two things happen:

  1. Informed URL/IP categorisation — the feature consumes Microsoft’s endpoint feed, so “Office 365 traffic” means Microsoft’s own current definition, per service category (Optimize / Allow / Default). Steering the Optimize category (Teams media, Exchange transport) is where the user-visible win lives.
  2. Microsoft-side telemetry — Microsoft shares per-path service health scores back, so path selection can weigh Microsoft’s view of each front door, not just your probe RTT. This is the differentiator the syllabus name-checks; know that it exists, what it adds, and that it requires the tenant-level opt-in.

The interaction with Part 8 bears repeating because it’s the classic deployment collision: OnRamp wants M365 on the fastest path; tenant restrictions want M365 auth flows through the inspected path (SIG). The clean resolution is category-level: steer Optimize-category media/transport traffic for performance, keep the login/auth domains in the decrypted SIG path where the tenant-restriction headers are injected. vManage’s application lists are granular enough to express that split — use it deliberately rather than discovering it in an incident.

Enablement checklist

  1. Dashboard → Cloud OnRamp for SaaS: enable the applications (Office 365, Webex, Salesforce, etc. — plus custom apps by domain/SaaS probe endpoint where the built-ins don’t cover you).
  2. Attach sites as DIA sites, gateway sites, or client sites (traffic arrives via gateways only).
  3. For M365: enable the Microsoft telemetry integration.
  4. Verify with the three cloudexpress commands, then watch the vManage per-app dashboard long enough to see a path decision change — if the winner never changes, either your paths are genuinely stable or your probes aren’t measuring what you think.

Next up, Part 11: the fabric grows into the cloud itself — Cloud OnRamp for Multicloud, automated transit gateways in AWS and vWAN hubs in Azure, and tag-driven intent mapping between VPCs and service VPNs.