EOS in large network with multiple stages

A few ways you can approach it.

You can run concurrently using multiple users and multiple cue lists. Each stage with it's own cue lists and consoles all on the same show.  The benefit and drawback of being able to control other stages from any console if you want to (or don't know what you are doing).

You can run each console with an sACN offset on the same network. Give each console a block of 50 or 125 universes.  As primary they won't step on each other, in client you will see each console on the network you want to connect to. aRFR will see it the same.

For the TV and Movies I work on I work with the first system.  As we are sharing set builds, effects, colors and working together.  If I was not working with the same team or if other companies were also shooting these stages then I'd do version 2.

Before getting into this is how I do it so it's the right way blah blah blah.... let's take a step back before searching for the solution you're looking for and look at the question. If I understand it you're changing from your old system to a new system, but would like it to work like the old system? Though related Cobalt and EOS can work in fairly different ways when we start talking about sACN networking.

Rather than asking why can't EOS do what Cobalt does... can we instead go with...

Why are you changing to an EOS platform?

What solutions are you looking to EOS for?

What is your current network architecture?

Now for the how I do it bit... I run 7 stages, split between various subnets all on one ETCNet. They can run independently, connected as client, multiconsole, backup, and remote. So... no your new system is not Cobalt, but it IS EOS and provides you even more options and network flexibility.

In summary, I think you might be better off flexing the possibilities of what EOS networking can do, opposed to making it do what Cobalt does. Otherwise, I'd ask why you're changing platforms?

Shortly why we change... Our Cobalt is rather old and it´s time to renew our consoles... Why bought a new Cobalt nowdays and why not buy MA? ;)

I start with VLC, Congo over to Cobalt and have large knowledge about how we could work with separated stages in same network. Now I try to understand and found how it works in new world of EOS so I could setup a system that works from my office and on stage, without stage 1 do things on stage 2. It´s hard to found information about this. Guide how it works on a single stage with server, backup and clients to a large TV-studio with diffrent setups.

We have a coreswitch in the middle and every stage has there own network switches. If we disconnect our coreswitch on one stage, we lose remote and fileserver. Easy if something strange happens in the rig, just unplug one cable and complete isolate the stage from rest of theater, and run our performance.

It had happens that collegues start up in wrong "net", and turn on lights on other stage. We had before that I split sACN-universe on multiple stages, mainstage sACN 1-24, stage 2... sACN 31-44 and so one. Then a guest performande came and connected to the network and did not know how the sACN in our building works and start to turn on lights on wrong sACN universe. This I solved in our core switch to block all sACN-traffic between our stages.

On our main stage we got 11 networkswitches, but we only have a maximum of two switces between console and DMX-node. The othwer stages have one or two networkswitches.

Well... the short reply is that I expect you're having difficulty finding it because one of the great things about EOS and ETC at large is that system design and architecture are at the wield of the end-user. A blessing and a curse. Are you working with an integrator or system designer? That's no judgement on you or your skill. You're in the trench and it's your house, you know what you need. An integrator and designer knows 5 places that did that 10 ways.

You could... segment your network at the layer 2/3 level like you are.

You could... put gateways into your network that limit the reach of guest sACN sources.

You could... set users with limited outputs.

You could...

We... in a large multi purpose facility including broadcast...  do a combo of users, gateways and patching. If it's not patched "EOS" won't control it.. for the most part excluding human error. Stage 1 is patched only for stage 1. Can it technically control anything else on the network yes... if it were patched and the active user has access and if the gateways on that stage allow the passing of control in that universe....

In your case I would focus on separating your control. Let the network be the network. Follow networking best practices and don't try to use your switches to manage sACN Control. Traffic yes, control no.

Use EOS networking with gateway configurations and appropriate sACN Control best practices to achieve your goals.

I think you'll have a lot easier time and expand the possibilities of control and reliability within your system.

Well... the short reply is that I expect you're having difficulty finding it because one of the great things about EOS and ETC at large is that system design and architecture are at the wield of the end-user. A blessing and a curse. Are you working with an integrator or system designer? That's no judgement on you or your skill. You're in the trench and it's your house, you know what you need. An integrator and designer knows 5 places that did that 10 ways.

You could... segment your network at the layer 2/3 level like you are.

You could... put gateways into your network that limit the reach of guest sACN sources.

You could... set users with limited outputs.

You could...

We... in a large multi purpose facility including broadcast...  do a combo of users, gateways and patching. If it's not patched "EOS" won't control it.. for the most part excluding human error. Stage 1 is patched only for stage 1. Can it technically control anything else on the network yes... if it were patched and the active user has access and if the gateways on that stage allow the passing of control in that universe....

In your case I would focus on separating your control. Let the network be the network. Follow networking best practices and don't try to use your switches to manage sACN Control. Traffic yes, control no.

Use EOS networking with gateway configurations and appropriate sACN Control best practices to achieve your goals.

I think you'll have a lot easier time and expand the possibilities of control and reliability within your system.