SD-WAN Fundamentals on the Catalyst 8000

SD-WAN Control Components

Traditional routing collapses everything — management, control decisions, and packet forwarding — into each individual router. Cisco Catalyst SD-WAN (the technology formerly known as Viptela) takes the opposite approach: it cleanly separates the network into four planes, each handled by a dedicated role.

A useful analogy is an airport. The WAN Edge routers are the aircraft that actually carry passengers (data). vBond is the security checkpoint and information desk at the entrance — it verifies your identity and tells you which gate to go to. vSmart is air traffic control, deciding which planes fly which routes. And Catalyst SD-WAN Manager is the airport operations center, where staff plan schedules, watch every screen, and set the rules everyone follows. No single component does everything, and that separation is exactly what makes the system scalable and easy to operate.

Figure 5.1: The four planes of the Catalyst SD-WAN architecture

vManage / Catalyst SD-WAN Manager

Catalyst SD-WAN Manager (its current name; you will still hear it called vManage) is the management plane — the network management system (NMS) and single pane of glass for the entire fabric. It performs four broad jobs.

First, it owns central configuration and templates. It stores the device inventory and per-site parameters such as system IP, site ID, and organization-name, and it uses device templates and feature templates to generate complete configurations that it pushes down to controllers and WAN Edges over secure connections.

Second, it is the place where policy is authored. Administrators define control policies (route filtering, manipulation, topology) and data policies (traffic steering, QoS, service chaining, security) in the GUI. vManage translates those clicks into OMP policy constructs and hands them to the vSmart controllers, which enforce them on the edges.

Third, it handles monitoring, analytics, and lifecycle management — collecting telemetry on interfaces, tunnel SLAs, and application performance; presenting dashboards and alarms; and managing software images and upgrades.

Fourth, and critically for onboarding, it is the device authority. vManage holds the whitelist of authorized serial numbers and UUIDs that vBond consults when a new device tries to join, and in IOS-XE deployments it integrates with Cisco Plug and Play. The practical takeaway: when a Catalyst 8000 reaches vBond but is rejected, the first thing to check is whether its chassis/serial appears (and is authorized) in vManage's device list.

vSmart Controllers

If vManage is where decisions are authored, vSmart is where they are distributed. vSmart is the centralized control-plane engine of Catalyst SD-WAN.

vSmart maintains a secure DTLS/TLS control connection to every WAN Edge in the fabric. Over those connections, edges advertise their reachable prefixes and their TLOCs (transport locators) using the Overlay Management Protocol (OMP). vSmart behaves like a route reflector for the overlay: it collects everything, runs best-path selection, and redistributes the appropriate routes back out to each edge based on policy. Edges never peer directly with one another at the control plane — they peer with vSmart, which gives the controller a complete, global view of the network.

Because vSmart sees the whole topology, it is also where topology and segmentation are realized. It builds full-mesh, hub-and-spoke, or regional-mesh designs purely by choosing which OMP routes to advertise where, and it enforces multi-tenancy by tagging and distributing routes per VPN. Finally, vSmart is the policy enforcement point — it applies the control and data policies that vManage authored and pushes the resulting decisions to the edges.

A common field symptom illustrates vSmart's role: if a Catalyst 8000 has a healthy management connection to vManage but builds no overlay tunnels to other sites, the problem is usually that its control connection to vSmart is down — or that a control policy on vSmart is deliberately blocking those routes.

vBond / Validator Orchestrator

The vBond orchestrator — now also called the Validator — is the orchestration plane and, almost always, the first SD-WAN node a brand-new WAN Edge talks to. Think of it as the bouncer at the door who also happens to know where every room in the building is.

vBond does three things. It performs authentication and admission control: it establishes a secure DTLS/TLS session with each WAN Edge (and with vSmart and vManage) using certificates, validates the device's identity, and checks with vManage that the serial/UUID is on the authorized whitelist. It performs controller discovery: once admitted, vBond hands the device the IP addresses or FQDNs of available vSmart and vManage instances, and the edge then builds direct control connections — vBond steps out of the path after the introduction. And it performs NAT traversal: because vBond sits on a public IP and learns both inside and outside addresses, it coordinates how a router behind NAT should connect.

