Combined tempaltes

A model citizen

Combined tempaltes



I am currently making a combined template that we will hopefully be able to use for multiple sites.


I have read the guides but I'm still unclear on a few details...


I started making the template based on an existing network. Obviously this template will be fine on the network it was made from but when applying it to other sites, is there a way to specify which settings it will or wont effect?


For example, the site to site VPNs will need slightly different settings on each site etc. Those sites already have everything setup and configured and I don't want the template to go changing and breaking things.


Also, switch port configs - will the template apply the same settings to each site or does it leave stuff like this alone? 



7 Replies 7
Kind of a big deal

As far as I understood, when you make a change within a template, the individual settings of the networks will be lost.

Thats why I have not used them so far. Only for intial setups. 

Recognizing I´ll need to do some specific settings, I´ll unbind the network. (At least when the specific  change is part of the template, if not its fine (example, template only manages wifi and I change something within switchportsettings, its fine))


My template is completely new, so all products appear in it, it is not cloned from a existing network.

A model citizen



so rather than clone an existing network for the template with all its mx unit settings etc, maybe it would be best to create a brand new blank template and just edit the settings I want to be applied to every network?

If I don't touch the other settings, then when I apply the template, it wont effect them? If I don't edit the settings, they will remain as default. - Basically, would a blank template change all a sites settings to default, or would it not change anything? Only things that have been specifically edited in the template get applied? 

The key to this is that only a subset of settings can have local overrides (settings that differ between sites bound to a common Template).  These are readily visible when you create a Template and bind a Network to it:   they are the 'Configure' options that are still visible when you select the Network, not the Template to which it's bound.   Configuration options that are only visible when you are managing the Template will have the same setting across all Networks bound to that Template.  This commonality simplifies the management of a large number of sites.    Bear in mind that you can have multiple Templates, if required.


The key local override relates to MX VLANs and subnets;   in an AutoVPN config you configure in the Template, for each VLAN, a subnet of a size of your choosing (e.g. /24) from a defined supernet (e.g. /16)   Dashboard will randomly choose a free one from that range, for each new Network bound to the Template.   Typically sites already have IP addressing of course, so you then go into the Network to change each VLAN to match the existing addressing for the site.  This change is made once, generally by whoever is overseeing the implementation of the MX at the site.


A 'blank' Template will configure all bound Networks to have whatever is the default set of settings.   Just because you haven't changed a setting, doesn't mean the Template isn't in control of that setting.

If the parameter you are interested in can be locally overriden, you can change it separately in each Network.  If not, you can only change it in the Template, at which point that will be applied to all Networks bound to that Template.

ooof, sounds like it's better to just forget about using templates altogether. If I have a large number of changes to do I'll just do them by API or something.

My recommendation would be just to try them, though API is a really powerful tool too, if you have some scripting abilities

I'd love to but I just cant risk it on live networks.

The future seems to be API so it's a good opportunity to learn it, I can create a bunch of scripts for any common changes we might make or for setting up new devices etc and hand them out to the team which should also help reduce human error in configs etc.

Thanks for the help!

No - you certainly wouldn't use it on live networks first - you'd set up a test-bed of some kind.   But you'd probably want to do that for API too..?

Get notified when there are additional replies to this discussion.