The DMVPN chapter ended with branches building tunnels to each other; SD-WAN industrialises the idea. The premise: branch connectivity should use any transport — two internet circuits, LTE, a residual MPLS — as one policy-managed fabric, with per-application path decisions and central control. Cisco's SD-WAN (the acquired Viptela platform) answers with an architecture whose first exam question is always the same: name the planes and their owners.
The four planes
- vManage (management plane) — the single pane: device templates and feature configuration, centralised policy authoring, monitoring and the API surface for automation. Admins touch vManage; vManage touches everything else.
- vBond (orchestration plane) — the meeting point: the one component that must be reachable from every transport, it authenticates new devices against certificates and allow-lists, tells them where their controllers are, and brokers NAT traversal by observing each device's outside address. Zero-touch provisioning — a branch router discovering everything from a factory state — runs through vBond.
- vSmart (control plane) — the route reflector of the fabric: every WAN edge holds a permanent DTLS/TLS session to its vSmarts, over which OMP runs. vSmart never forwards a customer packet; it distributes routes and, crucially, enforces centralized policy by modifying what it advertises to whom.
- WAN edge (data plane) — the routers (vEdge/cEdge, i.e. IOS-XE SD-WAN) at sites, building the IPsec tunnel mesh over every transport and applying local policy.
OMP and TLOCs
The Overlay Management Protocol is the fabric's single control protocol, carrying three route families: OMP routes (site prefixes, with attributes like originating site-id and preference), TLOC routes (transport locators — the tuple of system-ip, colour, encapsulation that names each edge's attachment to each transport, with its public/private addresses), and service routes (advertised firewalls and other services for traffic steering). An OMP route's next hop is a TLOC, exactly as a BGP next hop is an address: reach the prefix by building the IPsec tunnel to that TLOC. Colours (biz-internet, mpls, lte...) label transports so policy can say 'voice prefers mpls' in one line, and restrict controls which colours even attempt tunnels to each other. The BGP intuition transfers almost embarrassingly well: vSmart is a route reflector, OMP attributes are path attributes, centralized policy is an inbound/outbound route map applied at the reflector.
Edge# show sdwan omp routes 10.20.0.0/16 | include tloc tloc: 10.255.0.12, mpls, ipsec status: C,I,R tloc: 10.255.0.12, biz-internet, ipsec status: C,REdge# show sdwan bfd sessions summary sessions-total 6 sessions-up 6
What the fabric does that routing alone cannot
Every tunnel runs continuous BFD probes measuring loss, latency and jitter per path. Application-aware routing policy states SLAs — voice: loss < 1%, latency < 150 ms — and steers each application class onto whichever coloured path currently meets its SLA, moving flows when a path degrades rather than when it dies. Centralized data policy adds per-segment service chaining (guest VPN exits locally, corporate VPN chains through the DC firewall), and the whole configuration — being template-driven from vManage — is versioned, previewable and API-addressable. This is the automation chapter's philosophy applied to the WAN: intent centrally defined, rendered to devices, verified by telemetry.
Study advice for engineers arriving from the routing shelves: map every SD-WAN concept back to its classical ancestor — vSmart to a route reflector, TLOC to a next hop, colour restrict to peer groups, app-route policy to PBR with a pulse. The fabric is new; the reasoning is the same reasoning this library has been building since the OSI chapter, which is precisely why the fundamentals still gate the future.