Er is een moment dat bijna iedereen in onze wereld kent.
De zaal is nog leeg. De repetitie loopt. De patchlijsten zijn gecontroleerd, de streams staan online, de meters bewegen zoals ze moeten. En dan zegt iemand — vaak met de beste bedoelingen:
“Geen zorgen, we hebben redundantie. Rood en blauw zitten allebei op de switch.”
Op papier klinkt dat veilig. In de praktijk is het vaak vooral geruststellende taal.
Want daar begint precies het probleem: in veel AV over IP‑omgevingen gebruiken we woorden uit de broadcastwereld, maar niet altijd met dezelfde betekenis. En zodra dat gebeurt, sluipt verwarring het ontwerp binnen. Op een rustige voorbereidingsdag valt dat misschien niet op. Maar op een showdag — tijdens een change‑over, een première of een live uitzending — wordt precies daar het verschil zichtbaar tussen iets dat redundant oogt en iets dat daadwerkelijk redundant ís.
De echte gedachte achter rood en blauw
In broadcast zijn rood en blauw nooit bedacht als kleurcodering. Het was ook nooit bedoeld als cosmetische netwerklogica, of als slimme manier om twee VLAN’s op één switch te tekenen.
Rood en blauw zijn in essentie een discipline.
De gedachte is simpel en genadeloos eerlijk: als één netwerkpad faalt, mag het andere daar geen last van hebben. Niet een beetje onafhankelijk. Niet logisch onafhankelijk. Echt onafhankelijk.
Dat betekent: gescheiden switches. Gescheiden paden. Gescheiden forwarding. Geen gedeelde hardware. Geen gedeelde single points of failure.
Dat is ook waarom red/blue in de broadcastwereld zo’n sterke gewoonte is geworden. Niet omdat broadcasters van kleurcodering houden, maar omdat live televisie geen tweede poging kent. Redundantie moest daar niet goed voelen, maar aantoonbaar werken.
En precies die denkwijze is vandaag relevanter dan ooit in theaters, evenementenlocaties en podiumtechniek.
Waarom dit in AV over IP zo vaak misgaat
Nu steeds meer omgevingen overstappen op AV over IP, gebeurt er iets interessants: technieken uit broadcast worden overgenomen, maar soms zonder de ontwerpfilosofie die erbij hoort.
Dan ontstaat er bijvoorbeeld een ontwerp waarin media, audio, video en timing logisch worden opgesplitst in “red” en “blue”, terwijl alles nog steeds door dezelfde fysieke switch loopt.
Dat ziet er netjes uit in een schema.
Het voelt professioneel.
Het klinkt alsof het volgens de standaard is.
Maar als beide “netwerken” door dezelfde switch fabric lopen, dezelfde ASIC gebruiken, dezelfde buffers delen en op dezelfde timestamping‑engine vertrouwen, dan zijn het in werkelijkheid geen twee onafhankelijke netwerken. Dan zijn het twee namen voor hetzelfde risico.
En dat is precies waarom red/blue clocking op één switch voor PTPv2 of SMPTE 2110/2059 geen echte meerwaarde heeft.
PTP is geen mediastroom
Dat onderscheid is cruciaal.
Bij media begrijpen we redundantie steeds beter. Met SMPTE 2022‑7 stuur je twee identieke mediastromen over twee onafhankelijke netwerken. De ontvanger vergelijkt die stromen en kiest naadloos de juiste packets. Dát is red/blue zoals bedoeld: parallel, fouttolerant en hitless.
Maar PTP werkt niet zo.
PTP is geen videostroom die je dubbel kunt uitsturen en later slim kunt samenvoegen. PTP is de gezamenlijke tijdreferentie van het systeem. Het is de klok waarop audio, video en timing zich uitlijnen. En die klok gedijt het best bij rust, consistentie en een helder timingpad.
Zodra je op één fysieke switch “rood” en “blauw” voor PTP gaat simuleren, voeg je geen echte redundantie toe. Je voegt vooral complexiteit toe aan iets dat juist eenvoudig en stabiel moet blijven.
Eén switch blijft één failure domain
Hier zit de technische kern.
Als rood en blauw voor PTP op dezelfde switch zitten, delen ze nog steeds dezelfde onderlaag. Dezelfde hardware. Dezelfde timestamping‑engine. Vaak dezelfde oscillator. Dezelfde interne queue‑structuren en forwardinglogica.
Dus wat gebeurt er als die switch crasht?
Dan vallen rood en blauw tegelijk weg.
Wat gebeurt er als de switch verkeerd timestamped?
Dan zijn beide “netwerken” tegelijk verkeerd.
En wat als er jitter, drift of een bug in de timestamping zit?
Dan worden rood en blauw samen geraakt.
Precies daarom is VLAN‑segmentatie hier geen echte isolatie. VLAN’s zijn uitstekend voor ordening, beheer, security en traffic separation. Maar ze maken van één stuk hardware geen twee onafhankelijke timingwerelden.
Dat onderscheid wordt in de praktijk vaak te snel over het hoofd gezien.
Voor clocking wil je duidelijkheid, geen slimme trucs
PTP stabiliseert het best wanneer het netwerk een duidelijke en voorspelbare timingstructuur heeft: één helder timingdomein, een consistente path delay en zo weinig mogelijk asymmetrie.
Zodra je kunstmatige red/blue‑constructies gaat maken op één switch, maak je het systeem niet robuuster maar minder transparant.
BMCA‑gedrag wordt lastiger te volgen. Troubleshooting wordt complexer. Het wordt moeilijker uit te leggen wat nu precies de actieve timingbron is, welk pad dominant is en waar afwijkingen vandaan komen.
En iedereen die ooit onder tijdsdruk een timingprobleem in een live‑omgeving heeft moeten analyseren, weet: onduidelijkheid is zelden je vriend.
Waarom dit juist in theaters en podiumtechniek belangrijk is
In theaters, podia en live‑omgevingen komen steeds meer werelden samen. Audio, video, licht, rigging, show control en IT raken met elkaar verweven. Dat is krachtig, maar vraagt ook om een gedeeld begrippenkader.
En daar zit voor mij misschien wel de belangrijkste reden om broadcaststandaarden serieus te nemen — óók buiten de klassieke broadcastomgeving.
Niet omdat elke theaterinstallatie ineens een televisiestudio moet worden.
Maar omdat goede standaarden taal geven aan goed ontwerp.
Als “red/blue” voor de één betekent “twee VLAN’s”, en voor de ander “twee fysiek gescheiden failure domains”, dan heb je vóór de eerste show al een communicatief probleem. Op papier lijkt iedereen het eens, terwijl ze in werkelijkheid iets anders bedoelen.
Dat leidt tot de vervelendste soort fouten: fouten die pas zichtbaar worden wanneer het systeem onder druk staat.
Een technicus ziet twee kleuren in het schema en denkt: veilig.
Een programmeur ziet twee subnets en denkt: redundant.
Een operator vertrouwt erop dat de fallback echt onafhankelijk is.
Maar in werkelijkheid hangt alles nog steeds aan dezelfde switch.
Dat is niet alleen een technisch risico.
Dat is ook een organisatorisch risico.
De les uit broadcast is groter dan techniek
Wat we uit broadcast moeten meenemen, is niet alleen de topologie, maar vooral de denkhouding.
Rood en blauw betekenen niet: “we hebben het dubbel benoemd.”
Rood en blauw betekenen: “we hebben het zo ontworpen dat één fout niet beide paden raakt.”
Dat principe is tijdloos.
Of je nu werkt met ST 2110, Dante, AES67, een hybride AV over IP‑omgeving of een toekomstige theaterinfrastructuur waarin alles over Ethernet loopt: echte redundantie begint bij echte scheiding.
Niet bij kleurcodes.
Niet bij marketingtaal.
Niet bij schijnveiligheid.
Maar bij onafhankelijke failure domains.
Dus wat is verstandig?
Respecteer de betekenis van de standaard, niet alleen de terminologie.
Gebruik red/blue alleen wanneer je ook werkelijk twee onafhankelijke fysieke netwerken hebt. Gebruik voor PTP één schoon en consistent timingpad, of bouw échte fysieke scheiding als je redundante clocking nodig hebt.
Maar noem twee VLAN’s op één switch geen red/blue‑timingarchitectuur — want dat is het niet.
En misschien nog belangrijker: leer teams om die taal op dezelfde manier te gebruiken. In theater en podiumtechniek winnen we enorm veel wanneer ontwerpers, operators, integrators en technici hetzelfde verstaan onder woorden als redundantie, primary path, backup path, clock domain en failover.
Dat voorkomt fouten.
Dat maakt systemen begrijpelijker.
Dat versnelt troubleshooting.
En dat maakt ontwerpen uiteindelijk betrouwbaarder.
Tot slot
De kracht van broadcast zit niet alleen in de techniek, maar in de helderheid van denken. In het weigeren van halve zekerheden. In het onderscheid tussen wat redundant lijkt en wat redundant is.
Daarom is de boodschap wat mij betreft eenvoudig:
Rood en blauw zijn pas rood en blauw als ze ook echt onafhankelijk van elkaar kunnen falen.
Of nog scherper:
Als het niet fysiek gescheiden is, is het geen echt red/blue‑netwerk — en dus ook geen echte clock‑redundantie.
Eric Lindeman, NETGEAR ProAV Staff Systems Engineer Benelux
Voor meer informatie over de NETGEAR AV Switching neem gerust contact op met:
Commercieel: Simon Bol email: simon.bol@netgear.com
Presales: Eric Lindeman email: elindeman@netgear.com
Op het NETGEAR Pro AV Design Team via email: ProAVdesign@netgear.com
of kijk op https://www.netgear.com/nl/business/av/
Een overzicht van onze klassikale AV trainingen in Zoetermeer kan je hier vinden: https://innovatie.netgear.nl/audio-video-over-ip-trainingen/
