Cisco Catalyst SD-WAN Deep Dive Part 1: Components, Controllers, and the Four Planes
Every SD-WAN platform on this site so far — Fortinet’s ADVPN-based fabric, the Arista/VMware overlay, VeloCloud’s partner-gateway model — has its own opinion about where control, management, and orchestration should live. Cisco’s is the one most engineers will actually run into in a CCNP-track shop, because it’s the one with the certification track behind it and the largest installed base of inherited Viptela kit. It’s also the most cleanly decomposed of the four: where Fortinet folds control into the data-plane devices themselves via IBGP/ADVPN, Cisco splits the job across four distinct controller roles. That decomposition is the whole subject of this post.
This is part 1 of a ten-part series. We’re starting at the bottom — what the pieces are and how they find each other — before going anywhere near a routing table.
A Viptela box wearing a Cisco badge
Cisco didn’t build this architecture. Viptela did, starting around 2012, and Cisco acquired the company in 2017 for roughly $610M because building a credible SD-WAN controller stack from scratch would have taken longer than buying one that already worked. For the first few years post-acquisition the product was sold as “Cisco SD-WAN” running on Viptela’s own operating system (vEdge devices, ViptelaOS) plus the original vManage/vSmart/vBond controller trio, largely unchanged.
The branding has since settled on Cisco Catalyst SD-WAN, and the underlying shift that matters more than the name change is the move from ViptelaOS edges to cEdge — Cisco’s existing IOS-XE software with the SD-WAN feature set bolted on, running on ISR1000/4000, ASR1000, and Catalyst 8000 series hardware. The original vEdge appliances (100, 1000, 2000, 5000 series, plus the vEdge Cloud virtual edge) still exist, are still supported, and you will still find them in production at any customer who bought in early and hasn’t done a forklift refresh. Cisco’s own guidance is blunt: don’t deploy new vEdge. cEdge is where the platform investment goes now, and the IOS-XE convergence means a Catalyst SD-WAN edge can also run traditional IOS-XE features (NAT, ACLs, AAA, VRF-lite, the works) right alongside the SD-WAN data plane — something a pure-play ViptelaOS box was never going to get.
Keep both names in your head as you read the next nine parts: vEdge = legacy ViptelaOS hardware, cEdge = current IOS-XE hardware. Most of what follows applies to both; where the forwarding internals genuinely differ, I’ll call it out explicitly (that’s most of Part 4).
Four planes, not three
Fortinet’s SD-WAN fabric, VeloCloud’s, and Arista’s all describe themselves with a three-plane model: management, control, data. Cisco Catalyst SD-WAN insists on a fourth, and it’s not just marketing — the orchestration function genuinely is a separate, stateless role that the other vendors usually fold into the control or management plane. The four are:
| Plane | Component | Job | Persistent state? |
|---|---|---|---|
| Orchestration | vBond | First point of contact for a new edge; NAT detection; hands out controller addresses | No |
| Management | vManage | GUI/API, templates, monitoring, software/cert lifecycle | Yes (config DB) |
| Control | vSmart | OMP route reflection, centralized policy enforcement | Yes (OMP RIB) |
| Data | WAN Edge (vEdge/cEdge) | Actual packet forwarding, IPsec tunnel termination | Yes (forwarding tables) |
vBond — the orchestrator
vBond’s entire job is matchmaking, and it’s deliberately the dumbest, most stateless component in the stack so it can be scaled out trivially (anycast, multiple instances, no clustering complexity to worry about). When a new WAN Edge boots for the first time, it doesn’t know where vManage or vSmart live — all it has from its day-0 bootstrap (PnP, USB, or a minimal config) is a vBond address. The edge opens a DTLS (or TLS, depending on transport) session to vBond, and vBond:
- Validates the edge’s certificate against the configured root CA
- Performs NAT detection for the edge (is it behind NAT, and what kind — this matters a lot once we get to TLOC behavior in Part 3)
- Returns the list of vManage and vSmart addresses for the edge’s organization and site
That’s it. vBond never sits in the data path, never holds routing state, and once an edge has successfully connected to vManage and vSmart it doesn’t need vBond again until those addresses change or the edge reboots cold. If you’ve worked with STUN servers for NAT traversal in any other context, the conceptual shape is familiar — vBond is doing something analogous for the overlay’s control connections.
vManage — the management plane
vManage is the thing humans actually look at: a GUI (and a full REST API underneath it — we’ll spend all of Part 8 on that) for device templates, feature templates, software image management, certificate distribution, and monitoring dashboards. Architecturally it’s the closest analogue to FortiManager in the Fortinet world, or the Orchestrator in VeloCloud’s — a centralized config and visibility plane that pushes intent down to the devices that actually do the work.
It’s also the component with the worst scaling story, and that’s worth knowing before you’re staring at a multi-thousand-edge design. A single vManage instance is fine for small deployments; anything serious runs a cluster of at least three instances for HA, fronted by a load balancer for the NMS/UI traffic. Past roughly 2,000–3,000 edges, the bottleneck is almost never vSmart or vBond — both of those scale close to linearly because their per-edge workload is small and stateless-ish. It’s vManage’s underlying database (NMS) that starts to strain, because every device, every template render, every statistics poll lands there. We’ll come back to this with real numbers in Part 10 when we cover scale limits properly; for now, just file away that “add another vManage node” is not always the answer once you’re north of a few thousand edges.
vSmart — the control plane
vSmart is where this series is really headed, because vSmart is the thing running OMP (Overlay Management Protocol) — a control protocol that is deliberately, heavily borrowed from BGP. If you’ve read the BGP route-dampening posts on this site, a lot of OMP’s vocabulary will feel immediately familiar: it’s a path-vector protocol, it has its own AFI-like route types, and the relationship between a WAN Edge and a vSmart is structurally a route-reflector relationship, not a full-mesh peering. Every edge peers with every vSmart in its domain (not with other edges directly), and vSmart reflects routes between them — exactly the problem BGP route reflectors solve for iBGP full-mesh scaling, applied to the overlay.
I’m deliberately not going deep on OMP mechanics in this post — that’s the entirety of Part 2 and Part 3. What matters here is vSmart’s role: it’s the only component in the four that holds full visibility into the overlay’s routing state, and it’s the enforcement point for centralized control policy (which sites can talk to which, which TLOCs are preferred, route filtering — again, all properly covered in Part 3). You can and usually do run multiple vSmarts per domain for redundancy; they don’t peer with each other directly, they each independently peer with every edge and converge on the same view because every edge tells every vSmart the same thing.
WAN Edge — the data plane
The edge is the box actually carrying traffic — terminating IPsec tunnels to other edges, running BFD over those tunnels, making forwarding decisions, and (on cEdge specifically) doing all the IOS-XE things a router has always done. This is the only plane where the vEdge/cEdge split actually changes behavior rather than just branding, and it’s substantial enough that it gets its own section in Part 4. For now: every WAN Edge, vEdge or cEdge, holds a unique device certificate, maintains persistent DTLS/TLS control connections to vManage and every vSmart in-domain, and builds IPsec data tunnels to other edges based on what OMP tells it.
The certificate trust model
Nothing in this architecture works without certificates, and it’s worth being precise about this because it trips people up coming from a PSK-based world (if you’ve read the Fortinet IPsec PKI series, the motivation will sound familiar — pre-shared keys don’t scale past a handful of sites, certificates do).
Every controller (vManage, vSmart, vBond) and every WAN Edge gets a unique identity certificate. For controllers, this is typically issued from a Cisco-operated root (or an enterprise CA if you’ve gone that route via the enterprise-CA workflow), and the certs are what controllers use to authenticate to each other — vManage trusts vSmart, vSmart trusts vBond, and so on, all mutually, via the same root of trust. For WAN Edges, the model depends on hardware: Cisco-manufactured devices ship with a unique chassis-bound serial number and certificate baked in at the factory (signed by a Cisco root); on virtual edges (vEdge Cloud, or cEdge running as a virtual platform) there’s no factory-injected identity, so you generate and sign a CSR through vManage against your chosen root instead.
The practical upshot: all control-plane and orchestration-plane connections in this architecture are mutually authenticated via certificate, not by a shared secret, not by IP allow-listing. An edge that can’t present a cert the root trusts never gets past vBond, full stop. This is also why decommissioning a device properly (revoking/invalidating its certificate in vManage) matters more here than in a PSK world — a stolen PSK is a config change away from being neutered; a stolen-but-still-valid edge certificate is a live identity in your overlay until someone explicitly revokes it.
How an edge actually comes up
Put the four roles together and the bring-up sequence for a brand-new WAN Edge looks like this:
- Day-0 bootstrap. The edge gets a minimal config — at minimum, an address (or DNS name) for vBond, and enough underlay reachability (DHCP, static, or PnP-assisted) to reach it. This can come from a USB stick, ZTP/PnP, or manual CLI.
- Orchestration handshake. The edge opens a DTLS session to vBond, presents its certificate, and vBond validates it against the root CA. Assuming it’s valid, vBond performs NAT detection for the edge and returns the addresses of the vManage and vSmart(s) serving this edge’s organization.
- Management plane connection. The edge opens a persistent DTLS/TLS control connection to vManage. vManage pushes the edge’s full device configuration — feature templates, device templates, whatever’s been defined for that site.
- Control plane connections. The edge opens a persistent DTLS/TLS control connection to every vSmart in its domain (this is the full-mesh-to-vSmart, not full-mesh-to-other-edges, relationship mentioned above).
- OMP comes up. Once the control connection to a vSmart is established, the edge and vSmart exchange OMP routes over it — the edge advertises what it can reach (its TLOCs, its local service routes), vSmart reflects what every other edge in scope has advertised.
- Data plane tunnels form. Armed with OMP-learned TLOC information, the edge builds IPsec tunnels directly to other edges it needs to reach — this is the only point in the whole sequence where two WAN Edges talk to each other directly rather than via a controller. BFD comes up over each tunnel immediately after, which is what later detects path failure (covered properly in Part 4).
A simplified show control connections from a healthy cEdge gives you a feel for what step 3/4 looks like once it’s settled:
PEER PEER PEER SITE DOMAIN PEER PRIV PEER PUB
TYPE PROT SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE
vmanage dtls 10.1.0.1 100 0 10.1.0.1 12546 10.1.0.1 12546 biz-internet up
vsmart dtls 10.1.0.2 100 1 10.1.0.2 12546 10.1.0.2 12546 biz-internet up
vsmart dtls 10.1.0.3 100 1 10.1.0.3 12546 10.1.0.3 12546 mpls up
vbond dtls - 0 0 198.51.100.9 12346 198.51.100.9 12346 biz-internet up(COLOR here is a TLOC concept we haven’t earned yet — that’s Part 3. For now just notice that the same edge has separate control connections per transport, which is your first hint that TLOCs, not interfaces, are the real unit of identity in this architecture.)
Where this leaves us next to the rest of the site
If you’ve read the Arista/VMware deep dive, the shape here will feel like a cousin, not a stranger — Edge Connect ≈ WAN Edge, the Orchestrator ≈ vManage, and Arista’s Gateways do double duty that Cisco splits between vSmart’s control function and the data-plane hub role an edge plays. Against Fortinet, the comparison is sharper: FortiGates doing ADVPN have no separate control-plane controller at all — control and data collapse onto the same box, with FortiManager strictly out of the data and control path, push-config-only. Cisco’s insistence on a dedicated, stateful control plane (vSmart) is the single biggest architectural fork between “Viptela-lineage” SD-WAN and “firewall-grew-an-overlay” SD-WAN, and it’s the reason the next two posts exist as their own thing rather than a paragraph each.
That dedicated control plane is also exactly where the IPsec tunnels we just hand-waved into existence in step 6 get their parameters — and if you want the underlying mechanics of what an ESP packet actually looks like once those tunnels are up, the IPsec deep dive series is the companion reading; Cisco’s data-plane tunnels are IPsec underneath the OMP-driven orchestration, same ESP fields, same phase-2-style rekey concerns.
Part 2 picks up exactly where step 5 left off: what an OMP route actually contains, how it differs from a TLOC route and a service route, and why vSmart reflecting routes between edges is structurally identical to a BGP route reflector solving the iBGP full-mesh problem — right down to being able to break it the same ways.