ENSDWI Part 2: Architecture — Planes, Components, and Multi-Region Fabric

8 July 2026 Cisco ENSDWI SDWAN

Domain 1.0 (Architecture) is 20% of the ENSDWI exam, and section 1.1 — the planes and components — is its core. If the deep dive Part 1 gave you the architecture as a story, this post gives it to you as answers: the specific facts the exam tests, organised by blueprint line.

1.1.a Orchestration plane — vBond and NAT

vBond is the orchestration plane: the first point of contact for every device joining the overlay. Exam-relevant facts:

vBond authenticates every device by certificate and distributes vManage/vSmart reachability information. It is stateless and never in the data path.
vBond must have a public IP address or be 1:1 static-NATed — it’s the one component every edge must reach directly, and it cannot sit behind PAT. This is a favourite exam fact.
vBond performs STUN-like NAT detection: because it sees both the private (as reported) and public (as received) address:port of a connecting edge, it can tell the edge what kind of NAT it’s behind. Symmetric NAT on both ends of a tunnel breaks direct data-plane connectivity — that pairing forces traffic through an intermediate.
Multiple vBonds scale horizontally behind a single DNS name resolving to all of them; edges try each A record in turn.

1.1.b Management plane — vManage

vManage owns configuration, monitoring, and lifecycle: templates and configuration groups, software images, certificates, alarms, statistics, and the REST API. Persistent DTLS/TLS connections from every device. Single-node for small deployments, three-node cluster minimum for HA, and it’s the scaling bottleneck of the trio — the stats/config database, not the control plane, is what strains first. Devices remain forwarding if vManage dies; you just can’t change or see anything centrally. That “data plane survives management plane loss” pattern is tested for every controller.

1.1.c Control plane — vSmart and OMP

vSmart runs OMP (Overlay Management Protocol) and enforces centralized policy. Edges peer with vSmarts only — never with each other — making vSmart structurally a BGP route reflector for the overlay (deep dive Part 2 covers the mechanics properly). What the exam wants:

OMP advertises three route types — memorise all three:

Route type	Carries	Analogy
OMP routes (vRoutes)	Site prefixes learned from service-side VPNs (connected, static, OSPF, BGP, EIGRP)	BGP NLRI
TLOC routes	Transport locators — the tunnel endpoints, with color, encap, public/private IP:port pairs, weight, preference	Next-hop attribute, promoted to a route
Service routes	Network services (FW, IPS, load balancer) available behind an edge, for service insertion	Route target + service label

1.1.c (i) TLOC. A TLOC is the tuple {system-IP, color, encapsulation} — the identity of one transport attachment on one edge. Colors are predefined keywords (mpls, biz-internet, public-internet, lte, gold, …) split into public and private groups: private colors assume no NAT between two private-color endpoints and use private addresses; public colors use the NATed public address. An OMP route is unreachable unless its TLOC next-hop is both advertised and resolvable — “route present but no BFD session to its TLOC” is a classic exhibit scenario.

1.1.c (ii) vRoute. OMP route attributes the exam tests: origin protocol and metric (connected 0, static 1, eBGP 20, OSPF intra-area 110… carried, not recalculated), preference (higher wins, default 0… the OMP tiebreaker you set in policy), site-ID, TLOC (the next-hop), and VPN label. Best-path order worth knowing cold: valid → higher preference → higher TLOC preference → lower origin metric → highest system-IP as final tiebreak; up to four equal-cost OMP paths install by default (send-path-limit 4, max 16).

1.1.d Data plane — WAN Edge

1.1.d (i) IPsec and GRE. Data-plane tunnels between edges are IPsec (default) or GRE, chosen per-TLOC via encapsulation. IPsec uses ESP with keys distributed via OMP through vSmart — there is no IKE between edges. Each edge generates its own data-plane keys per TLOC and advertises them in its TLOC routes; vSmart reflects them. Pairwise keys are an optional hardening feature. Rekey default is 86400 seconds. Anti-replay window default 512. If you want the ESP packet anatomy itself, the IPsec deep dive covers it — ENSDWI only needs “ESP in tunnel mode, keys via OMP, no IKE”.

