Chapter 9: Deployment, Provisioning, and Day-0 Operations

Zero-Touch Provisioning

Think of zero-touch provisioning like activating a new smartphone. You take it out of the box, connect it to Wi-Fi, and it phones home to the manufacturer's cloud, identifies itself by serial number, downloads its profile, and configures itself — no manual setup required. Catalyst 8000 routers use the same idea: the device contacts Cisco's cloud, proves who it is, learns which controllers it belongs to, and pulls down its full configuration.

Zero-Touch Provisioning (ZTP) is the overall outcome: ship a router from the factory, plug it in, power it on, and it self-provisions into the SD-WAN fabric with no command-line work at the branch. Plug and Play (PnP) is the underlying mechanism that delivers that outcome — a software agent built into IOS XE plus a cloud registry. On Catalyst 8000, Cisco effectively uses the PnP infrastructure as the ZTP mechanism for IOS XE SD-WAN, while bootstrap files provide a more controlled, "almost-zero-touch" alternative.

Before going further, it helps to know the cast of characters involved in Day-0 onboarding:

PnP Connect portal

PnP Connect is a cloud service that lives under your Cisco Smart Account / Virtual Account and holds a registry of devices along with their onboarding instructions. It performs three key jobs: device registration and claiming (associating each device to your account by serial, PID, or SUDI), association to an SD-WAN profile (linking the device to a controller profile with Manager/vBond/vSmart FQDNs and the org name), and mapping to SD-WAN Manager (so Manager can pull device info and create a matching WAN Edge entry). This enables "cloud ZTP": the router phones home to PnP, PnP says "you belong to this SD-WAN Manager and vBond," and the router continues onboarding with those controllers.

Bootstrap files and day-0 config

Not every site has open internet access to reach Cisco's cloud. For those environments, SD-WAN Manager can generate a bootstrap configuration — a Day-0 file that contains everything the router needs to find its controllers on its own. A bootstrap file typically includes basic system parameters (hostname, system-IP, site-ID), the org name and vBond/orchestrator address, WAN transport interfaces configured as tunnel-interface, certificate/CSR/token details, and optional initial device-template variables (such as VPN 0 and the VPN 512 management VPN).

To generate one, go to Configuration → Devices, select the unused Catalyst 8000, and click Generate Bootstrap Configuration. You choose the transport type (static IP or DHCP), indicate whether the router is behind NAT, and download the file. On a physical device you copy it to USB/bootflash (matching the expected filename, e.g. a ciscosdwan.cfg style name); on a virtual C8000V you inject it as day-0 userdata. On first boot with no startup-config, the router loads this file and immediately knows its org name, vBond address, system-IP, site-ID, and transport interfaces. This is not strictly zero-touch — someone attaches the USB stick or injects the file — but it avoids all CLI work at the branch.

ZTP over cellular and internet

When a Catalyst 8000 boots at factory default with internet reachability, the closest thing to pure ZTP unfolds automatically:

1. Power on and DHCP — The WAN port obtains an IP address, default gateway, and DNS server.
2. PnP discovery — The PnP agent checks DHCP options (43, 60, 143), then resolves known PnP FQDNs (e.g. pnpserver.<domain>), then falls back to Cisco's global cloud PnP Connect over HTTPS.
3. Phone-home to PnP Connect — The router opens HTTPS (TCP 443) and presents its SUDI/serial and PID; the portal looks up the identity and finds the associated SD-WAN onboarding profile.
4. PnP returns SD-WAN information — Either the Manager/vBond FQDN and org name, or a lightweight bootstrap.
5. Connect to vBond — The router initiates a secure DTLS/TLS connection (often port 12346 or 443); vBond authenticates by certificate and returns Manager and vSmart addresses plus NAT-traversal info.
6. Enroll with SD-WAN Manager — The router builds a tunnel, appears as "reachable," is matched by chassis ID, and Manager pushes the full Day-1 configuration.
7. Join the fabric — The router establishes OMP sessions with vSmart and exchanges routes and policy.

Crucially, this works over a cellular transport just as it does over a wired internet circuit. A Catalyst 8000 with an LTE/5G module can obtain its IP from the cellular network and phone home over that same HTTPS path. The only onsite steps remain: rack the device, connect power, and provide a DHCP-enabled path with outbound HTTPS and DNS.

If onboarding fails, reach for show platform software pnp status and debug pnp discovery to inspect the DHCP/DNS/PnP attempts, and show sdwan control connections to check the vBond/vSmart/Manager status once a bootstrap has loaded.

Templates and Configuration Groups

