Multicast-Protokoll und Switche

[Dieter Koch]

Ich mit netzwerktechnischem gefährlichem Halbwissen hab da mal ne Frage:
Die KNX IP-Router haben ja alle eine (identische) Multicastadresse.
Wenn ich nun einen neuen Switch kaufe, hat der dann die notwendigen Eigenschaften gleich mit drin, um diesen "Dienst" leisten zu können oder muss man explizit solch ein Gerät kaufen.
Gibt es für das Multicast-Protokoll eine in der Netzwerktechnik gängige Norm-Nummer o.ä.

Bitte um Eure qualifizierten Antworten/Anregungen

Gruß
Dieter

[MarkusS]

Auf der KNX-Seite reden wir von IP-Multicast. IP-Multicast spielt sich im OSI-Modell auf Schicht 3 (Network Layer) ab.

Ein Ethernet-Switch ist eine Multiport-Bridge die auf Schicht 2 des OSI-Modells arbeitet (Data Link Layer).

Somit hat das Eine mit dem Anderen auf den ersten Blick nichts zu tun, da sollte jeder Switch tun.

Einschlägig für IP Multicast sind die RFCs 3170 und 3171.

Wer sich nicht für Netzwerktechnik interessiert kann hier mit dem Lesen aufhören.

Bei genauerer Betrachtung gibt es aber schon einen Zusammenhang: Die IP-Pakete werden in Ethernet-Frames verpackt und die Ethernet-Frames wissen herzlich wenig von IP-Multicast.

Die Adressierung auf dem Ethernet läuft über die MAC-Adressen der Ethernet-Geräte (MAC-Adresse = 48 Bit). Die MAC-Adresse wird üblicherweise während der Herstellung eines Gerätes gesetzt. Die ersten 3 Byte der MAC-Adresse werden auch als Organisationally Unique Identifier (OUI) bezeichnet, umgangssprachlich auch als "Herstellerkennung" bekannt wobei das nicht genau zutrifft.

Der Switch führt intern eine Liste welche MAC-Adresse an welchem seiner Ports hängt. Der Switch liest den Header jedes Ethernet-Frames aus um den Adressaten (MAC) zu ermitteln und dann den Frame an den Switchport zuzustellen an dem die MAC-Adresse der Empfängers gelern wurde. Dabei gilt die Regel dass Frames mit unbekannten MAC-Adressen an alle Switch-Ports geschickt werden (mit Ausnahme des Ports durch den der Frame in den Switch reingekommen ist).

Nun haben wir aber bei Multicast naturgemäss das Problem dass es mehrere Empfänger geben kann. Die einfache Lösung wäre nun, für jeden Empfänger einen Frame mit seiner spezifischen Adressierung loszuschicken womit einerseits der Sinn und Zweck von Multicast im Eimer wäre und andererseits der Sender ziemlich schnell überfordert wäre - unbrauchbar.

Also hat man sich überlegt dass man Multicast über spezielle MAC-Adressen zustellen kann. Konkret verwendet man MAC-Adressen mit der (dafür reservierten) OUI 01:00:5e - wobei die 1 im ersten Byte besagt dass es sich eben um Multicast handelt. In die übrigen 3 Byte der MAC-Adresse wird ein Teil der IP-Multicast-Adresse abgebildet (was aber nicht eindeutig ist da es dabei eben Überschneidungen geben kann aber besser als nix).

IP-Multicast im Ethernet lässt sich also relativ einfach über die MAC-Adresse 01:00:5e:XX:YY:ZZ rausfinden wobei es sich dabei eben um eine "virtuelle" MAC-Adresse handelt die kein Ethernet-Gerät tatsächlich besitzt (i.S.v. herstellerseitig zugewiesen).

Dementsprechend kann der Switch diese MAC-Adresse nicht in seiner MAC:Port-Zuordnungstabelle haben und er wird die an diese Adresse gerichteten Frames über alle Ports rausschicken (ausser den Port durch den der Frame rein kam).

