Template drawback ?

SOLVED
suneq
Getting noticed

Template drawback ?

Hi,

I would like to deploy the MX67W on around 700+ sites, all sites share the same configuration except the local networks. All local networks belong to the subnet 172.16.0.0/12 and have the same subnet mask /26.

From what I learned from the documentation, configuration template seems to be a good solution. 

 

Is there any important drawback that I must know before implementing template please?

Is there any situation in which a modification of the template or a human error can cause outage or problem? I surely overthink but I'm scared of losing all 700+ sites at the same time.

 

Thanks for your advices.

1 ACCEPTED SOLUTION
Ryan_Miles
Meraki Employee
Meraki Employee

Two primary considerations come to mind. First, the purpose of a config template is for when all bound sites (devices) will have very similar configs. While you can do local overrides for configs that need to deviate from the template setting not every setting is available for overrides. The list of current available overrides is here. If you require variability per site and it's not an available override then templates would not be right for you.

 

The other main factor is firmware upgrades. Firmware is set at the template level. So, when you perform a firmware upgrade it will apply to all bound networks. It will respect local timezone settings. So, if you set an upgrade for say 1am it will occur at 1am in the local timezone of the network. Just something to be aware of as this may sway you to go one way or another.

 

With that said I've had great success with templates and find them helpful in large deployments. But sometimes unique requirements drive a customer to not use templates and instead manage at scale with API's or a UI+API overlay solution like Boundless.

 

Interested in hearing from other users here.

View solution in original post

4 REPLIES 4
Ryan_Miles
Meraki Employee
Meraki Employee

Two primary considerations come to mind. First, the purpose of a config template is for when all bound sites (devices) will have very similar configs. While you can do local overrides for configs that need to deviate from the template setting not every setting is available for overrides. The list of current available overrides is here. If you require variability per site and it's not an available override then templates would not be right for you.

 

The other main factor is firmware upgrades. Firmware is set at the template level. So, when you perform a firmware upgrade it will apply to all bound networks. It will respect local timezone settings. So, if you set an upgrade for say 1am it will occur at 1am in the local timezone of the network. Just something to be aware of as this may sway you to go one way or another.

 

With that said I've had great success with templates and find them helpful in large deployments. But sometimes unique requirements drive a customer to not use templates and instead manage at scale with API's or a UI+API overlay solution like Boundless.

 

Interested in hearing from other users here.

@Ryan_Miles thanks a lot, your advices are very helpful.

 

For my understanding, if we have to change a setting which is not available for override, we have to unbind the site and we will have an outage because the local networks will revert to the version prior applying the template, am I correct?

 

Thanks.

@suneq We're rolling out a new feature to retain configs on template unbind. Most orgs should already have this enabled now.

 

Screen Shot 2021-11-04 at 7.32.02 AM.png

GreenMan
Meraki Employee
Meraki Employee

I find customers with a lot of sites  (the sort of scale you describe for yourself) find the power of Templates a bit scary;  yes, it's great that you can update a setting on that many sites, very, very quickly - but, as Spiderman rightly said;  with great power comes great responsibility.  😁

 

Remember though that all changes are visible in the Organization > Change log - so could be just as quick to back out at the same scale/rate   (maybe not so nice for firmware updates).

 

In such instances, maybe consider having 'a few' Templates, each of a scale that makes sense to you.

Template 1 - maybe with just my Lab Network bound - for initial testing

Template 2 - Ten guinea pig sites, I roll change out to second

Template 3 - 50 sites for further reassurance

Templates 4, 5, 6, 7, 8, 9 - each with max 100 bound sites, which I can phase the change through

 

A change in 10 GUIs still takes time, but a lot less than doing the same to 700 sites individually!   It's also maybe simpler than API if you don't have in-house skills for that (or can't readily get them in from a Cisco partner).

 

You can have as many Templates as you like, so cut this to suit your needs (and bearing in mind Ryan's excellent advice - in particular that the Dashboard API is there to provide ultimate flexibility, if you need it.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels