Configuration Templates, switch profiles and STP root bridge placement.

[ToryDav]

Hello,

I have a question for those who have worked with configuration templates. 

When setting the STP root bridge for a [switch] network using a configuration template, you must specify a profile at the template level. That setting is no longer available via the network settings when using configuration templates. 

This is ok because everything is cookie cutter. MDF stack member 1 should be the root bridge (where the network routers connect). 

The MDF stack member 1 is set with a switch profile, that profile is specified in the template switch settings and a priority of 4096 is specified.

However, this doesn't take effect. STP election occurs and continues to select sub-optimal root bridge within multiple different networks (different sites configured in the same way).

For example, now the root bridge shows the correct switch member as the root bridge, but with the default STP priority, not the priority as 4096 as it should be based on the config.. Some other locations it will be a suboptimal root bridge election altogether. 

Any tips for configuring STP when using Switch stacks, Configuration templates and switch profiles? Anything I am missing regarding setting this up with stacking in play?

Seems to be a bit buggy to me since I believe it is configured, but never takes effect, even with rebooting the network.. I've seen this happen at several sites now and isn't a 1 off issue.

[ToryDav · Accepted solution]

Found my answer:
From: 
https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/...

1. STP bridge priority cannot be changed on switch stacks using templates. In a network template, switch profiles can be assigned STP bridge priority values from Switch > Switch settings > STP configuration. A value assigned to a switch profile, however, will only propagate to the standalone switches bound to that profile; switch stacks will retain the default STP priority of 32768. 

So nothing actually can be done.

[MarcP]

---

@ToryDav wrote:
So nothing actually can be done.

---

Don´t use a template seems to be the answer 😉

While reading your initial post I already thought, why to use a template for a Corestack? Within one network you normaly only have one. 

Our Meraki SE even told me, if I have one site with several access switches and a core, I should put the core in its own network. <-- example was for firmwareupdates...

[ToryDav]

Hi @MarcP,

Yes I agree with you. I didn't design or implement this setup, just dealing with the effects of it. This particular organization has like 70-ish sites. So templated deployment made sense at the time I'm sure, but this limitation wasn't taken into consideration.

I am working on some work arounds for them to resolve this.

Where there are two or more stacks, the "Core" stack will need to be moved to a separate network.
Where there is one stack, I can increase the "access" standalone switches to priority 61440 on the template and this will allow the stack with the default 32768 priority to be root.
Where there are NO stacks, there is no issue.

The more I work with config templates, the less inclined I am to ever use them in a deployment in the future, to your point, why even bother.