Multicast soorten

[Veance]

In de datalinklaag, sublaag LLC, worden unicast multicast of broadcast frames verstuurd.
-Unicast om data te versturen tussen 2 users zeg maar.
-Broadcast om via BPDU frames aan kennismakking te doen in het subnet( alleen subnet omwille van laag 2 tussen onderdelen van een switch?)
- multicast dient om frames te versturen naar een specifieke groep (niet alle) users binnen 1 subnet.

Maar blijkbaar bestaat er ook zoiets als IP multicast.

Wat is het verschil tussen IP multicast en multicast frames? Want zoals ik het nu zie heeft dit niets(?) met elkaar te maken en zit dit op verschillende OSIlagen en protocols. IGMP is laag 3?

Wat is dan een voorbeeld van multicast op laag 2?

[ Voor 5% gewijzigd door Veance op 22-02-2023 12:55 ]

[skoolhaas]

Lees je eens in over PIM en IGMP. Dan kom je al een heel eind.

[Ben(V)]

IP multicast bestaat niet.
Een broadcast is zoals het woord al zegt iets dat je het hele subnet opstuurt zonder adres.
Ip is per definitie geadresseerd (via het IP-adres) en dus nooit een broadcast.

Igmp is een eigen protocol en zit tussen laag 2 en laag 3 in.

Broadcast is naar iedereen op het subnet
Unicast is naar een ontvanger op het subnet
Multicast is naar meerdere ontvangers op het subnet

Om Unicast en Multicast e ontvangen moet de ontvanger zich abonneren op de stream

[deHakkelaar]

Niemand?
Het meeste pijn doet nog dat subnet wordt verward met broadcast domain ... meerdere keren.
Of dat met broadcast/multicast geen IP wordt geadresseerd.
Of abonneren om een broadcast unicast te kunnen ontvangen.

[ Voor 3% gewijzigd door deHakkelaar op 27-02-2023 21:05 ]

[jadjong]

Multicast gedraagt zich in zeker zin als broadcast, iets wat op switchpoort 1 binnen komt gaat naar alle andere switchpoorten. Ongeacht het subnet van de zender en ontvanger. De enige manier om broadcast/multicast simpel te reduceren is door ze te scheiden met vlan of fysiek.
Multicast scheiden met vlan kan effectief zijn als je ontvangers allemaal interesse hebben in die ene stream, maar als er vier streams zijn zal je vier vlans moeten maken. Willen de ontvangers soms wisselen van stream 1 naar 4 dan wordt het helemaal ingewikkeld en zal je ook de vlan toewijzing van de switchpoort moeten wijzigen of je steekt fysiek de stekker in een andere poort. Niet heel erg handig in dagelijks gebruik.
Om dat op te lossen kan je een iets intelligentere switch plaatsen die IGMP snapt. De switch blokkeert dan uitgaande multicast op elke poort totdat de desbetreffende ontvanger op die poort roept 'doe mij die maar'. Vanaf dat moment heb je een dynamische toezijzing van switchpoorten in combinatie met multicast gebouwd. Dit is echter wel beperkt tot het vlan en mogelijk bijbehorende subnet. Hoewel mulitcast op zich layer3 is ben je hierin beperkt tot het layer2 domein, multicast blijft dus hangen op L2 switch niveau.
Wil je van het ene vlan met subnet naar het andere multicasten dan kan je nog intelligentere apparatuur plaatsen die multicast L3 routing doet. Multicasters vinden elkaar dan op basis van het unicast ip (192.x) en zullen vervolgens de router vragen om het multicast ip (224.x) van de ene naar de andere te routen. Dit kan met een router die multicast ondersteund, dit kan soms ook met een switch die voor unicast L2 is (en dus al het verkeer tussen de vlan/subnets via de router stuurt) maar voor mulitcast een uitzondering maakt en dit intern route. Stel dat je 500mbit/s video van het ene vlan naar het andere vlan wilt sturen dan kan dit binnen de switch direct van poort 4 naar 28, zonder eerste langs de externe router te gaan.
Dus multicast beweegt zich n de basis op layer2, totdat men truckjes is gaan bedenken om bijkomende problemen op te lossen en het layer3 compatible heeft gemaakt.

[mash_man02]

Meestal wordt er geen specifieke inrichting gedaan voor multicast op L2 standaard gedraagd zich dat exact het zelfde als een broadcast.

Daar zit echter een probleem in voor de manier waarop switches werken. Switches leren mac adressen en multicast frames hebben een multicast destination adres wat nooit geleerd wordt op een specifieke poort. En voor bepaalde clients die weinig resources hebben en al helemaal niet op sloten met ongericht verkeer zitten te wachten.

Voor switches betekend dat deze frames door de CPU van een switch gerepliceerd moeten worden naar alle porten die lid zijn van het betreffende broadcast domein / vlan. Stel je dan maar eens een flow van 15kpps voor die op 20 poorten gezet moet worden. Dat is zwaar voor een switch omdat de forwarding hardware daar niets mee kan.

Daarvoor heeft Cisco initieel CGMP bedacht wat later vervangen is door het gestandariseerde IGMP.

Met IGMP kunnen clients aangeven wat ze willen gaan ontvangen qua mulitcasting en een switch "snooped" mee om te zien wat een client wil. Op het moment dat een switch dat ziet wordt de gewenste multicatst flow in een hardware entry gezet naar de poort.

Dan weet de switch hardware (asic) dus als er een frame voor die groep voorbij komt dat deze alleen geforward hoeft te worden naar deze poort en kan dat zonder verdere tussenkomst van de cpu afhandelen.

