ENSDWI Part 6: WAN Edge Deployment — ZTP, Bootstrap, and TLOC Extension

14 July 2026 CiscoENSDWISDWAN

Domain 3.0 (Router Deployment) is 20% of ENSDWI and splits cleanly in two: getting edges into the fabric and wired to their transports (this part), and configuring the protocols and templates that run on them (Part 7).

3.1.a Onboarding: ZTP, PnP, and bootstrap

Three ways a factory-fresh edge finds its overlay. The exam tests the differences hard.

PnP — Plug and Play (cEdge)

The IOS-XE automatic flow:

  1. Edge boots with no config, gets DHCP on a supported interface.
  2. Resolves and calls devicehelper.cisco.com (Cisco’s PnP Connect service) over HTTPS.
  3. PnP Connect looks up the device serial → your Smart Account → your controller profile (vBond address + org-name), returns them.
  4. Edge contacts vBond, authenticates with its SUDI certificate, and proceeds through the normal bring-up (Part 2’s sequence).

Requirements: DHCP on the transport, DNS, HTTPS reachability to Cisco, device serial present in PnP Connect and synced to the vManage authorized list, and a device template/config group attached in vManage so it gets configuration on arrival.

ZTP — Zero Touch Provisioning (vEdge)

Same idea, ViptelaOS flavour: the edge calls ztp.viptela.com, which returns vBond details. Two facts distinguish it in exam questions: ZTP works only from specific ports (the designated ZTP interface per platform, e.g. ge0/0), and it’s the vEdge-lineage name — a question pairing “Catalyst 8300” with “ztp.viptela.com” is testing whether you know PnP vs ZTP.

Bootstrap — no usable DHCP/Internet path

When the site can’t do zero-touch (MPLS-only transport, no DHCP), generate a bootstrap configuration from vManage (ciscosdwan.cfg for hardware cEdge via USB/flash, cloud-init for C8000V) containing org-name, vBond, minimal VPN 0 config, and — for virtual platforms — the OTP/UUID that substitutes for factory identity. Device boots, reads the file, joins. Manual CLI minimum-config is the same thing typed by hand.

Virtual edge (C8000V) reminder from Part 5: no SUDI, so the bootstrap OTP is its proof of identity. Hardware proves itself; virtual is vouched for.

3.1.b DC and regional hub deployments

Design-pattern facts for the “describe” half of 3.1:

  • DC edges deploy in pairs for redundancy, each with TLOCs on all transports. Site-ID is shared by the pair (site-ID = failure domain = “these devices are the same place”; OMP won’t form data tunnels between same-site devices, and BFD between them isn’t expected).
  • The DC pair typically runs TLOC-extension between the two routers (below) so each router can use the circuit terminating on its neighbour, or both routers dual-home to both circuits at bigger sites.
  • Regional hubs aggregate branch traffic (hub-and-spoke via control policy — Part 8), host shared services, and often act as the gateway site for Cloud OnRamp SaaS and the DIA exit for branches without local Internet.
  • Hubs are also where MRF border routers live when Multi-Region Fabric is in play, and where you’d terminate the core-region transport.
  • Service-side integration at DC/hub scale is BGP or OSPF to the LAN core, with the loop-prevention markers covered in Part 7 (OMP↔BGP AS-path behaviour, OSPF down-bit/tag).

3.2.a Circuit termination and TLOC extension

The problem: a two-router branch with one Internet circuit into router A and one MPLS circuit into router B. Without help, router A has no MPLS TLOC and router B has no Internet TLOC — each router has half the transport diversity the site paid for.

TLOC extension fixes it: a link between the routers over which each router extends its neighbour’s transport. Router A’s ge0/2 towards B is configured tloc-extension ge0/0 (its Internet interface); router B then builds its biz-internet TLOC through A, sourcing tunnels via that cross-link. Mirror it for MPLS in the other direction. Now both routers own TLOCs on both colors, and the site survives either router or either circuit dying.

Configuration shape (IOS-XE side names differ, concept identical):

! Router A (owns Internet circuit on Gi0/0/0)
interface GigabitEthernet0/0/2
 description tloc-ext link to B
 ip address 192.168.100.1 255.255.255.252
