Zkušenost multicast (video) a levné switche

Zkušenost multicast (video) a levné switche
« kdy: 16. 12. 2021, 15:24:50 »
Ahoj,

chtěl bych se zeptat, jestli je zde někdo, kdo pracuje s video multicastem v nějakém větším rozsahu, ne jen v rámci systému případně v rámci LAN. Řešili jsme v práci v posledních letech s mcastem přenášeným přes internet hromadu problémů, kdy se ale většinou nakonec ukázalo, že za to může switch. Prostě se vždy hledalo všude možně po trase, sledovali se čítače na rozhraních a kvalita na konci. Většinou se třeba po nějaké době (nárazově) začal obraz mírně sypat, pomohl třeba restart posledního switche v serverovně. Nepoužíváme přihlašování do skupin (IGMP/MLD), pouze vlany obalující přenos kanálů.

Ale jelikož při podobných problémech zatím nakonec pomohla výměna switche za nějaký značkovější (vím že se měnilo z TP-LINK, možná ještě jedné značky), vyhodnotili jsme to interně tak, že prostě levnější switche střední třídy nejsou pro tento typ profi nasazení úplně vhodné. Nějak si matně pamatuji, že se tento problém snad i hodně řešil někde na ispforu, ale mohu se mýlit, nicméně to už bude určitě víc jak 10 let.

Proč mě to zajímá? Píšu diplomku o IPTV a tyto zkušenosti jsem tam zmínil. Nicméně jsou to jen subjektivní nepodložená tvrzení na základě zkušenosti, což se logicky moc nelíbí. Snažil jsem se dohledat nějaké relevantnější odborné zdroje, které by s touto tezí nějak pracovali, ale nic moc (ani ty neodborné). V podstatě mám stále na základě této poslední zkušenosti (cca rok zpět) zafixováno, že levný switch v nasazení 24/7/365 = dříve či později možný problém s multicastem, což se nám několikrát potvrdilo. Proto by mě zajímala jakákoli jiná zkušenost, která by mě třeba navedla na nějaký zdroj podobné zkušenosti/studie. Děkuji.
« Poslední změna: 16. 12. 2021, 15:33:02 od Petr Krčmář »


Okabe

Re:Zkušenost multicast (video) a levné switche
« Odpověď #1 kdy: 16. 12. 2021, 17:14:13 »
Co cekas? Ze si nekdo vzpomene, ze pred 10 lety resil multicast a vytahne stare logy a poznamky, ktere ti posle do diplomky? Pred deseti lety?? Nebo snad chces citovat archivni spekulace na ISP Forum? To je snad spatny vtip.

Tvuj vedouci ma pravdu. Nepodlozene tvrzeni bez dukazu nema v diplomce co delat. Proste tam tu "zkusenost" nedavej. Vyreseno.

Re:Zkušenost multicast (video) a levné switche
« Odpověď #2 kdy: 16. 12. 2021, 18:07:03 »
"Proto by mě zajímala jakákoli jiná zkušenost, která by mě třeba navedla na nějaký zdroj podobné zkušenosti/studie.".

Čekám, že tu třeba někdo kdo jede multicast masivně a podělí se o zkušenost třeba stylem "neměl jsem nikdy žádný problém" nebo něco jiného, případně ty zkušenosti rozvede třeba na konkrétní značky a výrobce, abych mohl pátrat po zdrojích. Neřeším co bylo před 10ti lety. Popsal jsem naše zkušenosti cca rok zpět, kdy prostá výměna nějakého vyššího modelu TP-LINK za EdgeCore pomohla. To že to prostě neuvedu je také možnost, ale proč napřed nezapátrat?
« Poslední změna: 16. 12. 2021, 18:12:55 od milancizek »

Re:Zkušenost multicast (video) a levné switche
« Odpověď #3 kdy: 16. 12. 2021, 22:06:03 »
Pro mě je levný switch třeba Cisco 2960 a tam, pokud si pamatuju, větší problémy s multicastem nebývaly.

