A VLAN with a Plan

Networks you may have known

In a theater production setup, it is quite possible that you have a need for more than one network. Here are a few things that theater makers have found a network need for in the recent past:

• Digital audio transport using Dante, AVB, Waves Soundgrid, etc.
• Digital video transport using NDI or SMPTE 2110.
• Lighting control using Art-Net or sACN (which QLab doesn’t produce, we know, we know…)
• Show control using OSC, VISCA, RTP-MIDI, etc.
• Keyboard video and mouse sharing (KVM) using a device like an AdderLink XDip.
• Digital intercom like Clear-Com HelixNet or Green-Go.
• Remote control of sound equipment like d&b amplifiers, Meyer Galileo GALAXY, and many kinds of mixing consoles.
• Remote control of video equipment such as BlackMagic Design VideoHubs and PTZOptics cameras.

Some of the devices in your system will only need access to one of these networks, while others will want access to two or more. Some of these networks will only reach some locations in your venue, others will want to be accessible at every speaker or microphone. It is complicated!

If you want your QLab Mac to be able to talk to all seven of the networks listed above, you’d need to add a bunch of USB network adapters, a shelf full of small network switches, and a bundle of network cables running every which way. It means a lot of long runs of delicate cable to tie up, a lot of labels, and frequently a lot of tangled mess.

A (hu)Man, a Plan, a VLAN

Fortunately, very smart IT folks have a great solution for this: virtual local area networks, or VLANs (usually pronounced “vee-lan” but “vlaan” is also accepted by the less self-serious.)

Simply put, VLANs are networks that behaves as though they’re physically separate from each other, when in fact they are using the same hardware. A very simple VLAN scenario might look like this:

In this drawing, two entirely separate networks share one set of physical infrastructure. The two network switches are managed switches which means you can configure them to behave in specific ways. Here, we’ve told them “use the six ports on the left for the audio VLAN, and the six ports on the right for the video VLAN.” Then, both VLANs are carried between the switches on a single cable connected to a tagged or trunk port, which is just a port on the switch which is set up to carry both VLANs. (Sometimes trunk ports are special in other ways, but not always and it’s not an important detail right now.)

Any device connected to the audio VLAN is totally unaware of the devices connected to the video VLAN, and vice versa.

This solves two problems of running multiple networks; it reduces the number of network switches we need to place in each location, and it reduces the number of long cables we need to drag all over our venue.

On the other hand, if we want to connect the QLab Mac to both networks, we still need two network cables and two ethernet ports. Some Macs have two ports built in, but others will need USB network adapters. If you only have two networks this isn’t so bad, but if you have four or six networks to connect to, it quickly becomes a real mess.

Fortunately, using some great tools in macOS and clever configuring of the switches, we can keep these several networks separate but use a single cable between the switch and the Mac, just like we did with the cable between the switches. This is the third advantage of using VLANs in the theater.

A caveat: this is complex stuff. We are going to scratch the surface and talk about a few tools you may use for this, but we’ll be working with professional IT equipment here. Your situation may change based on firmware updates, different approaches, or when a particular butterfly in Escanaba flaps her wings. So, be ready to do some research on how your particular network switch works!

How it works

First, let’s lay out our networks. Here is a setup taken from an actual show:

1. Dante Primary - A digital audio transport network with built-in redundancy. Devices on this network will self-assign IP addresses.
2. Dante Secondary - A digital audio transport network with built-in redundancy. Devices on this network will self-assign IP addresses.
3. Control Net - A closed network for team sound to send control data and files. This network will support macOS file sharing, QLab Collaboration, the sound console’s data port for a remote editor, a Raspberry Pi running Companion Pi, a WiFi access point for an iPad to use QLab Remote and DM Editor. Most devices on this network will use static IP addresses, but we might get rambunctious and run a DHCP server so we don’t have to set IP addresses for the designer’s laptop or the iPad.
4. Show Control - A data network shared with lighting and projections. They’re using an Ion and Isadora on this one, and the lighting folks want to be in charge of IPs on this network.
5. NDI Net - Our designer loves to score to recorded videos. So, she has a small NDI capture device that wants to get connected to the camera on the balcony rail. The signal for the camera already runs backstage, so the capture device will live there too.

