> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # Template Variables and Bulk CSV Attach - URL: https://www.pinglabz.com/sd-wan-template-variables/ - Published: 2026-11-06T06:12:32.000Z - Updated: 2026-11-06T06:12:32.000Z - Description: Shared SD-WAN templates need variables for system-ip, site-id, and LAN addresses. I mapped our two C8000v edges into a CSV-shaped table and did not attach it. - Author: Jaime - Tags: SD-WAN, Cisco A shared template is useful only if each site can still be different. System-ip, site-id, and the LAN address cannot be the same on every branch. Manager handles that with device variables, and for a pile of sites it lets you fill those variables from a CSV file instead of clicking through a form fifty times. This post shows which values on our two C8000v edges would become variables, and how a bulk CSV attach is supposed to work on Cisco Catalyst SD-WAN 20.18.2.1 with IOS XE 17.18.02, built in my home lab. I read the variable names Manager stores inside factory feature templates. I did not attach a template, download the attach CSV from the GUI, or upload a file. This is part of the [Cisco SD-WAN series](https://www.pinglabz.com/cisco-sd-wan/). Previous: [Configuration groups and feature profiles on 20.18](https://www.pinglabz.com/sd-wan-configuration-group-profiles/). Next: [Service VPN with OSPF on the LAN](https://www.pinglabz.com/sd-wan-ospf-service-side/). For SD-WAN Manager (formerly vManage) and the other old names, see the [name map](https://www.pinglabz.com/vmanage-vsmart-vbond-names/). ## The problem: one shape, many blanks edge1 and edge2 share an organization name, a Validator, the same colors, and the same OMP advertise statements. They do not share identity or LAN prefixes. | Value | edge1 | edge2 | Shared? | | ----------------------- | ---------------------- | ---------------------- | ------- | | hostname | edge1 | edge2 | No | | system-ip | 10.0.0.1 | 10.0.0.2 | No | | site-id | 100 | 200 | No | | organization-name | pinglabz-lab | pinglabz-lab | Yes | | Validator | 172.16.30.30 | 172.16.30.30 | Yes | | VPN 10 LAN | 192.168.10.1/24 on Gi4 | 192.168.20.1/24 on Gi4 | No | | OMP advertise connected | yes | yes | Yes | If you put the unique rows into the shared feature template as plain text, the second site cannot use that template. If you leave them as variables, one catalog serves both. Think of the template as a form letter. The CSV is the merge list: one row per device, one column per blank. [![Example CSV rows for edge1 and edge2 use placeholders for chassis IDs and the running system-ip, site-id, and VPN 10 addresses](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/sd-wan-template-variables.png)](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/sd-wan-template-variables.png?ref=pinglabz.com) ## Where variables live In classic feature templates, a field that can vary has a device-specific option. Manager then names the variable. The device template collects every variable from every child feature template. On attach, you either type the values or export a CSV, fill it, and upload it again. The factory System template `Default_System_Cisco_V01` stores three device-specific names: `host-name`, `system-ip`, and `site-id`. Those match the blanks on our two edges. The retail branch System template `Factory_Default_Retail_Branch_System` uses the same three, and also exposes extras such as `system_console_baud_rate` and `LAN1_Employee-ip`. Most of its other fields are marked ignore or constant (timezone UTC, overlay-id 1, and so on). A factory banner is simpler. `Factory_Default_Retail_Banner` defines `banner_login` and `banner_motd` as constants. The unused banner template I created, `unused-banner`, kept `banner_login` as a constant and left `banner_motd` as a variable. Transport templates add more columns quickly. `Factory_Default_Retail_VPN_O_INET_NAT_Enabled` includes device-specific names such as `vpn_if_bandwidth_upstream`, `vpn_if_bandwidth_downstream`, and `Transport_INET_VPN0_color_value`, plus NAT pool range names. I did not download a CSV from the attach screen, because that workflow selects devices. The names above come from the feature-template definitions themselves. Configuration groups use the same idea when you associate devices and deploy. Cisco documents editing system-ip and site-id on the Associate Devices page from 17.11.1a / 20.11.1, and converting values in a CLI add-on profile into device-specific variables from 20.10.1. The table below is the CSV I would build from those Manager names plus our running CLI. It is not a file I downloaded from the attach GUI. ``` csv-deviceId,host-name,system-ip,site-id,vpn10_gi4_ip ,edge1,10.0.0.1,100,192.168.10.1 ,edge2,10.0.0.2,200,192.168.20.1 ``` Cisco's downloaded files use the chassis or UUID as the device key, not the hostname alone. Use the identifier Manager shows in Configuration > Devices. I left placeholders here rather than reprint chassis identities. Shared values such as `organization-name pinglabz-lab` and `advertise connected` stay in the template or profile. They should not appear as columns unless you really want them to differ later. ## Attach in bulk, carefully Cisco's classic attach workflow, documented under device templates, is: 1. Select the device template and the target devices. 2. Download the CSV (or fill the table in the UI). 3. Upload the completed file. 4. Preview the assembled configuration per device. 5. Configure, which pushes the result and sets `vManaged` to `true`. Configuration groups replace "attach" with associate plus deploy, but the CSV-shaped list of per-device values is the same job. I did not run those five steps against the lab edges. They currently report: ``` vManaged: false Configuration template: None ``` A preview is the last safe moment to notice that edge2 would receive `192.168.10.1` because a column was copied down. After configure, Manager owns the box. ## Verify a spreadsheet before you upload it | Check | What to look for | | -------------------------------------------------------- | -------------------------------------------------- | | Unique system-ip | No duplicate 10.0.0.1 | | Unique site-id, unless it is a dual-edge site on purpose | 100 and 200 here are different sites | | LAN addresses | 192.168.10.1 stays on edge1, 192.168.20.1 on edge2 | | Device key | Chassis or UUID matches Configuration > Devices | | Preview | Service VPN and OMP advertise lines still present | After a real attach, `show sdwan system status` should name the template and `show ip route vrf 10` should still show the local connected prefix plus the far-site OMP route. ## What breaks - **A copied column.** Two sites with the same system-ip will not join the overlay correctly. - **The wrong device key.** Manager cannot map the row, or it maps it to a different box. - **Attaching without a preview.** You find the missing LAN interface after user traffic dies. - **Changing site-id on a live dual-edge design by accident.** Site-id is also the Site of Origin value used later in [service-side BGP](https://www.pinglabz.com/sd-wan-bgp-service-side/). Do not treat it as decoration. ## Key takeaways - Shared templates need variables for system-ip, site-id, hostname, and interface addresses. Shared facts stay in the template. - Our two edges already show which blanks a CSV would fill. Manager's factory System template names those blanks `host-name`, `system-ip`, and `site-id`. I did not download or upload a CSV. - Bulk attach is download, fill, upload, preview, configure. Preview is the last cheap mistake. - Leave `vManaged` false on a working CLI lab until the spreadsheet and the preview agree.