Skip to main content

Wider Page

 

Bigger text

 

A device template is a construct that contains a complete device configuration. Each device template is specific to a device type/model. For example, you create a device template for ISR4431 routers, another for C8200 routers, and another for C8300 routers, even though they can serve the same function in the network and have the same configuration structure. For example, you might have C8200 and C8300 routers at the same type of branches, but you need two different Device Templates because they are different hardware models.

When a device is attached to a device template, the vManage controller replaces its entire configuration with the one generated by the device template. Some people wrongly assume that the configuration generated by a device template is added to any existing configuration present on a device, which is not the case. 

For example, a router is configured via CLI and is connected to the SD-WAN control plane. You attach this router to a Device Template. The vManage controller replaces the router's entire present config with the configuration generated by the device template. If the router cannot connect to the control plane in 5 minutes, it reverts to its previous configuration. This safety mechanism is called the Rollback timer and can be customized via vManage.

In summary, the Device Template is a configuration end-state. 

We create device templates using multiple individual feature templates that make up the entire device configuration, as shown below. 

Device Templates.
Figure 1. Device Templates.

Notice that you can achieve the desired device configuration via three different combinations of templates:

  • Option 1: Using feature templates only.
  • Option 2: Using feature templates plus a CLI AddOn template.
  • Option 3: Using a CLI template that describes the device configuration completely in command-line syntax.

If all required features have a defined feature template on vManage, we use Option 1. If some capabilities do not have feature templates, we use Option 2 by adding a CLI AddOn template. When we want to use only command-line syntax, we use Option 3, which is not generally recommended for routers but is commonly used for onboarding controllers into vmanage-mode.

Notice also that some features are mandatory, which is indicated with the *(asterisk) in the top right corner. To simplify the creation of templates, Cisco SD-WAN comes with factory-default templates for each capability. Therefore, you simply use the factory-default feature template for mandatory features for which you do not intend to change the factory-default settings. 


Figure 2. Device Templates.

The big advantage of Device templates is that they allow network administrators to manage, deploy, and update configurations in a centralized manner across the network fleet rather than having to configure each device individually using the CLI. It provides a consistent and scalable method of managing the network, reducing errors, and saving time. It is also helpful when deploying new or replacing existing devices, as it allows for rapid and consistent configurations, rollbacks, and version control.

However, although device templates make configuring devices more scalable and consistent, they require deeper planning and analyzing than the old way of using the CLI and standalone device configurations. Administrators must carefully analyze which devices have identical functions and capabilities except for a couple of device-specific parameters and group them into a device template, as shown in Figure 1.9. However, this is not always a straightforward task. 

Figure 3. Grouping devices by function and role (per model).

CLI Templates

A CLI template is another configuration construct that allows us to define the entire configuration of a device using CLI command-line syntax instead of combining multiple feature templates. Variables are available using double braces, as shown in the following output.

system
host-name             {{NAME}}
system-ip             {{SYSTEM_IP}}
site-id               {{SITE_ID}}
organization-name     networkacademy-io
vbond vbond.networkacademy.io

Notice that not only one but any arbitrary number of configuration lines can be turned into a variable. For example, the entire BGP configuration section can be turned into a variable named {{BGP_CONFIG}}.

CLI templates are typically used for attaching a device template to the vSmart controllers so that they get into vManaged mode or for devices that use too many features that do not have templates, such as EtherChannel, advanced PIM/BGP config, OSPF VRF-lite, etc.

Device Template Workflow

Now, let’s see the workflow when working with Device Templates. It is especially important to see how the workflow changes when we go to Configuration Groups. 

Device Templates workflow.
Figure 4. Device Templates workflow.

Notice how vManage behaves when a network admin takes different actions on a device template, as shown in the diagram above.

  1. Attach devices to a device template - When a network admin attaches or detaches devices to a device template, the vManage controller takes the following actions:
    1. If the attached devices are online, vManage immediately pushes the configuration, and the config becomes active upon successful deployment.
    2. If the attached devices are offline, configuration is scheduled, and vManage will push the configuration immediately after the attached devices come online.
  2. Edit a device template - When a network admin edits a device template, vManage immediately pushes the configuration again, and it becomes active straight away.
  3. Edit a feature template – When a network admin edits a feature template, vManage updates every Device Template that uses this Feature Template. Then, it pushes the resulting configuration to all devices attached to the affected device templates.

