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
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.
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
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
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.