Re:Zkušenost multicast (video) a levné switche
« Odpověď #4 kdy: 18. 12. 2021, 21:23:35 »
V sitarine jsou multicasty pro IPTV osina v zadku. Ano, maji sve vyhody, ale jakejkoliv problem v siti je hned (doslova) videt a zakaznici jsou nervozni.

konzumni trida switchu vubec nema sanci iptv v multicastu odbavit, proste jsou potreba slusny switche (hp, cisco a spol). To samy plati pro radia - cokoliv halfduplexniho, MIMO a spol nema sanci ten provoz odbavit - ono totiz zalezi i na poradi packetu a jakmile se prehazi, je to v haji.

priklad: kdyz chybuje trasa, treba 5 chyb za minutu, tak v klasickym pouziti to nikoho netrapi a prijde se na to vicemene nahodou (samozrejme dohledovej soft by to mel ohlasit). Pro iptv v multicastu uz to znamena smrt, potazmo rozpad obrazu do rubikovky.

Ve vysledku to je strasne jednoducha matematika - pokud chce clovek provozovat IPTV v multicastu, musi mit sit na 100% funkcni. Jinak z toho bude vzdycky rubikovka.



Re:Zkušenost multicast (video) a levné switche
« Odpověď #5 kdy: 19. 12. 2021, 07:49:46 »
Dělal jsem kolem 2005 několik instalací Genetec Omnicast s multicastem a je o přesně jak píšeš. Levné switche nepoužitelné, v podstatě jsme skončili jen u Cisco. A i tam to tehdy nebylo 100% bez problémů. Naštěstí to za nás řešili dodavatelé, ale pamatuju si, že v jednom obchodním centru (pár set kamer) se specialista z Alef0 dost natrápil, než si to nějak sedlo. Bohužel konkrétní fakta ti po takové době nedohledám a ani nevím, jestli by to mělo ještě dneska význam.

Jarda

Re:Zkušenost multicast (video) a levné switche
« Odpověď #6 kdy: 19. 12. 2021, 08:13:22 »
Za 15 let jsme vyzkoušeli cca 8-10 značek levných switchů. Některé vypadly v testovací fázi; cca 4 se dostaly až do produkce. Ve 3 případech jsme se napojili přímo na továrnu a radili jim, jak to mají implementovat. Nakonec jsme zakotvili u jedné značky, která jakžtakž funguje (člověk nesmí požadovat nějaké finesy). Provozujeme jich necelou tisícovku.

V našem případě u těch levných switchů nebyl problém s forwardováním multicastu, ale ve všech případech byl problém s implementací IGMP a vlastními registracemi. Často to bylo způsobeno omezením samotného čipsetu (podle vyjádření vedoucího vývoje). Ale já jsem ty čipsety nestudoval, takže to vyjádření beru s rezervou. Problém je, že když nám udělali bugfix, tak téměř  vždy rozbili něco jiného. Což je ostatně dost častá vlastnost i u jiných technologií, které jsme potřebovali v Asii opravit.

Jeden typický problém za všechny: Query dotaz switch přeposlal všem uživatelům, jeden uživatel odpověděl reportem, switch tuto odpověď přeposlal opět do všech portů, ten report zdetekovali uživatelé a v souladu s RFC už neodpověděli. Následně tyto porty switch deregistroval na základě timeoutu pro odpověď a přestal jim posílat provoz. Řešením byla pouze izolace portů uživatelů.

Několikrát se objevil problém s omezením mcast adres (nešlo např. použít 239.0.0.1 nebo 239.0.0.10). A to buď od začátku, nebo daná adresa přestala fungovat po čase. Vše okolo fungovalo. Nebo se třeba narazilo na problém firmwaru, kdy se musel nastavit filtr (defaultní akce byla „deny“) pro daný rozsah mcast IP address. Jenže když jsme IGMP zakázali, tak ten filtr stejně fungoval, ale opačně. U většího provozu nám u některých switchů IGMP po čase komplet vytuhlo atd.

Prostě klasická ukázka výsledku softwarového vývoje Asie.

