When working with templates, there are some important considerations that you should take into account. One of the most common issues relating to the usage of templates is a result of how the unique subnetting is assigned to template children and how some deployments that employ summary routes can interact.

As part of the validation to ensure that the unique subnets handed out to template child networks are unique and to help keep the process as generally simple and straightforward as possible, the Dashboard automatically checks the current configuration of all related networks in the organization to ensure that no existing subnets or static routes overlap with the newly assigned unique subnet range. This ensures that in a large, AutoVPN-enabled topology, there are no unexpected overlapping routes. As a result, deployments that advertise large summary routes like 10.0.0.0/8 or 172.16.0.0/16 from a VPN hub will experience validation issues when trying to deploy new templated networks with unique subnets if the unique subnet range is contained within the advertised summary route. While this is an entirely valid design and helps to reduce the number of routes advertised to each spoke site, the related validation failure when deploying new sites once this topology is established is clearly an unwanted effect.

Fortunately, for customers who are looking to operate with this design, this strict validation can be modified by Meraki Support to apply only to other networks under the same template, allowing that validation to be partially bypassed and for new template child sites to be successfully deployed with unique subnet ranges inside the advertised summary routes.

In this case, however, it is imperative that you manually monitor and maintain a list of active and VPN-enabled subnets across the organization, as it is possible to see overlapping subnets automatically assigned between networks attached to different templates within the same organization. If an overlapping subnet is assigned and needs to be resolved in this situation, a local override can always be configured for the related network to manually configure a nonoverlapping subnet range for the child network.

One caveat that is specific to MX security appliance hardware and templates is how templates handle logical versus physical port numbering for MX appliances. Over the years, Meraki has developed and released a number of different MX models, each designed with a specific purpose and niche to fill within the market. As time has gone on, these purposes and niches have grown and evolved, and so has the MX product line to match. As a part of this growth and evolution, the physical port numbering scheme for different MX models has also evolved. Because of this, not every MX is consistent when referencing a physical port from the Dashboard configuration. For example, some models of MX use the physical port 1 as the primary uplink, making physical port 2 the first LAN port. Other models have a dedicated and labeled Internet port for the primary uplink, with the labeled port 1 acting as the first LAN port.

Obviously, this can cause some confusion when making a template-level configuration for the MX LAN ports. The important aspect to remember in this situation is that the Dashboard configuration at the template level is always referencing the logical function of a port, not necessarily the physical label. So when configuring port 3 of an MX on a template, that configuration will apply to the logical LAN port 3, whether that be the port physically labeled as port 3 on the device or not.

Pro Tip

You can find a matrix of Dashboard port mappings and their physical port counterparts for every model of MX in the “MX Cold Swap” document at https://documentation.meraki.com. Scroll down to the “Port Mapping for Different MX Models” section.

Another minor caveat to be aware of applies when you are using MV cameras with templates. Currently, Dashboard networks containing MV cameras can be attached to templates as template children and function as expected, with the exception of making template-level configurations for MV cameras. Due to the nature of how MV camera configurations are handled and the uniqueness of each camera and associated configuration within a deployment, all device configurations for the related MV cameras must still be done from within the child network.

The final potential caveat to be aware of applies when unbinding or removing a network from a template. Doing so presents two options for the configuration of the network after being removed from the template: Unbind and Retain Configurations or Unbind and Clear Configurations. Shown in Figure 4-3, these options allow administrators to unbind a network from a given template and either retain the current template-derived configuration or revert the network configuration to the state prior to binding the network to the template.