There is a moment almost everyone in our world recognizes.
The venue is still empty. The rehearsal is running. Patch lists have been checked, streams are online, meters are moving exactly as they should. And then someone says — usually with the best intentions:
“No worries, we’ve got redundancy. Red and blue are both on the switch.”
On paper, that sounds safe.
In practice, it’s often little more than reassuring language.
Because that is exactly where the problem begins: in many AV over IP environments, we borrow terminology from the broadcast world, but not always with the same meaning. And once that happens, confusion quietly creeps into the design. On a calm preparation day, you may not notice it. But on show day — during a changeover, a premiere, or a live broadcast — that’s when the difference becomes visible between something that looks redundant and something that truly is redundant.
The Real Idea Behind Red and Blue
In broadcast, red and blue were never intended as color coding. They were never meant as cosmetic network logic or a clever way to draw two VLANs on a single switch.
Red and blue are, at their core, a discipline.
The idea is simple and brutally honest: if one network path fails, the other must not be affected. Not mostly independent. Not logically independent. Truly independent.
That means separate switches. Separate paths. Separate forwarding. No shared hardware. No shared single points of failure.
That’s why red/blue became such a strong convention in broadcast. Not because broadcasters like using colors, but because live television does not get a second attempt. Redundancy there didn’t need to feel good — it needed to prove itself.
And that mindset is more relevant than ever today in theatres, live event venues, and stage technology.
Why This So Often Goes Wrong in AV over IP
As more environments move to AV over IP, something interesting happens: broadcast techniques are adopted, but not always the full design philosophy behind them.
That leads to designs where media, audio, video, and timing are logically split into “red” and “blue,” while everything still passes through the same physical switch.
It looks clean in a diagram.
It feels professional.
It sounds like it follows the standard.
But if both “networks” traverse the same switch fabric, use the same ASIC, share the same buffers, and rely on the same timestamping engine, then they are not two independent networks. They are two names for the same risk.
And that is exactly why red/blue clocking on a single switch for PTPv2 or SMPTE 2110/2059 adds no real value.
PTP Is Not a Media Stream
This distinction is crucial.
With media, we increasingly understand redundancy intuitively. SMPTE 2022‑7 sends two identical media streams over two independent networks. The receiver compares them and seamlessly selects the correct packets. That is red/blue used as intended: parallel, fault‑tolerant, and hitless.
But PTP does not work that way.
PTP is not a video stream you can simply duplicate and intelligently merge later. PTP is the shared time reference of the system. It is the clock that aligns audio, video, and timing. And that clock thrives on calmness, consistency, and a clearly defined timing path.
Once you start simulating red and blue for PTP on a single physical switch, you’re not adding real redundancy. You’re mainly adding complexity to something that should remain simple and stable.
One Switch Is Still One Failure Domain
This is the technical core of the issue.
If red and blue PTP paths run through the same switch, they still share the same foundation: the same hardware, the same timestamping engine, often the same oscillator, the same internal queue structures, and the same forwarding logic.
So what happens if that switch crashes?
Both red and blue disappear at the same time.
What if the hardware timestamps incorrectly?
Then both “networks” are wrong simultaneously.
What if there’s jitter, drift, or a bug in the timestamping logic?
Again, both red and blue are affected together.
That’s why VLAN segmentation is not real isolation in this context. VLANs are excellent for structure, management, security, and traffic separation. But they do not turn one piece of hardware into two independent timing worlds.
That distinction is too often overlooked in practice.
For Clocking, You Want Clarity — Not Clever Tricks
PTP performs best when the network has a clear and predictable timing structure: a single, well‑defined timing domain, consistent path delay, and as little asymmetry as possible.
When artificial red/blue constructs are created on a single switch, the system becomes less transparent rather than more resilient.
BMCA behavior becomes harder to reason about. Troubleshooting becomes more complex. It becomes harder to explain which timing source is active, which path is dominant, and where deviations originate.
Anyone who has ever had to diagnose a timing issue under time pressure in a live environment knows this: ambiguity is rarely your friend.
Why This Matters So Much in Theatres and Live Production
In theatres, stages, and live environments, multiple disciplines converge. Audio, video, lighting, rigging, show control, and IT are increasingly intertwined. That is powerful — but it requires a shared vocabulary.
And that may be the most important reason to take broadcast standards seriously, even outside classical broadcast environments.
Not because every theatre installation should suddenly become a TV studio.
But because good standards give language to good design.
If “red/blue” means “two VLANs” to one person, and “two physically separate failure domains” to another, then you already have a communication problem before the first show. On paper, everyone appears to agree — while in reality they are talking about entirely different things.
That leads to the most painful kind of errors: errors that only reveal themselves when the system is under pressure.
A technician sees two colors on the diagram and thinks: safe.
A programmer sees two subnets and thinks: redundant.
An operator assumes the fallback is fully independent.
But in reality, everything still depends on the same switch.
That is not only a technical risk.
It is also an organizational risk.
The Lesson from Broadcast Goes Beyond Technology
What we should take from broadcast is not just topology, but mindset.
Red and blue do not mean: “we named it twice.”
Red and blue mean: “we designed this so a single failure cannot affect both paths.”
That principle is timeless.
Whether you work with ST 2110, Dante, AES67, a hybrid AV over IP environment, or a future theatre infrastructure where everything runs over Ethernet: true redundancy starts with real separation.
Not with color codes.
Not with marketing terminology.
Not with the illusion of safety.
But with independent failure domains.
So What Is the Sensible Approach?
Respect the meaning of the standard, not just the terminology.
Use red/blue only when you actually have two independent physical networks. For PTP, use one clean and consistent timing path — or build real physical separation if redundant clocking is required.
But don’t call two VLANs on one switch a red/blue timing architecture, because it isn’t.
And perhaps even more important: teach teams to use the same language in the same way. In theatre and live production, we gain enormously when designers, operators, integrators, and technicians all mean the same thing when they say redundancy, primary path, backup path, clock domain, or failover.
That prevents errors.
That makes systems easier to understand.
That speeds up troubleshooting.
And it ultimately makes designs more reliable.
In Closing
The strength of broadcast lies not only in its technology, but in the clarity of its thinking. In refusing half‑measures. In clearly distinguishing between what appears redundant and what actually is redundant.
For me, the message is simple:
Red and blue are only red and blue if they can truly fail independently.
Or, more bluntly:
If it isn’t physically separated, it isn’t a real red/blue network — and therefore not real clock redundancy.
Eric Lindeman, NETGEAR ProAV Staff Systems Engineer Benelux
For more information about NETGEAR AV Switching, please contact the NETGEAR Pro AV Design Team via email: ProAVdesign@netgear.com
If you’d like to delve deeper into AV over IP switching, I invite you to check out our Online Academy via the link: https://academy.netgear.com/
On our training portal, you can find both AV and IT-related training courses. These courses are free to attend after registration, and at the end of each course, you can take an exam to earn a certificate.