Rozsypaný obraz si pamatuju jen v případě, kdy se aplikoval mcast storm control (unregistered flood provoz, deaktivované IGMP) nebo u kapacitního limitu portů (např. nefunkční fast-leave, který může způsobit i přetížení koncového zařízení)


Re:Zkušenost multicast (video) a levné switche
« Odpověď #7 kdy: 19. 12. 2021, 10:15:50 »
Děkuji tazateli i předřečníkům za výživné téma :-) Dost jsem se dozvěděl.

Multicast bez IGMP by se měl chovat jako broadcast. Nepochopím, jak tohle může fungovat chvíli a pak už ne :-) Ledaže switch tutéž adresu (multicast group) v určitých konfiguracích používá pro nějaké interní účely... Tupý multicast by proto měl fungovat skrz hloupé switche bez managementu - ovšem pokud potřebujete VLANy, tak samozřejmě smůla s hloupým switchem.
Ještě mě napadá - pokud by se multicast bez IGMP choval jako "nenaučený unicast", asi by se to dalo zabít odesláním paketu se zdrojovou příslušnou multicastovou L2 adresou ;-)

Věřím tomu, že implementace i pouhého IGMP je pro asijské levné značky oříšek. Jedná se v měřítkách masového trhu o okrajovou fičuru, takže odhadem nevěnují velkou pozornost testování.

Bylo tu zmíněno Cisco v roce 2005 - z té doby si pamatuji, že snad uměli PIM dense mode ale nepodporovali sparse mode, nebo tak nějak - ale je to už dávno a mimochodem v případě PIM se už bavíme o forwardování na třetí vrstvě (takové IGMP funguje v rámci L2 segmentu).

Měl jsem pocit, že to že pakety mohou dorazit "out of order", není v paketových sítích chyba ale vlastnost :-) Možná jsem příliš načichl liberalismem divokého internetu a vyšších vrstev. Poznámka "síť musí být 100% v pořádku, jinak multicast nefunguje" je každopádně hluboká a zásadní. A protože video se v internetu vyskytuje zcela běžně, soudím, že zde srovnáváme 1) ani ne tak s unicastovou adresací, jako spíš 2) s TCP vrstvou, která garantuje doručení při mírné ztrátě paketů a re-ordering při doručení s proházeným pořadím. A ano, TCP jede nad unicastem...
Předpokládám, že multicastovat video v mixu s normálním provozem má smysl jedině v kombinaci s priorizací videa - jinak se budou ztrácet pakety toho videa, s popsanými důsledky.

Popravdě si pamatuju kdysi dávno jednoho provozovatele... ehm... streamované videoslužby, který mi názorně předvedl, že i jeho TCP-based (HTTP-based) provozu vadí tu a tam ztracený paket. Nevypadalo to v těch streamech dobře. Fakt je, že to bylo dávno před YouTube a přehrávač zřejmě nebufferoval zdaleka tolik dopředu, jak je běžné dnes. Resp. ona ta služba byla navíc interaktivní, to video bylo live, takže nešlo "nasosat buffer dopředu".

Pokud správně chápu, doručovat živě streamovaných třeba 50 programů v IPTV skrz nějakou sdílenou masovou SoHo poslední míli (CaTV, GEPON) multicastem je beztak marné, protože v tom počtu se vždycky najde nějaký pošuk, který si zapne i tu poslední Klenot TV, takže na sdíleném downstreamu se beztak kapacita neušetří, takže to už se to může poslat broadcastem rovnou, což by zabralo hroznou šířku pásma... pročež jede televize dodnes vyhrazenými frekvenčními kanály (multiplexy) i v CaTV- je to tak? A "video on demand" z nějaké videotéky je jasně individuální = unicastová záležitost.
Jak je to vlastně na DSLku? Tam přece není v poslední míli sdílené pásmo? To je až "proti proudu od DSLAMu"? Pokud by se nad tímto provozoval multicasting, tak by ho nemusel řešit osobně DSLAM, ale až první IP hop = koncentrátor o kus dál (u ISP, který prodal službu koncovému zákazníkovi)...