I’ve got a few devices to connect together:

1. A QLab Mac - It has one network port and wants to connect to Dante Primary, Control Net, and Show Control Net. It is located at the front of house position (FOH).
2. A sound console - It has three network ports: Dante primary, Dante secondary, and control. Each network port only needs to connect to one network. It is also located at FOH.
3. A remote Dante I/O rack - It has two network ports, Dante primary and Dante secondary, each of which only needs to connect to one network. It is located backstage.
4. A speaker system processor - It has one port for control. It uses analogue connections for audio. How very 2009.
5. A connection to the Show Control Net - The lighting department will bring a network cable to us, and we need to get it plugged into our system such that the Macs on our network can communicate with their stuff. The connection will be at FOH for tech, and will move backstage for the show.
6. A Wifi access point - This just wants to get Control Net. It is located at FOH.
7. The sound designer’s Mac - It has one network port, and wants to connect to Dante Primary, Control Net, Show Control Net, and NDI Net.
8. The programmer’s Mac - There should be a connection available at FOH and also one backstage. Saves walking. It wants to connect to Dante Primary, Control Net, Show Control Net, and NDI Net.
9. An NDI capture device - This is backstage and only needs NDI.

We have two 10-port network switches for this show. The tenth port on each is an SFP port, which stands for Small Form-factor Pluggable. An SFP interface on networking hardware is a modular slot for a media-specific transceiver, such as for a fiber-optic cable or a copper cable. It can be nice to use fiber for long cable runs because it can carry a lot of data, it’s very lightweight, and it’s available in a ruggedized form for a reasonable price. On the other hand, it’s not always available and if you’re on tour and it breaks, you can’t just run to Office Depot and grab a temporary replacement. For this reason among others, the SFP port provides some flexibility which is nice to have.

Dante is best when it is as redundant as possible, so we don’t want to run both Dante Primary and Dante Secondary through the same network switch. If we did, it would mean a single switch failure would interrupt both Dante networks, which would eliminate the redundancy. Since we only have two devices which have Dante Secondary ports on the show, we don’t even need a switch. We’ll just connect them together. If we had a third device, we would add another network switch dedicated only to Dante Secondary.

So, given that, we can map out which devices will be connected to each port on each of our switches, and which VLANs those ports need to provide:

The “Link” ports connect the two switches to each other using a presumably very long cable. Alongside that very long cable, we’ll run another cable which directly connects the Dante Secondary port on the console to the Dante Secondary port on the remote I/O rack.

Configuring the switches

So let’s set this up! We’ll start with the FOH switch.

We’re using a Netgear MX4250 switch in this example, which supports all the protocols and techniques that we need in the theater and, as an added bonus, is quite friendly to program.

The first thing to do, no matter what, is do a full factory reset of the switch. We recommend this in order to be completely sure that there aren’t any settings hanging around that might conflict with our plans.

The switch has a number of pre-configured templates which we can use to program the switch very quickly. We’re going to start by setting up the profile for the Dante Primary VLAN using the Audio Dante profile template.

Because sound, and thus Dante, is the most important thing for this network, we want to make it easiest to access the Dante network. So, the first two ports on this switch (where we’re going to plug in QLab and the sound console) are set to receive the Dante Primary VLAN untagged. An untagged port (called an access port on Cisco switches) behaves like a regular port on a regular switch. When you plug a device into that port, the device “sees” the Dante network exactly as though it has been plugged into a “dumb” network that has no VLANs or configuration of any kind.