Es gibt allerdings "intelligente" Switches die diese Adressen auswerten können. Konkret können diese Switches den IGMP-Traffic mitlesen (IGMP ist das Protokoll über das Multicast-Gruppenmitgliedschaften geregelt werden) und entsprechend auch noch eine Tabelle führen wer welchen Multicast subscribed hat. Dieses Feature heisst IGMP Snooping, einschlägig dafür sind die RFCs 3376, 4541 und 4604.

[meudenbach]

Tolle Erklärung !!!

Pauschal kann man doch aber behaupten, dass Layer 2 Switches, also der übliche Standard Multicast grundsätzlich unterstützen ?!

Ich selbst bin da nämlich auch rein gefallen. Hatte erst kürzlich irre Probleme einen N146 in meinem Netz mit einem HS zu verheiraten... lange, lange gesucht bis ich gemerkt habe, dass in meinem Layer 3 Switch Multicast abgeschaltet war ...

LG

[MarkusS]

Pauschal kann man doch aber behaupten, dass Layer 2 Switches, also der übliche Standard Multicast grundsätzlich unterstützen ?!

Pauschal würde ich sagen: Ja. Worst Case schickt der Switch alle Multicast-Frames auf alle Ports, damit kann man i.d.R. problemlos leben. Eleganter ist es halt wenn der Switch da Eigenintelligenz besitzt aber in 99% der Netzwerke ist das ein kosmetisches Problem.

Ich selbst bin da nämlich auch rein gefallen. Hatte erst kürzlich irre Probleme einen N146 in meinem Netz mit einem HS zu verheiraten... lange, lange gesucht bis ich gemerkt habe, dass in meinem Layer 3 Switch Multicast abgeschaltet war ...

Routing ist ein ganz anderes Paar Schlappen. Routing passiert auf OSI Layer 3 - da wo auch der IP-Multicast wohnt. Normalerweise sollte jeder Router auch mit IP-Multicast umgehen können was im einfachsten Fall darauf hinausläuft dass der Router die Multicast-Pakete im Zweifelsfall auch auf alle Interfaces schickt (ausser auf das wo die Pakete reinkommen).

Die meisten der etwas besseren Router habe spezielle Mechanismen für Multicast, z.B. Juniper oder Cisco. Damit kann man den Multicast z.B. auf speziellen Interfaces / Routen blocken oder auf bestimmten Strecken auf Unicast umsetzen u.s.w. Spannend wird es dann wenn mit Sachen wie PIM (Protocol Independent Multicast) Multicast-Topologien aufbaut. So was geht weit über das IP-Gebastel in einem Heimnetz raus, das ist was für Männer

Wenn man an einen Router gerät der Multicast per Konfiguration blockt sieht man natürlich etwas schlecht aus.

Probleme gibt es auch immer wieder mit Firewalls wenn die Multicast-Quelle auf der bösen Seite ist.

[unique24]

Hallo,

heutztage werden "viele" Switch schon mit Routing Funktion ausgestattet ... nicht immer steht auch Layer-3 Switch dabei.

Deswegen kann man nicht mehr pauschal sagen, das Multicast und Broadcast über Switche ohne Probleme zu betreiben sind.
Wenns nicht geht, dann ist es in der Software des Switch deaktiviert.

Vermutlich 95% der Switche sind aber ohne Konfiguration nutzbar:-)

@Markus
Super erklart! Hab über die Zustellung von Multicast eigentlich noch nie nachgedacht. Dachte die werden generell wie Broadcasts bei den Switches behandelt.
"Greift" da dann aber auch das Spanning-Tree Protokol?? Ware ja fatal wenn nicht.
Bei meiner Cicso Ausbildung habe ich Multicast und dem Spanningtree nie in Zusammenhang gebracht !

[MarkusS]

heutztage werden "viele" Switch schon mit Routing Funktion ausgestattet ... nicht immer steht auch Layer-3 Switch dabei.

Deswegen kann man nicht mehr pauschal sagen, das Multicast und Broadcast über Switche ohne Probleme zu betreiben sind.
Wenns nicht geht, dann ist es in der Software des Switch deaktiviert.

