Eine Einführung in IP-Multicast
25.06.2026 40 Min. Lesezeit
Das Problem klassischer Unicast-Kommunikation
Die überwiegende Mehrheit der Anwendungen in heutigen IP-Netzwerken verwendet Unicast-Kommunikation. Dabei existiert für jede Kommunikationsbeziehung genau ein Sender und genau ein Empfänger. Ein Client baut eine Verbindung zu einem Server auf, Pakete werden an eine eindeutige Zieladresse übertragen und entlang des Routing-Pfades genau für diesen Empfänger weitergeleitet.
Dieses Modell funktioniert hervorragend, solange einzelne Kommunikationspartner miteinander kommunizieren. Problematisch wird es jedoch, wenn identische Informationen gleichzeitig an eine große Anzahl von Empfängern verteilt werden sollen.
Betrachten wir beispielsweise einen Livestream, der von einem Server an 1.000 Zuschauer übertragen werden soll. Bei reinem Unicast müsste der Server denselben Datenstrom 1.000 Mal erzeugen und versenden. Jeder Router im Netzwerk würde diese Datenströme unabhängig voneinander transportieren. Die Folge sind ein hoher Bandbreitenverbrauch, eine starke Belastung des Senders und eine ineffiziente Nutzung der Netzwerkinfrastruktur.
Genau dieses Problem adressiert Multicast.
Was ist Multicast?
Multicast beschreibt ein Kommunikationsmodell, bei dem ein Sender Daten an eine Gruppe von Empfängern überträgt. Der Sender kennt die einzelnen Empfänger dabei nicht und muss auch keine individuellen Verbindungen zu ihnen aufbauen.
Stattdessen sendet die Quelle ihre Daten einmal an eine Multicast-Gruppe. Das Netzwerk übernimmt anschließend die Aufgabe, den Datenstrom an alle interessierten Empfänger zu verteilen.
Multicast wird daher häufig als „One-to-Many-Kommunikation“ bezeichnet. Tatsächlich ist die Funktionsweise jedoch eher als „One-to-Interested-Receivers“ zu verstehen. Nur Hosts, die explizit Interesse an einer Multicast-Gruppe angemeldet haben, erhalten die entsprechenden Daten.
Der wesentliche Vorteil besteht darin, dass Pakete nur dort repliziert werden, wo sich die Übertragungswege tatsächlich verzweigen. Solange mehrere Empfänger denselben Netzwerkpfad nutzen, wird nur eine einzige Kopie des Datenstroms transportiert.
Dadurch sinken sowohl die Bandbreitenanforderungen als auch die Last auf Sendern und Routern erheblich.
Warum existiert neben Unicast und Broadcast noch Multicast?
In IPv4 existieren grundsätzlich drei Kommunikationsmodelle:
Unicast beschreibt die Kommunikation zwischen genau einem Sender und genau einem Empfänger.
Broadcast beschreibt die Kommunikation eines Senders mit allen Geräten innerhalb einer Broadcast-Domäne.
Multicast liegt zwischen diesen beiden Extremen. Daten werden weder an einen einzelnen Empfänger noch an alle Systeme übertragen, sondern ausschließlich an diejenigen Hosts, die Mitglied einer bestimmten Gruppe sind.
Broadcast besitzt insbesondere in großen Netzwerken erhebliche Nachteile. Jedes Endgerät muss Broadcast-Frames empfangen und verarbeiten, unabhängig davon, ob die Informationen relevant sind oder nicht. Aus diesem Grund wurde Broadcast niemals für die effiziente Verteilung größerer Datenströme entwickelt.
Multicast löst dieses Problem, indem Empfänger aktiv einer Gruppe beitreten können. Nur diese Geräte erhalten anschließend den entsprechenden Datenverkehr.
Typische Einsatzgebiete von Multicast
Multicast wird überall dort eingesetzt, wo identische Informationen an viele Empfänger verteilt werden müssen.
Historisch entstand die größte Verbreitung im Bereich IPTV. Provider können Fernsehkanäle als Multicast-Ströme übertragen und die Daten erst an den Stellen replizieren, an denen sich die Empfangswege zu den Kunden unterscheiden.
Auch im Finanzsektor wird Multicast intensiv genutzt. Börsenplätze verteilen Marktdaten in Echtzeit an Tausende von Handelssystemen. Da alle Empfänger dieselben Informationen erhalten sollen, wäre eine Unicast-basierte Verteilung äußerst ineffizient.
Weitere Anwendungsgebiete umfassen Videokonferenzen, Softwareverteilung, Echtzeit-Telemetrie, industrielle Steuerungsnetze sowie verschiedene Discovery-Protokolle.
Im Enterprise-Umfeld begegnet man Multicast außerdem indirekt bei Technologien wie mDNS, bestimmten Storage-Lösungen oder Routing-Protokollen, die ihre Nachbarschaftsinformationen über Multicast austauschen.
Die grundlegende Idee hinter IP-Multicast
Der zentrale Unterschied zwischen Unicast- und Multicast-Routing besteht darin, dass bei Multicast nicht das Ziel, sondern die Gruppe im Mittelpunkt steht.
Ein Empfänger signalisiert dem Netzwerk zunächst sein Interesse an einer bestimmten Multicast-Gruppe. Das Netzwerk erzeugt daraufhin einen Verteilbaum, über den Daten von der Quelle zu allen Mitgliedern dieser Gruppe transportiert werden können.
Während ein Unicast-Router typischerweise die Frage beantwortet:
„Über welches Interface erreiche ich die Zieladresse?“
muss ein Multicast-Router eine andere Frage beantworten:
„Über welche Interfaces befinden sich Empfänger dieser Multicast-Gruppe?“
Dadurch entstehen vollkommen andere Anforderungen an Routingtabellen, Weiterleitungsmechanismen und Kontrollprotokolle.
Multicast-Routing basiert deshalb nicht auf klassischen Zielpräfixen, sondern auf Zuständen für Quellen, Gruppen und Verteilbäume.
Genau diese Mechanismen bilden die Grundlage für Technologien wie IGMP, PIM Sparse Mode, Rendezvous Points, Shared Trees, Source Trees und Anycast RP, die in modernen IP-Netzwerken und insbesondere auf Juniper-Routern eingesetzt werden.
Multicast-Adressierung in IPv4
Bevor man die Funktionsweise von IGMP, PIM oder Rendezvous Points verstehen kann, muss zunächst klar sein, wie Multicast-Empfänger und Multicast-Gruppen überhaupt adressiert werden. Anders als beim Unicast-Routing existiert bei Multicast kein einzelnes Zielsystem. Stattdessen repräsentiert eine Multicast-Adresse immer eine Gruppe von Empfängern.
Eine Multicast-Adresse identifiziert also nicht einen bestimmten Host, sondern einen logischen Empfängerkreis. Jedes System, das Mitglied dieser Gruppe wird, erhält die an diese Adresse gesendeten Pakete.
Der IPv4-Multicast-Adressraum
Für IPv4 ist der gesamte Adressbereich 224.0.0.0/4 für Multicast reserviert. Dies entspricht allen Adressen von 224.0.0.0 bis 239.255.255.255.
Das erste Oktett beginnt immer mit den Bitwerten 1110, wodurch sich Multicast-Adressen eindeutig von Unicast- und Broadcast-Adressen unterscheiden lassen.
Ein Router erkennt dadurch bereits beim Empfang eines Pakets, dass es sich um Multicast-Verkehr handelt und eine spezielle Weiterleitungslogik erforderlich ist.
Innerhalb dieses Bereichs existieren verschiedene Unterteilungen, die jeweils unterschiedliche Aufgaben erfüllen.
Link-Local Multicast
Der Bereich 224.0.0.0/24 besitzt eine besondere Bedeutung. Diese Adressen werden ausschließlich innerhalb eines lokalen Layer-2-Segments verwendet und dürfen von Routern niemals weitergeleitet werden.
Viele Netzwerkprotokolle nutzen diesen Bereich für ihre grundlegende Kommunikation.
Beispiele sind:
- 224.0.0.1 für alle Hosts im lokalen Netzwerk
- 224.0.0.2 für alle Router
- 224.0.0.5 für OSPF-Router
- 224.0.0.6 für OSPF Designated Router
- 224.0.0.9 für RIPv2
- 224.0.0.13 für PIM-Router
Diese Gruppen werden häufig als Well-Known Multicast Groups bezeichnet.
Wenn beispielsweise ein PIM-Router Hello-Nachrichten versendet, werden diese an 224.0.0.13 adressiert. Alle PIM-fähigen Router innerhalb desselben Segments empfangen diese Pakete automatisch.
Da diese Gruppen niemals geroutet werden, entsteht kein Multicast-Zustand im Netzwerkkern.
Globale Multicast-Adressen
Der Bereich oberhalb von 224.0.0.255 kann grundsätzlich geroutet werden.
Hier befinden sich die Adressen, die typischerweise von Anwendungen für IPTV, Marktinformationssysteme oder Streaming-Dienste verwendet werden.
Ein Beispiel könnte die Gruppe 239.1.1.1 sein, über die ein IPTV-Kanal übertragen wird. Alle Empfänger, die dieser Gruppe beitreten, erhalten denselben Datenstrom.
Welche Anwendung welche Adresse verwendet, ist dabei grundsätzlich eine Designentscheidung des jeweiligen Netzbetreibers.
Administratively Scoped Addresses
Analog zu den privaten IPv4-Netzen existiert auch für Multicast ein Bereich mit administrativer Gültigkeit.
Dieser Bereich umfasst 239.0.0.0/8.
Die Adressen sind für die Nutzung innerhalb einer Organisation vorgesehen und sollen das Netzwerk nicht verlassen.
Vergleichbar mit RFC-1918-Adressen bei Unicast stellt dieser Bereich eine sinnvolle Wahl für interne Unternehmensanwendungen dar.
In vielen Enterprise-Netzen werden sämtliche Multicast-Dienste ausschließlich innerhalb dieses Bereichs betrieben.
Source Specific Multicast (SSM)
Eine besondere Rolle spielt der Bereich 232.0.0.0/8.
Dieser Adressraum ist exklusiv für Source Specific Multicast reserviert.
SSM basiert auf einem grundlegend anderen Betriebsmodell als klassisches Multicast.
Während ein Empfänger beim traditionellen Any-Source-Multicast lediglich einer Gruppe beitritt, spezifiziert er bei SSM zusätzlich die gewünschte Quelle.
Der Empfänger fordert also nicht mehr:
Ich möchte Daten für Gruppe G erhalten.
sondern:
Ich möchte Daten von Quelle S für Gruppe G erhalten.
Die Zustände im Netzwerk werden daher nicht mehr als (*,G), sondern ausschließlich als (S,G) aufgebaut.
Dadurch entfällt die Notwendigkeit eines Rendezvous Points vollständig. Die Architektur wird einfacher, sicherer und deutlich besser skalierbar.
Aus diesem Grund gilt SSM heute in vielen Umgebungen als bevorzugtes Multicast-Modell.
Multicast auf Layer 2
Nachdem die IP-Adressierung geklärt ist, stellt sich die nächste Frage:
Wie gelangen Multicast-Pakete eigentlich über Ethernet?
Auch auf Layer 2 müssen Switches erkennen können, welche Endgeräte Interesse an einer Multicast-Gruppe besitzen.
Dafür erfolgt eine Abbildung von IPv4-Multicast-Adressen auf Ethernet-MAC-Adressen.
Mapping von IPv4 auf Ethernet
Alle Ethernet-Multicast-Adressen beginnen mit dem Präfix:
01:00:5e
Dieses Präfix wurde von der IEEE speziell für IPv4-Multicast reserviert.
Die unteren 23 Bit der IPv4-Multicast-Adresse werden auf die letzten 23 Bit der MAC-Adresse abgebildet.
Dadurch entsteht jedoch ein Problem.
Eine IPv4-Multicast-Adresse besitzt 28 relevante Adressbits, die Ethernet-Adresse bietet jedoch lediglich Platz für 23 Bits.
Mehrere IPv4-Gruppen müssen sich daher dieselbe Layer-2-Adresse teilen.
Dieses Verhalten wird als Address Aliasing bezeichnet.
Ein Switch kann anhand der MAC-Adresse deshalb nicht eindeutig erkennen, zu welcher IPv4-Multicast-Gruppe ein Paket gehört.
Die genaue Auswertung erfolgt erst auf Layer 3 durch die Endsysteme.
Flooding ohne zusätzliche Mechanismen
Ein klassischer Ethernet-Switch besitzt zunächst keine Kenntnis darüber, welche Hosts Mitglied einer bestimmten Multicast-Gruppe sind.
Ohne weitere Informationen behandelt er Multicast-Verkehr daher ähnlich wie unbekannten Broadcast-Verkehr.
Die Frames werden an sämtliche Ports innerhalb des VLANs weitergeleitet.
Bei kleinen Netzwerken ist dieses Verhalten meist unkritisch. In größeren Umgebungen kann dies jedoch erhebliche Mengen unnötigen Datenverkehrs verursachen.
Insbesondere IPTV-Anwendungen können ohne Gegenmaßnahmen schnell mehrere Gigabit pro Sekunde an unerwünschtem Traffic erzeugen.
Aus diesem Grund wurden zusätzliche Verfahren entwickelt.
IGMP Snooping
Moderne Ethernet-Switches beobachten typischerweise den IGMP-Verkehr zwischen Hosts und Routern.
Dieses Verfahren wird als IGMP Snooping bezeichnet.
Der Switch analysiert die IGMP-Join- und Leave-Nachrichten und erstellt daraus eine Tabelle, welche Ports Interesse an bestimmten Multicast-Gruppen besitzen.
Erst dadurch wird eine gezielte Weiterleitung möglich.
Der Datenverkehr einer Gruppe wird anschließend nur noch an diejenigen Ports repliziert, an denen sich tatsächlich Empfänger befinden.
Aus Sicht eines Enterprise-Netzes ist IGMP Snooping oftmals die wichtigste Voraussetzung für einen effizienten Multicast-Betrieb.
Ohne IGMP Snooping würde jedes Multicast-Paket weiterhin nahezu wie ein Broadcast behandelt.
Die Besonderheit des Multicast-Routings
Bei Unicast existiert für jede Zieladresse genau ein Next Hop.
Ein Router betrachtet das Zielpräfix, führt einen Lookup in der Routing-Tabelle durch und leitet das Paket entsprechend weiter.
Dieses Modell funktioniert bei Multicast nicht.
Angenommen ein Stream soll an Empfänger in Frankfurt, München und Hamburg geliefert werden.
Ein klassischer Unicast-Lookup würde lediglich einen einzigen Ausgangspfad liefern. Multicast benötigt jedoch mehrere Ausgangsinterfaces gleichzeitig.
Der Router muss daher wissen:
- Von welcher Quelle stammen die Pakete?
- Für welche Gruppe sind sie bestimmt?
- Über welche Interfaces befinden sich Empfänger?
Multicast-Routing arbeitet deshalb nicht mit klassischen Routingtabellen, sondern mit speziellen Zuständen in der Multicast Forwarding Information Base (MFIB).
Die Einträge beschreiben dabei nicht ein Zielnetz, sondern einen Verteilbaum.
Ein typischer Zustand könnte beispielsweise lauten:
(S,G)
Quelle: 192.0.2.10
Gruppe: 239.1.1.1
Incoming Interface:
ae0.0
Outgoing Interfaces:
ge-0/0/3.0
ge-0/0/7.0
ge-0/0/8.0
Trifft ein Paket der Quelle auf dem Incoming Interface ein, repliziert der Router es auf sämtliche definierten Outgoing Interfaces.
Genau diese Zustände werden später durch IGMP und PIM dynamisch aufgebaut.
Reverse Path Forwarding (RPF)
Bevor wir IGMP und PIM betrachten, muss noch ein fundamentales Konzept verstanden werden: Reverse Path Forwarding.
RPF ist die zentrale Schleifenvermeidungsmechanik aller modernen Multicast-Protokolle.
Der Router prüft beim Empfang eines Multicast-Pakets nicht die Zieladresse, sondern die Quelle.
Anschließend wird anhand der Unicast-Routing-Tabelle ermittelt, über welches Interface die Quelle erreichbar wäre.
Nur wenn das Paket über genau dieses Interface eingetroffen ist, gilt der RPF-Check als bestanden.
Andernfalls wird das Paket verworfen.
Dieses Verfahren verhindert effektiv Routing-Schleifen innerhalb von Multicast-Verteilbäumen.
Gerade bei PIM-Sparse-Mode und Source Trees bildet der RPF-Check die Grundlage sämtlicher Weiterleitungsentscheidungen.
Ein wichtiger Merksatz für JNCIA-, JNCIS- und JNCIP-Kandidaten lautet daher:
Multicast-Routing basiert auf dem Unicast-Routing.
Existiert kein korrekter Unicast-Pfad zur Quelle, kann auch kein funktionierender Multicast-Baum aufgebaut werden.
Internet Group Management Protocol (IGMP)
Nachdem die Grundlagen von Multicast-Adressen, Layer-2-Weiterleitung und Reverse Path Forwarding verstanden sind, können wir uns dem ersten eigentlichen Multicast-Protokoll widmen.
IGMP ist das Protokoll, mit dem Hosts ihre Mitgliedschaft in Multicast-Gruppen verwalten. Es arbeitet ausschließlich zwischen Endsystemen und dem First-Hop-Router innerhalb eines gemeinsamen Layer-2-Segments.
Eine häufige Fehlannahme besteht darin, dass IGMP ein Routingprotokoll sei. Tatsächlich besitzt IGMP keinerlei Kenntnis über Quellen, Routing-Pfade oder den Aufbau von Multicast-Bäumen. Seine einzige Aufgabe besteht darin, einem Router mitzuteilen, welche Gruppen auf einem bestimmten Netzwerksegment benötigt werden.
PIM, das wir später betrachten werden, übernimmt anschließend den eigentlichen Transport dieser Informationen durch das Netzwerk.
Die Rolle des Last-Hop-Routers
Stellen wir uns ein VLAN mit mehreren Clients vor.
Ein Client möchte einen IPTV-Kanal empfangen, der über die Gruppe 239.1.1.1 übertragen wird. Der Host muss nun dem lokalen Router mitteilen, dass er Mitglied dieser Gruppe werden möchte.
Hierfür sendet der Host eine IGMP-Nachricht.
Der Router registriert die Mitgliedschaft und speichert die Information intern ab. Sobald mindestens ein Empfänger für diese Gruppe existiert, kann der Router beginnen, entsprechende Multicast-Zustände im Netzwerk aufzubauen.
Aus Sicht des Routers lautet die Information also nicht:
Host 192.168.10.100 möchte Gruppe 239.1.1.1 empfangen.
sondern vielmehr:
Auf Interface irb.10 existieren Empfänger für Gruppe 239.1.1.1.
Die einzelnen Hosts spielen für das Multicast-Routing später keine Rolle mehr.
IGMP Versionen
Im Laufe der Zeit wurden mehrere Versionen von IGMP entwickelt.
IGMPv1 definierte lediglich grundlegende Mechanismen zum Beitritt einer Gruppe.
IGMPv2 führte zusätzliche Optimierungen ein, insbesondere Leave-Nachrichten, wodurch Gruppenmitgliedschaften schneller entfernt werden konnten.
IGMPv3 erweitert das Modell um Source Filtering und bildet damit die Grundlage für Source Specific Multicast.
Heute wird in modernen Netzwerken nahezu ausschließlich IGMPv2 oder IGMPv3 eingesetzt.
Für SSM ist IGMPv3 zwingend erforderlich.
IGMP Membership Reports
Wenn ein Host einer Gruppe beitreten möchte, sendet er einen Membership Report.
Nehmen wir an, ein Client möchte den Stream der Gruppe 239.1.1.1 empfangen.
Der Host sendet daraufhin einen IGMP Report an diese Multicast-Gruppe.
Der lokale Router empfängt die Nachricht und erkennt:
Auf diesem Segment existiert mindestens ein Empfänger für Gruppe 239.1.1.1.
Anschließend erzeugt der Router lokale Zustände und informiert später über PIM die übrige Multicast-Infrastruktur.
Wichtig ist dabei, dass ein Router nicht jeden einzelnen Empfänger verfolgen muss.
Für die Weiterleitung genügt die Information, dass mindestens ein Host auf diesem Interface Interesse an der Gruppe besitzt.
Warum benötigt IGMP Queries?
Ein Router darf nicht davon ausgehen, dass einmal angemeldete Hosts dauerhaft existieren.
Clients werden ausgeschaltet, Netzwerkkabel werden entfernt oder Anwendungen beendet.
Daher muss der Router regelmäßig prüfen, ob Gruppen weiterhin benötigt werden.
Hierzu versendet er sogenannte Membership Queries.
Diese Queries werden an die Gruppe 224.0.0.1 gesendet, die alle Hosts eines Segments repräsentiert.
Jeder Empfänger antwortet anschließend mit einem Membership Report für die Gruppen, denen er angehört.
Bleiben Antworten aus, entfernt der Router die entsprechenden Mitgliedschaften.
Auf diese Weise bleibt die Multicast-Forwarding-Datenbank aktuell.
Querier Election
Innerhalb eines VLANs können mehrere Router vorhanden sein.
Würden alle Router gleichzeitig Membership Queries versenden, entstünde unnötiger Overhead.
Deshalb definiert IGMP eine Querier Election.
Der Router mit der niedrigsten IPv4-Adresse auf dem gemeinsamen Segment übernimmt die Rolle des Queriers.
Nur dieser Router versendet regelmäßig Queries.
Die übrigen Router beobachten den Prozess passiv.
Fällt der Querier aus, wird automatisch ein neuer gewählt.
Gerade in redundanten Enterprise-Netzen ist dieser Mechanismus von großer Bedeutung.
Leave Processing
Ein Problem früher IGMP-Versionen bestand darin, dass ein Router erst beim Ausbleiben von Membership Reports erkennen konnte, dass keine Empfänger mehr existierten.
Dies konnte mehrere Minuten dauern.
IGMPv2 führte daher Leave Messages ein.
Wenn ein Host eine Gruppe verlässt, sendet er aktiv eine Leave-Nachricht an den Router.
Der Router startet daraufhin eine sogenannte Group-Specific Query.
Er fragt gezielt nach, ob noch weitere Mitglieder dieser Gruppe vorhanden sind.
Erfolgt keine Antwort, kann die Mitgliedschaft sofort entfernt werden.
Dies reduziert unnötigen Multicast-Verkehr erheblich.
IGMPv3 und Source Filtering
IGMPv3 erweitert das ursprüngliche Gruppenmodell um Quelleninformationen.
Bis dahin galt lediglich:
Ich möchte Daten für Gruppe G erhalten.
Mit IGMPv3 kann ein Empfänger stattdessen ausdrücken:
Ich möchte Daten von Quelle S für Gruppe G erhalten.
oder:
Ich möchte Daten für Gruppe G empfangen, aber nicht von Quelle S.
Hierfür definiert IGMPv3 verschiedene Filtermodi.
Das wichtigste Szenario ist Source Specific Multicast.
Ein Empfänger fordert dabei explizit den Datenstrom einer bestimmten Quelle an.
Beispielsweise:
Quelle: 192.0.2.10
Gruppe: 232.1.1.1
Der Router kann daraus direkt einen (S,G)-Zustand ableiten.
Die gesamte Komplexität klassischer Rendezvous-Point-Architekturen entfällt.
Aus diesem Grund wird SSM heute häufig für IPTV, Finanzmarktdaten und andere großskalige Streaming-Anwendungen eingesetzt.
IGMP in Junos
Unter Junos wird IGMP typischerweise auf dem Layer-3-Interface aktiviert, an dem sich die Empfänger befinden.
Ein einfaches Beispiel könnte wie folgt aussehen:
protocols {
igmp {
interface irb.10;
}
}
Sobald IGMP aktiviert wird, beginnt der Router mit dem Versand von Queries und verarbeitet eingehende Membership Reports.
Für die Überprüfung stehen verschiedene Operational Commands zur Verfügung.
Besonders wichtig sind:
show igmp group
Dieser Befehl zeigt die aktuell bekannten Gruppenmitgliedschaften.
Für tiefergehende Analysen kann zusätzlich verwendet werden:
show igmp interface
oder
show igmp statistics
Diese Befehle gehören zu den wichtigsten Werkzeugen bei der Fehlersuche in Junos-basierten Multicast-Netzwerken.
Von IGMP zu PIM
An dieser Stelle verfügen wir über einen Router, der weiß:
- welche Gruppen existieren
- auf welchen Interfaces Empfänger vorhanden sind
- wann Gruppen hinzugefügt oder entfernt werden
Was dem Router jedoch noch fehlt, ist die Kenntnis darüber, woher die eigentlichen Multicast-Daten stammen.
Der Router weiß zwar:
Auf irb.10 möchte jemand Gruppe 239.1.1.1 empfangen.
Er weiß jedoch nicht:
Über welchen Pfad erreiche ich die Quelle dieses Datenstroms?
Genau dieses Problem löst Protocol Independent Multicast (PIM).
PIM bildet das eigentliche Routingprotokoll für Multicast-Netzwerke. Es sorgt dafür, dass zwischen Quellen und Empfängern die erforderlichen Verteilbäume entstehen und die notwendigen Zustände auf allen Routern aufgebaut werden.
Damit beginnt der eigentliche Kern moderner Multicast-Architekturen.
Protocol Independent Multicast (PIM)
Mit IGMP haben wir gelernt, wie Empfänger ihr Interesse an einer Multicast-Gruppe signalisieren. Der lokale Router weiß nun, welche Gruppen auf seinen Interfaces benötigt werden. Diese Information ist jedoch zunächst nur lokal relevant.
Sobald sich Quelle und Empfänger in unterschiedlichen Netzsegmenten befinden, muss ein Mechanismus existieren, der die Multicast-Daten durch das Netzwerk transportiert und dabei die notwendigen Verteilbäume aufbaut.
Diese Aufgabe übernimmt Protocol Independent Multicast, kurz PIM.
Der Name ist bewusst gewählt. PIM ist nicht an ein bestimmtes Unicast-Routingprotokoll gebunden. Ob OSPF, IS-IS, BGP oder statische Routen verwendet werden, spielt für PIM keine Rolle.
PIM nutzt die vorhandene Unicast-Routing-Tabelle, um Reverse-Path-Forwarding-Entscheidungen zu treffen. Das Routingprotokoll selbst bleibt davon unabhängig.
Daher stammt die Bezeichnung „Protocol Independent“.
Warum benötigt Multicast überhaupt ein eigenes Routingprotokoll?
Ein Unicast-Router muss lediglich die Frage beantworten:
Über welches Interface erreiche ich das Ziel?
Ein Multicast-Router muss dagegen beantworten:
Über welche Interfaces befinden sich Empfänger dieser Gruppe?
Die Anzahl der Empfänger kann dabei beliebig groß sein.
Außerdem können neue Empfänger jederzeit hinzukommen oder bestehende Empfänger verschwinden.
Multicast-Router müssen deshalb dynamisch Verteilbäume aufbauen, verändern und wieder abbauen.
Genau hierfür wurde PIM entwickelt.
PIM Dense Mode und Sparse Mode
Historisch existieren verschiedene Betriebsarten von PIM.
Die beiden wichtigsten sind Dense Mode und Sparse Mode.
Dense Mode war ursprünglich für Umgebungen gedacht, in denen nahezu jedes Netzwerksegment Empfänger besitzt.
Sparse Mode wurde für die heute wesentlich häufigere Situation entwickelt, in der nur wenige Segmente tatsächlich Multicast-Empfänger enthalten.
In modernen Enterprise-, Service-Provider- und Rechenzentrumsumgebungen wird praktisch ausschließlich PIM Sparse Mode eingesetzt.
Dense Mode besitzt heute hauptsächlich noch historische Bedeutung.
Für den weiteren Verlauf konzentrieren wir uns daher auf Sparse Mode.
Die Grundidee von PIM Sparse Mode
PIM Sparse Mode geht zunächst davon aus, dass keine Empfänger existieren.
Multicast-Daten werden daher nicht einfach in alle Richtungen geflutet.
Stattdessen müssen Empfänger aktiv Interesse anmelden.
Erst wenn eine Gruppe tatsächlich benötigt wird, wird ein entsprechender Verteilbaum aufgebaut.
Dieses Verhalten skaliert erheblich besser als Flood-and-Prune-Verfahren und bildet die Grundlage nahezu aller modernen Multicast-Netzwerke.
Der Rendezvous Point
Der zentrale Baustein von PIM Sparse Mode ist der Rendezvous Point, häufig als RP bezeichnet.
Man kann sich den RP zunächst als einen bekannten Treffpunkt vorstellen.
Sowohl Quellen als auch Empfänger kennen diesen Treffpunkt indirekt.
Die Quelle meldet dort ihre Existenz an.
Empfänger bauen zunächst einen Verteilbaum zum RP auf.
Dadurch entsteht ein gemeinsamer Verteilerpunkt für die jeweilige Multicast-Gruppe.
Der RP wird allerdings nicht dauerhaft im Datenpfad verbleiben. Seine wichtigste Aufgabe besteht zunächst darin, Sender und Empfänger zusammenzubringen.
Deshalb spricht man häufig auch von einem Shared Tree.
Shared Trees und (*,G)-Zustände
Wenn ein Empfänger einer Gruppe beitritt, existiert die Quelle möglicherweise noch gar nicht.
Deshalb wird zunächst kein quellenspezifischer Zustand aufgebaut.
Der Router erstellt stattdessen einen sogenannten Shared Tree State.
Dieser wird dargestellt als:
(*,G)
Das Sternsymbol bedeutet:
Beliebige Quelle für diese Gruppe.
Beispielsweise:
(*,239.1.1.1)
Dieser Zustand beschreibt:
Für Gruppe 239.1.1.1 existieren Empfänger, unabhängig davon, welche Quelle später Daten sendet.
Der Last-Hop-Router beginnt nun Join-Nachrichten in Richtung Rendezvous Point zu senden.
Auf jedem Router entlang des Pfades entstehen entsprechende (*,G)-Einträge.
Nach kurzer Zeit existiert ein vollständiger Verteilbaum vom Empfänger bis zum RP.
Dieser Baum wird als Rendezvous Point Tree (RPT) bezeichnet.
Wie Quellen bekannt werden
Betrachten wir nun die andere Seite.
Eine Quelle beginnt damit, Multicast-Daten für Gruppe 239.1.1.1 zu senden.
Der First-Hop-Router der Quelle erkennt den neuen Datenstrom.
Anschließend erzeugt er einen quellenspezifischen Zustand:
(S,G)
Beispielsweise:
(192.0.2.10,239.1.1.1)
Der Router kapselt erste Multicast-Pakete in sogenannte Register-Nachrichten ein und sendet diese direkt an den Rendezvous Point.
Dieses Verfahren wird als PIM Register bezeichnet.
Der RP erfährt dadurch:
Die Quelle 192.0.2.10 sendet Daten für Gruppe 239.1.1.1.
Erst jetzt können die Daten über den bereits vorhandenen Shared Tree an die Empfänger verteilt werden.
Der erste Datenfluss
Damit ergibt sich folgender Ablauf:
- Ein Empfänger tritt einer Gruppe bei.
- Der Last-Hop-Router erzeugt einen (*,G)-Zustand.
- PIM Join-Nachrichten bauen einen Shared Tree zum RP auf.
- Die Quelle beginnt zu senden.
- Der First-Hop-Router registriert die Quelle beim RP.
- Der RP leitet die Daten über den Shared Tree weiter.
In diesem Stadium fließen sämtliche Pakete über den Rendezvous Point.
Das ist funktional korrekt, aber nicht unbedingt optimal.
Warum Shared Trees ineffizient werden können
Der RP dient als zentraler Treffpunkt.
Dadurch kann es vorkommen, dass Daten einen unnötigen Umweg nehmen.
Betrachten wir folgendes Beispiel:
- Quelle in Frankfurt
- RP in Amsterdam
- Empfänger in München
Die Daten laufen dann zunächst:
Frankfurt → Amsterdam → München
Obwohl möglicherweise ein direkter Pfad zwischen Frankfurt und München existiert.
Je größer das Netzwerk wird, desto stärker wirkt sich dieser Umweg aus.
Aus diesem Grund wurde ein zweiter Mechanismus eingeführt.
Source Trees und (S,G)-Zustände
Sobald ein Router erkennt, dass tatsächlich Daten einer bestimmten Quelle empfangen werden, kann er einen direkten Baum zur Quelle aufbauen.
Dieser wird als Source Tree oder Shortest Path Tree bezeichnet.
Der Zustand lautet:
(S,G)
also beispielsweise:
(192.0.2.10,239.1.1.1)
Nun wird nicht mehr zum RP gejoint.
Stattdessen sendet der Router einen PIM Join direkt in Richtung der Quelle.
Die Unicast-Routing-Tabelle bestimmt dabei erneut den RPF-Pfad.
Nach erfolgreichem Aufbau fließen die Daten direkt von der Quelle zum Empfänger.
Der RP wird anschließend aus dem eigentlichen Datenpfad entfernt.
Dieses Verfahren bezeichnet man als SPT Switchover.
Der Ablauf eines SPT Switchovers
In einem typischen Netzwerk läuft die Kommunikation daher in zwei Phasen ab.
Zunächst entsteht ein Shared Tree:
Quelle
|
RP
|
Empfänger
Danach baut der Last-Hop-Router einen direkten Source Tree auf:
Quelle
|
Empfänger
Sobald der neue Pfad stabil ist, sendet der Router eine Prune-Nachricht in Richtung RP.
Der alte Datenpfad wird entfernt.
Die Daten fließen nun ausschließlich über den Shortest Path Tree.
In großen Netzen reduziert dies sowohl Latenz als auch Bandbreitenverbrauch erheblich.
Die wichtigsten PIM-Nachrichten
Im täglichen Betrieb begegnet man vor allem fünf Nachrichtentypen.
PIM Hello dient der Nachbarschaftserkennung auf gemeinsam genutzten Segmenten.
PIM Join wird verwendet, um einen Verteilbaum aufzubauen.
PIM Prune entfernt nicht mehr benötigte Zweige eines Baumes.
PIM Register meldet neue Quellen beim Rendezvous Point an.
PIM Register-Stop signalisiert dem First-Hop-Router, dass der RP die Quelle bereits kennt und keine weiteren Register-Pakete mehr benötigt.
Diese wenigen Nachrichtentypen bilden den Kern der PIM-Sparse-Mode-Control-Plane.
PIM-Nachbarschaften in Junos
Bevor PIM Join- und Prune-Nachrichten ausgetauscht werden können, müssen Router zunächst Nachbarn erkennen.
Hierfür verwendet PIM regelmäßige Hello-Nachrichten an die Multicast-Gruppe 224.0.0.13.
Sobald zwei Router gegenseitig Hellos empfangen, entsteht eine PIM-Adjazenz.
In Junos wird PIM typischerweise auf den Transit-Interfaces aktiviert:
protocols {
pim {
interface ae0.0;
interface ae1.0;
interface ae2.0;
}
}
Die Nachbarschaften lassen sich anschließend überprüfen mit:
show pim neighbors
Für viele Multicast-Probleme ist dies einer der ersten Befehle, die geprüft werden sollten.
Fehlen PIM-Nachbarn, können weder Join-Nachrichten noch Verteilbäume aufgebaut werden.
Die Multicast Routing Table
Während Unicast-Routen in der Routing Information Base (RIB) gespeichert werden, entstehen durch PIM zusätzliche Multicast-Zustände.
Unter Junos lassen sich diese beispielsweise anzeigen mit:
show multicast route
Hier erscheinen die bekannten (*,G)- und (S,G)-Einträge.
Gerade für JNCIS- und JNCIP-Kandidaten ist das Verständnis dieser Tabelle entscheidend.
Fast jede Fehlersuche im Multicast-Bereich beginnt letztlich mit der Frage:
Existiert der erwartete (*,G)- oder (S,G)-Zustand auf dem betroffenen Router?
Der Rendezvous Point im Detail
Im vorherigen Abschnitt wurde der Rendezvous Point zunächst als zentraler Treffpunkt für Quellen und Empfänger eingeführt. Für ein grundlegendes Verständnis ist diese Betrachtung ausreichend. In produktiven Netzen spielt der RP jedoch eine wesentlich größere Rolle, da die gesamte PIM-Sparse-Mode-Architektur von seiner Erreichbarkeit und korrekten Funktion abhängt.
Um moderne Multicast-Netzwerke zu verstehen, müssen wir daher genauer betrachten, wie ein RP ausgewählt wird, wie Router von seiner Existenz erfahren und welche Mechanismen für Hochverfügbarkeit eingesetzt werden.
Warum benötigt PIM Sparse Mode einen RP?
Das grundlegende Problem besteht darin, dass Quellen und Empfänger zunächst nichts voneinander wissen.
Ein Empfänger kann einer Gruppe beitreten, obwohl noch keine Quelle sendet.
Ebenso kann eine Quelle bereits senden, obwohl noch keine Empfänger existieren.
Der RP löst dieses Problem, indem er als gemeinsamer Referenzpunkt fungiert.
Jeder Router im PIM-Domain muss wissen:
Für welche Multicast-Gruppen ist welcher RP zuständig?
Sobald diese Information vorhanden ist, können sowohl Quellen als auch Empfänger unabhängig voneinander Zustände aufbauen.
RP-Mapping
Die Zuordnung zwischen Multicast-Gruppen und Rendezvous Points wird als RP-Mapping bezeichnet.
Ein Router benötigt diese Zuordnung immer dann, wenn er einen neuen (*,G)-Zustand erzeugen muss.
Nehmen wir an, ein Host tritt der Gruppe 239.1.1.1 bei.
Der Last-Hop-Router fragt nun intern:
Welcher RP ist für diese Gruppe zuständig?
Erst danach kann er den Join-Prozess starten.
In kleinen Netzwerken existiert häufig nur ein einziger RP für sämtliche Gruppen.
Größere Umgebungen verwenden dagegen mehrere RPs, die unterschiedliche Gruppenbereiche verwalten.
Ein Beispiel könnte sein:
239.1.0.0/16 → RP 10.10.10.10
239.2.0.0/16 → RP 10.20.20.20
239.3.0.0/16 → RP 10.30.30.30
Dadurch lassen sich Last und Zustände auf mehrere Systeme verteilen.
Statische RP-Konfiguration
Die einfachste Variante besteht darin, den RP auf jedem Router manuell zu konfigurieren.
In Junos erfolgt dies beispielsweise über:
protocols {
pim {
rp {
static {
address 10.10.10.10;
}
}
}
}
Jeder Router kennt dadurch denselben RP.
Diese Methode ist leicht verständlich und eignet sich hervorragend für Labore, Testumgebungen und kleinere Netzwerke.
Allerdings entstehen Skalierungsprobleme.
Jede Änderung des RP erfordert Anpassungen auf sämtlichen Routern der Multicast-Domain.
In größeren Umgebungen ist dies kaum praktikabel.
Dynamische RP-Verteilung
Um dieses Problem zu lösen, wurden Verfahren entwickelt, die RP-Informationen automatisch innerhalb der PIM-Domain verteilen.
Historisch existieren dafür zwei Verfahren:
- Auto-RP
- Bootstrap Router (BSR)
Während Auto-RP ursprünglich von Cisco entwickelt wurde, ist BSR als offener Standard definiert und wird von Junos unterstützt.
In modernen Umgebungen wird nahezu ausschließlich BSR verwendet.
Bootstrap Router (BSR)
Der Bootstrap Router dient als zentrale Verteilstelle für RP-Informationen.
Mehrere Router können sich als Candidate RPs registrieren.
Der BSR sammelt diese Informationen und verteilt sie anschließend an alle Router innerhalb der PIM-Domain.
Der Ablauf sieht vereinfacht wie folgt aus:
Zunächst melden Candidate-RPs ihre Gruppenbereiche beim BSR an.
Der BSR erstellt daraus eine RP-Datenbank.
Anschließend verteilt er diese Datenbank mittels Bootstrap Messages an sämtliche PIM-Router.
Jeder Router besitzt dadurch eine identische Sicht auf die RP-Zuordnung.
Der eigentliche RP bleibt dabei weiterhin für die Multicast-Gruppen zuständig. Der BSR übernimmt lediglich die Verteilung der Informationen.
Candidate RPs
Ein Router wird nicht automatisch Rendezvous Point.
Stattdessen wird er als Candidate RP konfiguriert.
Beispielsweise könnte Router A für den Bereich 239.1.0.0/16 zuständig sein.
Router B könnte denselben Bereich mit niedrigerer Priorität anbieten.
Der BSR entscheidet anschließend anhand definierter Kriterien, welcher RP für eine bestimmte Gruppe verwendet wird.
Dadurch entstehen bereits grundlegende Redundanzmechanismen.
RP-Lookup in der Praxis
Wenn ein neuer IGMP Join eintrifft, läuft intern ungefähr folgender Prozess ab:
- Der Router erkennt eine neue Gruppe.
- Er sucht die Gruppe in seiner RP-Datenbank.
- Der zuständige RP wird ermittelt.
- Ein (*,G)-Join wird in Richtung RP erzeugt.
- Entlang des Pfades entstehen neue Shared-Tree-Zustände.
Dieser Ablauf geschieht vollständig automatisch.
Für den Administrator sichtbar werden lediglich die resultierenden (*,G)-Einträge in der Multicast-Routing-Tabelle.
Die Schwäche eines einzelnen RP
Bis jetzt haben wir immer von einem einzigen RP gesprochen.
Ein einzelner RP stellt jedoch einen potenziellen Single Point of Failure dar.
Betrachten wir folgendes Szenario:
RP
|
----------------
| |
Quelle Empfänger
Fällt der RP aus, können bestehende Source Trees häufig weiterhin Daten transportieren.
Neue Gruppenbeitritte funktionieren jedoch nicht mehr.
Ebenso können neue Quellen nicht registriert werden.
Die gesamte Control Plane des Multicast-Netzwerks wird beeinträchtigt.
Für produktive Umgebungen genügt dies nicht.
Daher wurden verschiedene Hochverfügbarkeitsmechanismen entwickelt.
Anycast RP
Die heute am häufigsten eingesetzte Lösung ist Anycast RP.
Die Grundidee besteht darin, mehrere physische Router als denselben logischen Rendezvous Point auftreten zu lassen.
Mehrere Router erhalten dieselbe RP-Adresse.
Beispielsweise:
RP-Adresse:
10.10.10.10
Diese Adresse existiert gleichzeitig auf:
Router A
Router B
Router C
Über das Unicast-Routing entscheidet das Netzwerk automatisch, welcher dieser Router aus Sicht eines Clients am nächsten liegt.
Deshalb spricht man von Anycast.
Warum funktioniert das nicht allein?
Auf den ersten Blick scheint dies ausreichend zu sein.
In Wirklichkeit entsteht jedoch ein Problem.
Quellen und Empfänger können unterschiedliche RP-Instanzen erreichen.
Betrachten wir folgendes Beispiel:
Quelle → RP-A
Empfänger → RP-B
RP-A kennt die Quelle.
RP-B kennt den Empfänger.
Keiner der beiden kennt jedoch die Zustände des anderen.
Die Kommunikation würde scheitern.
Deshalb benötigen die Anycast-RPs einen zusätzlichen Synchronisationsmechanismus.
Anycast RP mit MSDP
Historisch wurde hierfür das Multicast Source Discovery Protocol (MSDP) entwickelt.
MSDP tauscht Informationen über aktive Quellen zwischen den verschiedenen RP-Instanzen aus.
Wenn eine Quelle an RP-A registriert wird, informiert MSDP die übrigen Anycast-RPs über diese Quelle.
RP-B erfährt dadurch ebenfalls von:
(192.0.2.10,239.1.1.1)
und kann die Empfänger korrekt bedienen.
Dadurch erscheint die Gruppe aus Sicht der PIM-Domain konsistent.
MSDP war über viele Jahre der De-facto-Standard für Anycast-RP-Deployments.
Anycast RP mit PIM
Moderne Implementierungen verwenden häufig ein vereinfachtes Verfahren.
Statt eines separaten MSDP-Protokolls können die Anycast-RPs spezielle PIM-Mechanismen zur Zustandsverteilung nutzen.
Die Grundidee bleibt identisch:
Alle RP-Instanzen müssen dieselben Quelleninformationen kennen.
Junos unterstützt sowohl klassische als auch moderne Anycast-RP-Architekturen, wobei die konkrete Implementierung von Plattform und Softwareversion abhängt.
Für heutige Enterprise- und Service-Provider-Netze wird meist ein PIM-basierter Ansatz bevorzugt.
Anycast RP in Junos
Konzeptionell besteht eine Anycast-RP-Lösung in Junos aus drei Komponenten:
Erstens benötigen alle RP-Instanzen dieselbe RP-Adresse.
Zweitens muss diese Adresse über das Unicast-Routing erreichbar sein.
Drittens muss ein Mechanismus zur Quellensynchronisation konfiguriert werden.
Bei der Fehlersuche sind dabei typischerweise drei Fragen entscheidend:
- Wird die Anycast-Adresse korrekt geroutet?
- Erreichen Register-Nachrichten den erwarteten RP?
- Werden Quelleninformationen zwischen den RP-Instanzen ausgetauscht?
Viele vermeintliche PIM-Probleme lassen sich letztlich auf einen dieser drei Punkte zurückführen.
Der Übergang zu Source Specific Multicast
Bis hierhin basiert die gesamte Architektur auf dem klassischen Any-Source-Multicast-Modell.
Dieses Modell besitzt jedoch inhärente Komplexität:
- Rendezvous Points müssen betrieben werden.
- RP-Mappings müssen verteilt werden.
- Quellen müssen registriert werden.
- Anycast-RP-Mechanismen erhöhen die Komplexität weiter.
- Zusätzliche Zustände entstehen durch Shared Trees.
Mit der zunehmenden Verbreitung großer Streaming- und IPTV-Plattformen entstand daher der Wunsch nach einem einfacheren Modell.
Anstatt zu sagen:
Ich möchte Daten für Gruppe G erhalten.
sollte ein Empfänger direkt sagen können:
Ich möchte Daten von Quelle S für Gruppe G erhalten.
Genau dieses Modell implementiert Source Specific Multicast (SSM).
SSM entfernt den Rendezvous Point vollständig aus der Architektur und reduziert viele der bisher behandelten Mechanismen auf einen wesentlich einfacheren (S,G)-basierten Betrieb. Für moderne Multicast-Netzwerke ist dies heute oft die bevorzugte Betriebsform und bildet den nächsten logischen Schritt unserer Betrachtung.
Source Specific Multicast (SSM)
Nachdem wir die vollständige Architektur von Any-Source Multicast (ASM) betrachtet haben, wird deutlich, warum viele moderne Netzwerke heute bevorzugt auf Source Specific Multicast setzen.
ASM wurde zu einer Zeit entwickelt, in der Multicast als universelle Gruppenkommunikation betrachtet wurde. Das Modell sollte beliebige Quellen und beliebige Empfänger unterstützen. Teilnehmer konnten einer Gruppe beitreten, ohne die Quelle zu kennen. Das Netzwerk übernahm die Aufgabe, Quellen und Empfänger zusammenzuführen.
Dieses Konzept ist flexibel, erzeugt aber erhebliche Komplexität:
Es werden Rendezvous Points benötigt.
RP-Mappings müssen verteilt werden.
Quellen müssen registriert werden.
Shared Trees müssen aufgebaut werden.
Anycast-RP-Mechanismen erhöhen die Komplexität weiter.
Für viele moderne Anwendungen ist diese Flexibilität jedoch gar nicht erforderlich.
Bei IPTV, Live-Streaming oder Marktdatenfeeds kennt der Empfänger die Quelle typischerweise bereits. Er möchte exakt einen bestimmten Datenstrom empfangen und nicht beliebige Sender innerhalb einer Gruppe.
Damit stellt sich die Frage:
Warum überhaupt einen Rendezvous Point verwenden?
Genau hier setzt Source Specific Multicast an.
Das Grundprinzip von SSM
Beim klassischen ASM meldet ein Empfänger Interesse an einer Gruppe an:
(*,G)
Beispielsweise:
(*,239.1.1.1)
Das Netzwerk muss anschließend herausfinden, welche Quellen für diese Gruppe existieren.
SSM dreht dieses Modell um.
Der Empfänger fordert direkt einen bestimmten Datenstrom an:
(S,G)
Beispielsweise:
(192.0.2.10,232.1.1.1)
Der Router kennt damit von Beginn an:
- die gewünschte Quelle
- die gewünschte Gruppe
Ein Rendezvous Point wird nicht mehr benötigt.
Ebenso entfallen Shared Trees vollständig.
Das Netzwerk baut unmittelbar einen Shortest Path Tree zur Quelle auf.
Warum SSM den Bereich 232.0.0.0/8 verwendet
Wie bereits bei der Multicast-Adressierung erwähnt, wurde der Bereich 232.0.0.0/8 exklusiv für SSM reserviert.
Diese Trennung ermöglicht eine eindeutige Interpretation der Gruppe.
Sobald ein Router eine Adresse aus diesem Bereich verarbeitet, weiß er:
Diese Gruppe verwendet das SSM-Modell.
Es existiert kein RP.
Es existieren keine (*,G)-Zustände.
Es werden ausschließlich (S,G)-Einträge aufgebaut.
Die Architektur wird dadurch erheblich vereinfacht.
IGMPv3 als Voraussetzung
Ein wesentlicher Unterschied zwischen ASM und SSM besteht darin, dass der Router die gewünschte Quelle kennen muss.
IGMPv2 kann lediglich Gruppenmitgliedschaften signalisieren.
Ein Host kann mitteilen:
Ich möchte Gruppe G empfangen.
Er kann jedoch nicht ausdrücken:
Ich möchte Quelle S für Gruppe G empfangen.
Diese Fähigkeit wurde erst mit IGMPv3 eingeführt.
Deshalb setzt SSM zwingend IGMPv3 voraus.
Ein typischer Membership Report enthält dabei sowohl Gruppen- als auch Quelleninformationen.
Der Last-Hop-Router kann daraus unmittelbar einen (S,G)-Zustand ableiten.
Der Aufbau eines SSM-Datenpfades
Der Ablauf ist deutlich einfacher als bei ASM.
Ein Empfänger fordert an:
(192.0.2.10,232.1.1.1)
Der Last-Hop-Router erzeugt sofort einen entsprechenden (S,G)-Eintrag.
Anschließend wird ein PIM Join direkt in Richtung der Quelle gesendet.
Dabei kommt erneut die normale RPF-Logik zum Einsatz.
Jeder Router entlang des Pfades erzeugt weitere (S,G)-Einträge.
Nach kurzer Zeit existiert ein vollständiger Source Tree.
Der Datenstrom kann unmittelbar fließen.
Es gibt:
- keinen RP
- keine Register-Nachrichten
- keine Shared Trees
- keine SPT-Umschaltung
Der gesamte Aufbau erfolgt in einem einzigen Schritt.
Vergleich zwischen ASM und SSM
Betrachten wir beide Verfahren aus Sicht des Netzwerks.
Beim ASM-Modell entsteht zunächst:
(*,G)
Danach:
(S,G)
Anschließend erfolgt der Übergang vom Shared Tree zum Source Tree.
Bei SSM entsteht dagegen unmittelbar:
(S,G)
Der erste Baum ist gleichzeitig der optimale Baum.
Viele Zwischenschritte entfallen vollständig.
Sicherheitsvorteile von SSM
Ein weiterer Vorteil wird häufig übersehen.
Beim ASM-Modell kann grundsätzlich jede Quelle Daten für eine Gruppe senden.
Das Netzwerk muss anschließend entscheiden, welche Quellen akzeptiert werden.
SSM eliminiert dieses Problem.
Der Empfänger definiert explizit die gewünschte Quelle.
Daten anderer Sender werden verworfen.
Dies reduziert sowohl die Angriffsfläche als auch die Wahrscheinlichkeit unerwarteter Datenströme.
Gerade in Provider- und Finanznetzwerken ist dies ein wichtiger Aspekt.
Skalierungsvorteile
In großen Netzen können Shared Trees und RP-Infrastrukturen erhebliche Mengen an Zuständen erzeugen.
Jeder RP muss:
- Gruppen verwalten
- Quellen registrieren
- Zustände replizieren
- Anycast-Mechanismen unterstützen
SSM beseitigt diesen gesamten Komplex.
Die Router verwalten ausschließlich die tatsächlich benötigten (S,G)-Einträge.
Dadurch sinkt die Belastung der Control Plane erheblich.
Aus diesem Grund setzen viele moderne IPTV-Plattformen nahezu ausschließlich auf SSM.
PIM im SSM-Betrieb
Ein häufiger Irrtum besteht darin anzunehmen, SSM würde PIM ersetzen.
Das ist nicht der Fall.
PIM bleibt weiterhin das Routingprotokoll.
Lediglich die RP-Funktionalität entfällt.
Die Router tauschen weiterhin:
- Hello-Nachrichten
- Join-Nachrichten
- Prune-Nachrichten
aus.
Der Unterschied besteht darin, dass sämtliche Zustände direkt als (S,G) aufgebaut werden.
PIM Sparse Mode bleibt also erhalten, allerdings ohne Rendezvous Point.
SSM in Junos
In Junos wird SSM typischerweise über einen definierten Gruppenbereich aktiviert.
Ein vereinfachtes Beispiel könnte folgendermaßen aussehen:
routing-options {
multicast {
ssm-groups {
232.0.0.0/8;
}
}
}
Zusätzlich muss auf den Empfängersegmenten IGMPv3 verwendet werden.
Erst dadurch können die erforderlichen Quelleninformationen übertragen werden.
PIM selbst bleibt auf den Transitinterfaces aktiviert.
Der Unterschied liegt ausschließlich in der Behandlung der Gruppen.
Für SSM-Gruppen wird kein RP-Lookup durchgeführt.
Zustände in der Multicast-Tabelle
Ein interessanter Unterschied zeigt sich in der Ausgabe der Multicast-Routing-Tabelle.
Ein ASM-Netzwerk enthält typischerweise sowohl:
(*,239.1.1.1)
als auch:
(192.0.2.10,239.1.1.1)
In einem reinen SSM-Deployment findet man dagegen ausschließlich:
(192.0.2.10,232.1.1.1)
Das Fehlen von (*,G)-Einträgen ist häufig ein guter Indikator dafür, dass ein Datenstrom tatsächlich über SSM betrieben wird.
Wann verwendet man ASM und wann SSM?
ASM bleibt sinnvoll, wenn Empfänger die Quelle nicht kennen oder mehrere Quellen dieselbe Gruppe nutzen können.
Typische Beispiele sind bestimmte Kollaborationsanwendungen oder ältere Multicast-Anwendungen.
SSM eignet sich dagegen hervorragend für:
- IPTV
- Live-Streaming
- Finanzmarktdaten
- Telemetrie-Plattformen
- Video-Distribution
- Mediennetzwerke
Kurz gesagt:
Immer dann, wenn der Empfänger die Quelle kennt, ist SSM meist die bessere Wahl.
Die Multicast Forwarding Information Base (MFIB)
Bislang haben wir vor allem über Protokolle gesprochen:
- IGMP
- PIM
- RP
- SSM
Diese Protokolle erzeugen jedoch letztlich nur Zustände.
Die eigentliche Paketweiterleitung erfolgt über spezielle Datenstrukturen innerhalb des Routers.
Für das Verständnis von Junos und insbesondere für JNCIS- sowie JNCIP-Kandidaten ist dieser Punkt entscheidend.
Denn die wichtigste Frage bei jeder Fehlersuche lautet letztlich:
Welche Zustände wurden tatsächlich in die Forwarding Plane programmiert?
Die Multicast Forwarding Information Base (MFIB)
Bisher haben wir uns hauptsächlich mit der Control Plane beschäftigt. IGMP meldet Empfänger an, PIM erzeugt Verteilbäume und der Rendezvous Point vermittelt zwischen Quellen und Empfängern.
Keines dieser Protokolle leitet jedoch tatsächlich Pakete weiter.
Wie im Unicast-Routing existiert auch im Multicast eine klare Trennung zwischen Control Plane und Forwarding Plane.
Die Protokolle erzeugen Zustände.
Die eigentliche Weiterleitung erfolgt anschließend in der Datenebene des Routers.
Gerade für Juniper-Zertifizierungen ab JNCIS-SP und spätestens auf JNCIP-Niveau wird dieses Konzept wichtig, denn viele Multicast-Probleme entstehen nicht beim Aufbau der Zustände, sondern bei deren Umsetzung in die Forwarding Plane.
Von der Routing Information zur Paketweiterleitung
Betrachten wir zunächst den bekannten Unicast-Fall.
OSPF, IS-IS oder BGP erzeugen Routen in der Routing Information Base (RIB).
Aus der RIB werden die besten Routen ausgewählt und anschließend in die Forwarding Information Base (FIB) installiert.
Die Packet Forwarding Engine (PFE) nutzt ausschließlich die FIB.
Dasselbe Prinzip existiert auch für Multicast.
PIM und IGMP erzeugen Zustände in der Routing Engine.
Diese werden anschließend in spezielle Multicast-Forwarding-Strukturen übertragen.
Erst dort entsteht die tatsächliche Weiterleitungslogik.
Die drei Sichten auf Multicast
Aus Sicht eines Junos-Routers existieren vereinfacht drei Ebenen.
Die erste Ebene beschreibt die Unicast-Erreichbarkeit.
Hier befinden sich OSPF-, IS-IS- oder BGP-Routen, die später für RPF-Entscheidungen verwendet werden.
Die zweite Ebene umfasst die Multicast-Control-Plane.
Hier entstehen die bekannten (*,G)- und (S,G)-Zustände.
Die dritte Ebene bildet die eigentliche Forwarding Plane.
Hier wird festgelegt:
- auf welchem Interface Pakete erwartet werden
- auf welchen Interfaces Pakete repliziert werden
- welche RPF-Prüfungen durchgeführt werden
Nur diese Ebene verarbeitet tatsächlich Datenpakete.
Incoming Interface (IIF)
Jeder Multicast-Eintrag besitzt genau ein Incoming Interface.
Dieses Interface ergibt sich aus dem RPF-Lookup zur Quelle.
Nehmen wir folgenden Zustand an:
(192.0.2.10,239.1.1.1)
Die Unicast-Routing-Tabelle ergibt:
192.0.2.10 erreichbar über ae0.0
Daraus folgt:
Incoming Interface:
ae0.0
Pakete dieser Quelle dürfen ausschließlich über ae0.0 eintreffen.
Erscheinen sie auf einem anderen Interface, schlägt der RPF-Check fehl.
Das Paket wird verworfen.
Dieser Mechanismus verhindert Routing-Schleifen und stellt sicher, dass Multicast-Bäume konsistent bleiben.
Outgoing Interface List (OIL)
Während ein Multicast-Eintrag nur ein einziges Incoming Interface besitzt, kann er beliebig viele Outgoing Interfaces enthalten.
Diese Liste wird als Outgoing Interface List oder OIL bezeichnet.
Beispiel:
Incoming:
ae0.0
Outgoing:
irb.10
irb.20
ae1.0
Trifft ein Paket über ae0.0 ein, repliziert die PFE das Paket auf sämtliche Interfaces der OIL.
Genau hier liegt die eigentliche Stärke von Multicast.
Die Quelle sendet nur ein einziges Paket.
Die Replikation erfolgt erst dort, wo sich der Verteilbaum verzweigt.
Paketreplikation in der Forwarding Plane
Ein häufiger Irrtum besteht darin anzunehmen, dass die Routing Engine jedes Paket mehrfach kopiert.
Das wäre bei hohen Bandbreiten unmöglich.
In modernen Juniper-Plattformen erfolgt die Replikation vollständig innerhalb der Packet Forwarding Engine.
Die Routing Engine erzeugt lediglich die notwendigen Zustände.
Die eigentliche Vervielfältigung übernimmt die Hardware.
Dadurch können selbst große IPTV- oder Streaming-Plattformen betrieben werden, ohne die Routing Engine zu belasten.
Dieser Unterschied ist insbesondere bei MX-Plattformen von zentraler Bedeutung.
Beispiel eines Verteilbaums
Betrachten wir einen Router mit drei Empfängersegmenten.
Quelle
|
ae0
|
Router
/ | \
irb10 irb20 ae1
Die MFIB enthält:
(S,G)
IIF:
ae0.0
OIL:
irb.10
irb.20
ae1.0
Für jedes eintreffende Multicast-Paket erzeugt die Hardware drei Kopien.
Die Quelle selbst bemerkt davon nichts.
Sie sendet weiterhin lediglich einen einzelnen Datenstrom.
Warum Multicast skalieren kann
Genau dieses Replikationsmodell macht Multicast interessant.
Betrachten wir einen Stream mit 10 Mbit/s.
Bei 1.000 Empfängern würde Unicast erzeugen:
10 Mbit/s × 1000
= 10 Gbit/s
Multicast transportiert dagegen entlang gemeinsamer Pfade weiterhin lediglich:
10 Mbit/s
Erst an den Verzweigungspunkten entstehen zusätzliche Kopien.
Je größer die Empfängergruppen werden, desto stärker wirkt dieser Skalierungsvorteil.
RPF-Checks in der Praxis
Viele Multicast-Störungen lassen sich auf fehlgeschlagene RPF-Checks zurückführen.
Nehmen wir folgendes Beispiel:
Quelle:
192.0.2.10
RPF Interface:
ae0.0
Ein Paket trifft jedoch über:
ae1.0
ein.
Der Router verwirft das Paket sofort.
Aus Sicht des Routers könnte es sich um einen Schleifenpfad handeln.
Dieses Verhalten ist vollständig unabhängig davon, ob die Daten ansonsten korrekt wären.
Bei nahezu jeder Multicast-Fehlersuche gehört daher die Überprüfung des RPF-Pfades zu den ersten Schritten.
RPF und Unicast-Routing
Eine weitere wichtige Erkenntnis lautet:
Multicast besitzt keine eigene Topologieberechnung.
PIM berechnet keine Wege.
PIM nutzt ausschließlich die Ergebnisse des Unicast-Routings.
Wenn OSPF oder IS-IS einen anderen Pfad auswählen, verändert sich automatisch auch der RPF-Pfad.
Dadurch sind Unicast- und Multicast-Routing unmittelbar miteinander verknüpft.
In vielen Betriebsumgebungen werden Multicast-Probleme letztlich durch Fehler im Unicast-Routing verursacht.
Die Rolle der Packet Forwarding Engine
Gerade bei Juniper-Plattformen lohnt sich ein kurzer Blick auf die Architektur.
Die Routing Engine ist verantwortlich für:
- IGMP
- PIM
- RP-Funktionen
- Zustandsverwaltung
Die Packet Forwarding Engine übernimmt:
- RPF-Prüfungen
- Paketreplikation
- Interface-Selektion
- Datenweiterleitung
Diese Trennung ermöglicht hohe Skalierbarkeit.
Selbst wenn Millionen von Paketen pro Sekunde verarbeitet werden, bleibt die Routing Engine weitgehend unbeeinflusst.
Multicast-Zustände in Junos
Die wichtigste operative Sicht bietet:
show multicast route
Hier erscheinen die bekannten (*,G)- und (S,G)-Einträge.
Für jeden Zustand können typischerweise folgende Informationen betrachtet werden:
- Quelle
- Gruppe
- Incoming Interface
- Outgoing Interface List
- Upstream Neighbor
- Alter des Zustands
Diese Ausgabe bildet die Grundlage nahezu jeder Multicast-Fehlersuche.
Ein erfahrener Multicast-Administrator beginnt selten mit Paketmitschnitten.
Er beginnt meist mit der Frage:
Existiert der erwartete Zustand?
Danach folgt:
Ist das Incoming Interface korrekt?
Und schließlich:
Befinden sich die erwarteten Interfaces in der OIL?
Multicast in der Praxis eines Service Providers
In Provider-Netzen können problemlos hunderttausende oder sogar Millionen von Multicast-Zuständen entstehen.
Besonders IPTV-Plattformen erzeugen große Mengen an (S,G)-Einträgen.
Daher spielen Skalierungsmechanismen eine wichtige Rolle:
- effiziente Hardware-Replikation
- optimierte State-Verwaltung
- kontrollierte SPT-Umschaltung
- RP-Redundanz
- SSM-Einsatz
Viele Designentscheidungen moderner Multicast-Netze dienen letztlich dem Ziel, die Anzahl der Zustände und die Belastung der Control Plane zu reduzieren.
Troubleshooting-Denkmodell
Bevor wir uns den konkreten Diagnosewerkzeugen widmen, lohnt sich ein mentales Modell.
Jedes Multicast-Problem lässt sich normalerweise einer von vier Ebenen zuordnen:
- Empfänger meldet sich nicht an (IGMP).
- Verteilbaum wird nicht aufgebaut (PIM).
- RPF-Pfad ist fehlerhaft (Unicast Routing).
- Zustand wird nicht korrekt weitergeleitet (MFIB/PFE).
Wer diese Reihenfolge konsequent verfolgt, kann die meisten Multicast-Probleme sehr schnell eingrenzen.
Troubleshooting von Multicast in Junos
Multicast gehört zu den Technologien, die auf den ersten Blick komplex wirken, sich bei systematischer Analyse jedoch meist sehr logisch verhalten.
Im Gegensatz zu vielen Unicast-Problemen existieren bei Multicast nur wenige fundamentale Mechanismen:
- Empfänger müssen Interesse anmelden.
- Verteilbäume müssen aufgebaut werden.
- Die Quelle muss über den erwarteten RPF-Pfad erreichbar sein.
- Die Forwarding Plane muss Pakete replizieren können.
Fast jede Störung lässt sich auf einen dieser Bereiche zurückführen.
Für die Praxis ist daher weniger die Anzahl der Kommandos entscheidend als vielmehr eine strukturierte Vorgehensweise.
Das wichtigste Prinzip: Immer vom Empfänger aus denken
Viele Administratoren beginnen die Fehlersuche bei der Quelle.
In der Praxis führt dies häufig zu unnötiger Komplexität.
Der bessere Ansatz besteht darin, am Empfänger zu beginnen und sich anschließend schrittweise in Richtung Quelle vorzuarbeiten.
Der Grund ist einfach:
Wenn kein Empfänger existiert, wird überhaupt kein Multicast-Baum aufgebaut.
Deshalb lautet die erste Frage immer:
Existiert auf dem Last-Hop-Router überhaupt Interesse an der Gruppe?
Schritt 1: IGMP prüfen
Der erste Kontrollpunkt ist die lokale Gruppenmitgliedschaft.
Unter Junos liefert:
show igmp group
eine Übersicht aller bekannten Empfängergruppen.
Ein Beispiel könnte folgendermaßen aussehen:
Group: 239.1.1.1
Interface: irb.10
Fehlt die erwartete Gruppe, liegt das Problem meist außerhalb von PIM.
Mögliche Ursachen sind:
- Host sendet keinen IGMP Report
- IGMP Snooping blockiert die Mitgliedschaft
- Falsches VLAN
- IGMP nicht aktiviert
- Anwendung tritt der Gruppe nicht korrekt bei
Solange die Gruppe hier nicht sichtbar ist, lohnt sich die Analyse von PIM meist noch nicht.
Schritt 2: Existiert ein Multicast-Zustand?
Sobald die Gruppenmitgliedschaft sichtbar ist, muss geprüft werden, ob daraus ein Routing-Zustand entstanden ist.
Hierfür dient:
show multicast route
Bei ASM könnte beispielsweise erscheinen:
(*,239.1.1.1)
oder:
(192.0.2.10,239.1.1.1)
Bei SSM sollte unmittelbar ein (S,G)-Eintrag vorhanden sein.
Fehlt jeglicher Zustand, wurde der Join-Prozess nicht erfolgreich gestartet.
Dann liegt die Ursache meist in:
- fehlendem RP
- fehlerhaftem RP-Mapping
- fehlender PIM-Konfiguration
- ungültigem SSM-Design
Schritt 3: PIM-Nachbarn prüfen
Ohne PIM-Nachbarn können keine Join-Nachrichten transportiert werden.
Daher gehört folgender Befehl zu den wichtigsten Werkzeugen:
show pim neighbors
Typischerweise sollte jeder Transit-Link mindestens einen erwarteten Nachbarn anzeigen.
Fehlen Nachbarn, sind häufig folgende Ursachen verantwortlich:
- PIM nicht aktiviert
- Interface down
- Layer-2-Konnektivität fehlt
- Falsche Address Family
- Paketfilter blockieren PIM
Viele vermeintliche Multicast-Probleme sind letztlich einfache PIM-Adjazenzprobleme.
Schritt 4: Den Join-Pfad verfolgen
Wenn die Nachbarn existieren, muss geprüft werden, ob die Join-Nachrichten tatsächlich bis zur Quelle oder zum RP gelangen.
Hierbei helfen je nach Plattform und Junos-Version verschiedene Detailansichten.
Besonders interessant ist dabei:
- Upstream Neighbor
- Incoming Interface
- Join State
Ein funktionierender Join-Prozess sollte auf jedem Router entlang des Pfades sichtbar sein.
Findet man den letzten Router mit einem gültigen Zustand, lässt sich die Fehlerdomäne meist sehr schnell eingrenzen.
Die wichtigste Frage bei jedem (S,G)
Sobald ein (S,G)-Eintrag existiert, sollte immer folgende Frage gestellt werden:
Ist das Incoming Interface korrekt?
Beispielsweise:
(S,G)
Incoming Interface:
ae0.0
Nun muss geprüft werden:
Erwartet der Router die Quelle tatsächlich über ae0.0?
Diese Entscheidung basiert vollständig auf dem Unicast-Routing.
Deshalb sollte unmittelbar danach überprüft werden:
show route <Quellenadresse>
Ergibt die Route ein anderes Interface als der Multicast-Eintrag, liegt ein RPF-Problem vor.
RPF-Probleme erkennen
RPF-Probleme gehören zu den häufigsten Ursachen für Multicast-Störungen.
Ein klassisches Szenario sieht folgendermaßen aus:
Quelle
|
ae0
|
Router
|
Empfänger
Der Router erwartet die Quelle über ae0.
Durch eine Routing-Änderung treffen die Pakete jedoch über ae1 ein.
Die Folge:
RPF failed
Der Router verwirft sämtliche Pakete.
Für den Empfänger sieht dies identisch zu einem kompletten Ausfall der Quelle aus.
Tatsächlich handelt es sich jedoch lediglich um einen RPF-Konflikt.
Typische Ursachen für RPF-Fehler
In der Praxis treten RPF-Probleme häufig auf durch:
Asymmetrisches Routing.
Uneinheitliche IGP-Metriken.
Fehlerhafte ECMP-Implementierungen.
BGP-Änderungen.
Fehlende Routen zur Quelle.
Unvollständige Routing-Tabellen.
Gerade in großen Service-Provider-Netzen entstehen viele Multicast-Störungen letztlich durch Veränderungen im Unicast-Routing.
Troubleshooting von ASM
Bei ASM kommen zusätzliche Komponenten hinzu.
Neben Quelle und Empfänger existiert der Rendezvous Point.
Deshalb muss geprüft werden:
- Ist der RP erreichbar?
- Ist das RP-Mapping korrekt?
- Werden Register-Nachrichten verarbeitet?
- Existieren (*,G)-Zustände?
- Erfolgt die SPT-Umschaltung?
Eine sinnvolle Reihenfolge lautet:
Zunächst RP-Erreichbarkeit prüfen.
Anschließend die Shared-Tree-Zustände kontrollieren.
Danach die Quelle analysieren.
Erst zuletzt die SPT-Umschaltung betrachten.
Typisches ASM-Fehlerbild
Ein häufiges Szenario:
(*,G) vorhanden
(S,G) fehlt
Dies bedeutet oft:
Der Empfänger hat erfolgreich zum RP gejoint.
Die Quelle wurde jedoch nicht registriert.
Mögliche Ursachen:
- Register-Pakete erreichen den RP nicht
- RP kennt die Quelle nicht
- RPF-Problem auf dem Source Path
- Fehlerhafte Anycast-RP-Synchronisation
Der Fehler liegt dann meist näher an der Quelle als am Empfänger.
Troubleshooting von SSM
SSM ist häufig deutlich einfacher zu analysieren.
Da keine RP-Infrastruktur existiert, reduziert sich die Fehlersuche auf:
- IGMPv3
- PIM
- RPF
Die wichtigsten Fragen lauten:
Kennt der Router die gewünschte Quelle?
Existiert ein (S,G)-Eintrag?
Ist der RPF-Pfad korrekt?
Treffen Pakete über das erwartete Interface ein?
Dadurch lassen sich viele Fehler deutlich schneller eingrenzen als in ASM-Umgebungen.
Troubleshooting von Anycast RP
Anycast RP erzeugt eine zusätzliche Fehlerdimension.
Hier müssen drei Ebenen betrachtet werden:
Die Anycast-Adresse.
Die PIM-Funktion.
Die Synchronisation zwischen den RP-Instanzen.
Ein typisches Problem sieht beispielsweise so aus:
Quelle registriert sich an RP-A.
Empfänger nutzt RP-B.
Die Quelleninformationen werden jedoch nicht repliziert.
Die Folge:
Empfänger erhalten keinen Datenstrom.
Obwohl beide RPs grundsätzlich funktionieren.
In solchen Situationen müssen die Anycast-RP-Mechanismen selbst untersucht werden.
Die Bedeutung des Zustandsalters
Ein häufig übersehener Hinweis ist das Alter eines Zustands.
Viele Ausgaben enthalten Informationen wie:
Age: 00:00:12
oder:
Age: 03:14:51
Ein ständig zurückgesetzter Timer kann auf Flapping hinweisen.
Ein sehr alter Zustand kann dagegen zeigen, dass der Baum bereits lange stabil existiert.
Gerade bei intermittierenden Problemen liefert dieser Wert oft wichtige Hinweise.
Paketmitschnitte sinnvoll einsetzen
Viele Administratoren greifen sofort zu Paketmitschnitten.
Bei Multicast ist dies häufig nicht der effizienteste Ansatz.
Ein sinnvoller Ablauf lautet:
- IGMP prüfen.
- PIM prüfen.
- Multicast-Zustände prüfen.
- RPF prüfen.
- Erst danach Pakete analysieren.
Wenn die Zustände bereits fehlen, wird ein Mitschnitt selten neue Erkenntnisse liefern.
Anders formuliert:
Control Plane zuerst.
Data Plane danach.
Das mentale Modell eines erfahrenen Multicast-Engineers
Erfahrene Multicast-Spezialisten betrachten nahezu jedes Problem anhand derselben Kette:
IGMP
↓
PIM
↓
RPF
↓
MFIB
↓
Pakete
Sobald ein Glied der Kette fehlt, müssen die nachfolgenden Schritte nicht mehr untersucht werden.
Dieses Vorgehen reduziert die Komplexität erheblich und ermöglicht eine sehr zielgerichtete Analyse.
Fazit: Wie Multicast wirklich funktioniert
Nach unserer Reise durch die Multicast-Architektur lässt sich die gesamte Technologie auf wenige zentrale Prinzipien reduzieren.
Ein Empfänger signalisiert über IGMP sein Interesse an einer Gruppe.
PIM erzeugt daraus einen Verteilbaum.
RPF stellt sicher, dass Pakete über den korrekten Pfad eintreffen.
Die Multicast Forwarding Information Base definiert, auf welchen Interfaces repliziert werden muss.
Die Packet Forwarding Engine übernimmt schließlich die eigentliche Vervielfältigung der Pakete.
Alle weiteren Konzepte – Rendezvous Points, Shared Trees, Source Trees, Anycast RP oder SSM – sind letztlich Erweiterungen dieses Grundmodells.
Wer diese Zusammenhänge verstanden hat, besitzt bereits das Fundament für sämtliche Multicast-Themen von JNCIA über JNCIS bis hin zu JNCIP. Die eigentliche Herausforderung liegt anschließend nicht mehr im Verständnis einzelner Kommandos oder Protokollnachrichten, sondern darin, die Zustände entlang des Verteilbaums korrekt zu interpretieren und deren Auswirkungen auf die Forwarding Plane nachzuvollziehen. Genau dort trennt sich in der Praxis meist die reine Zertifizierungsvorbereitung vom tiefen technischen Verständnis moderner Multicast-Netzwerke.