Asijské levné managed/websmart switche zvládají bez problému zhruba statické VLANy a 802.1q a snad STP. Jakékoli chytristiky navíc jsou příjemný bonus, ale nelze a priori spoléhat na bezchybnost :-( V průmyslových switchích jsem potkal problémy v protokolech pro kruhovou redundanci - které jsou většinou proprietární a mělo by se jednat o "parádní číslo" těchto switchů. Inu vývoj embedded SW/FW a síťových protokolů v nevelké asijské firmě... Pravda je, že nalezené problémy byly promptně řešeny. Mimochodem právě ve všelijakých proprietárních vychytávkách z tohoto soudku se často používá multicasting "pro režijní účely".

Off topic: poslední dobou mám v popisu práce, trápit různé switche provozem PTP (IEEE1588) - a to je teprve smutné kino. Bez korekcí to funguje skrz staré / levné a nepříliš chytré switche, nebo s korekcemi skrz vybrané modely drahého nového hardwaru. Ale je tam docela velká šedá zóna mezi = switche, které PTP nominálně nepodporují, což dělají nikoli tím způsobem, že by PTP propustily spolehlivě nastojato, ale spíš tím způsobem, že mi PTP úplně filtrují, nebo třeba propustí většinu PTP provozu ale sem tam zahodí paket (přestože linka není vytížená) apod. Nebo taky switche, které "PTP jmenovitě podporují", ale reálně to funguje jenom v určité konkrétní konfiguraci, jednou ročně ve středu za úplňku. Nebo si pamatuju na jednu rodinu switchů, které původně měly PTP podporovat (dle "upcoming" datasheetu), ale postupně zmínky o PTP mizely z datasheetů a návodů, až byly vygumovány úplně.
I jsem k tomu slyšel zákulisní drb, že se takový křemík skutečně vyskytuje (čipsety eth switchů) kde se výrobce pokusil o implementaci PTP, ale nasekal tam takové bugy, že to reálně nefunguje, takže to člověk v konfiguračním rozhraní nenajde, ale nějaká troska už v tom hardwaru je, na PTP provoz reálně nějak reaguje a "omylem škodí".
« Poslední změna: 19. 12. 2021, 10:21:31 od František Ryšánek »

Re:Zkušenost multicast (video) a levné switche
« Odpověď #8 kdy: 20. 12. 2021, 20:54:58 »
vemu to pokud mozno zkratka:

Citace
Multicast bez IGMP by se měl chovat jako broadcast. Nepochopím, jak tohle může fungovat chvíli a pak už ne :-)
Switch proste neustoji tu zatez broadcastu a zacne kravnout. U nizsich switchu naprosto bezna vec

Citace
Ještě mě napadá - pokud by se multicast bez IGMP choval jako "nenaučený unicast", asi by se to dalo zabít odesláním paketu se zdrojovou příslušnou multicastovou L2 adresou ;-)
Prekvapko: mac adres odpovidajicich IP adresam multicastu neni nejak extra moc, stava se, ze vice multicastu ma stejnou macovku. Krabice si to pak musi prekousat na vyssich vrstvach.

Citace
Měl jsem pocit, že to že pakety mohou dorazit "out of order", není v paketových sítích chyba ale vlastnost :-)
Ten counter v hlavicce multicastu ma 4 bity. Takze 16 packetu v rade a pak jede od nuly. Nic moc rezerva.

Citace
...soudím, že zde srovnáváme 1) ani ne tak s unicastovou adresací, jako spíš 2) s TCP vrstvou, která garantuje doručení při mírné ztrátě paketů a re-ordering při doručení s proházeným pořadím.
vsechny videosluzby jedou nad TCP, mam dojem ze vyjimkou je google ktery snad ma nasazen protokol quic nebo jak tomu hybridu rikaji, nejak vic jsem se tomu nevenoval. Vsichni resi bufferovani v radu minimalne desitek vterin, aby dokazali zakaznikum dopravit videoobsah i na nekvalitnich linkach. Z principu UDP nema vetsi bufferovani u multicastu zadny smysl - co nedorazilo ve spravnou chvili to uz nedorazi.

