ENSDWI Part 3: Edge Platforms and Cloud OnRamp
Part 3 closes out the Architecture domain with blueprint sections 1.2 (edge platforms and capabilities) and 1.3 (Cloud OnRamp). Both are “describe” topics — no configuration exhibits here — but Cloud OnRamp for SaaS in particular gets tested with scenario questions that assume you know the three access modes apart, so “describe” doesn’t mean shallow.
1.2 Edge platforms and capabilities
The two software families
Everything on the edge runs one of two operating systems:
- cEdge — IOS-XE SD-WAN. Cisco’s mainstream IOS-XE with the SD-WAN control stack integrated (one unified image since 17.2; the days of separate SD-WAN images are gone). This is the present and future of the platform.
- vEdge — ViptelaOS. The original Viptela hardware and software. Still supported for existing estates, explicitly not for new deployments, and the vEdge 100/1000/2000/5000 hardware has end-of-life dates attached. Some newer features (App-QoE, the full embedded security stack, config groups) never came to vEdge.
Hardware families to recognise
The exam won’t ask you to size a box from a throughput table, but it does expect you to place families:
| Family | Role |
|---|---|
| Catalyst 8200/8300 | Branch — the current ISR successors |
| Catalyst 8500 | Aggregation/hub — fixed high-throughput (QFP-based) |
| Catalyst 8000V | Virtual edge — ESXi/KVM/cloud marketplaces; also the DevNet/CML lab workhorse |
| ISR 1000/4000 | Previous-generation branch, fully supported cEdges |
| ASR 1000 | Previous-generation aggregation |
| ISR1100-X (vEdge 100 successors) | Can run either ViptelaOS or IOS-XE — a migration-path platform |
| Catalyst 8000 with Cellular / CG113/CG522 | LTE/5G transports |
Capability facts worth holding: all cEdges do the standard data-plane set (IPsec/GRE tunnels, BFD, app-route, deep packet inspection via SD-AVC); embedded security (Snort IPS, URL-F, AMP) needs sufficient memory (8 GB+) and a security-capable platform; App-QoE (DRE/TCP-opt) needs service-node-capable hardware — 8300/8500 with SSD, or external CSP.
Licensing in one paragraph
Cisco DNA subscription tiers — Essentials / Advantage / Premier — gate features, not hardware: Essentials covers basic SD-WAN (tunnels, app-route, basic policy), Advantage adds full policy, segmentation beyond a handful of VPNs, and Cloud OnRamp, Premier adds the security stack and SIG entitlements. Tier questions occasionally appear; the safe memory hook is “OnRamp = Advantage, security = Premier”.
1.3 Cloud OnRamp
Four variants, four different problems. The blueprint lists them as SaaS / IaaS / Colocation / Multicloud (Cloud and Interconnect), and the deep dive Part 6 walks the first two operationally — this post covers what the exam needs on all four.
1.3.a Cloud OnRamp for SaaS
Problem: Office 365, Salesforce, Webex et al. perform terribly when branch traffic backhauls to a DC before hitting the Internet. Solution: measure the quality of every candidate path to each SaaS application and steer per-application onto the best one.
Mechanics the exam tests:
- The edge sends HTTP probes (to app-specific well-known endpoints) out each candidate exit and computes a vQoE score (0–10) per application per path from loss and latency. Best score wins; steering re-evaluates continuously.
- Three access modes — know these apart:
- DIA (Direct Internet Access): branch has local Internet; probes and traffic exit locally.
- Gateway: branch has no usable local exit; SaaS traffic rides the overlay to a designated gateway site (DC or regional hub), which probes and exits. The comparison is then DIA-vs-gateway or gateway-vs-gateway.
- Client access (cloud-edge): for Webex-style services, the site itself hosts nothing — mode matters less; recognise the name.
- Enabled from vManage (Configuration → Cloud OnRamp for SaaS), needs SD-AVC enabled and DNS resolution on the probing interfaces. Monitoring shows per-app per-path vQoE — an exhibit favourite.
- For Office 365 specifically, integration with Microsoft’s informed network routing telemetry can feed Microsoft’s own per-URL categories into path choice.
1.3.b Cloud OnRamp for IaaS
Problem: extend the overlay to workloads in public cloud without hand-building IPsec. Solution: vManage orchestrates a pair of C8000V cloud gateways into the cloud provider and wires them to your VPCs/VNets.
- Supported clouds: AWS, Azure, GCP (GCP arrived later; AWS and Azure are the exam staples).
- In AWS: vManage creates a transit VPC (or attaches to a Transit Gateway) containing two C8000Vs, then maps host VPCs to it. Discovery and mapping of host VPCs happens from the vManage GUI with cloud-account credentials.
- In Azure: same pattern into a transit VNet or Azure Virtual WAN hub — the vWAN integration deploys the C8000V pair as an NVA inside Microsoft’s hub.
- The gateways are full fabric members: TLOCs, OMP, BFD, policy, just running in the cloud. Workload reachability is advertised into OMP like any service-side network.
- Know the words “host VPC/VNet” (workloads) vs “transit VPC/VNet” (gateways) and that mapping is done in vManage, not the cloud console.
If you run AWS/Azure day-to-day, the cloud on-ramp architecture pair on this site covers the same decision from a vendor-neutral angle.
1.3.c Cloud OnRamp for Colocation
Problem: regionalise services (firewalls, load balancers, WAN optimisation) without hairpinning everything through a distant DC. Solution: put a service cluster in a carrier-neutral colocation facility near the traffic.
Components to recognise:
- CSP (Cloud Services Platform) 5444/5456 x86 appliances hosting the VNFs.
- Catalyst 9500 switches as the cluster fabric.
- VNFs: virtual edges (C8000V), virtual firewalls (FTDv, ASAv, or third-party), and other services, stitched into service chains.
- Orchestrated from vManage as a cluster object; traffic is steered to the colo via normal control/data policy (service insertion — Part 10 territory).
The exam wants the concept and the component names, not CSP deployment detail.
1.3.d Multicloud and Interconnect
The v1.2 addition. Two halves:
- Cloud (Multicloud): the umbrella workflow in vManage that unifies IaaS on-ramps across AWS/Azure/GCP — one dashboard for cloud gateways, host discovery, and cloud-to-cloud routing intent (site-to-cloud, cloud-to-cloud via the fabric).
- Interconnect: vManage orchestrates a software-defined cloud interconnect (SDCI) provider — Megaport or Equinix Fabric — deploying a C8000V inside the provider’s fabric and buying virtual cross-connects (VXCs) to AWS Direct Connect / Azure ExpressRoute / Google partner interconnect on demand. You get private, SLA-backed cloud access provisioned from the same vManage workflow, no per-cloud IPsec over Internet.
Memory hook: Multicloud = your gateways in their cloud; Interconnect = your router in Megaport’s/Equinix’s fabric with private wires to every cloud.
Exam traps for this domain
- Don’t deploy new vEdge — any design answer proposing new ViptelaOS hardware is wrong by policy.
- Cloud OnRamp for SaaS needs SD-AVC; probes are HTTP, score is vQoE 0–10.
- Gateway mode exists precisely for branches without DIA — a question describing “no local Internet at branch, still want best SaaS path” is pointing at gateway mode.
- IaaS on-ramp gateways are C8000V pairs orchestrated by vManage — not native cloud VPN gateways.
- Colocation = CSP 5000 + Cat9500 + VNF service chains.
- Interconnect partners: Megaport, Equinix. If the answer says CenturyLink, keep reading.
That’s domain 1.0 done — 20% of the exam. Part 4 starts domain 2.0 with controller deployment: cloud vs on-prem hosting, installing the trio, and the scalability/redundancy design facts.