Template Variables and Bulk CSV Attach

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. Previous: Configuration groups and feature profiles on 20.18. Next: Service VPN with OSPF on the LAN.

For SD-WAN Manager (formerly vManage) and the other old names, see the name map.

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.

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.

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-CHASSIS>,edge1,10.0.0.1,100,192.168.10.1
<EDGE2-CHASSIS>,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

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. 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.