JNCIP-ENT: Unicast‑ und Multicast‑Routing
29.06.2026 5 Min. Lesezeit
Unicast‑ und Multicast‑Routing werden oft getrennt betrachtet, obwohl sie im praktischen Betrieb untrennbar miteinander verknüpft sind. Besonders deutlich wird das im Zusammenspiel zwischen Multicast-Routing-Protokollen und dem zugrunde liegenden Unicast-Routing. Multicast berechnet keine eigene vollständige Topologie, sondern nutzt die Informationen, die bereits im Netzwerk vorhanden sind. Daraus entsteht eine Abhängigkeit, die häufig unterschätzt wird und viele Fehlerbilder erklärt.
Die Grundlage dieses Zusammenspiels ist die Tatsache, dass Multicast-Pfade nicht eigenständig bestimmt werden. Stattdessen orientieren sie sich an den bestehenden Unicast-Routen. Ein Router entscheidet beim Empfang eines Multicast-Pakets, ob es gültig ist, indem er überprüft, ob es über den erwarteten Weg eingetroffen ist. Dieser Mechanismus wird als Reverse Path Forwarding bezeichnet. Dabei wird nicht der Weg zum Ziel geprüft, sondern der hypothetische Rückweg zur Quelle. Kommt ein Paket nicht über das Interface an, das der Router selbst für den Weg zur Quelle nutzen würde, wird es verworfen.
Diese Logik ist überraschend einfach, aber enorm wirkungsvoll. Sie verhindert Schleifen und sorgt dafür, dass der Multicast-Verteilbaum konsistent bleibt. Gleichzeitig führt sie dazu, dass Multicast vollständig von der Korrektheit des Unicast-Routings abhängt. Wenn die Unicast-Routen falsch sind, inkonsistent oder unvollständig, wirkt sich das unmittelbar auf den Multicast-Verkehr aus. Ein Router kann dann Multicast-Pakete verwerfen, obwohl die eigentliche Multicast-Konfiguration korrekt ist.
Ein klassisches Beispiel dafür ist die asymmetrische Routing-Situation. Wenn der Weg von der Quelle zum Empfänger nicht identisch ist mit dem Weg zurück zur Quelle, kann der Reverse-Path-Check fehlschlagen. Für den Router sieht es so aus, als ob das Paket über einen „falschen“ Pfad empfangen wurde. Obwohl die physische Konnektivität gegeben ist, wird das Paket verworfen, weil es nicht den Erwartungen der Unicast-Topologie entspricht. Dieses Verhalten führt oft zu schwer nachvollziehbaren Fehlern, da die Ursache nicht in Multicast selbst liegt.
Ein weiterer kritischer Punkt ist die Wahl der besten Route im Unicast-Routing. Da Multicast sich direkt auf diese Information stützt, beeinflussen Änderungen in der Unicast-Topologie unmittelbar den Multicast-Baum. Wenn sich beispielsweise der bevorzugte Weg zu einer Quelle ändert, baut sich der Multicast-Baum entsprechend neu auf. Dieser Prozess ist nicht zentral gesteuert, sondern ergibt sich aus der lokalen Sicht jedes Routers. Kleine Inkonsistenzen können daher dazu führen, dass unterschiedliche Router unterschiedliche Annahmen über den optimalen Pfad treffen.
Die Rolle von Protokollen wie PIM besteht in diesem Zusammenhang nicht darin, selbst Routingentscheidungen zu treffen, sondern darin, die Verteilung der Zustandsinformationen zu koordinieren. PIM stellt sicher, dass Router wissen, welche Interfaces Teil eines Multicast-Baums sind und wohin Daten weitergeleitet werden müssen. Die Auswahl der Pfade selbst erfolgt jedoch indirekt über die Unicast-Routing-Information. Diese Trennung ist bewusst gewählt, da sie es erlaubt, Multicast unabhängig vom verwendeten IGP oder BGP zu betreiben.
In der Praxis führt diese Architektur zu einer klaren Diagnosemethodik. Wenn Multicast-Verkehr nicht wie erwartet funktioniert, liegt die Ursache häufig nicht im Multicast-Protokoll selbst, sondern im zugrunde liegenden Unicast-Routing. Ein fehlerhafter Eintrag in der Routing-Tabelle oder eine unerwartete Änderung im Routing-Protokoll kann dazu führen, dass der Reverse-Path-Check nicht mehr erfüllt ist. Der Router reagiert darauf deterministisch, indem er den Datenverkehr verwirft.
Ein weiteres Beispiel ist die Situation, in der mehrere mögliche Wege zur Quelle existieren. Obwohl das Netzwerk physisch redundant aufgebaut ist, wird im Multicast-Kontext nur der Pfad genutzt, der aus Sicht des Unicast-Routings als optimal gilt. Andere Pfade bleiben ungenutzt, selbst wenn sie technisch gleichwertig wären. Diese Einschränkung ist eine direkte Folge der Forwarding-Logik und unterscheidet sich deutlich vom Verhalten in Unicast-Netzen, in denen mehrere Pfade aktiv genutzt werden können.
Auch die Interaktion mit dynamischen Änderungen im Netzwerk ist ein wichtiger Aspekt. Wenn sich die Unicast-Topologie ändert, etwa durch einen Link-Ausfall oder eine Neubewertung von Kosten, wirkt sich dies sofort auf den Multicast-Verkehr aus. Der Verteilbaum wird angepasst, was zu kurzen Unterbrechungen oder Umlenkungen führen kann. Diese Effekte sind nicht das Ergebnis eines Fehlers, sondern Teil des normalen Betriebsverhaltens eines dynamischen Netzwerks.
Die Komplexität steigt weiter, wenn mehrere Routingprotokolle beteiligt sind. In Umgebungen, in denen beispielsweise OSPF und BGP parallel eingesetzt werden, hängt die Multicast-Forwarding-Entscheidung davon ab, welches Protokoll letztlich den Weg zur Quelle bestimmt. Die Präferenz und die Wechselwirkungen zwischen diesen Protokollen beeinflussen somit indirekt auch den Multicast-Verkehr. Eine Änderung in der Protokollpräferenz kann dazu führen, dass ein anderer Next-Hop gewählt wird, was wiederum den gesamten Multicast-Baum verschiebt.
Ein oft unterschätzter Punkt ist die Notwendigkeit einer konsistenten Sicht innerhalb des Netzwerks. Wenn verschiedene Router unterschiedliche Vorstellungen darüber haben, wie die beste Route zur Quelle aussieht, kann der Multicast-Baum fragmentiert werden. Einige Router akzeptieren den Verkehr, während andere ihn verwerfen. Dieses Verhalten ist besonders schwer zu erkennen, da es nicht unmittelbar sichtbar ist, sondern sich nur in Form von fehlenden Datenströmen äußert.
Die enge Kopplung zwischen Unicast- und Multicast-Routing bedeutet, dass die Stabilität und Konsistenz des gesamten Netzwerks entscheidend ist. Multicast verstärkt Probleme im Unicast-Routing, anstatt sie zu kaschieren. Gleichzeitig ermöglicht es eine sehr effiziente Datenverteilung, wenn die zugrunde liegende Struktur sauber aufgebaut ist.
Das Verständnis dieser Abhängigkeiten ist entscheidend, um Multicast nicht isoliert zu betrachten. Es genügt nicht, die Funktionsweise von PIM oder IGMP zu kennen. Erst im Zusammenspiel mit der Unicast-Topologie wird deutlich, warum Multicast sich in bestimmten Situationen so verhält, wie es tut. Wer diese Zusammenhänge berücksichtigt, kann Probleme deutlich schneller eingrenzen und vermeidet typische Fehlannahmen, bei denen die Ursache im falschen Teil des Systems gesucht wird.