Redundantie in AV‑over‑IP: wat wél werkt, en wat je moet vermijden

Een recent praktijkvoorbeeld laat dat duidelijk zien: een reseller ging ervan uit dat hij een redundante AV‑netwerkarchitectuur had opgebouwd door op front‑of‑house één switch te plaatsen, op het podium een andere switch, en deze twee met twee glasvezellinks te verbinden.
De gedachte: “Dubbel verbonden = redundant.”

De realiteit: zo werkt redundantie in AV‑over‑IP niet.
Zeker niet bij realtime UDP‑ en RTP‑verkeer, waarin kloksignalen, audio‑ en videosignalen ononderbroken en zonder jitter moeten doorstromen.

Tijd om dat misverstand recht te zetten.

1. Het grootste misverstand: Vasthouden aan TCP‑denken

De meeste IT‑netwerken zijn ontworpen rondom TCP/IP, een protocol dat:

• retransmissions ondersteunt
• acknowledgements gebruikt
• flow & congestion control toepast
• pakketvolgorde kan herstellen

Daardoor kunnen TCP‑applicaties prima omgaan met korte onderbrekingen, route‑wijzigingen of linkfailover.

Maar AV‑over‑IP werkt niet op basis van TCP. AV‑verkeer bestaat uit:

• UDP‑stromen
• RTP‑audio‑ en videoframes
• PTP‑v2 clocking (IEEE 1588)

Deze protocollen:

• sturen nooit opnieuw
• hebben geen foutcorrectie
• tolereren bijna geen jitter
• kunnen geen reconvergentie opvangen
• vallen direct hoorbaar/zichtbaar uit bij micro‑interrupties

Waar TCP kan “wachten”, moet AV realtime door het netwerk stromen.

2. Waarom IT‑redundantietechnieken niet geschikt zijn voor AV

Veel engineers ontwerpen AV‑over‑IP netwerken alsof het IT‑netwerken zijn en gebruiken technieken zoals:

• stacking / virtual chassis
• LACP‑bundels
• RSTP / MSTP

Deze technieken zijn uitstekend voor TCP‑dataverkeer, maar veroorzaken problemen bij realtime AV‑payloads.

2.1 Opmerking over stacking

Stacking wordt vaak gezien als een vorm van redundantie, maar voor AV‑over‑IP is het onbruikbaar.

De belangrijkste redenen:

• Stacked members delen control‑plane functies, waardoor PTPv2‑clocking instabiel wordt en hierdoor niet naar behoren werkt.
• De control‑plane latencies in een stack zijn te groot voor tijdkritische AV‑stromen.
• Een stack functioneert als één enkel systeem, waardoor er meerdere single points of failure ontstaan.

Daarom wordt stacking in AV‑netwerken niet beschouwd als betrouwbare redundantie.

2.2 LACP in AV‑netwerken: wel bruikbaar, maar niet als redundantie‑mechanisme

LACP wordt binnen IT én AV veel gebruikt om bandbreedte te bundelen.
Op NETGEAR AV‑switches werkt LACP zeer stabiel en is het ideaal om uplinks te schalen of bottlenecks te voorkomen.

Maar voor AV‑over‑IP redundantie schiet het LACP protocol tekort.

Waarom?

• LACP balanceert per flow → AV‑streams zijn meestal single‑flow, dus ze belanden op één fysieke link.
• Bij linkfailover ontstaat een korte interruptie, omdat LACP de defecte link uit de bundel moet verwijderen.
  → Dit veroorzaakt het wegvallen van RTP‑clockinformatie én het wegvallen van AV‑streams.
• LACP levert dus wel schaalbare bandbreedte, maar geen realtime‑veilige redundantie.

Kortom:
Gebruik LACP voor throughput, niet voor failover.

2.3 RSTP en MSTP verstoren realtime traffic

• Convergentietijd is veel te traag voor AV‑workloads.
• Veranderingen in forwarding states veroorzaken packet loss.
• PTP‑domeinen raken instabiel bij elke STP‑wijziging.

RSTP/MSTP horen niet thuis in een AV‑core.

3. Redundantie begint niet bij dubbele switches — maar bij power

Veel AV‑problemen hebben niets met het netwerkdesign te maken, maar met stroomvoorziening.

3.1 Redundant voeden is stap één

• dual PSU’s
• gescheiden stroomgroepen/fases
• UPS waar nodig

Een redundante uplink redt een switch niet die simpelweg uitvalt.

3.2 Daarna volgt een AV‑specifiek netwerkdesign

• QoS correct toepassen
• voldoende bandbreedte reserveren
• solide IGMP‑architectuur
• robuust multicast‑fabric
• correct PTP‑domeinontwerp

3.3 En dan pas: nadenken over fysieke netwerk‑redundantie

Zoals:

• A/B‑netwerken
• gescheiden fysieke routes
• gespiegelde fabric
• dual‑NIC devices waar mogelijk

Redundantie is een architectuurprincipe, geen feature.

4. De harde realiteit: veel AV‑apparaten hebben maar één netwerkpoort

Veel AV‑apparaten beschikken helaas nog steeds over:

• één NIC
• geen Audio Redundancy Mode
• geen SMPTE ST 2022‑7 support

Dat betekent:
geen apparaat‑niveau redundantie → altijd aandachtspunt in je design.

5. Wat dan wél werkt? AV‑native redundantieprincipes

5.1 Geen single point of failure in de core

• gescheiden A‑ en B‑netwerken en/of MLAG
• volledig gescheiden power
• gescheiden fiber routes

5.2 Twee volledig onafhankelijke signal paths

Zoals in broadcast‑omgevingen:

• A = primair
• B = secundair
• Device kiest autonoom
• Failover is naadloos
• Ondersteund door Dante, AES67 + ST 2022‑7, SMPTE ST 2110

5.3 Redundantie testen zoals je audio test

• trek een kabel uit
• reboot een switch
• controleer PTP‑gedrag
• observeer IGMP‑stromen
• controleer jitter en latency

Pas als je dit live kunt doen zonder dropouts, is je netwerk écht redundant.

Conclusie

Echte redundantie in AV‑over‑IP vereist een heel andere aanpak dan in traditionele IT‑netwerken.

Waarom?

• AV‑workloads gebruiken UDP/RTP, niet TCP
• Realtime verkeer verdraagt géén micro‑interrupties
• Stacking, LACP en STP zijn geen geschikte failover‑mechanismen
• Redundantie begint bij power en design, niet bij uplinks
• Veel AV‑apparaten hebben slechts één netwerkpad
• De meest robuuste opzet blijft een A/B‑gescheiden netwerk en/of MLAG‑architectuur

De kern is helder:
Alleen wanneer je het gedrag van realtime AV‑protocollen begrijpt, kun je een netwerk ontwerpen dat écht redundant is.

Duizelt het je een beetje van alle jargon, heb heb ik deze blog voor je!