ENSDWI Part 4: Controller Deployment — Cloud, On-Prem, Scale, and Redundancy

10 July 2026 CiscoENSDWISDWAN

Domain 2.0 (Controller Deployment) is 15% of ENSDWI across four blueprint lines. This part covers the two “describe” lines — cloud deployment (2.1) and on-prem deployment (2.2) — plus the scale/redundancy design rules. Part 5 takes the two hands-on lines: certificates/device lists and control-plane troubleshooting.

2.1 Controller cloud deployment

The default, and what Cisco pushes hard: Cisco-hosted controllers. Cisco stands up vManage, vBond, and vSmart in Cisco-managed cloud (AWS/Azure under the hood), and you get:

  • Provisioning through Cisco PnP portal / plug-and-play connect tied to your Smart Account — controllers appear pre-certificated with your org-name baked in.
  • Cisco handles infrastructure availability, snapshots, and (with your scheduling) software upgrades of the controllers. You still own configuration, policy, and edge software.
  • Controllers get public IPs by default; edges reach them over Internet transport. MPLS-only sites need either an Internet-reachable path for control, or you request private-IP controller access wired into your MPLS (supported, but the exam default assumption is public reachability).

Why the exam cares: the decision factors. Cloud-hosted wins on time-to-deploy, no hosting infrastructure, and Cisco-managed uptime. On-prem wins on data sovereignty / regulatory control, air-gapped or private networks, and full lifecycle ownership. A question describing a defence customer with no Internet connectivity is steering you to on-prem.

2.2 Controller on-premises deployment

2.2.a Hosting platforms

On-prem controllers are VMs (vBond can also run on hardware as a vEdge in vBond mode, historically). Supported hypervisors: VMware ESXi and KVM. Images ship as OVA (ESXi) and qcow2 (KVM). Rough sizing to recognise, not memorise precisely: vManage is the heavy one (16 vCPU / 32 GB RAM / 500 GB+ disk for small deployments, growing with device count and stats retention); vSmart and vBond are light (2–4 vCPU, 4–16 GB).

Two deployment-position facts the exam likes:

  • vBond needs to be reachable from every transport — in practice it sits in a DMZ with a public (or 1:1 static-NATed) address. PAT is unsupported for vBond, full stop.
  • vManage and vSmart can sit behind NAT/firewalls, as long as the required ports are open: UDP 12346 (+ per-core offsets) for DTLS, TCP 23456+ for TLS, and the edges/controllers can initiate to them.

2.2.b Installing controllers

The install sequence is a describe-level topic but exhibit questions show CLI from the middle of it, so know the shape:

  1. Deploy the three VMs from OVA/qcow2. Console in; each boots to a minimal ViptelaOS-style CLI (vManage prompts to select the persistent storage disk on first boot).
  2. Minimum bring-up config on each: system host-name, system-ip (unique, unrouted-is-fine identifier — it’s overlay identity, not a routable address), site-id (controllers at the same DC share one), organization-name (must match exactly across everything, case-sensitive), and vbond <address> (on the vBond itself, add local: vbond 203.0.113.10 local).
  3. Configure VPN 0 (transport) interface with tunnel-interface and allowed services, and VPN 512 for out-of-band management.
  4. Install certificates (Part 5’s subject).
  5. Add vSmart and vBond to vManage (Configuration → Devices → Controllers) so vManage can push their config and sync certificates.

The VPN-number fact generalises and gets tested: VPN 0 = transport, VPN 512 = management on every device in the fabric, controllers and edges alike.

Scalability and redundancy (2.2.c)

The design-numbers section. These are the facts multiple-choice questions are built from:

vManage

  • Single node: fine up to ~2,000 devices.
  • Cluster of 3 (or 6): HA and horizontal scale. All members active, services (application server, statistics, configuration DB) distributed; cluster members must sit in the same DC / low-latency segment (single-digit ms) because the DB replicates synchronously.
  • Beyond one region: disaster recovery pairs an active cluster with a standby cluster elsewhere, arbitrated by an arbitrator vManage; failover is administrator-triggered or automated with the DR workflow, not sub-second.
  • Losing vManage does not interrupt forwarding or control — only management.

vSmart

  • Scale is horizontal: add vSmarts, each edge connects to (by default) up to 2 vSmarts (max-control-connections), and all vSmarts converge on the same OMP view because every edge feeds them identically. No vSmart↔vSmart peering.
  • Maximum 20 vSmarts per overlay (the number occasionally appears; more usefully, know “you scale by adding instances and using affinity”).
  • Controller groups / affinity: assign vSmarts to controller-group-ids, then set each edge’s preferred groups (controller-group-list) so regions prefer local vSmarts and fail over to remote ones. This is the mechanism behind “how do I make European edges use European vSmarts?” questions.
  • Losing all vSmarts: existing data-plane tunnels and routes persist (edges keep last-known OMP state per graceful restart, default 12 hours, max 7 days) but no new routes/policy propagate. Know the graceful-restart behaviour — “vSmarts unreachable, does traffic stop?” is a classic. Answer: no, existing paths keep forwarding.

vBond

  • Stateless, so redundancy is trivial: run several, list them all behind one DNS name; edges resolve and walk the list.
  • Losing all vBonds affects only new control-connection formation (new devices, or devices recovering from full connectivity loss); established overlays don’t care.

Edges

  • Each edge holds control connections per TLOC: by default DTLS to vManage over one transport and to vSmarts over every transport (tunable with max-control-connections per tunnel-interface — setting 0 on an MPLS TLOC that shouldn’t carry control is a standard design pattern, and a standard exam answer).

Ports and protocols cheat block

DTLS (default)  : UDP 12346 base; port-hopping tries 12366, 12386, 12406, 12426
                  (+ per-core offsets on multi-core: 12346-12445 range in practice)
TLS (optional)  : TCP 23456 base for control connections
NETCONF         : vManage -> devices, over the DTLS/TLS control channel
ZTP / PnP       : HTTPS/DNS outward from factory-default edge (Part 6)

Port-hopping is worth a sentence: an edge failing to form control connections on 12346 (e.g. a middlebox eating it) retries on offset ports automatically; show sdwan control local-properties shows the port in use. Disable port-hop on controllers; edges keep it unless behind well-known firewall rules.

Exam traps for this domain

  • Org-name mismatch (case included) = certificate validation failure = no control connections. The single most common “why won’t it join” answer.
  • vBond: public or 1:1 static NAT, never PAT. vManage/vSmart: NAT is fine.
  • vManage cluster = same site, low latency. Geographic redundancy = DR active/standby, not a stretched cluster.
  • vSmarts down ≠ forwarding down. Graceful restart keeps last OMP state (default 12 h).
  • system-ip is an identifier, not routable; VPN 0 = transport, VPN 512 = management.
  • Affinity (controller groups) is how you pin regions to local vSmarts.

Part 5 finishes the domain with the practical half: the certificate trust chain and device authorized lists (2.3), and the control-connection troubleshooting flow (2.4) that powers half the exhibit questions on the exam.