Cisco Catalyst SD-WAN is what used to be called Cisco SD-WAN, which used to be called Viptela. The name has changed three times in six years, and that churn is itself a source of confusion: engineers searching for "Viptela" and engineers searching for "Catalyst SD-WAN" are looking for the same product. This post clears up the naming, explains what Catalyst SD-WAN actually is, and walks through the architecture so the rebrand stops being a barrier to understanding it.
For the broader technology, see the SD-WAN complete guide.
The naming history, settled
| Era | Name | What changed |
|---|---|---|
| Pre-2017 | Viptela | Independent SD-WAN startup |
| 2017 | Cisco acquires Viptela | Becomes "Cisco SD-WAN" |
| 2020-2022 | Cisco SD-WAN | vEdge hardware phased out; cEdge (IOS XE) becomes the platform |
| 2023 onward | Cisco Catalyst SD-WAN | Rebranded under the Catalyst umbrella to align with Catalyst switching and wireless |
It is all the same product line. The "Catalyst SD-WAN" name signals that the edge runs Cisco IOS XE (the same OS as Catalyst routers and switches) rather than the old Viptela OS. If you read older documentation that says "Cisco SD-WAN" or "Viptela," it is describing this product. The controller components kept their names through the rebrand.
What Catalyst SD-WAN is
Catalyst SD-WAN is Cisco's overlay SD-WAN solution: a software-defined WAN where a centralized controller plane manages policy and a distributed set of edge routers builds an encrypted overlay across whatever transport is available (MPLS, broadband, LTE, 5G). It is transport-independent, application-aware, and centrally orchestrated - the standard SD-WAN value proposition, delivered the Cisco way.
The thing that distinguishes Catalyst SD-WAN from competitors is the IOS XE edge. Because the cEdge runs the same OS as a normal Catalyst router, you get the full IOS XE feature set - rich routing, QoS, security - on the same box that does the SD-WAN overlay. There is no separate "SD-WAN appliance" with a reduced feature set.
The four-plane architecture
Catalyst SD-WAN splits cleanly into four planes. Each has a named component.
| Plane | Component | Role |
|---|---|---|
| Management | Catalyst SD-WAN Manager (formerly vManage) | The single dashboard. Policy authoring, templates, monitoring, troubleshooting, software management. |
| Orchestration | Catalyst SD-WAN Validator (formerly vBond) | Authenticates every device joining the fabric, brokers the initial control connections, and helps devices behind NAT find each other. |
| Control | Catalyst SD-WAN Controller (formerly vSmart) | The brain. Distributes routing (via OMP) and policy to all edges. Edges never peer directly for control - they all talk to the Controller. |
| Data | cEdge routers (IOS XE) | The edges themselves. They build the IPsec overlay tunnels and forward traffic. |
Note the rebrand renamed the controllers too: vManage, vBond, and vSmart are now Manager, Validator, and Controller. Older docs and the CLI still surface the v-names in places, so know both.
OMP: the routing protocol of the fabric
The piece that makes Catalyst SD-WAN tick is OMP - the Overlay Management Protocol. OMP is to the SD-WAN overlay what BGP is to the internet: it is how routes, TLOC (Transport Locator) information, and service routes are distributed.
Every cEdge has an OMP session to the Controller. The edge advertises its local prefixes and its TLOCs (essentially "here is how to reach me, over these transports") up to the Controller. The Controller applies policy and reflects the information back down to other edges. No edge runs a full routing table of every other edge's details - the Controller is the route reflector for the entire fabric.
This is why the Controller is the control plane: pull it out and existing tunnels keep forwarding for a while, but no new routing information propagates and policy changes stop.
How an edge joins the fabric
The bring-up sequence, simplified:
- A new cEdge powers on with a minimal config and a certificate (or a one-time password / Plug-and-Play profile).
- It reaches out to the Validator. The Validator authenticates the device and tells it where the Manager and Controllers are.
- The edge forms control connections to the Controllers.
- The Manager pushes the device's full configuration via a template or a configuration group.
- The edge brings up IPsec data-plane tunnels to other edges, builds its OMP routing, and starts forwarding.
The point of this flow is zero-touch provisioning. A branch router can be drop-shipped to a site, plugged in by someone non-technical, and configure itself from the Manager. The Validator is the trust anchor that makes that safe.
Configuration model: templates and configuration groups
You do not SSH into Catalyst SD-WAN cEdges and type config the way you would a normal router. You configure them from the Manager using one of two models:
- Feature templates / device templates - the original model. Feature templates define reusable config blocks (a VPN, an interface, an OSPF instance); device templates assemble them per device.
- Configuration groups - the newer, simpler model introduced to reduce the template sprawl. Group-based, with a more intuitive UI.
Either way, the principle is the same: configuration is centralized, version-controlled in the Manager, and pushed - not typed per box. This is the operational shift that trips up engineers coming from traditional IOS: the router's running-config is an output of the Manager, not something you edit directly.
Where Catalyst SD-WAN fits vs alternatives
| Solution | Best fit |
|---|---|
| Catalyst SD-WAN | Cisco-standardized enterprises wanting deep IOS XE feature parity, strong cloud on-ramps, and integration with Cisco security (Umbrella, SSE). |
| Meraki SD-WAN | Lean-IT organizations wanting the simplest possible cloud-managed experience; trades depth for ease. |
| Fortinet / VMware / Versa | Covered in the SD-WAN pillar - chosen on price, security-stack integration, or single-vendor SASE ambitions. |
Within the Cisco portfolio, the choice is usually Catalyst SD-WAN vs Meraki SD-WAN. Catalyst is the more capable, more configurable platform; Meraki is the simpler, more opinionated one. Larger and more complex networks tend to land on Catalyst.
Common points of confusion
| Confusion | Clarification |
|---|---|
| "Is Viptela still a thing?" | Yes, it is just renamed. Viptela = Cisco SD-WAN = Catalyst SD-WAN, same product line. |
| "vEdge vs cEdge?" | vEdge ran Viptela OS and is end-of-sale. cEdge runs IOS XE and is the current platform. |
| "vManage / vBond / vSmart vs Manager / Validator / Controller?" | Same components, post-rebrand names. Both appear in current docs. |
| "Do I configure the routers directly?" | No. Configuration is centralized in the Manager via templates or configuration groups. |
Key takeaways
Cisco Catalyst SD-WAN is the rebranded, IOS XE-based evolution of Cisco SD-WAN (originally Viptela). It uses a four-plane architecture - Manager, Validator, Controller, and cEdge data plane - tied together by OMP, the overlay routing protocol. Edges join the fabric through a zero-touch flow anchored by the Validator, and they are configured centrally from the Manager rather than box-by-box. If you understand the four planes and OMP, the rebrand stops mattering: it is the same architecture under every name it has carried.
For the broader SD-WAN cluster, see the SD-WAN pillar.
