Networking an ETC Ion with one network port

Hi all,

Theater maker/tech lead here. I've got a show that controls the ETC ION using OSC via Qlab. In most theaters, we've had Ions with 2 ethernet ports, and we use their secondary port for our cueing needs. An upcoming theater we're going to only has 1 port, but says "we do have a switch adapter that holds multiple ports."

I'm not quite deep enough on networking to know if this is trustworthy and will work. If they're using their only port for their "primary" house LX needs, does physically adding ports via a switch mean that we'll actually have a "secondary" port for our cueing needs?

I can change the IP address in Qlab so we're on the same network, but not sure if that's sufficient to give us the control we need.

Thanks in advance for any help!


  • Using a switch should work without a problem. Mainly the quality of the switch can cause some problems with multicast.
    You should use a managed high quality switch, set IGMP snooping on and activate the spanning tree protocol.

  • There is no real difference to the way the console will work if you have 1 or 2 network ports.
    The switch doesn't add network adaptors to the consoles just allows multiple things to be connected via a network.

    The advantage of 2 network ports is allows for segregation of different networks so you can only send protocols to different ports.

    So while your machine running Qlad is going to see some extra traffic on its network adaptor its probably not going to cause it any problems unless you are running a large amount of universes from the console.
    Then using correctly setup network switches would handle this and make sure traffic is going to where it needs to go.

  • set IGMP snooping on and activate the spanning tree protocol.

    Isn't this a bit OverPower for this setup?

    Especially the Spanning Tree?

  • No, this is necessary when you use more than one switch in the system.
    - IGMP snooping forwards the Multicast groups, which are used for sACN, to the other switches
    and also looks for wrong multicast traffic.
    - Spanning Tree is useful to avoid loops in the the network system which can crash the whole system.
    This can happen when there is a wrong patch connection.

    In this case it is not clear which network infrastructure is present.

  • Spanning tree (so long as it is Rapid (RSTP)) is never overkill. It should always be enabled.

    IGMP can be overkill on small networks, it could also cause unexpected issues in the wrong hands.
    Case in point, you would also need an IGMP querier in the system when IGMP snooping is enabled.

    My rule of thumb is:

    • < 10 universe no need for IGMP

    • > 10 universes consider using IGMP

  •   You are right but most Layer 2 switches subsume under IGMP Snooping also the IGMP Querier functionality. On Layer 3 switches it can configured separate. 

  • As a location of a IGMP Querier can be critical, this feature is oftern unrequired on edge switches.
    Many edge (and popular cheap) switches do not include an IGMP Querier.
    A notable, popular and cheap, switch of example would be [at least some of] the Netgear prosafe range

  • Yes, the cheap switches can cause many problems, so I replaced my Netgear with Aruba 19xx and 25xx.
    I don't understand people how uses consoles for thousands of Dollars/Euros and use a $20 network switch, and crying that the system are not working as expected.
    I have planned a large ETC System in Munich 2008 with 35 Net3 nodes, 4 Sensor dimmers with doubled processors. I used 3 HPE 25xx switches which cost about € 6000.- at that time, but they work until now in 24/7 without problems.

  • The arts is cash strapped, not every theatre can afford, or need, to spend $$$$ (€/££££) on equipment.

    Expensive or cheap equipment can used incorrectly and not every one has the networking skill to resolve this. Thus why even cheap unmanaged switches have a use.

  • I think if you own a console for e.g. € 10.000.- you will have also the € 300.- for a high quality managed switch.

  • You both made you point clear.
    Thank you very much.

    I am grateful for your advise and knowledge. 


    If we dive any deeper, i think we will slightly go off-topic and explode the Thread.

  • Thanks everyone! It sounds like it's hard to pin down an answer completely without knowing more about their broader networking system. I'll see if I can get more info from them, including what switches they have. Are their any other concise questions I could ask that would help sort this out?

    I'm a little nervous about them configuring a managed switch correctly.(I should have mentioned I'm advancing this tech but won't be there on the ground!).

    If their general system is simple, could the unmanaged switch work? In other words, if I change the target IP in Qlab to their Ion's IP, and send OSC messages which essentially say "hit go on this cue in this cue list," could that play nicely with the activity they're conducting to control their stuff?

    This show has less than 15 fixtures, it's quite small. 

    Thanks again!

  • A very small system like yours will work with an unmanaged switch.