When onboarding stalls at "Attempting to contact vBond," the usual culprits are a wrong or unreachable vBond FQDN in DNS, blocked ports, or a clock/certificate mismatch breaking TLS. For resilience, production fabrics typically deploy multiple vBond instances behind DNS round-robin.

WAN Edge Onboarding

Getting a Catalyst 8000 from its shipping box into a live fabric is called onboarding, and the design goal is zero-touch: a non-technical installer should be able to rack the device, plug in the WAN cable, and power it on, with everything else happening automatically. Two workflows accomplish this — ZTP and PnP — and although they start differently, they converge on exactly the same end state.

ZTP and PnP Onboarding

Zero Touch Provisioning (ZTP) is the classic Viptela-style workflow, originally built for vEdge hardware and cloud-based edges, though it also works with IOS-XE SD-WAN. The flow proceeds in stages:

1. Boot. A factory-default device powers on with its image and built-in identity certificate. Its WAN-facing interface uses DHCP to obtain an IP address, gateway, and DNS server.
2. Discover vBond. The device queries a well-known ZTP FQDN (or a statically configured ZTP/vBond address). The ZTP service validates the serial/chassis ID and returns the organization name and the vBond FQDN/IP.
3. Connect to vBond. The edge opens a DTLS/TLS session to vBond using its certificate and organization name; vBond authenticates it and confirms with vManage that the serial is authorized.
4. Receive the controller list. If authorized, vBond sends the addresses (and often priorities) of the vSmart and vManage servers, frequently with multiple entries for redundancy.
5. Establish control connections. The edge forms a direct OMP control connection to each vSmart and a management connection to vManage.
6. Download configuration. vManage recognizes the device by serial and either auto-attaches a predefined template or waits for an operator, then pushes the full configuration.
7. Form the overlay. The edge advertises its TLOCs and prefixes via OMP; vSmart distributes them; IPsec tunnels come up and user traffic begins to flow.

Figure 5.2: WAN Edge zero-touch onboarding handshake

Plug and Play (PnP) is the workflow used for IOS-XE platforms — which includes the Catalyst 8000 family — and integrates with Cisco's cloud PnP service or an on-prem PnP server. A factory-default Catalyst 8000 boots, gets an IP via DHCP, and reaches out over HTTPS to a default Cisco PnP host (a devicehelper FQDN) or an on-prem server, identifying itself with its burned-in SUDI (Secure Unique Device Identifier) certificate. PnP looks up the device's claim record and returns controller information — vBond/vManage/vSmart addresses and the organization name — plus an optional small bootstrap configuration. From that point on, the device follows steps 3–7 above, exactly like ZTP.

The simplest way to remember the distinction:

For air-gapped or offline networks, neither cloud service is reachable, so operators use an on-prem PnP/ZTP server or perform a manual Day-0 bootstrap via USB or console — keying in vbond, organization-name, system-ip, site-id, and VPN 0 addressing by hand — after which the device still uses vBond/vSmart/vManage for the overlay.

Certificates and Serial Whitelisting

Zero-touch onboarding only works because the fabric can trust a device it has never seen before, and that trust rests on two pillars: certificates and the serial whitelist.

Every WAN Edge ships with a built-in identity certificate. On a Catalyst 8000, that is the SUDI certificate, programmed into a tamper-resistant chip at the factory and signed by Cisco's certificate authority. When the device contacts vBond, the DTLS/TLS handshake proves cryptographically that the router is a genuine Cisco device with the identity it claims. Certificates also secure every other control connection — edge-to-vSmart, edge-to-vManage, and controller-to-controller.

