datax87
Goto Top

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

Content-Key: 562030

Url: https://administrator.de/contentid/562030

Printed on: April 26, 2024 at 09:04 o'clock

Member: aqui
Solution aqui Mar 31, 2020 updated at 16:57:23 (UTC)
Goto Top
Hallo, kennt sich jemand mit dem Thema "Multicast" aus?
Sollte eigentlich in einem Administrator Forum, oder ? face-wink
Diese Form der Zustellung der Pakete nennt sich dann "Flooding".
Das hast du absolut richtig erkannt und dir auch richtig erklärt ! face-wink
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 ! face-wink

Ü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
Member: Datax87
Datax87 Mar 31, 2020 at 18:04:13 (UTC)
Goto Top
Hi, danke für deine Rückmeldung.

Habe mir gerade erneut die Erläuterungen unter dem bereits geposteten Link durchgelesen:
http://www.firewall.cx/networking-topics/general-networking/107-network ...

Dort wird erklärt, dass sich ein Switch vor der Entscheidung wie er ein IP-Paket zustellen muss,
das niederwertigste Bit aus dem 1. Oktett der Ziel-MAC-Adresse anschaut:

"Ethernet uses the low-order bit of the high-order octet to distinguish conventional unicast addresses from multicast addresses. A unicast would have this bit set to ZERO (0), whereas a multicast would be set to ONE (1)"

Wenn dieses Bit eine "0" ist, dann ist es ein Unicast-Paket und wird entsprechend als Unicast-Paket zugestellt,
also nur an dem Port ausgegeben, wo der Ziel-Teilnehmer (PC, Notebook etc.) angeschlossen ist. Den betreffenden
Port, auf dem das Unicast-IP-Paket ausgegeben werden muss, kann der Switch ja dann in seiner MAC-Tabelle "nachschauen".

Ist dieses Bit auf "1" gesetzt, so wird es als Multicast-Paket behandelt und einfach auf allen Switch-Ports ausgegeben.
Das ist bei L2-Switches scheinbar in der Firmware so festgelegt worden. 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.

Weitere Fragen, die gerade noch aufgekommen sind:

Wie ist denn der Ablauf, wenn sich z.B. ein TV bei einer IPTV-Multicast-Übertragung die Audio-/Videodaten
von einem bestimmten Server holen möchte?

"Schreibt" er dann als Ziel-IP-Adresse ins IP-Paket einfach eine bestimmte Multicast-IP-Adresse oder mit welcher
IP-Adresse kommuniziert er dann?

An welcher Stelle wird denn die Ziel-MAC-Adresse in ein Multicast-IP-Paket "geschrieben"?
Macht das bereits der Server, der z.B. meinem Fernseher Audio-/Videodaten zusendet!?
Member: aqui
Solution aqui Apr 01, 2020 updated at 08:39:37 (UTC)
Goto Top
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 ! face-wink
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 face-wink
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)
mcjoin
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 !
Member: Datax87
Datax87 Apr 01, 2020 updated at 11:47:13 (UTC)
Goto Top
Zitat von @aqui:
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 ??

Mir war zu Anfang wie gesagt nicht klar, warum ein L2-Switch Multicast-Pakete einfach per "Flooding"
an allen Ports ausgibt. In der Firmware hätte man ja auch festlegen können, dass Pakete mit unbekannten MAC-Adressen einfach verworfen
werden. Dann würde mit L2-Switchen halt einfach kein IPTV per IP-Multicasting funktionieren und man müsste zwingend
einen Switch mit IGMP-Unterstützung verwenden.

Woher weiß eigentlich ein Fernseher, welche Multicast-Gruppe er joinen muss?
Erfragt er vorher die verfügbaren Multicast-Gruppen bei einem Server des IPTV-Anbieters!?
Member: aqui
Solution aqui Apr 01, 2020 updated at 12:20:41 (UTC)
Goto Top
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... face-wink
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 face-wink
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.