It’s important to understand how templates operate in the Dashboard to be able to take full advantage of their capabilities and avoid some of the more common pitfalls. Creating a template is similar to creating a regular network in that it can be created as a combined template or as a standalone type such as security appliance only or switch only; see Figure 4-1 for an example.

Figure 4-1 Short Example List of Configuration Templates as Viewed from Organization > Configuration Templates in the Dashboard

Unlike regular Dashboard networks, however, configuration templates only hold configurations and do not contain any individual devices. Instead, networks are attached to templates as child networks, which allows them to inherit the template-level configurations that apply to any devices in those networks.

This enables you to create and configure a template and then push that pushed to any network that is attached to the template as a child network without requiring additional manual configuration. Because most configurations can be set at the template level through the combination of network-level settings and device profiles, for many deployments, a single template can be configured and used to deploy hundreds of sites with minimal to no network-specific configurations required.

Using a configuration template can greatly simplify the configuration and deployment process when creating a new network, whether that be something as simple as a basic teleworker endpoint or something more complex like an entire store or branch network. As an example of the options available in configuration templates, this section demonstrates using a template for the MX subnetting and VLAN configurations, which can be defined at the template level in either of two different ways: same subnetting or unique subnetting. Keep in mind as you read through this introductory section on templates that while the focus is on MX use cases, you can use templates for devices other than MX security appliances, with several unique features offered for different device types, such as MR and MS devices using templates. For now, focusing on a single product will enable you to concentrate on how you can use templates in the Dashboard.

When configuring VLANs at the template level, you choose a subnetting method for each VLAN from the Subnetting drop-down list, as shown in Figure 4-2. The options are Unique or Same. If you select Same for a given VLAN, every security appliance attached to the template will be configured with an identical subnet and interface IP address for that VLAN. This option is great for consistency among sites that require only local and Internet access, but it would cause routing issues, due to the duplicate subnets for sites, where multiple locations may need to communicate over VPN back to a central hub location. For that reason, VLANs created using the Same subnetting option cannot be enabled for AutoVPN.

Figure 4-2 Demonstrating a Unique Subnet Configuration for a VLAN in a Template

In a situation like that, you can choose the Unique subnetting option for one or more VLANs on the template, as in Figure 4-2. This requires that you define a subnet pool on the template for the VLAN in question as well as a child subnet size to determine the number of addresses that should be allocated from the available subnet pool for that VLAN to each child network. For example, if your subnet pool for the VPN-enabled VLAN on a template is configured as 10.0.0.0/8, then you can choose to uniquely allocate an appropriate number of addresses for that VLAN to each child network, automatically ensuring that no overlapping subnets exist for each template child. For example, you could set the allocation size down to a /29 or /30 if very few unique addresses are required at each site, or set it all the way up to a /10 if required, or anywhere in between to best match the needs of the deployment.

The MX subnetting options are just one of many examples of how configurations can be created and customized at the template level based on the needs of the child networks. Each device type has a multitude of options when creating related template configurations, allowing for nearly endless customization of each template and the associated child network and device configurations.

Leave a Reply

Your email address will not be published. Required fields are marked *

Explore More

API Tips and Tricks – Automating the Dashboard – Cisco Meraki

When you use the Dashboard API, there are several important things that you should keep in mind. Primarily, any account that has API access enabled has the same level of

SNMP – Automating the Dashboard – Cisco Meraki

SNMP is also a potential option that can be employed for automation with any Meraki platform. One notable difference between SNMP and webhooks or syslog is that when using SNMP,

Routing – MX and MG Best Practices – Cisco Meraki

In addition to the previously discussed security features offered by the MX series, MX devices are also capable of performing L3 routing through a number of different configurations, including basic