Ein Switch ist ein Switch und hat einen sehr klar definierten Funktionsumfang. Nur weil vor ein paar Jahren jemand auf die Idee kam, an einen Switch eine Routerfunktionalität dranzubasteln ändert das nichts am Prinzip des Switches - wie ich oben schon schrieb: eine Multiport-Bridge. Dementsprechend ist auch die Bezeichnung des Layer 3-Switches ziemlich daneben, Ethernet wird nun mal auf Layer 2 geswitcht und IP wird auf Layer 3 geroutet.

Wenns bei so einem Combogerät mit dem Multicast klemmt ist i.d.R. nicht die Switchkomponente Schuld sondern der angeflanschte Router.

Hab über die Zustellung von Multicast eigentlich noch nie nachgedacht. Dachte die werden generell wie Broadcasts bei den Switches behandelt.
"Greift" da dann aber auch das Spanning-Tree Protokol?? Wäre ja fatal wenn nicht.

Spanning Tree hat mit Multicast wenig zu tun. Spanning Tree dient zur Vermeidung redundanter Pfade in einem Netzwerk:

I think that I shall never see
a graph more lovely than a tree.
A tree whose crucial property
is loop-free connectivity.
A tree that must be sure to span
so packet can reach every LAN.
First, the root must be selected.
By ID, it is elected.
Least-cost paths from root are traced.
In the tree, these paths are placed.
A mesh is made by folks like me,
then bridges find a spanning tree.

Nicht von mir sondern von Radia Perlman, die hat Spanning Tree erfunden.

Bei meiner Cicso Ausbildung habe ich Multicast und dem Spanningtree nie in Zusammenhang gebracht !

Jaja, die Cisco-Ausbildung. Ist schon ein paar Tage her dass ich meinen Cisco-Trainerschein gemacht habe.

Spanning Tree nutzt selbst Multicast zur Topologiefeststellung bzw. zur Spanning Tree-internen Kommunikation - allerdings ist Spanning Tree ein Protokoll auf OSI Layer 2 und nutzt als Multicast einen reinen Ethernet-Multicast auf OSI Layer 2 (Multicast-Adresse 01:80:C2:00:00:00) während es in der Eingangsfrage um einen IP-Multicast ging. Ein Ethernet-Multicast / Ethernet-Broadcast hat auf der anderen Seite vom Router eh nix verloren da ein Router per Definition eine Broadcastgrenze bildet da er nicht auf Data Link Layer-Ebene arbeitet.

Wer sich ernsthaft weiterbilden will kauft sich von Radia Perlman "Interconnections" (Ethernet-Bibel) und von Douglas Comer "Internetworking with TCP/IP Vol. 1"

[unique24]

Hallo Markus,

vielen Dank für deine Ausführungen.
Den Zusammenhang von Multicast auf Spanning Tree habe ich wegen deiner Aussage zusammengebracht:

Dabei gilt die Regel dass Frames mit unbekannten MAC-Adressen an alle Switch-Ports geschickt werden (mit Ausnahme des Ports durch den der Frame in den Switch reingekommen ist)

Das ist ja die "klassische" Broadcast Methode ... wenn ich nun einige Switche in Redundanz laufen hätte, muss das Spanning Tree die Multicast dementsprechend behandeln, sonst hätte man ja den "Broadcaststorm" Effekt.

Geht aber nun zu weit OT.

Schöne Grüße

[Dieter Koch]

Einschlägig für IP Multicast sind die RFCs 3170 und 3171.

Wer sich nicht für Netzwerktechnik interessiert kann hier mit dem Lesen aufhören.

Erstmal vielen DAnk für die Antworten.

Habe trotzdem weitergelesen. Wenn ich die Antworten so für mich auswerte, so lese ich daraus, daß ein Switch, an dem man nichts einstellen kann für Multidcast geeignet ist. Es gibt ja managebare (Intelligente) und nicht managebare (dumme) Switche.
Ich kaufe eben einen dummen.

Ist das so richtig??

Gruß
Dieter

[MarkusS]