Remember that there is a Rollback Timer - a configurable interval at which the devices roll back to their previous configuration if they lose the control connections to vManage.

Device/Feature Templates Best Practices

Let’s now review the best practices that can help you manage your templates better and more efficiently.

  1. Plan ahead: Planning ahead is the most essential aspect of templates. Before creating templates, you must clearly understand the environment - which devices have identical configurations and roles and which do not; which features can be combined in a feature template that can be reused and which cannot; and so on. While templates are powerful and flexible, it's easy to make them overly complex. Ensure templates are as simple as possible. Break complex templates with multiple variables into multiple feature templates with fewer variables.
  2. Standardize the environment: Templates work best in a standardized environment where everything is as predictable and repetitive as possible. For example, consistent interface naming across branches allows you to hardcode the interface names into the respective feature templates as global parameters. Then, upon deploying, you don’t need to populate interface names for each device. This can be a significant improvement when working with thousands of devices. For example, for all ISR4431 routers, you always connect Gi0/0 to the Internet and Gi0/1 to the MPLS provider, etc. We talk about this in more detail in the Design chapter.

  3. Descriptive naming: This one is super important. Always use descriptive names for your device and feature templates. The name must indicate the role, scope, platform, and purpose. This makes it easier to identify and apply templates correctly. Some people also include template versioning in the names so that they can quickly roll back to older stable versions if required. Additionally, some (including myself) prefer to use only capital letters when specifying template names. This makes it very quick and easy to differentiate your templates from the factory default ones. 

    For example, I like to use the following name structure for feature templates. Notice all capital letters, the FT- prefix, and the descriptive name. You can also add purpose and versioning for larger-scale deployments.

    FT-<SCOPE>-<FEATURE>
FT-COMMON-SYSTEM
FT-COMMON-NTP
FT-COMMON-AAA
FT-BRANCH-VPN0
FT-DATACENTER-OSPF

    And the following name structure for device templates. Notice all capital letters, the DT- prefix, and the descriptive name. You can also add <VARIANT> at the end, such as SMALL, MEDIUM, or LARGE, etc.

    DT-<ROLE>-<PLATFORM>-<WAN-DESIGN>
DT-BRANCH-C8300-MPLS-INET
DT-BRANCH-C8200-DUAL-INET
DT-DATACENTER-C8500-MPLS-INET
DT-CAMPUS-C8300-DUAL-INET
  4. Use variables wisely: Feature templates support variables, which can be provided when attaching the template to a device. While this is a powerful feature, it's crucial to ensure that variables are used appropriately and not overcomplicated. It is always a tradeoff – more variables make the template more flexible but more complex and cumbersome to deploy, and vice versa. Additionally, some people prefer to rename all variables to more descriptive names. (I personally always use capital letters).
  5. Maintain documentation: Although the solution provides a built-in description field, most administrators maintain separate documentation that describes templates’ purpose, configuration details, variables, and other considerations. In large-scale implementations, the documentation may include spreadsheets with all variables that are used to populate the values on vManage.
  6. Backup templates: Regularly back up your templates and the respective documentation. Although the solution has robust backup mechanisms, it's always good practice to have external backups in disaster recovery scenarios.
  7. Test in the lab: It is a good practice to test a template in a lab environment before applying it to production devices, especially in large-scale deployments, where we attach hundreds of devices to the same template. We have seen the workflow of Device Templates. When you attach devices, vManage immediately pushes the configuration, and it takes immediate effect. Later on, we will see what improvement Configuration Groups provide in that respect.
  8. Review regularly: Over time, the network environment changes. People's perspectives on the network design change as well. It is an excellent practice to review and optimize your templates regularly.
  9. Train the team: It is essential that all team members know the significance of each template and the agreed process for updating or deploying new templates. Since templates are applied at scale, human errors can be applied to hundreds of devices at once. Regularly reviewing the most critical templates with the team is an excellent practice.