Cisco Catalyst SD-WAN (formerly Cisco SD-WAN, originally Viptela) is the dominant enterprise SD-WAN platform in 2026. The architecture that Cisco bought from Viptela in 2017 and rebranded multiple times since is genuinely good: a clean four-component decomposition, a BGP-derived control protocol that network engineers already understand, and a deployment model that scales from single-branch pilots to 6,000-edge global deployments.
This article walks through the four components (vManage, vSmart, vBond, WAN Edge), the OMP control protocol, the cEdge vs vEdge distinction, and how the components interact during a typical fabric bring-up. If you are studying for ENSDWI, designing a Cisco SD-WAN deployment, or just trying to read a vSmart log file, this is the reference.
The Four Components
| Component | Form factor | Plane | Job |
|---|---|---|---|
| vManage (SD-WAN Manager) | VM (3 or 6 nodes for HA) | Management | UI, REST API, template engine, monitoring backend, certificate authority |
| vSmart controllers | VM (2-3 per region) | Control | OMP routing protocol; distributes routes and policy to WAN Edges |
| vBond orchestrator | VM (2 instances, internet-facing) | Orchestration | Authenticates new WAN Edges; bootstraps cert distribution |
| WAN Edge (cEdge or vEdge) | Hardware appliance or VM at every site | Data | Forms IPsec tunnels; enforces policy |
vManage (SD-WAN Manager)
vManage is the single GUI and REST API operators use to run the entire fabric. It is the heaviest component:
- Web UI (HTTPS, role-based access)
- REST API (full automation surface, called the SD-WAN API)
- Template engine that generates per-WAN Edge configurations from feature templates and device templates
- Telemetry collector and monitoring database
- Software image repository and upgrade orchestrator
- Built-in certificate authority for fabric certificates
HA is implemented as a clustered deployment: 3 nodes minimum (with a quorum requirement) or 6 nodes for high-scale deployments. The cluster shares a database backend; losing a single node has no operator-visible impact, losing two breaks operator access until quorum is restored.
Cisco renamed vManage to "SD-WAN Manager" in the 20.x release branch around 2023; older documentation still uses vManage. The two terms refer to the same product.
Practical implication: vManage is the day-2 ops experience. If your operators struggle with vManage, your SD-WAN deployment will feel hard to run regardless of how good the underlying fabric is.
vSmart Controllers
vSmarts are the control-plane brains. They run OMP (Overlay Management Protocol) sessions to every WAN Edge, distribute routes and policy, and serve as the central decision point for control-plane state.
Key facts:
- Lightweight VMs (no big database, no UI)
- Typically 2 or 3 per region for HA (Cisco recommends 3 for production)
- WAN Edges form OMP sessions to all vSmarts simultaneously and receive identical state
- vSmarts do not need to share state with each other; each independently produces the same OMP output
- vSmart failure is graceful: WAN Edges keep forwarding with cached OMP state, just cannot receive new policy updates
The number of vSmarts you need depends on the WAN Edge count, not on the management complexity. Each vSmart can handle thousands of OMP sessions. For a 1,000-edge fabric, 2 vSmarts active-active is plenty.
vBond Orchestrator
vBond is the bootstrap component. When a brand-new WAN Edge boots up at a branch, it needs to find the rest of the fabric. The sequence:
- WAN Edge boots, has DHCP-acquired IP and DNS.
- WAN Edge resolves a configured DNS name (e.g.
vbond.example.com) to vBond's public IP. - WAN Edge contacts vBond, presents its certificate (root-of-trust pre-installed at manufacturing or via PnP Connect).
- vBond authenticates the certificate, looks up the WAN Edge's organization, and replies with the IPs of vManage and vSmart for that organization.
- WAN Edge contacts vManage to download configuration, vSmarts to establish OMP, and is now part of the fabric.
vBond is internet-facing because new edges have not yet joined the private overlay - they have to reach vBond over the public internet on first boot. That is why vBond is architecturally separate: it has different security requirements (public IP, hardened, exposed) than the rest of the platform (which can live entirely behind firewalls).
You typically deploy 2 vBond instances behind a load balancer or DNS round-robin. They are stateless beyond their certificate database, so HA is straightforward.
WAN Edges: cEdge and vEdge
WAN Edges are the data-plane devices at every branch. They form the IPsec overlay tunnels, do DPI to identify applications, apply per-application policy, and enforce the SD-WAN's behavior on customer packets.
Two WAN Edge variants exist for historical reasons:
| Type | OS | Hardware | Status in 2026 |
|---|---|---|---|
| vEdge | Viptela OS | Original Viptela hardware (vEdge 100, 1000, 2000, 5000) | Legacy; end-of-sale; supported but not recommended for new deployments |
| cEdge | Cisco IOS-XE (SD-WAN image) | Catalyst 8000 series, ISR 4000, ASR 1000, ISR 1000, virtual cEdge | Default for all new deployments; full feature parity and beyond |
cEdge runs the same IOS-XE you might recognize from Catalyst 9000 switches and Catalyst 8000 routers, with an SD-WAN-specific image and control plane. It supports the full Cisco IOS feature set (advanced routing, QoS, security features, advanced application-aware steering) on top of the SD-WAN overlay.
Cisco has been migrating customers off vEdge since 2020. By 2026 the recommendation is cEdge for everything. New ENSDWI training and certifications focus on cEdge.
OMP: The Overlay Management Protocol
OMP is the BGP-style routing protocol vSmarts use to distribute fabric state to WAN Edges. If you understand BGP, OMP makes immediate sense - it is BGP with SD-WAN-specific extensions.
What OMP carries:
| OMP route type | Carries | BGP equivalent |
|---|---|---|
| OMP Routes | Customer routes (per-VPN), with the originating WAN Edge's TLOC list | Like BGP routes with extended community attributes |
| TLOC Routes | "Transport Locators" - each edge's transport identity (color + system IP + encapsulation) | No direct BGP equivalent; SD-WAN-specific |
| Service Routes | Where to find services (firewall, NAT) that traffic should traverse | BGP communities for service insertion |
The TLOC concept is what makes SD-WAN's transport-agnostic overlay work. Each WAN Edge has multiple TLOCs (one per transport: MPLS, Internet, LTE, etc.) identified by a "color" attribute. When the policy says "voice goes over MPLS", it really says "voice prefers TLOCs with color=mpls". Path selection is then a TLOC selection problem.
Policy in OMP works like BGP route policy: route maps, prefix lists, communities, set operations. If you have configured BGP route maps you have configured OMP policy. See the BGP cluster pillar for the foundational BGP concepts.
A Typical Fabric Bring-Up
The end-to-end sequence for spinning up a new SD-WAN fabric from scratch:
- Deploy vManage cluster. 3 VMs, configure clustering. This is the first component because it is the certificate authority for everything else.
- Deploy vBond instances. 2 VMs with public IPs. Register them with vManage. Configure DNS so the fabric's bootstrap name resolves to vBond.
- Deploy vSmart controllers. 2 or 3 VMs. Register them with vManage. They will establish OMP sessions to WAN Edges as those come online.
- Configure organization, certificates, root cert chain. All in vManage.
- Author feature templates and device templates in vManage. One device template per branch type; feature templates are the building blocks (interfaces, OMP, BGP, NAT, etc.).
- Onboard first WAN Edge. Plug in, power up, ZTP (Zero Touch Provisioning) flow runs: DHCP for IP, DNS to vBond, vBond authenticates and points to vManage, vManage pushes template, edge establishes OMP to vSmarts, fabric joins.
- Roll out remaining edges. Each one repeats step 6. Templates handle the per-site differences automatically.
The whole bring-up for a small fabric (3 vManages + 2 vBonds + 2 vSmarts + first 5 edges) is a 1-2 day effort. Subsequent edges onboard in minutes.
Scale Considerations
Cisco-published scale numbers for the platform in 2026:
| Component | Per-instance scale |
|---|---|
| vManage cluster (3-node) | Up to 2,000 WAN Edges |
| vManage cluster (6-node) | Up to 6,000 WAN Edges |
| vSmart controller | Thousands of OMP sessions; rarely the bottleneck |
| vBond instance | Hundreds of bootstrap requests per minute; rarely the bottleneck |
| cEdge (Catalyst 8500) | Up to 20+ Gbps SD-WAN throughput |
For very large deployments (3,000+ edges) the bottleneck is usually vManage's database; vSmart and vBond scale linearly without much fuss.
Day 2 and Beyond
The architecture handles the bring-up well. The harder part is operating it. Day-2 operations on Cisco Catalyst SD-WAN center on:
- Template lifecycle (one-off changes drift away from templates over time)
- Policy authoring (centralized policy is powerful but easy to author incorrectly)
- vManage performance (the cluster needs care as edge count grows)
- Software upgrades (rolling cEdges through new firmware without breaking tunnels)
- Observability (correlating "user says Salesforce slow" with vManage metrics)
For the operational depth argument, see Cisco SD-WAN in 2026: The Real Value Is Day-2 Operations.
Summary
Cisco Catalyst SD-WAN (formerly Viptela) decomposes into four components: vManage (management), vSmart (control), vBond (orchestration), and WAN Edge (data). The control protocol is OMP, a BGP-derived path-vector that distributes routes, TLOCs, and service advertisements. cEdge is the modern IOS-XE WAN Edge; vEdge is the legacy Viptela-OS variant that you should not deploy new.
If you understand BGP and the three-plane SD-WAN architectural model, the Cisco platform is straightforward. The difficulty is operational - templates, policy authoring, vManage performance at scale - rather than architectural. Bookmark the SD-WAN cluster pillar for the cross-vendor view, and the SD-WAN architecture article for the three-plane model that this Cisco-specific one fits into.