Once a router is reachable in SD-WAN Manager, something has to define what configuration gets pushed to it. SD-WAN Manager offers two configuration models for IOS XE edge devices like the Catalyst 8000: the traditional template model and the newer Configuration Group model. Both ultimately generate IOS XE SD-WAN configuration, but they differ in how you design, reuse, and deploy it.

Feature and device templates

In the traditional model, feature templates are the basic building blocks of a device's configuration. Each feature template represents one feature on the router — System (hostname, system-IP, site-ID, org name, timezone), VPN (VPN 0 transport, VPN 512 management, service VPNs), VPN interface, Routing (OMP, BGP, OSPF, static), and Security/AAA/logging/SNMP/NTP. The power comes from parameterization: many fields are set as device-specific variables rather than hard-coded, so the same VPN-interface template can be reused across hundreds of routers, with each supplying its own IP through a variable like vpn0_if1_ip. A useful analogy is a form letter: the body is identical for everyone, but the name and address are filled in per recipient.

A device template ties multiple feature templates together and binds them to a specific hardware platform. You select a device type — for example, a Catalyst 8300 — and assemble the System, VPN 0/512, VPN-interface, OMP, BFD, and routing templates into a complete, model-aware definition. A typical worked flow: onboard the router, confirm it is validated and present in SD-WAN Manager, create reusable feature templates, create a device template for the specific model (e.g. C8300-1N1S-4T2X), associate the feature templates, attach the device template to one or more routers, fill in per-device variables (manually or by CSV), then review and deploy — SD-WAN Manager renders the feature templates and pushes the combined configuration via NETCONF.

The main drawback of this model is that device templates are model-specific. Even when the logical design is identical, you often need a separate device template for a C8200, a C8300, and a C8500 — leading to template sprawl, the very pain point that motivated Configuration Groups.

Configuration Groups and parcels

Starting with SD-WAN Manager 20.8 and IOS XE SD-WAN releases around 17.9 and later, Cisco introduced Configuration Groups, a more modular, intent-based construct that is now the strategic direction for IOS XE devices. Two scope rules are essential: Configuration Groups are supported only on IOS XE-based devices (which includes the Catalyst 8000 family), and a device can be managed by either a device template or a Configuration Group — never both at once.

A Configuration Group is a logical grouping of devices that share a common role or business intent, configured using modular building blocks called feature profiles. Unlike a device template tied to one SKU, a single Configuration Group can span multiple Catalyst 8000 models that share the same design. The main profile types are the System Profile (hostname, system-IP, site-ID, banner, AAA, logging, DNS, NTP), the Transport Profile (VPN 0 interfaces, tunnel settings, TLOC colors), and the Service Profile (service VPNs, LAN interfaces, BGP/OSPF, DHCP pools). Within each profile, configuration is broken into smaller atomic elements called features or parcels — a specific service VPN, a transport interface, a BGP process, an NTP stanza — so a small change can be localized to a single parcel.

To create a Configuration Group, you use the Workflow Library → Create Configuration Group wizard, which walks you through naming the group (e.g. BRANCH_DUAL_INTERNET), building the System, Transport, and Service profiles with smart defaults, associating target devices, and previewing the compiled configuration before committing. The model also supports fine-grained RBAC: a WAN team can own Transport profiles while a LAN team owns Service profiles. When a feature is not yet modeled natively, CLI add-on templates remain available in either model, letting you inject free-form IOS XE configuration that SD-WAN Manager merges with the model-driven config — handy for advanced QoS or proprietary monitoring during migrations, at the cost of less validation and harder reuse.

Variables and CSV onboarding

For large deployments, filling in per-device variables one screen at a time would be unbearable. Both models support bulk provisioning through a CSV file, where each row is a device and each column maps to a template variable. Three columns are mandatory and must come first:

After those three, you add a column for each variable to populate. To onboard twenty branch routers sharing one device template, you build a spreadsheet with twenty rows, the three mandatory columns, plus columns such as vpn0_if1_ip and vpn10_lan_ip. At attachment time, SD-WAN Manager ingests the CSV, matches each row to its device by serial, and renders all twenty configurations in one operation. If a required variable is left blank, attachment can fail or the router may receive an incomplete configuration — so validating the CSV before deployment is a critical habit.

High Availability

Getting a single router online is only part of the job. A branch that runs a hospital, a trading floor, or a 24-hour distribution center cannot tolerate an outage just because one router reloads or one circuit goes dark. High-availability (HA) design ensures that a user's default gateway, the SD-WAN control connections, and at least one data-plane path always remain up, with rapid automatic failover. Redundancy is the underlying principle: deploy duplicate components so that the failure of any one does not interrupt service.