Citace
Předpokládám, že multicastovat video v mixu s normálním provozem má smysl jedině v kombinaci s priorizací videa - jinak se budou ztrácet pakety toho videa, s popsanými důsledky.
jakakoliv prioritizace je jenom berlicka, jedine overene reseni je dostatecna kapacita linek. To uz dneska neni takovy problem, 10Gb lasery stoji par korun. A na vsech switchich (pokud zrovna na nich zrovna neni PIM) musi byt zapnuty igmp snooping, jinak napriklad zakaznikovi v panelaku dorazi do boxu vsechny mulsticasty prihlasene na dane lokalite -> to box vazne neukousa.


Citace
Asijské levné managed/websmart switche zvládají bez problému zhruba statické VLANy a 802.1q a snad STP. Jakékoli chytristiky navíc jsou příjemný bonus, ale nelze a priori spoléhat na bezchybnost :-(
Bez urazky, testy switchu stredni tridy asijskych vyrobcu nedopadly pri vetsim zatizeni multicasty zrovna na jednicku. Proste jakmile je tech multicastu vic, maji s nimi problem. Vic jsme se tim nezabyvali a nasadili overene reseni.

Osobni nazor, o kterem zde ale nechci diskutovat: v uvahu pro nas pripadaji Cisco / HP switche. Cisco bohuzel hraje hru s licencemi na vyssi funkce, HP je na druhou stranu za polovicni cenu a taky dostatecne funkcni.



Re:Zkušenost multicast (video) a levné switche
« Odpověď #9 kdy: 20. 12. 2021, 23:13:42 »
@Hobbit díky za poučený komentář :-)

vemu to pokud mozno zkratka:

Citace
Multicast bez IGMP by se měl chovat jako broadcast. Nepochopím, jak tohle může fungovat chvíli a pak už ne :-)
Switch proste neustoji tu zatez broadcastu a zacne kravnout. U nizsich switchu naprosto bezna vec
Rozuměl bych, že vést seznamy živých IGMP příjemců v L2 síti může být dost zátěž na management CPU. Čím větší L2 segment, tím hůř.

Ale vrtá mi hlavou, jestli switch nějak vytěžuje i forwarding multicastového payloadu. Uvítám případně odkazy na další čtení ohledně architektury switchových čipsetů :-) Co je to přesně ten crossbar/matrix? To přece nemůže fungovat doopravdy "každej s každým" (neblokující full mesh) = je to třeba velmi rychlá sběrnice do nějaké paměti, ze které se paket ve fázi "forward" vytáhne a jednotlivé egressové porty si "dekódují" cílové adresy, které je zajímají? RAM buffery pro "store and forward" jsou sdílené, nebo nějak nadrobené per port?

Na Vašem empirickém poznatku samozřejmě tyhle ohavné interní detaily nic nemění.

Citace
Citace
Ještě mě napadá - pokud by se multicast bez IGMP choval jako "nenaučený unicast", asi by se to dalo zabít odesláním paketu se zdrojovou příslušnou multicastovou L2 adresou ;-)
Prekvapko: mac adres odpovidajicich IP adresam multicastu neni nejak extra moc, stava se, ze vice multicastu ma stejnou macovku. Krabice si to pak musi prekousat na vyssich vrstvach.
No já jsem se bavil spíš o zdrojových L2 adresách. Při odeslání paketu na multicast destination může být source adresa unicastová. Celá ta moje poznámka byl spíš vtípek, že by multicast destination šel protáhnout opravdu hloupým switchem i jako nenaučený unicast destination, což by ale fungovalo jenom do chvíle, než někdo použije dotyčnou multicastovou adresu jako zdrojovou. Je to fakt jenom blbej vtip, protože jak sám píšete dál, pro seriózní použití je praktickou nutností IGMP snooping.

