Maak een einde aan de pixelvorming: handleiding voor het oplossen van multicast-problemen |

Is de townhall-bijeenkomst van uw CEO bevriezing? Worden uw digital signage-schermen willekeurig zwart?

Als je bedrijfsnetwerken beheert, ken je dat gevoel van paniek wel. Je controleert de linkbezetting en die staat op een prima 10%. Je pingt de bron en de latentie is <1 ms. Toch vertoont de video macroblokken (pixelvorming) of valt het geluid weg.

Ik heb het afgelopen decennium besteed aan het oplossen van problemen met multicast-video voor Fortune 500-bedrijven en stadions. Het probleem ligt zelden aan de bandbreedte, het is fysica en protocolgedrag.

Deze handleiding is precies de werkwijze die ik gebruik om MPEG-TS-streams in hoge resolutie te stabiliseren in complexe Layer 3-omgevingen. We gaan verder dan “de kabel controleren” en verdiepen ons in de onzichtbare boosdoeners die de videokwaliteit aantasten: Microbursts, PCR-jitter en IGMP-tekortkomingen.

Fase 1: Ken je vijand (het is niet altijd "lag")

Voordat je aan de configuratie van een router gaat sleutelen, moet je ophouden met het woord “lag” te gebruiken en onderscheid gaan maken tussen de twee soorten jitter die de verbinding verpesten IPTV.

1. Netwerkjitter (RTP-jitter)

Dit is wat de meeste netwerkingenieurs weten. Het is het verschil in vertraging tussen ontvangen pakketten (RFC 3550).

De Realiteit: Moderne settopboxen (STB’s) zijn voorzien van de-jitterbuffers (200 ms–500 ms). Ze kunnen een kleine hoeveelheid netwerkjitter aan.
De valstrik: Desktopspelers met een lage latentie hebben vaak zeer kleine buffers. Als je jitter plotseling piekt, laten ze pakketten onmiddellijk vallen.

2. Videojitter (PCR-jitter)

Dit is de stille moordenaar.

Wat is het? Jitter in de Programmaklokreferentie (PCR) ingebed in de MPEG-TS-payload zelf.
Het symptoom: Je netwerk toont nul druppels, maar de video vertoont groene blokken of de beeld- en geluidssynchronisatie klopt niet.
De oorzaak: Dit gebeurt meestal wanneer een transcoder of multiplexer defect raakt, of wanneer een router pakketten onjuist “herlabelt”. Als je last hebt van PCR-jitter, helpt geen enkele vorm van QoS om dit te verhelpen. Je moet de encoder repareren.

Fase 2: De "10 Gbps-leugen" en het microburst-probleem

Ik zie dit bij 90% in de netwerken die ik controleer. Je kijkt naar je grafiektools (SolarWinds, PRTG) en ziet een bezettingsgraad van 10%. Je gaat ervan uit dat de verbinding vrij is.

Je hebt het mis.

Standaard voert SNMP elke 5 minuten een poll uit. Video-encoders genereren echter verkeer in heftige pieken (I-frames zijn enorm groot; P/B-frames zijn heel klein). Als er precies op het moment dat een I-frame binnenkomt een databaseback-up binnenkomt op je switchpoort, raakt de uitvoerbuffer onmiddellijk vol.

Hoe je het kunt vangen

Dit zie je niet op het dashboard. Je hebt de CLI nodig. Zoek naar Productiedaling in de betreffende videowachtrij.

Cisco IOS: show policy-map interface (Zoek naar “drops” in de prioriteitswachtrij).
Juniper: show interfaces queue (Zoek naar “Tail-dropped packets”).

De oplossing: vergroot je buffers

Het vergroten van de bandbreedte lost microbursts niet op. Buffer diepte doet.

Pro-tip: Voor spraakwachtrijen is een lage latentie vereist (kleine buffers). Videowachtrijen moeten pieken aankunnen (middelgrote/grote buffers).

Configuratiestrategie voor Cisco: Als je druppels ziet, verhoog dan de wachtrijlimiet. De standaardinstelling (vaak 64 pakketten) is belabberd voor HD-video.

policy-map ENTERPRISE-WAN
 class VIDEO-STREAMING
  bandbreedte in procenten 30
  ! De toveropdracht: vergroot de hold-queue om I-frame-pieken op te vangen
  queue-limit 512 pakketten

Configuratiestrategie voor Juniper: Gebruik tijdbuffers om “tijd” op te slaan in plaats van bytes.

stel de schedulers voor de serviceklasse in: VIDEO-SCHEDULER buffer-size temporal 50k
! 50k microseconden = 50 ms buffer. Voldoende om een piek te doorstaan.

Fase 3: Forensische analyse met Wireshark

Stop met gissen. Om aan te tonen dat het netwerk onschuldig (of schuldig) is, moet je het verkeer bij de ontvanger vastleggen en de MPEG-TS laag.

De “gouden” filters voor videotechnici

Sla deze filters op. Ze filteren de ruis meteen weg.

Filter	Waarom je het nodig hebt	De “Uh-Oh”-indicator
`mp2t`	Bevestigt dat het verkeer daadwerkelijk MPEG-TS is.	Als dit veld leeg is, ontvang je geen multicast.
`mp2t.cc.fout`	Het doorslaggevende bewijs. Controleert de continuïteitstellers.	Elke waarde > 0 betekent dat je een pakketje bent kwijtgeraakt. Punt uit.
`rtp.p_type == 33`	Isoleert de standaard MPEG-TS-payload.	Gebruik dit om te controleren of je naar de juiste stream kijkt.

Geavanceerde techniek: de microburst visualiseren

Open Statistieken -> I/O-grafieken in Wireshark.
Cruciale stap: Stel het interval in op 1 ms.
Breng je UDP-verkeer in een grafiek weer.
Als je pieken ziet die je verbindingssnelheid gedurende periodes van 1-5 ms overschrijden, dan heb je microbursts vastgesteld. Laat deze grafiek aan je leidinggevende zien.

Fase 4: Waarom multicast niet goed werkt (tekortkomingen van IGMP)

90% van “intermitterende” storingen waarbij de stream 3 minuten werkt en daarna wegvalt, zijn te wijten aan IGMP Snooping tekortkomingen.

1. De afwijking bij de aanvrager

IGMP Snooping vereist een baas (de Querier). Dit zou je grote Core Switch moeten zijn.

De mislukking: Als een kleine toegangsschakelaar de verkiezing wint, kan hij de tracking-tabel niet aan. Als hij uitvalt, lopen de streams vast.
De oplossing: Stel je Core Switch vast als de Querier. Wijs hem het laagste IP-adres toe in de VLAN.

2. De valkuil van “snel verlof”

Het scenario: Een gebruiker schakelt over naar een ander kanaal.
Het risico: Als ip igmp snooping fast-leave is ingeschakeld op een uplink, gaat de schakelaar ervan uit dat iedereen is klaar met die stroom en sluit deze voor het hele gebouw af.
De regel: 'Snel verlof' inschakelen ALLEEN op aansluitpoorten (waar de tv wordt aangesloten). Nooit op hoofdkabels.