Dual-router branch design

In Cisco SD-WAN, a dual-router branch is modeled as one site with two devices. Both Catalyst 8000 routers share the same site-ID (giving them a common branch identity and consistent policy), but each has a unique system IP — analogous to a unique loopback in classic WAN design — and both use the same organization/domain name. Both routers independently build control connections to redundant vBond, vSmart, and vManage controllers over every available transport.

A common physical topology pairs two Catalyst 8000 routers (each toward one or more ISPs/MPLS), a switch stack dual-homing each router via LACP port-channels, VRRP between the two routers on each user VLAN, and optionally a TLOC extension link so each router can use the other's WAN circuits.

Treating both routers as a single SD-WAN site keeps policy and routing symmetric and simplifies application-aware routing and SLA tracking at the branch.

VRRP and TLOC redundancy

On the LAN side, VRRP (Virtual Router Redundancy Protocol) is a first-hop redundancy protocol that presents a single virtual IP and virtual MAC as the host default gateway. One router becomes the VRRP master and forwards traffic for the virtual IP; the other is the backup. A typical VLAN 10 design: Router A SVI 10.10.10.2 (priority 120, master), Router B SVI 10.10.10.3 (priority 100, backup), and VRRP virtual IP 10.10.10.1 (the gateway every client points to).

The clever enhancement on IOS XE Catalyst SD-WAN is VRRP Interface Tracking. Instead of failing over only when the chassis dies, the master can lower its priority — and hand over the master role — when tracked WAN interfaces or SD-WAN SLA trackers detect loss or degradation. A good design tracks the DIA interface state, the MPLS/backup link state, and an SD-WAN SLA tracker (loss, latency, jitter). If Router A loses all usable WAN circuits, its priority drops below Router B's, so Router B becomes master and the LAN default gateway effectively moves to the router that still has working WAN connectivity. Always enable VRRP preempt on the preferred router so it reclaims the master role once its WAN health is restored.

On the WAN side, redundancy centers on the TLOC (Transport Location), which identifies an edge transport attachment point by color, encapsulation, system-IP, and interface IP, and is used for both control (OMP) and data tunnels. Each Catalyst 8000 forms control connections from each active TLOC to all controllers, with BFD monitoring each TLOC for fast failover. TLOC extension takes redundancy further by letting one router "borrow" the other's WAN circuits over an inter-router link (commonly a redundant LACP port-channel). If Router A owns DIA1 and Router B owns DIA2, TLOC extension lets each router use both as valid TLOCs, so each can survive the loss of its own WAN ports by exiting through the peer's transports. Because the inter-router link becomes critical, it should be redundant and carry QoS so TLOC-extension traffic is not starved.

Chassis and power redundancy

Redundancy is not only a network-protocol concern; it extends down to the hardware. Within a single Catalyst 8000 chassis, many models support dual power supplies so that the failure of one PSU — or one feed from a PDU — does not drop the router. Pairing each power supply with a separate circuit or UPS protects against an upstream electrical fault as well. At the branch level, the dual-router design is itself the chassis-redundancy strategy: two physically separate routers mean that a hardware failure, software crash, or maintenance reload of one chassis leaves the second fully operational. When Router A fails completely, VRRP on every VLAN converges to Router B, which continues using its own (and any TLOC-extended) circuits, so the site stays up.

A worked end-to-end example ties the layers together. Two Catalyst 8300 routers share site-ID 100 (system IPs 10.255.100.1/.2), joined to the same SD-WAN domain and controller cluster. Each forms an LACP port-channel toward the switch stack. For VLAN 10, Router A is VRRP master at priority 120 and Router B is backup at 100, with the VIP at 10.10.10.1. VRRP tracks each router's DIA and MPLS interfaces plus an SD-WAN SLA tracker. TLOC extension runs in both directions, so each router advertises both its own and the peer's TLOCs. Application-aware routing prefers MPLS for voice/critical apps (failing over to DIA on SLA degradation) and DIA for general internet/SaaS. The result: if Router A's DIA fails but MPLS survives, internet traffic shifts to Router B's DIA (possibly via TLOC extension) while MPLS stays on A; if a whole router or PSU fails, the site rides through on the survivor.

The accepted HA best practices pull this together: deploy at least two controllers per role in separate locations; provide at least two diverse transport circuits per site (DIA plus MPLS, optionally with LTE/5G backup); use BFD and SLA trackers tuned to avoid flapping; apply QoS so control, BFD, and VRRP traffic are prioritized; match MTU/MSS across links and TLOC extensions; align VRRP roles with any inline firewall design; and always test failover scenarios before production cutover.