Certificates prove what a device is; the whitelist decides whether it is allowed in. An attacker could, in principle, present a valid Cisco certificate from some other router, so authentication alone is not enough. vManage maintains an authoritative list of the serial numbers and UUIDs that belong in this organization's fabric, and vBond checks every joining device against it. A device must pass both tests — valid certificate and an authorized serial — before it is admitted.

Two failure modes dominate real deployments. The first is the dreaded "chassis not authorized" rejection, meaning the serial is missing from (or not authorized in) vManage's inventory. The second is subtler: time. TLS handshakes fail if the device clock is wrong or a certificate has expired, so an edge with no NTP and a battery-dead clock may present a perfectly valid certificate and still fail the handshake. A mismatched organization-name between the device and the controllers produces the same kind of admission failure.

Control Connections

Once a device is admitted, the fabric runs on control connections — the secure DTLS/TLS sessions that carry everything except user data. It is worth being precise about which sessions exist, because troubleshooting almost always starts here.

After vBond makes the introduction, each WAN Edge establishes separate, direct DTLS/TLS sessions to vManage and to each vSmart controller. The session to vManage is used mainly to push and pull configuration and telemetry. The session to vSmart carries OMP — routes, TLOCs, services, policies, and even the encryption keys the edges later use. An edge forms one OMP adjacency with each vSmart, which provides control-plane redundancy and lets the design scale out.

Figure 5.3: Control connections versus the IPsec data plane

The important mental separation is this: control connections (edge↔controller, DTLS/TLS) are completely independent of the IPsec data-plane tunnels that later form between edges. They run over different paths, secure different traffic, and fail in different ways. When diagnosing a fabric, the disciplined order is to verify the control plane first — are the DTLS/TLS sessions up to each controller, and is the OMP session exchanging routes? — before ever looking at data-plane tunnels. If control connections are up but no OMP routes are arriving, the cause is usually a control policy on vSmart rather than an underlay or IPsec problem.

Overlay Planes

With the device onboarded and its control connections up, we can finally look at how the fabric actually moves packets. This is where two distinct "planes" meet: the OMP control plane, which decides what exists and where, and the IPsec data plane, which physically carries the traffic. Keeping these two ideas separate is the single most useful concept in all of SD-WAN.

OMP Control Plane

The Overlay Management Protocol (OMP) is the brain of Catalyst SD-WAN. It is a TCP-based, path-vector protocol conceptually very similar to BGP — it advertises reachability with rich attributes and makes policy-driven best-path decisions. The crucial structural fact is that OMP runs between each WAN Edge and the vSmart controllers, never directly between edges, and it runs inside the secure DTLS/TLS control connection. Locally learned routes on an edge — connected, static, OSPF, EIGRP, or BGP — can be redistributed into OMP and advertised across the overlay.

OMP carries three types of routes, and understanding the division of labor between them is what makes the overlay click:

A vRoute is a VPN prefix bound to a TLOC — for example, "192.168.1.0/24 in VPN 10, reachable via TLOC (1.1.1.1, mpls, ipsec)." A TLOC route describes a WAN attachment point itself, advertised in the transport VPN (VPN 0). A service route advertises something like a firewall so that policy can steer traffic through it.

The end-to-end flow ties these together. An edge learns LAN prefixes locally, then advertises its TLOC routes and vRoutes up to vSmart over the OMP session. vSmart maintains a global OMP RIB, runs best-path selection across everything it has heard, applies centralized control policy, and advertises the selected, policy-allowed routes back down to each edge — tailored to that site's topology. The receiving edge installs the vRoutes into its per-VPN routing tables and resolves each route's next hop using TLOC information, which tells it which transport to use. In one line: local route → OMP vRoute/TLOC → vSmart global view and policy → remote edge → TLOC resolves the transport → tunnel.

Figure 5.4: End-to-end OMP route flow through vSmart

IPsec Data Plane and TLOCs

OMP decides everything, but it carries no user data. The actual traffic rides IPsec tunnels built directly between WAN Edges — and the object that makes those tunnels possible is the TLOC.

