372
« 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í".
Zobrazit příspěvky
