Certainly I would rather Video/Audio/lighting/building infrastructure to exist on separate physical networks in most cases. Any yes with entertainment we would seldom get into layer 3, My thought were more to use Vlans in a festival situation, or a separate
VLAN on a theaters lighting
network so a tour can keep their floor package or video controls separate from the
house light rig.
For example,
VLAN 1- festival light rig controlled by
artnet
Vlan 2-Headliners MA NET, for their floor package, and
console/
tracking backup
console
Vlan 3 support TitanNet, for their floor package, and
console/
tracking backup
console
Unless the tour is
interfacing with
house fixtures, they will probably not want to touch the
house network if it can be avoided. In a roadhouse scenario, SM fiber, MM fiber, and
STP CAT6 connectivity between places is much more important than having a backbone
network. Festivals may be a little different where you have guest consoles on a shared
system but usually simplicity and
ease of troubleshooting trumps elegance of configuration.
VLAN's are great for very specific purposes, but only when supported by someone who knows exactly what they're doing. A lot of people look at a 52-port
network switch and assume that all ports are on the same
system. They don't know that some ports are reserved for trunks, others are access ports for various
VLAN's, some ports may be turned off, and that an occasional port may be setup for mirroring other ports for packet sniffer troubleshooting. They look at a
switch and assume they can
plug into any port on that
switch and it will work. In potentially uncontrolled environments, it's more reliable to have 2-3 switches and label each with their own purpose than to trust people will
jack into the correct ports on a large, single
switch with tiny numbering and a spaghetti of cables to sift through.
The other issue at
play is that it drives the cost of your switches up. If you keep one
protocol per
switch, you can optimize the QoS for that
protocol without losing your ability to trunk. This is something you can do on a lower cost L2 managed
switch by setting the global QoS parameters. If you dump 3
VLAN's with their own protocols onto the same
switch and each has their own requirements for QoS, they'll probably behave within that
switch but one
protocol will stomp on the other 2 when you
send packets across your trunk. Setting QoS per port or per
VLAN is usually an L3 feature and will put you into the thousands of dollars per
switch range. Else, you have to do 3 trunks, 1 per
VLAN.
There's something to be said too for keeping
network configurations simple. If you're on the
road and your
switch dies on a simple, non-converged
network, you can probably get away with whatever you can find in the local
venue's basement or at Best Buy. If you get crafty and custom and your
switch gets hit by lightning or drenched, it's much harder to source a $3500 replacement
switch out on the
road that seamlessly integrates into your multiple
VLAN's without sparking up unanticipated issues.
...also running several cat lines as a trunk for redundancy, seeing as there will probably be a bunch of crowd surfers
stomping all over them.
Yeah, don't put your
network lines there. Sudden drastic changes in the
network topology can have consequences and aggregated trunk lines aren't a good way to handle stray boot heels. If you can't reasonably secure your cables between locations, it's not worth putting thousands of dollars into switches because you have bigger problems. I haven't experimented with spanning tree and aggregated trunk lines specifically, but remember that the way spanning tree works to prevent
network loops is that when it detects a change in
topology, it shuts off data transmission on each port and pings them one at a time to see what changed. In a streaming lighting or audio application, plugging something in can cause noticeable blips across your
network. Cisco's Rapid Spanning Tree feature and other manufacturers' versions mitigate this, but under certain conditions can still cause issues.
A few years ago at Rock in Rio(the one in vegas) I heard many horror stories about the terrible lighting
network, I don't know what the major issues were, but apparently they were experiencing up to 5 seconds of
latency, and this is with time coded shows. So the fact that most manufactures just recommend that you use an unmanaged
switch,
plug every thing in and leave it alone, for sure has good reason.
I'd be interested to hear more about this if anyone knows anything. Horror stories are the best way to learn what not to do. I know a fellow whose coworker in a moment's inattention killed the entire
house network at a casino on the Vegas strip. The guy accidentally connected the Cobranet
network to the
house switches. Because they used L2 unmanaged switches for Cobranet, the multicast packets became broadcast and created a broadcast storm on the
house network, sending streaming audio traffic out to all of the ports on the casino's
network.
In one fell swoop they knocked out the point-of-sale, security, gaming, and hotel WiFi systems -- another reason why I tend to be a fan of keeping a set of switches for each
protocol at
play and avoid
VLAN's. You can still kill a segment of a
network or a single
protocol but with standalone, independent networks it's much hard to take down the primary, secondary redundant, and control networks all
in one fell swoop.