A TLOC (Transport Locator) is the attachment point where a WAN Edge connects to a particular transport (Internet, MPLS, LTE, Metro-E). It is uniquely identified by a 3-tuple:

TLOC = (system IP, color, encapsulation)

The system IP is a logical router ID — not the interface address — and it stays the same across all of a router's TLOCs; color and encapsulation distinguish one WAN link from another. The encapsulation is the tunnel protocol — IPsec (the default, with encryption) or GRE — and the two ends must match for a tunnel to form. Default tunnel MTU depends on encapsulation: 1442 bytes for IPsec, 1468 for GRE, later adjusted by BFD-based path MTU discovery.

Here is the relationship that ties the two planes together. The DTLS/TLS control connections and the IPsec data tunnels are decoupled but interdependent. vSmart, via OMP, distributes not only routes but also the encryption keys and security parameters edges need to build IPsec sessions. TLOC routes tell an edge which remote system-IP and transport to connect to; once two edges hold matching TLOC routes and the necessary crypto material, they negotiate IPsec directly and the data-plane tunnel comes up. In other words, OMP builds the data plane: change OMP, and the IPsec topology follows.

This decoupling is also the key to troubleshooting. If an IPsec tunnel flaps while OMP stays up, suspect the underlay — transport reachability, NAT, or IPsec parameters — not control-plane routing. But if OMP/DTLS goes down, the edge stops receiving fresh routes and keys; existing tunnels may linger briefly, but once timers expire, routes and tunnels are withdrawn and connectivity is lost until OMP recovers.

For each active tunnel, the two edges also run a BFD (Bidirectional Forwarding Detection) session inside the tunnel. BFD detects failures quickly and continuously measures latency, jitter, and loss; those measurements drive application-aware, SLA-based routing — letting the fabric prefer MPLS for a latency-sensitive app and fall back to Internet when MPLS degrades.

Color and Transport Definitions

The middle element of the TLOC tuple — color — does more work than its name suggests. A color is a globally significant label that identifies a specific transport and tells the fabric whether that transport is public or private. That classification governs which IP address (and whether NAT traversal) is used when building a tunnel.

Cisco provides a fixed set of colors. A single WAN Edge cannot reuse the same color twice, so a router with two Internet links must use two different public colors (for example, biz-internet and public-internet).

The address-selection rule follows directly: if either color is public, the edges try to form the tunnel over their public IP addresses; only when both colors are private do they use private addresses. This is why choosing the right color is a design decision, not just a label: tag an MPLS link biz-internet and the fabric will try to reach it via a public address that may not exist, breaking tunnel formation.

Two controls refine the default behavior. The restrict keyword on a color forces a TLOC to build tunnels only to TLOCs of the same color. Tunnel groups add an orthogonal dimension: only TLOCs sharing a tunnel group will connect, regardless of color — useful in multi-carrier or multi-tenant designs.

Worked example — a Catalyst 8000 branch with MPLS and Internet. Consider a branch (system IP 1.1.1.1) and a data center (system IP 2.2.2.2), each with an MPLS link and a biz-internet link:

• Branch TLOCs: A = (1.1.1.1, mpls, ipsec) and B = (1.1.1.1, biz-internet, ipsec)
• Data Center TLOCs: C = (2.2.2.2, mpls, ipsec) and D = (2.2.2.2, biz-internet, ipsec)

All four TLOCs are advertised to vSmart via OMP. By default, vSmart's policy allows the matching pairs: A ↔ C (mpls ↔ mpls) forms an IPsec tunnel over the private MPLS addresses with no NAT, and B ↔ D (biz-internet ↔ biz-internet) forms an IPsec tunnel over the public Internet addresses, typically with NAT on each side. Cross-transport pairs (A ↔ D, B ↔ C) form only if the design allows them.

Figure 5.5: TLOC pairing and IPsec tunnels between a branch and data center