# Cisco SD-WAN Templates: — Feature Templates, Device Templates, Variables & Config Groups Source: https://ai.techclick.in/blog_cisco_sdwan_templates Markdown: https://ai.techclick.in/blog_cisco_sdwan_templates.md Publisher: Techclick Infosec Pvt Ltd Cisco SD-WAN templates explained for the ENSDWI 300-415 exam: feature templates (System, VPN, OMP, BGP, NTP, AAA), device templates, the variables CSV, Global vs Device-Specific scope, config preview/diff, CLI add-on templates, and the newer Configuration Groups. Cisco SD-WAN Templates: — Feature Templates, Device Templates, Variables & Config Groups student learning map A visual study map for Cisco SD-WAN Templates: — Feature Templates, Device Templates, Variables & Config Groups showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Cisco SD-WAN Templates: — Feature Templates, Device... Cisco SD-WAN · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① Why templates — you can't CLI... 4. Practice ② Feature templates — System, VPN,... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most engineers think… Most engineers think SD-WAN provisioning is "open vManage, fill in the boxes once, hit attach, done." So they build one giant template, type the IP for every site by hand, and SSH a quick fix whenever something's off. Wrong — and it falls apart at scale. The whole point is small reusable feature templates assembled into one device template , with the per-site bits pulled from a variables CSV so 500 routers ride one design. And the moment you SSH a manual change onto a template-attached device, vManage marks it Out-of-sync and your next push either overwrites the hack or fails validation. Templates only help if you treat them — not the CLI — as the source of truth. ## ① Why templates — you can't CLI 500 routers by hand Picture Sneha at Infosys handed a rollout: 500 branch WAN Edge routers, all basically the same design — same routing, same NTP, same security — differing only in hostname, system-IP and site-ID. Configuring them by SSH is a week of copy-paste and guaranteed typos. The SD-WAN answer is templates : build the design once, scale it by data, not by hand. The model has three layers and it's worth memorising the order. A feature template is one small block — "the System config", "VPN 0", "the NTP config". Several feature templates assemble into one device template , which holds the complete operational config for one device type (a C8000v, an ISR 1100). That device template attaches to many devices, and the bits that differ per site come from variables filled from a CSV — one row per router. 👉 So far: feature template = one block, device template = the full config, variables = the per-site bits from a CSV. Next: see the whole assembly line in one picture. Figure 1 — Feature → Device → many devices Left column: reusable feature templates (System, VPN, VPN-Interface, OMP, BGP, Banner, NTP, AAA). They assemble into one device template in the middle. A variables CSV with one row per site fills device-specific values. The device template attaches to many WAN Edge routers, each getting its own values from its CSV row. - Feature templates → one Device template → many devices (Variables from CSV) reusable feature templates System (host, site-id) VPN 0 / 512 / 1 VPN-Interface OMP / BGP Banner / NTP / AAA Device Template one per device type (C8000v, ISR1100…) Variables CSV host_name,system_ip,site_id one ROW per site Mumbai-Edge1 10.0.1.1 · site 101 Pune-Edge1 10.0.2.1 · site 102 Chennai-Edge1 10.0.3.1 · site 103 same template, different CSV row → different config Key idea: build detection once, scale by ROW. 500 routers = 500 CSV rows, not 500 CLI sessions. manual/CLI drift template-managed variable/per-device key idea in sync Follow it left to right: small feature templates snap into ONE device template; a variables CSV with one row per site fills the per-device values; the same template attaches to many routers, each picking up its own row. The dabbawala analogy lands this for Indian students. Mumbai's dabbawalas don't memorise 200,000 individual home addresses — they use one coding scheme (the colour-and-letter tag on each tiffin) that every dabbawala reads the same way. The scheme is the template; the specific tag on your tiffin is the variable. Build the scheme once and 5,000 dabbawalas scale it. SD-WAN templates are exactly that: the design is shared, the address is per-tiffin. You'll live on two screens. Feature templates are at Configuration > Templates > Feature Templates (click Add Template , pick the device model, pick the feature). Device templates are one tab over at Configuration > Templates > Device Templates . In Catalyst SD-WAN Manager the menu is the same; only the product name on the banner changed. ### Four words you'll use every day Tap each card — these anchor the whole lesson. 🧱 Feature template tap to flip One small reusable block of config — System, VPN, OMP, NTP. The Lego brick. You attach features to a device template, never straight to a device. 📦 Device template tap to flip The complete config for ONE device type, built by assembling feature templates. This is what you attach to actual routers. 🏷️ Variable tap to flip A per-device value (hostname, system-IP) the template leaves blank as {name} and fills from the CSV. Same design, different address. 📄 Variables CSV tap to flip One column per variable, one row per device. Fill it, upload it, and 500 routers get 500 different configs from one template. So: scale by row. Quick check · Q1 of 10 Rahul at TCS attaches a freshly-built 'System' feature template directly to a router and it won't apply. What did he get wrong about the model? a) Feature templates attach to a DEVICE template, not straight to a device — assemble it into one first b) System templates need a separate licence c) He must reboot vManage d) Feature templates can't hold the hostname Correct: a. A feature template is a building block; you assemble it into a device template, and the device template is what attaches to routers. No licence, reboot, or hostname limit is involved — the hierarchy is feature → device → device. Pause & Predict Predict: if 500 routers share ONE device template but each has a different hostname and system-IP, where do those 500 different values actually come from? Type your guess. Reveal answer Answer: From the variables CSV — one column per variable (host_name, system_ip, site_id), one row per device. The template holds the shared design and leaves the per-site fields as {variables}; the CSV supplies the 500 unique rows at attach time. That's how one template produces 500 distinct configs. ## ② Feature templates — System, VPN, OMP, BGP, NTP, AAA & variables Feature templates come in families, and a handful cover most of a branch. The System template owns the device identity — site-id, system-ip , hostname, timezone, organization-name. The VPN template defines a routing segment: VPN 0 is the transport (underlay) side, VPN 512 is the out-of-band management VPN, and VPN 1+ are your service/LAN VPNs. VPN-Interface templates sit inside a VPN and configure an actual interface (IP, tunnel, TLOC colour ). The control-plane and edge-services families round it out. OMP tunes the overlay routing protocol (timers, path limits, redistribution). BGP configures the LAN-side or DC routing peering. Banner , NTP and AAA are the housekeeping you set once and reuse everywhere — login banner text, time servers, and the TACACS/RADIUS login model. The exam loves asking which family owns which knob, so anchor them now. ### Scope: the dropdown that makes one template fit many sites Every field on a feature template has a small scope dropdown to its left, and this is the single most important control in the whole lesson. Global means the same value on every attached device (organization-name, NTP server). Device-Specific turns the field into a variable — vManage asks you to name it (e.g. host_name , system_ip ) and the CSV fills it per router. Default leaves the factory value so you type nothing (and make no typo). Figure 2 — Global vs Device-Specific vs Default Three columns explain the scope dropdown on each feature-template parameter. Global applies one value to all attached devices. Device-Specific creates a variable like host_name that the CSV fills per device. Default uses the factory value. A worked example shows organization-name as Global, system-ip as Device-Specific variable, and NTP stratum left at Default. The scope dropdown — the one control that makes a template reusable Global same value on EVERY attached device organization-name e.g. ntp server, AAA model Device-Specific becomes a VARIABLE filled per device by CSV {system_ip} {host_name} unique per site → variable Default factory value — you type nothing ntp stratum, log level leave it = fewer mistakes Worked example — one System feature template, three scopes organization-name = Techclick-Infosec [scope: Global] system-ip = {system_ip} [scope: Device-Specific] console-baud-rate = (factory) [scope: Default] manual/CLI drift template-managed variable/per-device key idea in sync The rule of thumb: same-for-all → Global; unique-per-site → Device-Specific (a {variable}); factory-fine → Default. The worked example shows all three on one System template. This is exactly why one feature template fits many sites. Set organization-name to Global (every device shares it), set system-ip and host-name to Device-Specific (each device's own value), leave console-baud-rate at Default. Now the same System template rides Mumbai, Pune and Chennai — only the CSV row changes. Get greedy and make everything Device-Specific and your CSV balloons to 40 columns; get lazy and make a unique field Global and every router ends up with the same system-IP (a fast way to break OMP). vManage → Configuration → Templates → Feature Templates → Add Template → (device model) → Cisco System . Real fields and the scope dropdown. (Recreated for clarity — your console matches this.)"> 🖥️ This is the screen you build the block on — vManage → Configuration → Templates → Feature Templates → Add Template → (device model) → Cisco System . Real fields and the scope dropdown. (Recreated for clarity — your console matches this.) vmanage.lab.local · Configuration · Templates · Feature Template · Cisco System 1 Template Name BR-System-IND 2 Hostname {host_name} 3 System IP {system_ip} Site ID {site_id} Organization Name Techclick-Infosec (Global) 4 Timezone Asia/Kolkata (Global) Save Common mistake — the duplicate system-IP Symptom: you attach the template and OMP routes flap or controllers drop a device. Cause: system-ip was left as Global (or hard-typed) instead of Device-Specific, so two routers booted with the same system-IP. Fix: set system-ip, site-id and hostname to Device-Specific variables so each router gets its own value from its CSV row — never a shared one. cEdge CLI — verify what the System template actually pushed Branch-Edge1# show sdwan running-config system Branch-Edge1# show sdwan system status Expected output system host-name Mumbai-Edge1 system-ip 10.0.1.1 site-id 101 organization-name "Techclick-Infosec" ! Version: 17.12.3a vManage mode: enabled Reboot reason: power-on Quick check · Q2 of 10 Priya at ICICI wants the NTP server identical on all 200 branches but each branch to keep its own hostname. Which scopes does she pick? a) Both Global b) Both Device-Specific c) NTP server Global, hostname Device-Specific d) NTP server Default, hostname Global Correct: c. Same-on-all values (the NTP server) are Global; unique-per-site values (the hostname) are Device-Specific variables filled by the CSV. Making both Global would force one shared hostname; both Device-Specific would needlessly bloat the CSV with an identical NTP column. Pause & Predict Predict: you set hostname to Device-Specific but forgot to put a host_name column in your CSV. What happens at attach time? Type your guess. Reveal answer Answer: vManage won't let you complete the push — the attach wizard shows the missing variable and the device row stays incomplete until you supply a value. Device-Specific fields are mandatory inputs; an empty required variable fails validation rather than silently pushing a blank hostname. Add the column (or type the value in the per-device form) and re-validate. ## ③ Device templates — assemble, fill the CSV, preview & push Now you assemble. At Configuration > Templates > Device Templates you click Create Template > From Feature Template , pick the device model, name it, and then slot your feature templates into the sections vManage lays out — Basic Information (System, Logging, AAA, BFD, OMP, Security), Transport & Management VPN (VPN 0, VPN 512 and their interfaces), Service VPN (VPN 1+), and Additional Templates (Banner, NTP, SNMP). Each device template is specific to one device type — you can't share a C8000v template with an ISR 1100. With the template built, you attach devices . vManage now needs the per-device values for every Device-Specific variable you created. You fill them two ways: type them into the per-device form, or — the way you do 500 at once — download the variables CSV , fill it offline, and upload it. The CSV has one column per variable and one row per device; the header row carries the exact variable names you chose. ### ▶ Follow one device template from build to live Watch a branch router go from 'attach' to a verified push, step by step. Press Play for the healthy path, then Break it to see the failure. ① Assemble feature templates → snapped into one Device Template (C8000v) ▼ ② Fill CSV download CSV → host_name,system_ip,site_id → one row per site ▼ ③ Preview Config Preview shows the diff : what changes vs the device's current config ▼ ④ Push Configure Devices → push → status Done-Scheduled → Success , device In-sync Press Play to step through the healthy path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Never skip the preview. Before the push, Config Preview (and the Config Diff view) shows the full intended config and exactly what will change versus what's on the box. This is your last safety gate — read it the way you'd read a git diff before committing. If the diff shows a line you didn't expect (a VPN being removed, an interface shut), stop and fix the template, don't push and hope. ### Out-of-sync and CLI mode — how a manual change breaks the contract A template-attached device is in Manager (vManage) mode — vManage owns the config and the box rejects local edits. Detach the template and the device drops to CLI mode , where you configure it by hand. The trap: SSH a 'quick fix' onto a device that's still in Manager mode and vManage flags the device template Devices.">Out-of-sync — running config no longer matches intended config. Figure 3 — Manager mode vs CLI mode + out-of-sync A decision diagram contrasting Manager (vManage) mode where the device template owns the config, against CLI mode where no template is attached. A manual config change on a template-attached device causes an out-of-sync state. The fix is either resync from the device or update the template and push, never silent SSH edits. Manager mode vs CLI mode — and how SSH breaks the contract Manager (vManage) mode device template attached vManage owns the config local CLI edits are rejected ✓ CLI mode NO template attached you configure box-by-box manual SSH allowed — at your own risk Detach Re-attach The trap: SSH a quick fix onto a template-attached device vManage flags the device template Out-of-sync — running config ≠ intended config. Next template push will overwrite your hack, or fail validation. Right fix A: update the template edit feature template → Config Preview/Diff → Configure Devices (push) Right fix B: detach to CLI mode make the change, then re-attach so intent matches reality manual/CLI drift template-managed variable/per-device key idea in sync Read the two boxes, then the red trap: an SSH change on a template-attached device makes it Out-of-sync. The two green fixes show the only safe ways to make that change stick. Aditya at HCL faces this Aditya, an L2 engineer, gets paged: a branch router shows 'Out-of-sync' in vManage after a late-night change. Someone had SSH'd in to add a static route during an outage and it 'worked', but now every template push is blocked. Likely cause The device was in Manager mode (template attached), so the manual CLI static route created a mismatch between the device's running config and vManage's intended config. vManage refuses to push until intent and reality are reconciled — it won't silently overwrite an unknown change. Diagnosis He checks Configuration > Devices, sees the device template status is Out-of-sync, and opens Config Diff to see exactly which lines drifted (the rogue static route). vManage > Configuration > Devices > (device) > … > Template Status / Config Diff Fix Add the static route into the correct feature template (or a CLI add-on template) so intent now includes it, preview the diff, and push. The push reconciles the device — the manual route is now template-managed, not a hidden drift. Verify After the push, Configuration > Devices shows the device template In-sync, Config Diff is empty, and 'show sdwan running-config' on the box matches the template — future pushes succeed. Quick check · Q3 of 10 Karthik at Airtel finds a device stuck Out-of-sync because of a manual CLI tweak made during an outage. What's the clean way to make that change permanent? a) Leave it — Out-of-sync is harmless b) Add the change into the feature/CLI add-on template, preview the diff, then push to reconcile c) Factory-reset the router d) Delete the device template entirely Correct: b. You fold the manual change into the template (a feature template or a CLI add-on), preview the diff, and push — now intent includes it and the device returns to In-sync. Ignoring Out-of-sync risks the next push overwriting the change; a reset or deleting the template are destructive overkill. Pause & Predict Predict: a device is in Manager mode and you SSH in to 'config t' a quick change. What does the device do, and what does vManage show? Type your guess. Reveal answer Answer: In Manager (vManage) mode the device rejects local configuration edits — you generally can't commit a manual change at all. If a change does land (e.g. via a path vManage doesn't control, or after a partial detach), vManage flags the device template Out-of-sync in Configuration > Devices, because the running config no longer matches the intended template. The fix is to make the change through the template, not the CLI. ## ④ CLI add-on templates, Configuration Groups, preview & rollback Feature templates can't expose every IOS-XE knob. When the GUI lacks a setting, you use a CLI add-on feature template . You write the literal IOS-XE commands, add the CLI add-on to the device template alongside your normal feature templates, and vManage appends those lines to the generated config. You can even use {variables} inside the CLI add-on so per-device values still come from the CSV. It's the escape hatch — powerful, but the more you lean on it, the less the GUI represents the truth. vManage — CLI Add-On feature template body (real IOS-XE lines) ip ssh version 2 login block-for 120 attempts 4 within 60 ntp server 10.5.5.10 source GigabitEthernet0/0/0 banner login ^C Authorised Techclick users only ^C Expected output ! appended to the device config on push, after the GUI-built features Branch-Edge1# show sdwan running-config | include block-for login block-for 120 attempts 4 within 60 ! In-sync after push — the add-on lines are now template-managed The newer model Cisco wants you on is Configuration Groups with feature profiles . Instead of dozens of separate feature templates, a configuration group bundles them into profiles (System, Transport, Service) and adds a guided workflow plus per-device parcels. You'll find it at Configuration > Configuration Groups (in Cisco vManage Release 20.11.1 and earlier it lived under Configuration > Templates > Configuration Groups ). From 17.12/20.12 Cisco recommends migrating, and a Configuration Conversion Tool turns existing templates and policies into config groups and policy groups. This matters for the exam and the field in 2025–2026. From Cisco IOS XE Catalyst SD-WAN 17.15.1a / Control Components 20.15.1 , some features are configurable only by API, and those releases are the last to support a few legacy template paths — another nudge toward Configuration Groups. From 17.15.1a you can also share a feature profile across multiple configuration groups, so you stop rebuilding the same System profile per group. The 300-415 blueprint explicitly asks you to configure and verify CLI and vManage feature configuration templates and to describe configuration groups and feature profiles — so know both worlds. Figure 4 — Templates cheat-sheet A nine-tile cheat sheet covering the template hierarchy (feature to device to attach), feature template families, the variables CSV, CLI add-on templates, configuration groups and feature profiles, config preview and rollback, out-of-sync, the menu paths, and the verification show commands. Cisco SD-WAN Templates — your one-glance map Hierarchy feature → device → attach → fill variables → push Feature families System · VPN · VPN-Int OMP · BGP · Banner/NTP/AAA Variables CSV 1 col / variable, 1 row / device download after you fill it CLI add-on template for config the GUI lacks appended on top of features Config Groups feature profiles, newer model 17.12/20.12+ recommended Preview / Rollback Config Diff before push roll back to last good vManage paths Configuration > Templates > Feature Configuration > Templates > Device Configuration > Configuration Groups (20.11 & earlier: Templates > Config Groups) verify on the WAN Edge show sdwan system status show sdwan running-config system show sdwan control connections vManage: Device > Config Preview / Diff Your one-card map of the whole lesson — keep it open while you build your first device template, and revisit it before any ENSDWI 300-415 question on provisioning. vManage → Configuration → Templates → (device template) → Attach Devices → Config Preview / Config Diff . (Recreated for clarity — your console matches this.)"> 🖥️ This is the safety gate you'll use on every push — vManage → Configuration → Templates → (device template) → Attach Devices → Config Preview / Config Diff . (Recreated for clarity — your console matches this.) vmanage.lab.local · Configuration · Templates · Attach Devices · Config Diff 1 Device Mumbai-Edge1 (C8000v) 2 Template Status Out-of-sync → will reconcile 3 View Config Diff (intended vs running) Variables source Upload CSV (1 row per device) 4 On error Roll back to last good config Configure Devices Pro tip — the mental model that sticks For any provisioning task ask two questions: (1) is this value the same on all devices or unique per site? same → Global, unique → Device-Specific variable, factory-fine → Default; (2) can the GUI express it? yes → feature template, no → CLI add-on, and if you're starting fresh in 2025+ → Configuration Groups. Almost every template decision maps onto that grid. Common mistake — pushing without reading the diff Symptom: a push removes a VPN or shuts an interface that branch users needed, and the site goes dark. Cause: you attached a template and hit Configure Devices without opening Config Preview / Diff. Fix: always read the diff first (it's a git-diff for your router); if you see an unexpected removal, fix the template before pushing. If a push does break a site, roll back to the last good config from the device's task view. Prove you've got the templates model Take a real ask — "stand up 50 new branches, identical design, each with its own hostname and system-IP" — and name it cold: build feature templates (System/VPN/OMP/NTP/AAA), set hostname & system-ip to Device-Specific variables, assemble one device template for the model, fill a 50-row variables CSV, preview the Config Diff, push, and verify In-sync with show sdwan running-config . If you can say that without notes, you're ready for the cert and the NOC floor. Next: Centralized Policy & Topologies Back: Segmentation & VPNs Quick check · Q4 of 10 Meera at Wipro needs an IOS-XE setting that her feature templates don't expose, but she still wants vManage to own the config. Best move? a) SSH the command in and ignore the Out-of-sync flag b) Add a CLI add-on feature template with the raw IOS-XE lines, then push c) Detach the template permanently and run CLI mode forever d) Downgrade vManage Correct: b. A CLI add-on feature template lets you push raw IOS-XE lines that the GUI doesn't expose while keeping the device in Manager mode and the config template-managed. SSHing it in creates Out-of-sync drift; living in CLI mode loses central management; a downgrade fixes nothing. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. Why can't I attach a feature template straight to a router? Global vs Device-Specific vs Default — how do I pick? What does 'Out-of-sync' actually mean and how do I clear it? When do I use a CLI add-on template instead of a feature template? Are device/feature templates being replaced by Configuration Groups? How do I push to 500 devices without 500 forms? Pre-curated from Cisco SD-WAN docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember In Cisco SD-WAN, which object do you attach directly to a WAN Edge router? a) A single feature template b) A variable c) A CSV row d) A device template (built by assembling feature templates) Correct: d. A device template — the complete config for one device type, assembled from feature templates — is what attaches to routers. A feature template is only a building block; a variable and a CSV row supply per-device values, not the attachment object. Q6 · Apply You must deploy 300 branches with identical design but each its own hostname, system-IP and site-ID. What do you build? a) 300 separate device templates b) One device template with hostname/system-IP/site-ID set Device-Specific, filled by a 300-row variables CSV c) One feature template attached straight to all 300 routers d) A CLI add-on template per router Correct: b. One device template carries the shared design; the per-site fields are Device-Specific variables filled by a 300-row CSV. 300 device templates defeats the purpose; a feature template can't attach to a device; a CLI add-on per router is manual sprawl. Q7 · Apply On a System feature template, you want organization-name identical everywhere but system-IP unique per router. Which scopes? a) organization-name Global, system-IP Device-Specific b) Both Global c) Both Device-Specific d) organization-name Default, system-IP Global Correct: a. Same-on-all values are Global (organization-name); unique-per-device values are Device-Specific variables (system-IP). Both Global would force one shared system-IP and break OMP; both Device-Specific needlessly bloats the CSV; Default/Global for these is wrong. Q8 · Analyze A device template reads 'Out-of-sync' and every push is blocked. Controllers are up and the CSV is complete. Most likely root cause? a) The vManage licence expired b) The device model doesn't match the template c) A manual CLI change was made on a template-attached (Manager-mode) device d) The variables CSV had too many rows Correct: c. Out-of-sync means running config diverged from intended config — classically a manual CLI change on a Manager-mode device. A licence issue or row count wouldn't produce 'Out-of-sync', and a model mismatch blocks attach entirely rather than showing drift on an attached device. Q9 · Analyze You need an IOS-XE knob the feature-template GUI doesn't expose, but the device must stay vManage-managed. Best approach and why? a) SSH the command in and accept Out-of-sync b) Detach the template and run CLI mode permanently c) Use a bigger variables CSV d) Add a CLI add-on feature template with the raw lines and push — config stays template-managed Correct: d. A CLI add-on feature template pushes raw IOS-XE lines while keeping the device in Manager mode and the config template-managed. SSHing creates drift; permanent CLI mode loses central management; the CSV only supplies variable values, not new config lines. Q10 · Evaluate Two designs for a 2025 greenfield 200-branch rollout: (A) one giant device template with every per-site value typed in by hand; (B) feature templates with Device-Specific variables + a CSV, previewed via Config Diff, or Configuration Groups. Which is stronger and why? a) A — one big template is simpler to maintain b) B — variables + CSV (or Config Groups) scale by row, the Config Diff is a safety gate, and no hand-typed per-site values means fewer typos and no Out-of-sync drift c) A — typing values by hand avoids CSV errors d) Identical — pick by licence cost Correct: b. Design B scales (one row per site, not one form per site), the Config Diff catches mistakes before push, and Configuration Groups is Cisco's recommended path from 17.12/20.12. Hand-typing 200 sites guarantees typos and drift; one giant hand-filled template doesn't scale and isn't simpler at all. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: In one line, why does a manual SSH change on a template-attached device cause Out-of-sync? Then compare to the expert version. Compare with expert answer Expert version: Because the device is in Manager mode where vManage owns the config — the manual change makes the running config diverge from vManage's intended template config, so vManage marks the device template Out-of-sync until you fold the change into the template and push. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Templates at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary Feature template One reusable block of config (System, VPN, OMP, NTP, AAA). The building block you assemble into a device template — never attach it straight to a device. Device template The complete operational config for one device type, built by assembling feature templates. This is what you attach to real routers. Variable A per-device placeholder like {host_name} or {system_ip} created when a field's scope is Device-Specific; filled per router from the CSV. Variables CSV vManage-generated spreadsheet: one column per variable, one row per device. Fill offline and upload to push to many devices at once. Scope (Global / Device-Specific / Default) The dropdown on each feature-template field: Global = same on all, Device-Specific = a variable, Default = factory value. System IP Each device's unique controller-plane ID (a /32). Set Device-Specific; duplicating it breaks OMP and controller connections. CLI add-on feature template A feature template holding raw IOS-XE lines, appended on top of GUI-built config, for settings the feature templates don't expose. Supports {variables}. Manager (vManage) mode A device template is attached; vManage owns the config and rejects local CLI edits. CLI mode No template attached; you configure the device box-by-box over SSH/console. Detaching a template puts a device into CLI mode. Out-of-sync The device's running config no longer matches the intended template config (usually a manual CLI change). Shown in Configuration > Devices. Config Preview / Config Diff vManage view of the full intended config and exactly what will change vs the device's current config — your last safety gate before push. Configuration Groups / feature profiles The newer model (recommended 17.12/20.12+): feature profiles (System/Transport/Service) bundled into a configuration group; a Conversion Tool migrates classic templates. #### 📚 Sources Cisco Catalyst SD-WAN Systems and Interfaces Configuration Guide, IOS XE 17.x — "Configure Devices" (feature → device template assembly, Global/Device-Specific/Default scope, attach, variables CSV, Manager vs CLI mode, out-of-sync, Config Preview/Diff). cisco.com/c/en/us/td/docs/routers/sdwan/configuration/system-interface/ios-xe-17/systems-interfaces-book-xe-sdwan/configure-devices.html - Cisco Catalyst SD-WAN Systems and Interfaces Configuration Guide, IOS XE 17.x — "CLI Add-On Feature Templates" (raw IOS-XE lines appended on top of feature templates; supports variables). cisco.com/c/en/us/td/docs/routers/sdwan/configuration/system-interface/ios-xe-17/systems-interfaces-book-xe-sdwan/cli-add-on-feature-template.html - Cisco Catalyst SD-WAN Configuration Groups Reference Guide — "Introduction" & "Using Configuration Groups" (feature profiles System/Transport/Service; Configuration > Configuration Groups path, 20.11.1 and earlier path; Conversion Tool; shared profiles from 17.15.1a). cisco.com/c/en/us/td/docs/routers/sdwan/configuration/config-groups/configuration-group-guide/introduction.html - Cisco Community — "Viptela Template out of sync" (real customer thread: device template Out-of-sync after a manual change, detach-to-CLI / update-template-and-push resolution). community.cisco.com/t5/sd-wan-and-cloud-networking/viptela-template-out-of-sync/td-p/4453460 - Cisco Community — "Failed to attach template … Device failed to process request" (push/validation failures from bad variable values; check Config page before push; verbose log /var/log/nms/vmanage-server-deviceconfig-template.log). community.cisco.com/t5/sd-wan-and-cloud-networking/failed-to-attach-template-to-c1111-8pltewea/td-p/4113797 - Release Notes for Cisco Catalyst SD-WAN Control Components Release 20.15.x — features API-only from 17.15.1a/20.15.1; last release for some legacy paths; migration to Configuration Groups encouraged (recent ≤12-mo item). cisco.com/c/en/us/td/docs/routers/sdwan/release/notes/20-15/rel-notes-controllers-20-15.html - Cisco 300-415 ENSDWI v1.2 exam topics — "Configure and verify CLI and vManage feature configuration templates" and "Describe configuration groups and feature profiles for configuration management". learningnetwork.cisco.com/s/ensdwi-exam-topics ### What's next? Templates get the boxes configured identically — but identical isn't enough. Next you'll bend the overlay to your will: hub-and-spoke vs mesh topologies, control policy on vSmart, and steering traffic where the business needs it. Next · Centralized Policy & Topologies → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt