Ich möchte mich mehr mit Multicast befassen und schreibe daher diese Beiträge, im ersten Teil geht es hauptsächlich um Multicast im Layer 2 bzw. innerhalb eines Segments an einem Router.
Im Gegensatz zu Unicast, Nachrichten an einzlne Empfänger, und Broadcast, Nachrichten an Alle, ist Multicast dafür da Nachrichten an eine Gruppe von Empfängern zu senden.
Um diese Funktion darstellen zu können gibt es eigene IP und MAC Adressen für Multicast:
Bei IPv4 liegen die Multicast IPs im Bereich der alten Class D (als es noch kein CIDR gab und wir noch von Klassen gesprochen haben). Das heißt sie sind im Bereich 224.0.0.0 bis 239.255.255.255. Innerhalb dieses Bereich gibt es allerdings viele Reservierte Adressen, diese sind hier nachzulesen: https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml
Zu den IPv4 Adressen gibt es korrespondierent MAC Adressen, diese haben einen festdefinierten Aufbau. Alle Multicast MAC Adressen beginnen mit 01:00:5E: um danach mit den letzten 23Bit der IP Adresse die MAC Adresse zu vervollständigen. Das heißt, die Multicast IP Adresse 225.19.18.23 ergibt die MAC Adresse 01:00:5E:13:12:17. Dies führt allerdings dazu, dass viele IP Adressen die gleiche MAC Adresse ergeben. Um bei dem Beispiel zu bleiben, die IP 235.147.18.23 ergibt ebenfalls die MAC 01:00:5E:13:12:17. Um genau zu sein, können 32 IP Adressen die gleiche MAC Adresse ergeben. Ist das nun ein Problem?
Die IETF geht davon aus, dass es innerhalb einer Organisation selten zu diesem Problem kommt, da nicht sonderlich viele Multicast Applikationen eingesetzt werden. Und selbst wenn es dazu kommt, sollten sie höheren OSI Schichten sich darum kümmern. Also z.B. nutzt Applikation 1 völlig andere Datenformate als Applikation 2. Oder die Applikationen nutzen eine Authentifizierung. Dadurch funktionieren beide Applikationen, aber die Teilnehmer an je einer Multicast Gruppe haben den zusätzlichen Aufwand die unnützen Daten zu verwerfen. Es kann allerdings vorkommen, dass es zu Problemen kommt. Ein Beispiel sind Multicast Streams von TV Sendern. Wenn die MAC Adresse von zwei Sendern identisch ist, kommen beide Streams am Empfänger an und dieser kann sie nicht mehr unterscheiden. Da beide Streams ohne Authentifizierung die, mehr oder weniger, gleichen Daten liefern. Es könnte auch dazu führen, dass ein etwaig implementiertes Ratelimiting/Shaping greift und den Empfang komplett verhindert, da die Datenrate doppelt so hoch ist wie sie dürfte.
Wie umgeht man das Problem? Zum einen Tritt dieses Problem nur innerhalb eines Segments auf, also hinter dem gleichen Router. Solange die Empfänger der beiden Multicast Streams hinter verschiedenen Routern sind, tritt es gar nicht auf. MAC Adressen sind nur innerhalb eines LANs/VLANs wichtig, alles darüber hinaus arbeitet auf Schicht 3 und mit IP Adressen. Aber um dem Problem aus dem Weg zu gehen, und mehr Kontrolle in die eigene Multicast Umgebung zu bringen, ist es Ratsam einen Bereich für Multicast Adressen fest zu legen, z.B. dürfen im Unternehmen nur die Multicast IPs 239.0.0.0 bis 239.127.255.255 genutzt werden. Somit gibt es nur eindeutige MAC Adressen. Wie viele Multicast Applikationen können nun genutzt werden? 23 Bit entspricht 8’388’480 Adressen.
Für IPv6 gibt es ebenfalls festgelegte IP Bereiche, Multicast IPv6 Adressen sind sogar sehr leicht zu erkennen, denn sie beginnen immer mit FF (8Bit). Danach folgen 4 Bit die Flags darstellen. Ob eine Multicast IP Well-Known oder Transient ist, ob der RP in der Adresse mit angegeben wurde und ob die Multicast IP auf einer Unicast IP basiert. Und weitere 4 Bit für den Scope der Adresse (also den Gültigkeitsbereich). Somit bleiben 112 Bit für die eigentliche Multicast IPv6 Adresse.
Der Scope einer IPv6 Multicast Adresse gibt an in welchem Bereich diese Adresse Gültigkeit besitzt. Dazu gehören z.B. FF01:: „Local-Node Scope“, FF02:: „Link-Local Scope“ und auch FF05:: „Site-Local Scope“.
Eine Liste der reservierten IPv6 Multicast Adressen inkl. des jeweiligen Scopes findet sich hier: https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml
IPv6 Multicast Adressen werden ebenfalls auf MAC Adressen gemappt, allerdings anders als es bei IPv4 der Fall ist. Es werden die letzten 32 Bit der IPv6 Multicast Adresse genutzt, zum Beispiel bei der Adresse FF02::18:37B2:CA5D folgendes: „37B2:CA5D“. Um die vollen 48Bit der MAC Adresse zu erreichen, werden davor 16 Bit mit 0x3333 aufgefüllt. Somit ergibt sich die IPv6 Multicast MAC Adresse: 33:33:37:B2:CA:5D
IGMP & MLD
Das Internet Group Management Protocol (IGMP) und Multicast Listener Discovery (MLD) sind die gemeinsame Sprache für Multicast Teilnehmer innerhalb eines Subnets. IGMP für IPv4 und MLD für IPv6.
Die beiden Protokolle sind dafür da, um Empfängern eine Möglichkeit zu geben einem Multicast Stream beizutreten (Report) oder ihn zu verlassen (Leave). Zudem geben sie Routern die Möglichkeit zu prüfen (Query) ob es noch Teilnehmer für einen Stream innerhalb eines Segments gibt. Falls darauf nicht geantwortet wird, beendet der Router die weitergabe des Streams in dieses Segment.
IGMP gibt es mittlerweile in 3 Versionen, v1, v2 und v3. Ich beschreibe IGMPv2 um dann die Unterschiede zu v1 und v3 aufzuzeigen. MLD funktioniert im Grunde identisch, daher werde ich darauf nur kurz weiter eingehen.
IGMPv2 Hosts haben folgende Möglichkeiten sich mitzuteilen: Membership Report Messages, IGMPv1 Membership Report Messages und Leave Group Messages.
Membership Report Messages sind dazu da einer Multicast Gruppe (Stream) beizutreten und einem Router, nach einem Query dessen, mitzuteilen dass man an einer Gruppe teilnimmt. Diese Teilnahme-Mitteilung wird übrigens pro Segment immer nur einmal zum Router gesendet, selbst wenn viele Teilnehmer teilnehmen. Dieser Report wird an die Group-IP gesendet und wird somit von allen Teilnehmern empfangen, sobald sie diesen empfangen, senden sie selbst keinen Report (Suppression). Das spart Bandbreite und CPU.
Die Leave Group Message ist dazu da um einen Stream zu verlassen, also die Multicast Gruppe nicht mehr zu empfangen. Hierzu wird vom Empfänger die Leave Group Message an die Adresse 224.0.0.2 (All Routers) gesendet, also nicht an die Multicast Gruppe, wie bei den Reports. Dadurch weiß der Router dass ein Teilnehmer den Stream nicht mehr empfangen möchte, erzeugt ein Query um zu erfragen ob es weitere Teilnehmer für den Stream innerhalb dieses Segments gibt und wartet auf Antwort. Wenn ja, wird der Stream weiterhin gesendet, wenn nicht, wird die Weiterleitung beendet.
Was hilft das nun dem Teilnehmer der den Stream beendet hat? Zum einen, hört der Teilnehmer nicht mehr auf die Multicast MAC Adresse des Streams und verwirft die Pakete. Zum anderen gibt es IGMP Snooping auf Switchen, das bedeutet, dass Switche die IGMP Nachrichten ebenfalls auswerten und ihr Forwarding entsprechend anpassen. Wenn ein Switch einen Leave Group Message liest wird das Forwarding zu diesem Port eingestellt und der Host erhält den Stream nicht mehr. Genauso wenn ein Switch einen Report erhält, damit Joined ein Teilnehmer einen Stream und der Switch beginnt die MAC Adresse der Gruppe an den Teilnehmer weiterzuleiten.
Router können ebenfalls IGMP Messages versenden, wie oben schon beschrieben gibt es Querys. Hierbei gibt es aber zwei Unterscheidungen. Es gibt das „General Query“ und das „Group-Specific Query“.
Das General Query wird, standardmäßig, alle 60s an alle Segemente versendet um festzustellen ob noch Gruppen-Teilnehmer da sind. Falls nicht wird die Weiterleitung von Streams in dieses Segement gestoppt. Das General Query wird an die Multicast IP 224.0.0.1 (All Systems on this Subnet) gesendet.
Das Group-Specific Query wird an die Multicast-Gruppen IP gesendet und enthält ebenfalls die Gruppen-IP. Um zu verhindern dass ein Group-Specifiy Query verloren geht oder korrupt übertragen würde, werden zwei im Abstand von 1s gesendet. Damit werden Teilnehmer dieser Gruppe aufgefordet einen Report zu senden um die Teilnahme an der Gruppe zu bestätigen.
Wenn ein Router das erste Mal auf einem Subnetz aktiv wird, nimmt er an dass er der Multicast Querier ist. Also der Router verantwortlich für die Weiterleitung von Multicast Streams. Wenn aber mehrere Router auf einem Subnetz vorhanden sind, darf nur einer von ihnen die Streams weiterleiten. Auch hierbei werden die Queries der Router genutzt.
Sobald ein Router aktiv wird, sendet er ein General Query. Das ist dafür um schnell zu erfahren welche Multicast Gruppen aktiv sind um alarmiert andere Multicast Router die ebenfalls in diesem Subnetz aktiv sind. Was passiert nun wenn zwei, oder mehr, Router aktiv sind? Es darf nur einer die Multicast Streams weiterleiten und der aktive Querier sein. Die Regel hierbei ist einfach, der Router mit der niegrigeren IP Adresse ist der Querier. Die anderen Router werden zu „Non-Querieren“. Der Non-Querier mit der nächsten niedrigsten IP hört auf die Queries des Queriers und übernimmt die Querier Rolle falls dieser Ausfällt. Timer für diese Vorgänge sind alle 60s ein Query, nach 120s keinerlei Queries übernimmt der nächste Router.
Unterschiede zu IGMPv1:
IGMPv1 hat keine Leave Group Message – das heißt, es vergeht mehr Zeit bis ein Stream beendet wird, da die Teilnehmer die Gruppe nicht selbstständig verlassen können. Erst wenn auf den Query des Routers kein Report folgt wird die Weiterleitung beendet.
IGMPv1 hat kein Group-Specific Query – das liegt daran, dass es keine Leave Group Message gibt. Warum einzelne Gruppen Querien wenn die Teilnehmer sie nicht verlassen können?
IGMPv1 hat keine spezifizierte Max-Response-Time in den Queries. Dafür gibt es eine fixe Zeit von 10s.
IGMPv1 hat keinen Querier Auswahl Prozess – das bedeutet die Auswahl des Queriers wird per IP Multicast Routing Protokol durchgeführt, hierbei wird der Designated Router für Multicast festgelegt. Da die verschiedenen Protkolle allerdings andere Mechanismen verwenden kann es vorkommen dass zwei DRs in einem Segement vorhanden sind, und somit zwei Querier.
IGMPv3
IGMPv3 ist die Nachfolge Version von IGMPv2, macht diese also eigentlich Obsolet. Aber IGMPv2 ist weiterhin weitverbreitet und noch der Standard auf Cisco Routern. Daher ist es wichtig beide Versionen zu verstehen.
IGMPv3 brachte die Möglichkeit für Source-Specific Multicast und somit ein Group-and-Source-Specifiy-Query. Dieses Query ermöglicht es, eine Gruppe nicht nur anhand der Gruppen Adresse zu identifizieren sondern auch anhand der Source Adresse. Die Membership Reports und Group Leave Messages wurden dahingehend angepasst.
Wenn eine Gruppe nun viele Sourcen hat, kann der IGMPv3 Router eine Filterung anhand der Source machen, basierend auf den Requests der Gruppen Teilnehmer. Zum Beispiel kann ein Teilnehmer in seinem Membership Report angeben, er möchte diese Gruppe von genau dieser Source empfangen. Oder, per Include bzw. Exclude Filtern, angeben dass er von diesen Sourcen (Include) empfangen möchte oder von allen Sourcen außer diesen angegebenen (Exclude). Wenn in den Membership Reports einzelne Sourcen nicht enthalten sind, werden die Streams dieser Sourcen nicht weitergeleitet.
Das Source Filtering ist die wichtigste Veränderung zwischen IGMPv2 und v3, aber es gibt noch mehr Veränderungen zwischen den beiden Versionen:
IGMPv3 Queries haben eine Robustness Variable und einen Query Interval, damit ermöglichen sie eine Synchronisation der Querier und Non-querier.
Die Max-Response-Time lässt sich länger einstellen, IGMPv2 ließ max. 25,5s zu. IGMPv3 lässt nun bis zu 53 Minuten zu.
IGMPv3 Report Messages werden nun an die Well-Known IGMP Multicast Adresse 224.0.0.22 gesendet. Das vereinfacht das IGMP Snooping.
Die Reports können nun mehrere Group Records enthalten, also mehrere Multicast Streams. Das erhöht die Effizienz des Reportings.
IGMPv3 Queries haben ein „Suppress Router-Side“ Flag, das sorgt dafür, dass die normalen Timer Updates vermieden (suppressed) werden, bis zum empfang eines Queries.
IGMPv3 Hosts machen keine Suppression mehr, das heißt jeder Host sendet seine(n) Report(s), auch wenn bereits andere Hosts einen Report für die Multicast Gruppe gesendet haben.
IGMPv2 und v3 sind abwärtskompatibel, das heißt sie können mit den alten Nachrichten und den Einschränkungen der älteren Versionen umgehen und passen sich entsprechend an. Das betrifft aber immer nur ein Segment (LAN, VLAN) denn nur dort ist IGMP ausschlaggebend.
Das gleiche betrifft MLD. MLD gibt es ebenfalls in zwei Versionen, MLDv1 (= IGMPv2) und MLDv3 (=IGMPv3). Cisco Standard ist MLDv2. Die Funktionalitäten unterscheiden sich nicht, IGMP und MLD sind aber nicht kompatibel. Allein schon wegen der sehr unterschiedlichen Adressen (IPv4 vs IPv6).