As always, let's first provide some context and start with the most fundamental question - why do we need templates in the first place?

Why do we need Device Templates?

Imagine you are hired to do a brand-new greenfield deployment of a network with 100 branches. Almost all branches have the same design: two routers with nearly identical configurations except for the device-specific values such as hostname, router ID, and interface settings. 

In a traditional CLI-based environment, how would you configure all routers? You will likely first create the complete configuration for one branch. Then you will copy the entire configuration in Notepad, replace the device-specific values for each additional site, and paste the configuration to the respective devices. 

Basically, you will create a template of the CLI configuration of two routers, copy/paste it multiple times, and configure the rest of the network one device/one branch at a time, as shown in the diagram below.

It doesn't seem very scalable and efficient, but almost every network engineer has used it at some point in their career. But what if the organization has 1000+ branches? How long would the deployment take? And more importantly, how many configuration errors will occur during all that copy/pasting?

Well, for many years, it has been obvious that large-scale networks need a more consistent way to deploy and manage configurations. Device Templates were introduced to address this exact problem.

From copy/pasting CLI to Templates

Device Templates are the first major step away from the traditional human-to-device CLI configuration model and toward centralized configuration. Instead of configuring each device one box at a time, we define the desired configuration on vManage in a centralized manner and apply it at scale to multiple devices. 

The main idea is to define once and reuse many times. First, we create Feature Templates that define the configuration of each individual feature used by a device model, such as a Catalyst 8300 router. We do this once for features such as System, AAA, OMP, interfaces, routing protocols, VPNs, BFD, etc.

Next, we combine all required Feature Templates into a Device Template. Together, these Feature Templates define the complete configuration of the device. Again, this is done only once per hardware platform, as shown in the diagram below.

The Device Template can then be reused across all devices that perform the same role and require the same general configuration. Instead of building each router configuration separately in Notepad or another text editor, we create the configuration structure once in the Manager GUI and apply it consistently to all routers that have the same role in the network.

This may look like a small change, but operationally it is a huge improvement. Consider a network with a hundred C8300 branch routers. 

• With CLI-based config, we may have to copy, edit, and deploy 100 separate configs in Notepad or another text editor. Also, keep unique values such as System-IP and Hostname in an Excel sheet or a similar tool.
• With templates, we define the common configuration structure once and supply only the values that differ between devices upon deployment. This is much more scalable, reduces copy/pasting errors, and keeps the network config consistent everywhere.

There is also an important change in ownership. The running configuration is still loaded in the device RAM, but the startup config lives on vManage and is managed centrally.