!
sdwan
 interface GigabitEthernet0/0/2
  tloc-extension GigabitEthernet0/0/0

Exam-tested details:

  • TLOC extension is per-transport, one hop: the extension interface binds to the specific WAN interface being shared.
  • For Internet-facing extensions, the extending router must NAT the neighbour’s tunnel traffic (or the extended interface needs its own public addressing/routable subnet towards the provider) — questions probe whether you know the extended TLOC still needs valid addressing to the transport.
  • L3 TLOC extension over a routed segment (with a routing protocol on the cross-link) is supported for vEdge-era designs; the standard answer is the direct L2 cross-link.
  • The alternative at big sites is simply dual-homing both routers to both circuits — TLOC extension exists for when the circuit physically lands on one box.

3.2.b Dynamic tunnels

By default the overlay is a full mesh: every TLOC pair (color-compatible, per policy) gets an IPsec tunnel with BFD. That’s the baseline the exam assumes unless policy says otherwise. Two mechanisms modify it:

  • Control policy (Part 8) filtering TLOC advertisements → hub-and-spoke or partial mesh, with fixed tunnels.
  • Dynamic on-demand tunnels: spoke-to-spoke tunnels that form only when there’s traffic. Configure on-demand enable on the edges; spokes route via a backup path through the hub initially, and direct spoke-spoke tunnels are triggered by traffic, then torn down after an idle timeout (default 10 minutes). Requirements the exam checks: on-demand is set on both spokes, a hub provides the always-on backup path, and OMP still advertises everything — it’s the tunnels that are on demand, not the routes.

Restraint hierarchy worth reciting: restrict (on a color: only tunnel to same color), tunnel groups (only tunnel to matching group IDs), max-control-connections, and control policy — these are the knobs that shape who tunnels to whom.

3.2.c Underlay–overlay connectivity

How packets in VPN 0 get anywhere: each transport interface needs reachability to the transport’s next hop — usually a static default route in VPN 0 per transport (or DHCP-learned). The overlay then rides on top; service-side VPNs never leak into VPN 0 unless you engineer it.

The engineered exceptions ENSDWI expects:

  • NAT DIA fallback / route leaking between VPN 0 and service VPNs for direct Internet access (Part 9 covers DIA policy; the underlay piece is ip nat route / leak of a default into the service VPN pointing at the VPN 0 NAT interface).
  • Loopback TLOCs: TLOC bound to a loopback (bind mode to a physical, or standalone) for designs where the WAN IP must survive interface changes — the SD-WAN resilience series walks the same idea on another vendor.
  • Underlay routing on the cross-link/DC fabric so TLOC-extension and DC-pair traffic can reach the transports.

Verification commands

show sdwan running-config sdwan          ! tunnel-interface config, colors, tloc-extension
show sdwan control local-properties      ! per-TLOC NAT type, public/private pairs
show sdwan bfd sessions                  ! which tunnels actually formed (full mesh? hub only?)
show ip route vrf 65528                  ! VPN 0 underlay routing (transport VRF on IOS-XE)
show sdwan omp tlocs                     ! TLOCs including extended ones

show sdwan bfd sessions output showing spokes with sessions only to hub colors is the standard exhibit for “control policy or on-demand tunnels are in play”.

Exam traps for this domain

  • PnP = cEdge/devicehelper.cisco.com; ZTP = vEdge/ztp.viptela.com/specific port. Don’t mix lineages.
  • Zero-touch needs DHCP + DNS + Internet; MPLS-only or static sites = bootstrap.
  • A template/config group must be attached in vManage for zero-touch to end in a configured device — otherwise it joins and sits in CLI mode.
  • TLOC extension: per-transport, requires NAT or routable addressing on Internet extensions, and exists so dual-router sites get full transport diversity.
  • On-demand tunnels: traffic-triggered, idle teardown, hub backup path required, routes are always there.
  • Same site-ID = no tunnels between those devices (that’s by design for DC pairs).

Part 7 stays in domain 3.0: OMP configuration and path selection, TLOC tuning, running OSPF/BGP/EIGRP/VRRP on the service side, multicast support, and the config-group/feature-profile workflow v1.2 added.