Met het hulpmiddel IGMP-snooping kan een switch in staat gesteld worden wirespeed multicast forwarding te doen.

Dit kan oop op L3 maar is wat zeldzamer, op internet wordt dit niet ondersteund. BInnen grote organsiaties soms wel. Dan krijg je ook te maken met PIM , protocol indempendent multicasting. Een protocol wat fundamenteel een forwarding tree bouwt op basis van unicast routing protocollen waarbij je ook nog voor disctribtie modellen sparse of dense en soms een combinate kunt gebruiken.

Hierbij is dense het model waarin we aannemen dat iedreen wilt ontvangen en we de tree afbouwen naarmate we leren dat dat niet helemaal het geval is en sparse mode precies andersom werkt.

Sparse klint daarmee anntrekkelijker maar is wezelijk complexer doordat we de multicast behoefte ergens moeten gaan verzamelen om te zien hoe de flow het beste van de source naar de destination kunnen krijgen. Dat doen we met een randevous point die dan weer dynamisch gekozen kan worden uit een aantal candidaten die verschillende multicast groepen kunnen vertegenwoordigen middels een RP bootstrap protocol.

Een mooi voorbleed van multicast over L2 zijn veel protocollen in netwerk land zoals vrrp, hsrp, ospf en dergelijke. Meer praktisch is dat bijvoorbeeld mdns. Deze protocollen zijn echter zo licht dat daar geen igmp voor toegepast wordt en ze feitelijk geforward worden door de cpu's van swiches.

Wil je zelf eens experimenteren met multicasting dan zkan ik VLC media player aanbevelen, deze speler kan ook video naar multicast zetten met IGMP.

[Veance]

Prachtig, bedankt iedereen voor de info. Ik zal het nog allemaal nog een paar keer opnieuw moeten lezen en opzoekingen doen voor ik alles begrijp.

Dus jullie bedoelen dat een voorbeeld van multicast gewoon videostreaming is? Ik dacht dat (video)streaming en gaming UDP was en net zoals TCP op laag 4 voorkwam?

[ Voor 32% gewijzigd door Veance op 24-02-2023 15:40 ]

[Veance]

deHakkelaar schreef op vrijdag 24 februari 2023 @ 05:30:
Niemand?
Het meeste pijn doet nog dat subnet wordt verward met broadcast domain ... meerdere keren.
Of dat met broadcast/multicast geen IP wordt geadresseerd.
Of abonneren om een broadcast te kunnen ontvangen.

op Broadcast hoef je toch niet te abonneren dacht ik, dat krijgt 'iedere deelnemer' van een netwerk.
En dus een broadcast doamin zou dan het volledige netwerk van een switch zijn?

[mash_man02]

Alle applicatieve toepassingen doorlopen het gehele osi model tot laag 7 wat presentatie is, daar is geen onderscheid tussen UDP en TCP. Ook UDP kent net zoals tcp poorten en daarmee unieke sockets.

UDP is een sneller protocol omdat het geen states en ook geen controle heeft. Dat heeft voordelen, met name als je het over real time toepassingen zoals gaming, video streaming hebt.

Als daar iets fout gaat en er pakketjes verloren gaan heeft het geen zin om deze data met error correctie te gaan corrigeren. Stel je maar voor hoe een voip gesprek klinkt als je de missende data uit de vorige 5 seconden opeens ergens anders gaat tussenvoegen.

[Veance]

Ondertussen vond ik nog volgende terug :

https://networktechstudy....t-multicast-igmp-snooping

[deHakkelaar]

Veance schreef op vrijdag 24 februari 2023 @ 15:45:
[...]
op Broadcast hoef je toch niet te abonneren dacht ik, dat krijgt 'iedere deelnemer' van een netwerk.
En dus een broadcast doamin zou dan het volledige netwerk van een switch zijn?

Sorry, ik bedoelde abonneren voor unicast ipv broadcast aansluitend op de reactie voor de mijne.
Gecorrigeerd en bedankt!

EDIT:

Veance schreef op vrijdag 24 februari 2023 @ 15:45:
En dus een broadcast doamin domain zou dan het volledige netwerk van een switch zijn?

Juist.
Als niet opgedeeld in vlan's.

[ Voor 25% gewijzigd door deHakkelaar op 27-02-2023 21:06 ]

[dion_b]

Veance schreef op vrijdag 24 februari 2023 @ 15:33:
Prachtig, bedankt iedereen voor de info. Ik zal het nog allemaal nog een paar keer opnieuw moeten lezen en opzoekingen doen voor ik alles begrijp.

Dus jullie bedoelen dat een voorbeeld van multicast gewoon videostreaming is? Ik dacht dat (video)streaming en gaming UDP was en net zoals TCP op laag 4 voorkwam?

Pas op met generalisaties. In leerboeken staat vaak dat streaming en gaming altijd UDP is, maar genoeg voorbeelden van beide die alsnog TCP gebruiken om al dan niet moverende redenen, of een mix van de twee.

Maar lees je eigen vraag eens: je hebt het over layer 4 protocollen. Wat zeggen die over hoe het verkeer op layers 2 en 3 vervoerd wordt? Niets.

Draai het om: stel je hebt multicast streaming op layer 2/3. Welk layer 4 protocl dacht jij dan dat erover zou lopen als het geen UDP of TCP zou zijn

Je kunt UDP streaming dus prima combineren met unicast of met multicast, afhankelijk van toepassing en implementatie.

[Veance]

weer een puzzelstukje bij. Bedankt hoor !