The designer and programmer ports, on the other hand, want easy access to the Control Net VLAN, but still need access to Dante Primary as well. So, we will assign their ports to have access to the Dante Primary VLAN, but tagged. Tagged, in this case, means that the port attaches a tag to all the network traffic passing through that port. If the device plugged into that port knows to look for the tag, it can sort the incoming traffic according to its tag. Cisco switches use the term trunk to refer to a port with tagged traffic on it. Later on, we’ll teach the Macs that are plugged into these ports how to handle tagged traffic.

The “tag” itself is the VLAN ID, which is set by you and needs to be unique for each VLAN in your system. In this example, the Dante Primary VLAN is set to ID 2.

Let’s repeat the setup process for the Show Control network, using Netgear’s Data profile template.

Ports 1, 7, 8, 9, and 10 receive Show Control Net, and only port 7 (the Lighting port) is untagged.

The Show Control Net VLAN is set to ID 3.

Now we repeat the setup process for the NDI network. There are a lot of profile templates that can work for this; we used the one called “Video”. The NDI VLAN is set to ID 4.

Finally, we’ll set the default VLAN of the switch to be our Control Net. This one will be a little different than the other two, because we are going to define an IP address with which to connect to the switch, and set up a DHCP server to give IP addresses to devices which don’t have static addresses set up. We’ll tell the switch to serve addresses starting at 50 so that we can manually assign addresses 2 through 49 to devices that we want to have a static address, like the QLab Mac and the console.

The default VLAN on the switch always uses ID 1.

That’s all the setup we need to do on this switch.

The backstage switch can be configured in much the same way, although as our charts above show us, different ports should have different VLANs.

Configuring the computers

Now that the switches are ready, we need to head over to macOS System Settings to set up some virtual interfaces.

In macOS terminology, a network interface is an actual physical component (or group of components) which can send and receive network traffic. All modern Macs have a built-in WiFi interface. The Mac Mini, Mac Studio, and Mac Pro have built-in ethernet interfaces. You can also add network interfaces to a Mac in the form of USB or Thunderbolt network adapters. If you have a Mac Pro, you can also add a network interface in the form of a PCIe card, which was once upon a time the only way to add network interfaces. That’s why you’ll often hear folks referring to a “network card” even when there’s no actual card involved.

A network service is the system-level software that connects macOS to the network interface.

A virtual interface is sort of a hybrid of the two. It’s the layer at which we are going to teach the Mac about VLANs.

On the Mac, in System Settings, we choose Network from the list on the left, and then scroll to the bottom of the window and click the •••⌄ button. From the button’s pop-up menu, we choose Manage Virtual Interfaces.

Create a new VLAN for the Dante Primary network.

Set the tag to match the ID of the VLAN in your switch configuration, and choose the (actual) interface that you’re using to connect the Mac to the switch.

Once you’ve done this, the virtual interface appears alongside your other network interfaces, and behaves just like any other network interface.

Repeat these steps for each VLAN that the Mac needs to communicate with. In this example, the regular “Belkin USB-C LAN” interface connects to the Control Net VLAN because it’s the default VLAN. On top of the Dante Primary virtual interface shown in the screen shots above, you would need to add another virtual interface for the Show Control Net.

Once that’s done, the physical interface will behave like it’s simultaneously three separate interfaces connected to three separate networks. The tag, or VLAN ID, on each virtual interface allows the Mac to see and separate out the tagged traffic.

A crucial piece of this puzzle, which you may have already guessed, is that piling two virtual interfaces on top of the physical one means you need to be sure the physical interface has enough bandwidth to carry the traffic of all three networks at the same time. In this example, the Belkin USB-C LAN adapter has 1 gigabit capacity. So, as long as the peak traffic of all three networks totals less than one gigabit per second, we’ll be fine. If it adds up to more than that, we’ll need to step up to a 2.5, 5, or 10 gigabit adapter.

In conclusion

VLANs, while somewhat complex and cumbersome to set up, can ultimately save time, space, and money without sacrificing the ability to compartmentalize network traffic according to the needs of your show. The ability of macOS (and, sure, Linux and Windows too) to communicate with tagged ports on a managed switch helps keep your racks tidy and your bits and bytes organized.