Control Network vs Media Network Separation
By VJ Ries · Published 2026-07-12 · Updated 2026-08-01 · 10 min read
Control and media traffic should not share one flat network without a plan. Separate them one of two ways: physically separate networks, each with its own switches and cabling, or one converged managed fabric split by VLAN. Media (Dante audio, NDI and AV-over-IP video) is high-bandwidth and clock-sensitive, and it depends on multicast for discovery and clocking. Control is light but must never miss its window: commands to processors, touch panels, PTZ heads and management interfaces. Physical separation gives the smallest blast radius and the simplest failure domains; VLAN segmentation gives fewer switches and one cable plant to run. Choose physical for rented, multi-vendor or highest-stakes rigs; choose converged VLANs for controlled installs where one team owns the switches.
What is a control network versus a media network?
One dropped or delayed packet is an audible glitch or a frame tear. That is the stake on a media network. It carries the show itself: Dante or AES67 audio, NDI and other AV-over-IP video, the real-time streams the audience sees and hears. High-bandwidth. Sustained. Sensitive to latency and clock jitter. Discovery and clocking are always multicast (mDNS discovery, PTP clock), but whether the media flows themselves are multicast depends on the protocol: AES67 and SMPTE ST 2110 are multicast-native, while Dante and NDI carry media as unicast by default and only use multicast when you deliberately enable it.
Instructions about the show are what a control network carries: a controller taking a switcher cue, a touch panel driving a PTZ head, status polls, projector and PDU commands, the management interfaces of the gear itself. Packets are small and bursty. Bandwidth is almost never the problem. The requirement is different. The command that fires the next cue cannot be the one that gets starved.
| Trait | Media network | Control network |
|---|---|---|
| Typical traffic | Dante/AES67 audio, NDI/AV-over-IP video streams | Cue commands, status polls, small unicast messages |
| Bandwidth | High and sustained, video flows dominate | Low and bursty, rarely a bandwidth problem |
| Sensitivity | Latency and clock sensitive, jitter breaks sync | Timing-tolerant, but must not drop the command that fires a cue |
| Multicast | Discovery and clocking always; media itself depends on protocol (AES67/ST 2110 yes, Dante/NDI unicast by default) | Mostly unicast, with some discovery |
| Who lives here | Consoles, stage boxes, DSPs, encoders, decoders, media NICs | Show controllers, touch panels, PTZ control, projectors, PDUs, management ports |
Why separate control from media at all?
The goal is independent failure domains. When control and media share a broadcast domain, a single event can take out both at once. Usually it takes out control right when you need it to recover the media. Separation buys four specific protections:
- No contention. A saturated media link (a large multicast NDI flow, a device flooding the wire) cannot starve the control packet that fires the next cue. The two never compete for bandwidth.
- Contained blast radius. A broadcast storm, a cable loop, or a rogue DHCP server stays on its own network. Share the broadcast domain and one bad NIC can drop the console-to-stage link along with the video.
- Smaller attack surface. Control and management interfaces (a switcher web UI, a PDU, a processor admin page) have no business being reachable from a media device a vendor patched in, or from anything a guest can touch.
- A live recovery path. When media misbehaves, you want control still up to reset, repatch, or reboot the offending gear. Shared fate removes your recovery path at the moment you need it.
Physically separate networks or VLAN segmentation?
Two honest ways exist to separate control from media. Physically separate networks give each class its own switches and cabling with no shared path: two independent fabrics that cannot see each other because there is no wire to cross. Converged (VLAN-segmented) puts every class on one managed switch or stack, split into VLANs and trunked between switches. Both deliver logical separation. What differs is failure domain, cost and the skill needed to run them.
| Dimension | Physically separate networks | Converged (VLAN-segmented) |
|---|---|---|
| Separation mechanism | Different switches and cabling, no shared path | One managed fabric, split by 802.1Q VLAN |
| Blast radius | Smallest: a failure is trapped in one physical fabric | Bounded by VLAN and config, a switch or trunk fault can hit several classes |
| Hardware | More switches, more ports, more cases | Fewer switches, one stack to buy and rack |
| Cable plant | Parallel runs per network, heavier multicore | One trunk carries every class between switches |
| Config skill | Low: plug into the right switch, you are on the right network | Higher: VLANs, trunks, and IGMP snooping all correct or it fails silently |
| Flexibility | Rigid: a new class means a new network | Flexible: add a VLAN in software |
| Best when | Rented, touring, or multi-vendor, or you cannot trust the shared config | Controlled install, one team owns and documents the switches |
What does each topology actually look like?
Physically separate: a media switch (or fabric) carries only media; a control switch carries only control; no uplink runs between them. Recovery is simple. The two networks cannot affect each other by construction. The cost is real hardware. Two switches, two sets of runs, two things to rack and power.
Converged: one managed switch or stack carries a media VLAN and a control VLAN (and usually a management VLAN and a firewalled guest VLAN), with a single trunk carrying all of them between switches. Endpoints plug into access ports that put them on one VLAN without the device knowing VLANs exist. One fabric to buy, rack and cable. One config to get exactly right. The mechanics of that split (access versus trunk ports, IGMP snooping, numbering) are covered in the VLAN planning guide, where the model already gives control its own VLAN.
When is a physically separate network the right call?
Physical separation is the original segmentation, and it is still the smallest-blast-radius option because there is nothing to misconfigure between the two networks; reach for it when any of these hold:
- Gear is rented, touring, or crosses multiple vendors who each bring their own switches, and you cannot audit one shared config on show day.
- The stakes make a shared failure domain unacceptable, and buying extra switches is cheaper than the risk of one event taking both networks down.
- The media side is already a single dedicated system (a Dante rig that is only consoles, stage boxes, and amps). It is isolated as-is, and folding control onto it buys little.
- Nobody on site will reliably configure and test VLANs before doors, so a config-dependent separation is one you do not actually have.
A dedicated switch that carries one system and nothing else is isolated better than any VLAN can manage, because the isolation is physical rather than a setting someone has to keep correct.
When is VLAN segmentation the right call?
Converged VLANs win when one team owns the network and the class count makes parallel physical networks impractical. Reach for it when these hold:
- A permanent or semi-permanent install where one team owns the switches, documents them, and keeps the config under change control.
- You have several traffic classes to keep apart (audio, video, control, management, guest), and running a separate physical network per class is impractical to buy, rack, and cable.
- Cost, weight, and cable-plant simplicity matter: one trunk between switches instead of a parallel multicore per class.
- You want one documented fabric that survives crew turnover, rather than a pile of dedicated switches nobody has mapped.
Converged does not mean careless. Control still gets its own VLAN. Management gets its own. Guest stays firewalled from everything. The reference five-VLAN model is a good starting point, and the same drawing can carry the IP schedule for the addresses inside each subnet.
How do you document either choice so the crew can build it?
Both topologies fail the same way when undocumented: a device on the wrong network and no record of where it belonged. The crew needs to know which fabric or VLAN every device is on, and which switch port carries it. That is a switch-port map plus port-to-port documentation for every run, produced during the preproduction workflow, not reverse-engineered on site.
In WireFlow, network assignments live on the same drawing as the signal flow: each device carries its network or VLAN and IP; switch ports are documented port by port (see switch-port documentation); PoE loads sit alongside. One source of truth replaces a diagram, a spreadsheet and a wiki page drifting apart, and the rest of the AV networking guides build on the same map.
Frequently asked questions
- Can control and media safely share one switch?
- Yes, on a managed switch with control and media on separate VLANs; IGMP snooping and a querier on the media VLAN; a tested port map. That is the converged model. It is common in installs. The risk is not the sharing but config error and a shared failure domain, which is why touring and multi-vendor rigs often stay physically apart.
- Is a separate control network overkill for a small system?
- Often, yes. A small dedicated media rig (a Dante network that is only consoles, stage boxes and amps) is already isolated, and a few control devices can sometimes ride the same dedicated switch. The dividing line is sharing, not device count. Once the network is shared with house IT, guests or another trade, real separation earns its keep.
- Where do device management ports go, control or media?
- Management interfaces (switch admin, PDU web UIs, processor management NICs) usually belong with control or on a dedicated management network. Never on the media VLAN. That keeps the media network quiet and keeps admin surfaces away from gear a vendor or guest might touch.
- Does separating control from media reduce latency?
- Not directly. Separation mainly removes contention and jitter risk: control traffic cannot be starved by a media flood, and media clocks are not disturbed by control chatter. In practice the well-separated network is the more predictable one, which is what real-time AV actually needs. Separate cabling buys the same predictability with a smaller blast radius. That is why it stays common for rented, touring and highest-stakes work.
Document your AV network in WireFlow
VLANs, IPs, PoE, and switch ports live on the same diagram as your signal flow, one source of truth for the whole system.