Now let’s shift the focus from why to how. Creating a Device Template actually begins with Feature Templates, which may seem counterintuitive at first, but makes perfect sense once you understand why.

To understand Feature templates, let’s look at the CLI configurations of three similar routers that are part of the same SD-WAN network. Even that small portion of the config clearly shows that most of the CLI configuration lines are the same on every router. The same config repeats again and again (in white), and only some parameters have device-specific values (in yellow). 

Let’s take one logical section of the CLI configuration, such as the system config. If we replace the values that differ on every device (in yellow) and keep the lines that repeat everywhere (in white), we get the following system block.

system
 system-ip {{system-ip}}
 site-id {{site-id}}
 organization-name "example"
 vbond vbond.example.com

Now we can reuse this block on every device by simply replacing the placeholders {{}} with the device-specific value. For example, instead of {{system-ip}} on cEdge-1, we enter 10.255.255.1, on cEdge-2, we enter 10.255.255.2, and on cEdge-3, we enter 10.255.255.3.

Well, that is what feature templates are. A Feature Template is a reusable configuration block that defines one specific function or capability of a network device. You can think of it as the GUI-form equivalent of one logical section of the CLI configuration. For example, the OMP section in the CLI config holds all OMP-related settings configured on the device, as shown on the left in the diagram below. 

The feature template idea is that we can define this configuration in a template using the GUI, as shown on the right. You can see how Feature templates abstract the complex CLI configuration into a form-based GUI representation, where you can fill in the desired parameters for a given capability. This makes it easier to manage and update the settings for a particular feature across multiple devices without having to configure each one individually via the CLI.

However, looking at this example, you may be asking a question like: “But we must configure different values on different routers. For example, some routers have different send_path_limit values. Do we need to create multiple OMP feature templates?” 

To account for that, Cisco SD-WAN allows you to define device-specific variables within feature templates. 

Variables

We know very well that network devices have many device-specific parameters that are unique per device. For example, each device has a unique hostname, System IP, IP addresses, interface names, etc. To account for that, vManage gives us the ability to specify three different types of values when creating feature templates:

• Global (the globe icon) - When you specify a global value, it applies to all devices to which the feature template is attached. For example, this will probably be the case for the SNMP communities, Syslog servers, TACACS, or banner messages that are exactly the same on many devices. At a later stage, when you want to change the Banner of all nodes, you would simply update the feature template value, and it updates every device that is using this feature template.  
• Device-specific (the device icon) - When you know that a particular parameter is unique for each device, you specify a device-specific value. When you select the Device Specific icon, the “Enter Key” box opens. It asks for a key, which is a unique string that identifies the parameter during the attachment process. In the diagram below, these are the [system_site_id] and [system_system_ip] strings. Upon applying a device template to a given device, the vManage controller asks for the actual unique value for these variables.
• Default (the checkmark icon) - The default value represents the factory default settings. It cannot be changed, so the text box is always greyed out and inactive. When you want to overwrite the default value, you change the value type to either Global or Device-specific.

In practice, every feature template that you create on vManage contains variables. When you attach a device template to a device, the vManage controller prompts you to populate the variables with actual values. For example, when you attach a device to the template shown in Figure 1.11, vManage prompts you to give values to the [system_site_id] and [system_system_ip] variables. 

Additionally, you can make an entire group of parameters device-specific by checking the “Mark as Optional Row” checkbox in the right corner of the configuration object, as shown in the screenshot below. 

When a configuration object is checked as Optional, as shown above, the entire group of parameters is greyed out and is treated as device-specific but optional; then it can be included or omitted for each individual device when attaching devices to the device template.

One crucial aspect of Device Templates is that the process of entering values for all device-specific parameters can become unscalable when using the vManage GUI while working with many devices. That’s why the solution allows us to upload a spreadsheet with all values for all device-specific variables.

Variable Spreadsheet

When you attach a device template to a large number of devices, it becomes hard to enter the required values in the browser. There are many situations where you might have to start again from scratch. For example, if you incidentally close the web browser tab while entering variable values or incidentally click back to the previous page. The browser is not the best tool for entering many values. The Cisco SD-WAN allows us to define all device variables in Excel, which is a more suitable tool for working with large numbers of values.    

We create a spreadsheet with the header row containing the variable name, each row corresponding to a device, and the columns defining the values of variables. However, the first three columns of the spreadsheet must always be in the following order:

1. csv-deviceId - The serial number that uniquely identifies the device.
2. csv-deviceIP - The System IP address of the device.
3. csv-host-name - The hostname of the device.

The following table is an example of a spreadsheet with the values for three vSmart controllers. 

You can export a skeleton table from a device template by clicking the action icon … and selecting “Export CSV.”

Excel spreadsheets are much more scalable and less prone to errors than the web browser when populating variable values to vManage. 

CLI Add-on Feature Templates

When you start working with feature templates, at some point, you certainly encounter the following situation – you want to enable a feature on a router, but you can’t find the respective feature template. Well, that’s because not all available features on a device have feature templates on vManage. As we said earlier, the CLI has more access to the box’s hardware than the GUI/API. That’s why, for some “not used that much” features, you must use a CLI add-on template that adds a block of custom CLI code to the device configuration.

When we attach a device to a template containing both a Feature and a CLI Add-on template, vManage merges the configuration, prioritizing the CLI add-on template. The controller first generates the entire device configuration based on the feature templates and then adds the CLI add-on commands on top. Hence, the CLI add-on template adds an additional configuration and can overwrite an equivalent configuration in a feature template.

When configuring a CLI Add-on template, always ensure that the commands you enter appear in the “show sdwan run” on the device itself. Also, remember that only one CLI add-on template can be attached to a device template.

Default Feature Templates

When you power up a Cisco device like a router or switch for the first time, its configuration is not empty, right? All configuration parameters are set to their default values. It is the same logic as with Device Templates. A brand-new device template uses all default device templates that come preconfigured. Then the device template represents the default device configuration.