Erstmal vielen DAnk für die Antworten.

Habe trotzdem weitergelesen. Wenn ich die Antworten so für mich auswerte, so lese ich daraus, daß ein Switch, an dem man nichts einstellen kann für Multidcast geeignet ist. Es gibt ja managebare (Intelligente) und nicht managebare (dumme) Switche.
Ich kaufe eben einen dummen.

Ist das so richtig??

Die intelligenten Switches haben auch ihre Daseinsberechtigung aber wenn einem ein "einfaches" Netz ohne z.B. Segmentierung (VLANs) ausreicht (was z.B. in einem EFH der Fall sein sollte) reicht auch ein einfacher Switch.

HP macht grundsolide Sachen zu sehr fairen Preisen, im kleinen Segment ist Linksys ganz gut aufgestellt. Ggf. auf PoE achten, sehr praktisch wenn man seine Telefone oder WLAN-APs vom Switch weg mit Strom versorgen kann.

[Gaston]

Tolle Erklärung !!!

Jo, da gibts nichts zu meckern. Perfekt!

Pauschal kann man doch aber behaupten, dass Layer 2 Switches, also der übliche Standard Multicast grundsätzlich unterstützen ?!

Jein! Ein Switch braucht multicasting nicht zu unterstützen, dementsprechend unterstützt jeder layer-2 switch multicasting

Wie Markus schon geschrieben hat funktioniert ein switch nach dem Prinzip dass er bei jedem eingehenden Paket die Zieladresse (MAC) des Pakets liest und in seiner forwarding Tabelle sucht. Wird ein Eintrag gefunden so wird das Paket nur an den entsprechenden Port weiter geleitet. Wird kein Eintrag gefunden wird das Paket an alle Ports gesendet (ausser dem Port an dem das Paket eingegangen ist).

Am Anfang (nach dem Start) ist die forwarding tabelle eines switches (i.d.R) leer. Bei jedem eingehenden Paket wird nun die Quellmacaddresse ausgelesen und in die forwarding Tabelle zu diesem Port eingetragen.

Geht also am router an Port 3 ein Paket von Quelle AA-AA-AA-AA-AA-AA ein mit Ziel BB-BB-BB-BB-BB-BB so wird AA-AA-AA-AA-AA-AA in die forwarding Tabelle eingetragen mit dem Port 3. Von nun an wird jedes Paket mit Ziel AA-AA-AA-AA-AA-AA nur an Port 3 geschickt.

Da eine Multicastadresse im Multicast Protokol nie als Quelladresse verwendet wird, trägt sie der Switch auch nie in die forwarding Tabelle. Somit ist Multicast transparent für den Switch.

Gruss,
Gaston

[JoeHorn]

Thema forwarding Tabelle:
Ich vertausche die Ports zweier PCs (ggf. auch im Betrieb).
Gibt es einen Mechanismus, der dafür sorgt, das der Switch seine forwarding Tabelle korrigiert (zumindest korrigieren könnte) oder muß ich die per Reset löschen?

[MarkusS]

Einen neuen Switch kaufen natürlich.

Der Switch merkt doch dass die MAC-Adresse die vorher auf 20 war plötzlich auf 21 ist - und das ziemlich genau in dem Moment wo das Gerat auf 21 aktiv wird. Abgesehen davon wirst Du es kaum schaffen dass Gerat so schnell umzustecken dass der Switch die Illusion kriegt dass das Gerat auf 20 noch da ist obwohl es schon auf 21 steckt. Noch bevor Du den Stecker ganz draussen hast geht beim Switch das Interface auf down und damit ist der Eintrag in der Forwarding Table weg. Und selbst wenn Du das schafftest - oder den Switch vergewaltigst indem Du ein Gerat mit identischer MAC-Adresse ins Spiel bringst: Spanning Tree nimmt sich des Problems an.

[JoeHorn]

Ach so, sobald der PC abgeschaltet wird, ist auch sein Eintrag weg. Ich hatte bisher angenommen, die Tabelle bleibt länger erhalten...
Kleiner Irrtum von mir...