Maestro Best Practices

[Lari_Luoma]

Hi Everyone!

I’m excited to share that my colleague John White and I have co-authored a new Maestro Best Practices Guide. This document brings together lessons learnt from real-world projects and field experience, and we hope it will serve as a practical resource for anyone working with Maestro.

Please feel free to save it for your own use — and more importantly, let us know your feedback. If you have additional best practices or tips from the field, share them here. I’ll be happy to incorporate them into future updates so this guide continues to grow with community input.

Looking forward to your thoughts and contributions!

[Danny]

Thanks for putting this together!

I recommend running the document through a grammar checker like LanguageTool to improve clarity and correctness.

[Lari_Luoma]

Thanks for the feedback Danny. I replaced the file in my original post with a fixed version now. Some of them I already had fixed in the Word-version, but for some reason the version I posted had still those errors.

[Dario_Perez]

Great work!

[the_rock]

Amazing job...super helpful! 

[John_White]

Looks good Lari, thanks again for your support on this. 

[the_rock]

Jonny White...man, cant believe I see you on here...its been FOREVER lol

Hows life? : - )

Andy

[PhoneBoy]

Great stuff, I'll make sure to call it out in the next CheckMates Go episode 🙂 

[Timothy_Hall]

Incredible, thanks @Lari_Luoma!  I always appreciate seeing battle-hardened best practice recommendations like this, formed by dozens (if not hundreds) of complex Maestro deployments in the real world.

[the_rock]

I saw all @Lari_Luoma did for one of our clients for maestro deployment and they were so impressed, to say the least. Personally, I had never seen that level of knowledge and expertise from someone, its hard to even describe with right words.

Andy

[Lari_Luoma]

Thank you so much, Andy — I’m truly humbled by your kind words.

It’s always a privilege to support our customers, wherever they are, and I’m glad I could contribute to a successful Maestro deployment. Seeing the impact of our work firsthand and knowing it made a difference for the client is incredibly rewarding.

I’m grateful to be part of a team that values excellence and collaboration. Always happy to help!

[the_rock]

100%...maybe if I say RC in Ottawa, you may remember who it was : - )

Andy

[_Val_]

Thanks, @Lari_Luoma , great work!

[adelguia]

I would add this Key reason in point 6:

• If shared uplink is used then each SG should have unique VLAN IDs. It's no posible to have the same VLAN ID in multiple SGs with shared UPLINKs. 

That's an important point that everyone should have in mind while designing. We are in the middle of a migration and had to change the design from 2 SG to 1 SG because of this.

[Lari_Luoma]

Good point, and thanks for bringing it up.

Just to highlight: different VLAN IDs between Security Groups on shared uplinks are not only best practice, but a mandatory requirement. The system won’t allow the same VLAN ID across multiple SGs on a shared uplink, so this needs to be accounted for during design.

That said, the stronger recommendation is to use dedicated interfaces per Security Group whenever possible. Shared uplinks can create dependencies where external issues affect every SG tied to that interface, reducing isolation and resiliency.

Your example is a good reminder that planning these details upfront helps avoid costly redesigns mid-migration.