What's changed: Initial version
1.2Cisco Catalyst SD-WAN
Covers how responsibilities are split across vSmart (control), vManage (SD-WAN Manager) (management), vBond (orchestration), and cEdge/vEdge (data plane); route distribution via OMP; and the benefits of centralized policy and circuit-cost optimization against the limits of controller dependence—framed as diagnosing "which component to suspect" during a fault.
In a traditional WAN you logged into the router at each site and configured routes and policy individually. Cisco Catalyst SD-WAN (formerly Viptela) separates control—deciding how routes are chosen—from data forwarding, which actually carries packets, and centralizes control on controllers so that configuration effort does not grow linearly with the number of sites. What ENCOR asks is not a list of product names but the diagnosis of how responsibility is divided across the four components and what stops, and what does not, when one of them fails.
1.2.1Component responsibilities
- vSmart is the control plane. It aggregates routes, TLOCs (transport locations), and service information received from each edge via OMP (Overlay Management Protocol), applies policy, and redistributes them to the edges. It sits in a role close to a BGP route reflector, and the key point is that edges do not exchange routes directly with each other but learn through vSmart.
- vManage (SD-WAN Manager) is the management plane. It provides centralized configuration via GUI/API (templates), monitoring, software management, and the entry point for troubleshooting. It is the window for configuration change and visibility, not directly involved in forwarding decisions or route distribution. Consequently, if vManage goes down, data forwarding continues under the configuration already pushed.
- vBond is the orchestration plane. It authenticates new or rebooted edges and tells them where vSmart and vManage are, acting as the broker that admits them to the fabric. It also handles NAT traversal for edges behind NAT. It is not involved in steady-state route distribution, but its impact shows up as an edge that cannot reach vBond cannot onboard.
- cEdge/vEdge is the data plane: the routers that actually forward traffic, deployed at sites and data centers. IPsec tunnels are built between edges, and each edge decides which transport (MPLS, internet, LTE, etc.) to use according to the routes and policy received from vSmart. Lineage differs: cEdge is IOS XE based while vEdge is Viptela OS based.
1.2.2Benefits and limits
- Benefits: circuit-cost optimization (bundling inexpensive internet and LTE alongside costly MPLS and choosing per application), centralized policy (applying templates and policy from vManage/vSmart at once, suppressing per-site configuration drift), near zero-touch deployment (onboarding via vBond), and visibility (per-application performance monitoring with dynamic path switching).
- Limits: controller dependence (with control and management centralized, controller availability and reachability become new design problems), learning/migration cost (a template and policy model distinct from traditional routing operations must be learned), and more troubleshooting layers (you must separate an overlay fault from a fault on the underlying transport circuit). Design-wise it matters that SD-WAN does not make the circuit quality itself better.
1.2.3Route distribution via OMP and fault isolation
- OMP exchanges OMP routes (destination prefixes), TLOCs (which transport and attachment point a destination is reachable through), and service routes (where services such as firewalls are inserted) between edges and vSmart. Because edges build the overlay forwarding table from what vSmart provides, losing the control connection to vSmart means no new route information arrives.
- Isolation principles: a vManage outage means no configuration change or monitoring but data forwarding continues; a vSmart outage stops new route distribution and policy updates so the fabric cannot follow topology changes; a vBond outage leaves existing communication alone but blocks onboarding of new edges. If "all sites lose connectivity simultaneously," the first suspect is not a controller but the shared transport circuit.
Most-tested is the role mapping: vSmart = control plane (aggregates and redistributes routes via OMP, route-reflector-like); vManage = management plane (the window for configuration/monitoring, not involved in forwarding); vBond = orchestration (authentication, onboarding, NAT traversal); cEdge/vEdge = data plane (actual forwarding over IPsec tunnels). On top of that, "what stops when which one fails" is the classic diagnostic question, and the point that data forwarding does not stop during a vManage outage is especially targeted.
Suppose you operate 40 sites on Catalyst SD-WAN and one morning receive a report that "we cannot log into the vManage GUI." The first thing to confirm is whether site business traffic has actually stopped. Checking with users, applications between existing sites work normally and only the monitoring dashboard is unavailable. From this you can conclude the fault is confined to the management plane. vManage handles pushing configuration templates and providing visibility, but edges keep forwarding autonomously according to the configuration they already hold and the OMP routes learned from vSmart—so the data plane keeps running even when vManage is down. Deciding at this point to "reboot every edge to try to recover" is therefore the worst possible move: on their way back, rebooted edges need reachability to vBond and a re-established control connection to vSmart, so you would promote a management-only fault into a genuine outage with traffic loss. The correct procedure is to check vManage's own availability (other nodes if clustered, the path to it, certificate expiry) while, in parallel, running the edge-side equivalent of show sdwan control connections to confirm that control connections to vSmart remain up. Conversely, if the report were "only one site cannot reach the newly built site," the suspect is not vManage but policy application on vSmart (a TLOC or prefix filter unintentionally withholding routes) or onboarding of the new site (vBond reachability, certificates). And if "all sites lost only the internet-transport tunnels at the same time," the proper first suspect is the shared transport circuit (the ISP side), not a controller. SD-WAN troubleshooting narrows to a single component when you isolate along two axes: the scope of the symptom (all sites or some) and the kind of function that stopped (forwarding, configuration change, or new admission).
| Component | Plane | Primary responsibility | What stops if it fails |
|---|---|---|---|
| vSmart | Control | Aggregates routes/TLOCs via OMP, applies policy, and redistributes | New route distribution and policy updates (cannot follow topology change) |
| vManage (SD-WAN Manager) | Management | Template push, monitoring, software management | Configuration change and visibility only (forwarding continues) |
| vBond | Orchestration | Edge authentication, controller discovery, NAT traversal | Onboarding of new or rebooted edges |
| cEdge/vEdge | Data | Actual traffic forwarding over IPsec tunnels | Traffic forwarding at that site |
Trap: "If vManage goes down, all sites lose connectivity" is wrong—vManage is the management plane, and edges keep forwarding on already-pushed configuration and already-learned OMP routes. Rebooting edges in a panic makes them need vBond/vSmart connectivity to come back, promoting a management-only fault into a real outage. Also wrong: "deploying SD-WAN improves circuit quality itself"—SD-WAN is a technology for intelligently choosing among multiple transports, not for improving the bandwidth or latency of any individual circuit.
1.2.4Section summary
- vSmart is control (aggregating and redistributing routes/TLOCs via OMP), vManage is management (configuration/monitoring), vBond is orchestration (authentication/onboarding), and cEdge/vEdge is data (actual forwarding over IPsec)
- Isolate faults along two axes—the scope of the symptom (all sites or some) and the function that stopped (forwarding, configuration change, or new admission). Forwarding continues through a vManage outage
- The benefits are circuit-cost optimization, centralized policy, and easier deployment; the limits are controller dependence, learning cost, and additional troubleshooting layers. Circuit quality itself does not improve
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. While operating 40 sites on Catalyst SD-WAN, you can no longer log into the vManage GUI. Users confirm that business applications between existing sites are working normally. What is the most appropriate action at this point?
Q2. A newly built site's cEdge cannot join the fabric, while communication among existing sites is unaffected. A new edge must be authenticated and learn where the controllers are. Which component's reachability and certificates should be checked first?
Q3. Management asks, "If we deploy Catalyst SD-WAN, will the latency and packet loss of our current internet circuits themselves improve?" Which answer is technically most accurate?

