Any suggestions for managing MSTP config revisions?

[JustJoe]

So I understand the concept that MSTP requires consistent Name, Revision, and instance-hash on each switch in a "region" group of switches so they can recognize each other as such.

Also is logical that if there are changes to entries in an instance on one switch, the revision number should also be changed/(incremented) and all other switches must (manually) duplicate that new revision.

My question: Since the revision mismatch during the updates can cause some switch "excitement" in that region until they all match again, does anyone have a procedure or guidelines they follow to do it smoothly?

mike99 maybe?

and Feature Request:

Would it be possible for the WS STP tab to have a "Mini-" Backup & Restore of just the MSTP instances that could allow easy management and synchronization across switches. The filename could default to the region Name + Revision. Might even be able to copyright that concept?

(edit to attempt title correction to MSTP ... arg.)

[Stephen]

As far as best practice's for the production scenario of MSTP, mike99 or another experienced user would be a good reference as it's still a beta feature for us and I only work out of a lab.

As for you're feature request, I've actually been pondering for awhile some similar idea's.
Would you be interested in me wrapping this feature into the Netonix Manager?
We've been thinking about how we might perform global config actions with the manager and potentially this might be a good candidate for testing.

If I implemented something like that on the Manager - would you be willing to try it out?

[JustJoe]

Gosh Stephen,
Don't hate me, but we so far have not found a need to use Netonix Manager. So even if I did test, it would be in an artificial lab setup which for that might not be useful.

I don't dispute your logic that for an overall network function, N/M would make sense to be able to do it. But then, could it take advantage of underlying common code that could also have access from the GUI ?

One thing to consider is that input from mike99 might help us sort out how to avoid connectivity issues that might arise while there is a mismatch. That would be something N/M would also have to deal with.

It's funny because in other sources I have read, people refer to it as ManualSTP instead of Multiple. lol! MSTP in layer2 reminds me of OSPF configuration in layer3. Your GUI implementation of MSTP is actually rather smooth and informative.

[mike99]

We should test the impact to be sure but I'm pretty sure it will follow CIST forwarding until region match again. It would probably impact the network. It's best practice to add extra vlans by region just in case so you won't have to do a config change if you need an new VLAN.

I would personally make sure that management VLAN is not in a include in a MSTP instance, handle through the CIST, to make sure management is not affected will doing MSTP config changes.

I found the following link that try to explain it in details
https://costiser.ro/2014/02/13/how-can- ... r-network/