Verarbeitung von Multicast-Traffic bei Layer-2-Switchen (ohne IGMPv3-Support)
Hallo, kennt sich jemand mit dem Thema "Multicast" aus?
Ich versuche gerade zu verstehen, warum es in Netzwerken,
wo die verwendeten Switche keine IGMPv3-Unterstützung haben,
zu überlasteten Verbindungen kommen kann.
Laut meinen Infos stellt ein Layer-2-Switch (der keinen IGMPv3-Support hat)
empfangene Multicast-Pakete in der Form zu, dass er diese einfach an alle Netzwerkports ausgibt.
Diese Form der Zustellung der Pakete nennt sich dann "Flooding".
Meine Frage dazu:
Aus welchem Grund macht ein Layer-2-Switch das einfach per "Flooding",
also dass der den Traffic dann einfach an allen Ports ausgibt?
Einfach, weil es in der Firmware des Switches so festgelegt ist
so wie er es bei Broadcasts (an die FF:FF:FF:FF:FF:FF) auch macht!?
Zum Thema "Multicast" habe ich folgenden Link gefunden und mir
diese Seite mal durchgelesen:
http://www.firewall.cx/networking-topics/general-networking/107-network ...
Nach dem Lesen dieser Seite ist bei mir auch die Frage aufgekommen,
an welcher Stelle Ziel-MAC-Adresse in die Multicast-IP-Pakete "geschrieben" wird.
Macht das der heimische Router, der die Multicast-IP-Pakete aus dem Internet empängt
und dann in das LAN weiterreicht!?
Freue mich auf Eure Rückmeldungen.
Datax
Ich versuche gerade zu verstehen, warum es in Netzwerken,
wo die verwendeten Switche keine IGMPv3-Unterstützung haben,
zu überlasteten Verbindungen kommen kann.
Laut meinen Infos stellt ein Layer-2-Switch (der keinen IGMPv3-Support hat)
empfangene Multicast-Pakete in der Form zu, dass er diese einfach an alle Netzwerkports ausgibt.
Diese Form der Zustellung der Pakete nennt sich dann "Flooding".
Meine Frage dazu:
Aus welchem Grund macht ein Layer-2-Switch das einfach per "Flooding",
also dass der den Traffic dann einfach an allen Ports ausgibt?
Einfach, weil es in der Firmware des Switches so festgelegt ist
so wie er es bei Broadcasts (an die FF:FF:FF:FF:FF:FF) auch macht!?
Zum Thema "Multicast" habe ich folgenden Link gefunden und mir
diese Seite mal durchgelesen:
http://www.firewall.cx/networking-topics/general-networking/107-network ...
Nach dem Lesen dieser Seite ist bei mir auch die Frage aufgekommen,
an welcher Stelle Ziel-MAC-Adresse in die Multicast-IP-Pakete "geschrieben" wird.
Macht das der heimische Router, der die Multicast-IP-Pakete aus dem Internet empängt
und dann in das LAN weiterreicht!?
Freue mich auf Eure Rückmeldungen.
Datax
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 562030
Url: https://administrator.de/contentid/562030
Ausgedruckt am: 24.11.2024 um 02:11 Uhr
5 Kommentare
Neuester Kommentar
Hallo, kennt sich jemand mit dem Thema "Multicast" aus?
Sollte eigentlich in einem Administrator Forum, oder ? Diese Form der Zustellung der Pakete nennt sich dann "Flooding".
Das hast du absolut richtig erkannt und dir auch richtig erklärt ! Er kann diese MC Pakete ja nicht zielgenau zustellen wenn er kein IGMP spricht und muss dann diese Pakete genau wie Broadcasts an allen seinen Ports fluten. Was soll er auch anderes machen wenn er nicht weiss wo die Multicast Empfänger sind...?!
Übrigens ist das nicht IGMPv3 abhängig sondern auch bei IGMPv2 was derzeit noch am weitesten verbreitet ist.
Aus welchem Grund macht ein Layer-2-Switch das einfach per "Flooding",
Er erkennt die Multicast Pakete an ihrer Mac Adress Struktur !! Layer 2 Switches kennen rein nur Mac Adressen und fällen eine Forwarding Entscheidung immer rein nur auf Mac Basis. Was anderes kennen sie ja nicht.Broadcasts erkennen sie an der "all FF" Struktur. Bei Multicast Pseudo Mac Adressen werden die unteren 23 Bit der IP-Adresse in die MAC-Adresse 01:00:5E:00:00:00 eingesetzt, was dann den Bereich 01:00:5E:00:00:00 bis 01:00:5E:7F:FF:FF ergibt. Siehe dazu auch hier:
https://de.wikipedia.org/wiki/Multicast#IP-Multicast
Erkennt der Switch diese Bit Struktur in der Destination Mac flutet bzw. kopiert er diese Pakete auf alle seine Ports. Höchst ineffizient und kostet extrem Performance auf der Switch CPU. Deshalb sind ungemanagte Switches mit schwachen SOC Chips oder solche ohne IGMP in MC Umgebungen meist ein NoGo.
Tipp:
Nimm dir einen Rechner mit Wireshark und VLC drauf und einen kleinen Raspberry Pi oder zweiten Rechner.
Dann machst du DAS_HIER und etwas Kino im heimischen Netz und siehst dir den Multicast Strom und besonders dessen Mac Adressen mal genau mit dem Wireshark an !
Das bestätigt dann das normierte Multicast Verhalten von oben !
Übrigens ganz besonders spannend wird Multicast im WLAN. Gute APs machen ein Rewriting und schreiben Multicast in Unicast Frames um. Guckst du hier:
https://www.heise.de/ct/ausgabe/2014-14-Probleme-bei-Multicast-im-W-LAN- ...
Wie man Multicast im Layer 3 Umfeld routet mit PIM Sparse und auch eine dynamische Distribution der dafür erforderlichen Rendezvous Point IP Adresse mit BSR (Bootstrap Router Protocoll) einrichtet erklärt dieser Thread:
UPNP mit Mikrotik Routerboard hEX PoE und D-Link DGS-1210-24 Switch
das niederwertigste Bit aus dem 1. Oktett der Ziel-MAC-Adresse anschaut:
Das ist richtig, denn das haben einzig und allein ja nur Multicast Frames ! Wäre ja auch doof, wenn der Switch diese Multicast-Pakete einfach verwerden würde, nur weil er nicht ermitteln kann, an welchem Port der Ziel-Teilnehmer angeschlossen ist.
Bahnhof, Ägypten ??Diesen kryptischen Satz verstehst vermutlich nur du selber ?! Oder was wolltest du uns damit sagen ??
Wie ist denn der Ablauf...
Wireshark ist hier, wie immer, dein bester Freund ! Nutze den, dann musst du nicht alles einzeln erfragen Ein Bild sagt mehr als 1000 Worte...
Der Client schickt ein IGMP Join Request an 224.0.0.2 (v2) bzw. bei v3 dann 224.0.0.22 und der Dienst startet dann mit der entsprechend customizten Multicast Adresse. (Hier 239.255.1.2, .150 ist ein Server der ein Video mit Ton ins Netz streamt per RTP)
Mit welchen Adressen kommuniziert wird zeigt dir ja der obige Trace. Zusätzlich siehst du dort auch die Mac Address Struktur wie oben beschrieben !
An welcher Stelle wird denn die Ziel-MAC-Adresse in ein Multicast-IP-Paket "geschrieben"?
Siehe Wireshark Screenshot oben !Macht das bereits der Server, der z.B. meinem Fernseher Audio-/Videodaten zusendet!?
Ja ! Das ist wie hier der Server mit der .150 !warum ein L2-Switch Multicast-Pakete einfach per "Flooding" an allen Ports ausgibt.
Tut er doch bei Broadcasts und unknown Unicasts auch und ist das gleiche Prinzip... dass Pakete mit unbekannten MAC-Adressen einfach verworfen
Das wäre ja ein völlig widersinniges und auch nicht Standard konformes Verhalten. Damit würde kein einziger Switch mehr sauber funktionieren. Das würde natürlich logischerweise kein einziger Hersteller auf der Welt machen !Dann würde mit L2-Switchen halt einfach kein IPTV per IP-Multicasting funktionieren
Nicht nur das !!Dann würde der gesamte Switch nicht mehr funktionieren. ARPs würden nicht durchkommen, Broadcasts würden nicht durchkommen, unknown Unicasts würden nicht durchkommen.
Gerade ARPs und unknown Unicast Flooding sind essentiell für eine Grundfunktion. Ohne solche grundlegenden Mechnismen wäre so eine Box ein dummer Ziegelstein ohne Funktion
und man müsste zwingend einen Switch mit IGMP-Unterstützung verwenden.
Nöö, das geht auch mit einem billigen, ungemanagten China Switch vom Blödmarkt Grabbeltisch.Woher weiß eigentlich ein Fernseher, welche Multicast-Gruppe er joinen muss?
Das ist dann in seiner Firmware kodiert. Hier kannst du mal die Multicast Gruppen der Telekom sehen über die sie IPTV ausstrahlt:https://iptv.blog/artikel/multicastadressliste/
Kannst du mit jedem stinknormalen VLC Client sehen...
Erfragt er vorher die verfügbaren Multicast-Gruppen bei einem Server des IPTV-Anbieters!?
Manche machen das so. Viele TVs oder Settop Boxen ziehen sich beim Einschalten vorher diese Liste per TFTP o.ä. vom Provider. Da hat aber jeder unterschiedliche Verfahren.Kannst du alles auch ohne Aufwand zuhause in deinem Heimnetz ganz einfach selber checken. Guckst du wie gesagt HIER.