Citace
Citace
Měl jsem pocit, že to že pakety mohou dorazit "out of order", není v paketových sítích chyba ale vlastnost :-)
Ten counter v hlavicce multicastu ma 4 bity. Takze 16 packetu v rade a pak jede od nuly. Nic moc rezerva.
Heh netušil jsem že je tam aspoň 4bit counter...

Citace
Z principu UDP nema vetsi bufferovani u multicastu zadny smysl - co nedorazilo ve spravnou chvili to uz nedorazi.
Taktak. Ono by nemělo smysl ani u unicastového provozu baleného do UDP.

Citace
Citace
Předpokládám, že multicastovat video v mixu s normálním provozem má smysl jedině v kombinaci s priorizací videa - jinak se budou ztrácet pakety toho videa, s popsanými důsledky.
jakakoliv prioritizace je jenom berlicka, jedine overene reseni je dostatecna kapacita linek.
:-D ano! nejnamáhavější na konfiguraci shapingu je vždycky vysvětlit "vlastníkovi řešení", že jakýkoli shaping/priorizace je nakonec na pikaču resp. že primární problém s přetíženým úzkým hrdlem ve finále neřeší. Případné výjimky spíš potvrzují pravidlo.

Citace
To uz dneska neni takovy problem, 10Gb lasery stoji par korun. A na vsech switchich (pokud zrovna na nich zrovna neni PIM) musi byt zapnuty igmp snooping, jinak napriklad zakaznikovi v panelaku dorazi do boxu vsechny mulsticasty prihlasene na dane lokalite -> to box vazne neukousa.
PIM je v control plane pro třetí vrstvu, IGMP pro druhou vrstvu. Ale se zbytkem ze srdce souhlasím :-)


Re:Zkušenost multicast (video) a levné switche
« Odpověď #10 kdy: 21. 12. 2021, 07:29:17 »
Ale vrtá mi hlavou, jestli switch nějak vytěžuje i forwarding multicastového payloadu. Uvítám případně odkazy na další čtení ohledně architektury switchových čipsetů :-)

Tady někdo tvrdí, že v levných switchích se multicast (a broadcast, a nenaučený unicast) děje s účastí CPU. Hledejte nadpis "replication engine".

Re:Zkušenost multicast (video) a levné switche
« Odpověď #11 kdy: 21. 12. 2021, 08:59:22 »
Ale vrtá mi hlavou, jestli switch nějak vytěžuje i forwarding multicastového payloadu. Uvítám případně odkazy na další čtení ohledně architektury switchových čipsetů :-)

Tady někdo tvrdí, že v levných switchích se multicast (a broadcast, a nenaučený unicast) děje s účastí CPU. Hledejte nadpis "replication engine".

Ono to dává smysl, "levné" switche jsou levné proto, že jsou na něčem osekané. Multicast není typický use-case, tak na něj nemají připravený hardware a řeší se až v CPU.

Re:Zkušenost multicast (video) a levné switche
« Odpověď #12 kdy: 21. 12. 2021, 10:55:04 »
Například switch HPE OfficeConnect 1920S 48G 4SFP PPoE+ mrší provoz multicastu neuvěřitelným způsobem. Pokud přes něj jde jen jednomu odběrateli, tak to funguje. Při přihlášení druhého odběratele první po chvíli upadne. Při vhodném restartu zdrojů a odběratelů lze docílit stavu, kdy to funguje, ale jen do okamžiku než se něco restartne. A to se jedná o switch, který o sobě v dokumentaci výslovně tvrdí, že multicast umí.

Re:Zkušenost multicast (video) a levné switche
« Odpověď #13 kdy: 21. 12. 2021, 19:22:08 »
1920 jsou soho switche s jakymsi managementem. Ve starsi verzi multicast snesly docela slusne, ty novejsi (jsou asi 3 roky na trhu, +-) jsou jeste orezanejsi a multicast jim ocividne nesvedci.

Chce to alespon rady 5120/5130, pak to dela co ma a na siti o nich proste nevite.