1.1.d (ii) BFD. BFD runs inside every data-plane tunnel automatically — you cannot disable it — and does two jobs: path liveness (detect blackout) and path quality measurement (loss/latency/jitter feeding app-aware routing). Defaults: hello 1000 ms, multiplier 7, poll-interval 600000 ms (10 min) with 6 poll windows per app-route calculation. Per-color tunable. BFD down = tunnel down = OMP routes over that TLOC withdrawn. Deep dive Part 4 if you want the convergence story.

1.1.e Multi-Region Fabric

New in v1.2 and heavily flagged in the current exam. MRF splits the overlay into regions: access regions (1–63) containing edge routers, and region 0 — the core — containing border routers that stitch regions together. Key facts:

Without MRF, a large fabric is one flat OMP domain and full-mesh tunnel scaling becomes the problem. With MRF, edges build tunnels within their region only, plus to their region’s border routers; inter-region traffic transits the region-0 core between border routers.
vSmarts are assigned per-region; border routers join both their access region and region 0.
Site-to-site traffic across regions is edge → BR (region A) → BR (region B) → edge, and the core hop can ride a dedicated transport (e.g. premium backbone) — this is the “transport gateway” story.
Benefits the exam expects you to recite: tunnel-count reduction, simplified policy (per-region), traffic-engineering the core independently of access, and incremental migration (region by region).

1.2 Edge platforms (preview)

Platform families get proper treatment in Part 3, but architecture questions sometimes lean on the split: cEdge = IOS-XE SD-WAN (Catalyst 8000, ISR1k/4k, ASR1k, C8000V virtual) — current and default; vEdge = ViptelaOS legacy (vEdge 100/1000/2000/5000, vEdge Cloud) — supported, not for new deployment. Controllers don’t care which; OMP and policy are identical from vSmart’s point of view, with feature gaps at the edges (App-QoE, advanced security are cEdge-only).

1.3 Cloud OnRamp (preview)

Also Part 3’s subject in full, but at architecture level know the four names and one-liners: SaaS = pick the best exit for Office365/Salesforce per-app via vQoE scores; IaaS = extend the fabric into AWS/Azure/GCP with cloud gateways; Colocation = service chains in Equinix-style colos on CSP hardware; Multicloud/Interconnect = orchestrated site-to-cloud and cloud-to-cloud over SDCI providers (Megaport, Equinix Fabric).

Verification commands to recognise

Exhibit questions for this domain are nearly always one of these (IOS-XE sdwan forms shown; vEdge drops the keyword):

show sdwan control connections      ! DTLS/TLS sessions to vBond/vManage/vSmart
show sdwan control local-properties ! cert state, system-ip, site-id, org-name, NAT type per TLOC
show sdwan omp routes               ! vRoutes with preference/origin/TLOC/status (C=chosen, I=installed, R=resolved)
show sdwan omp tlocs                ! TLOC routes incl. public/private IP:port and encap
show sdwan bfd sessions             ! per-tunnel state, color pair, loss/latency/jitter

Learn the local-properties output especially — certificate-not-installed and org-name-mismatch both surface there, and Part 5 builds its whole troubleshooting flow on it.

Exam traps for this domain

vBond behind PAT — not supported. Static 1:1 NAT only.
OMP peering is edge↔vSmart only. Any answer with edges peering OMP to each other is wrong.
TLOC = system-IP + color + encap. Two circuits on one edge = two TLOCs, same system-IP.
Data-plane IPsec keys come from OMP, not IKE. IKE appears in ENSDWI only for manual IPsec tunnels to non-SD-WAN devices.
BFD is always-on inside tunnels; you tune it, you don’t enable it.
MRF region 0 = core, border routers live in both worlds, access regions never talk edge-to-edge directly across regions.

Part 3 finishes the architecture domain: edge platform families and capabilities, and all four Cloud OnRamp variants in the depth the blueprint’s “describe” verb actually demands.