Einführung
Wir haben über IP Multicast gesprochen. Diesen Monat fange ich an, den PIM Sparse Mode zu behandeln. Frühere Artikel, die von Interesse sein könnten:
- Die Protokolle von IP Multicast
- PIM Dense Mode
Sparse Versus Dense Mode
Erinnern Sie sich, dass PIM Dense Mode (im Prinzip) verwendet wird, wenn Multicast an den meisten Orten erwünscht ist. Die anfänglichen Multicast-Pakete werden also überall geflutet, wobei der Verkehr an Orten, die den Multicast-Feed nicht benötigen, durch Pruning abgeschnitten wird. Bis vor kurzem litt der PIM Dense Mode unter dem periodischen Re-Flooding alle 3 Minuten, aber in 12.1(5)T hat die Funktion PIM Dense Mode State Refresh dieses Problem gelöst. Mit dieser Funktion ist PIM Dense Mode wohl für eine einfache Implementierung von Multicast geeignet. Insbesondere dort, wo die zusätzliche Kontrolle von PIM Sparse Mode nicht benötigt wird und wo gelegentliches „versehentliches“ Flooding nicht sehr schädlich wäre.
PIM Sparse Mode verwendet einen expliziten Anfrageansatz, bei dem ein Router den Multicast-Feed mit einer PIM Join-Nachricht anfordern muss. PIM Sparse Mode ist angezeigt, wenn Sie eine genauere Kontrolle benötigen, insbesondere wenn Sie im Vergleich zu Ihrer Bandbreite große Mengen an IP-Multicast-Verkehr haben. Der PIM Sparse Mode lässt sich recht gut skalieren, da die Pakete nur dorthin gehen, wo sie benötigt werden, und weil er nur bei Bedarf einen Status in den Routern erzeugt. Aus diesem Grund wurde es als Internet-Experimental-Protokoll eingestuft.
Der Preis, den wir für diese zusätzliche Kontrolle zahlen, ist eine leichte zusätzliche Komplexität. PIM Sparse Mode verwendet einen speziellen Router, der als Rendezvous-Punkt (RP) bezeichnet wird, um die Flussquelle oder den Multicast-Baum mit dem Router neben dem gewünschten Empfänger zu verbinden. Der RP wird in der Regel nur vorübergehend verwendet, wie wir weiter unten sehen werden.
Es kann verschiedene RPs für verschiedene Multicast-Gruppen geben, was eine Möglichkeit ist, die Last zu verteilen. Normalerweise gibt es einen RP pro Multicast-Gruppe. Die Redundanz von RP’s ist ein fortgeschrittenes Thema und erfordert etwas mehr Fachwissen. Eine Möglichkeit, dies zu erreichen, ist das MSDP-Protokoll (möglicher späterer Artikel in dieser Reihe).
Erinnern Sie sich, dass eine PIM-Join-Nachricht an eine Quelle (oder bei PIM-SM möglicherweise an einen RP) gesendet wird, basierend auf Unicast-Routing. Die Join-Nachricht besagt: „Wir brauchen eine Kopie der Multicasts von hier“. Sie verbindet den Absender des Join und die zwischengeschalteten Router mit einem bestehenden Multicast-Baum, gegebenenfalls bis zurück zum Ziel des Join. Eine Prune-Nachricht besagt in der Tat „wir brauchen das hier nicht mehr“. Ein Router, der eine Prune-Nachricht empfängt, prüft, ob er andere Schnittstellen hat, die den Multicast-Fluss benötigen, und sendet, falls nicht, seine eigene Prune-Nachricht. Eine fortgeschrittene Technik besteht darin, eine separate und möglicherweise andere Kopie der Unicast-Routing-Informationen nur für Multicast-Zwecke zu erstellen. Dies ermöglicht eine „Lenkung“ der Join-Nachrichten. MultiProtocol BGP, MBGP, für Multicast ist eine Möglichkeit, dies zu tun (möglicher späterer Artikel in der Serie).
Grundlegender Rendezvous-Punkt (RP)
Wir haben bis jetzt gesehen, dass PIM-SM einen Rendezvous-Punkt (RP) verwendet, um Quelle und Empfänger zu verbinden. Es kann nur einen RP pro Multicast-Gruppe geben, und die einfachste Implementierung verwendet einen RP für alle Multicast-Gruppen.
Lassen Sie uns die Grundlagen der Verwendung des RP durchsprechen. Nehmen wir an, die Quelle beginnt zu senden, bevor es Empfänger gibt. Wenn die Dinge andersherum laufen, ändern sich einige Details leicht, aber es ist nicht sehr unterschiedlich.
So: die Multicast-Quelle beginnt zu senden. Wie wir bereits festgestellt haben, gibt es kein Protokoll oder ähnliches für die Registrierung von Quellen mit IP-Multicast. Die Quelle sendet, und es liegt an dem/den benachbarten Router(n), das Richtige zu tun. Bei PIM-SM weiß der benachbarte Router über den RP Bescheid. (Der benachbarte Router leitet die Multicast-Daten an den RP weiter, indem er sie in eine oder mehrere Unicast-Register-Nachrichten einkapselt. Normales Routing liefert das Register an den RP. Der RP entkapselt die Multicast-Nachricht und leitet Kopien an den Shared Tree weiter (ein solcher ist bereits vorhanden, wenn es Empfänger gibt, die bereits vor dem Sendebeginn der Quelle angeschlossen waren). Wenn es Empfänger gibt (ausgehende Schnittstellen im Shared-Tree-Zustand), sendet der RP einen PIM-Join zurück an die Quelle. Dies verbindet die Quelle mit dem RP mit einem Quellbaum, dem (S, G) Shortest Path Tree (SPT). Sobald der RP Multicasts entlang dieses SPT empfängt, sendet er einen Register-Stop, um dem Router der Quelle mitzuteilen, dass er keine Register-Pakete mehr senden soll. Der Grund für dieses Verhalten ist, dass keine Multicast-Pakete verloren gehen, wenn bereits Empfänger vorhanden sind.
Übrigens, wenn keine Empfänger vorhanden sind, wird die Register-Stop-Nachricht gesendet. Wenn dann später ein Empfänger auftaucht (IGMP an den Nachbarrouter, PIM Join vom Nachbarrouter zurück zum RP), dann sendet der RP zu diesem Zeitpunkt den PIM Join an die Quelle.
Die folgende Abbildung geht davon aus, dass es eine Quelle und aktive Empfänger (nicht dargestellt) gibt. Der dargestellte Empfänger sendet einen IGMP-Report an Router D. Router D sendet daraufhin einen PIM-Join an den RP. Da es weitere Empfänger gibt, ist der RP bereits in den Quellbaum eingebunden (blau dargestellt) und empfängt den Multicast-Datenstrom. Er leitet die Pakete des Source Tree Flow über den Shared Tree (grün dargestellt) weiter.
Nun haben wir die Pakete, die von der Quelle zum RP über den Source Tree (Shortest Path Tree, SPT) und vom RP zum Empfänger über den Shared Tree gehen. Wenn die aggregierte (*, G) Paketbitrate (von allen Quellen) einen Schwellenwert in Kbps überschreitet, löst dies den Router, der dem Empfänger am nächsten ist, dazu aus, zu versuchen, dem Quellbaum beizutreten. Er sendet einen Join in Richtung der Quelle des Multicast-Flusses. Beachten Sie, dass der vorherige Join an den RP gesendet wurde. Der Join in Richtung der Quelle geht Router für Router in Richtung der Quelle, bis er auf einen Router trifft, der bereits im Quellbaum ist. Dadurch wird der Router in der Nähe des Empfängers in den Quellbaum aufgenommen. Wenn ein Paket entlang dieses Baums tatsächlich empfangen wird, wird ein Prune an den RP gesendet. Das bedeutet: „Danke, aber ich bekomme meinen Multicast jetzt im Großhandel und nicht im Einzelhandel“, da dieser Prozess den RP in der Mitte ausschließt.
Die folgende Abbildung zeigt, wie dies funktioniert. Die roten Pfeile oben links zeigen den Join zur Quelle. Dadurch wird der obere blaue Fluss in Gang gesetzt, die Pakete werden entlang des Source Tree weitergeleitet. Die unteren rechten roten Pfeile sind dann die Prunes, da der Shared Tree Flow nicht mehr benötigt wird (dargestellt als grüne gestrichelte Linie). Beachten Sie, dass die Quellbaum-Pakete auf einem direkteren Weg beim Empfänger ankommen, im Allgemeinen mit einer geringeren Latenzzeit.
Übrigens kontrollieren wir den Schwellenwert. Er ist konfigurierbar. Die Voreinstellung ist null Kbps: ein Paket wird empfangen, und es wird auf Source Tree umgeschaltet. Wenn wir viele Quellen für eine bestimmte Multicast-Gruppe haben (z. B. Konferenzschaltung, VoIP), dann gibt es für jede einen (S, G)-Quellbaumeintrag. Wenn wir den Schwellenwert so einstellen, dass er nie aktiviert wird, dann gehen alle Pakete durch den RP (eine Art Konferenzschaltung) und benutzen nur den (*, G) Shared Tree. Der Schwellenwert wird auch für den Switchback und den Switchover verwendet. Quellbäume mit niedriger Rate (S, G) werden auf den gemeinsamen Baum zurückgeschaltet. Das Verkehrsaufkommen wird jede Minute überprüft.
Wenn ein Empfänger beitreten möchte und sein Nachbarrouter im SPT (Source Tree) ist, dann wird der Shared-Tree-Eintrag der ausgehenden Schnittstelle in den Source-Tree-Eintrag kopiert, was davor schützt, Verkehr zum RP und dann „zurück“ zum Router im SPT schicken zu müssen.
Sie werden sich übrigens fragen, wozu es hier den RP gibt? Wegen des Schwellenwert-Mechanismus gibt uns der RP eine Möglichkeit, den Shared Tree zu verwenden und die explosive Erstellung von Zustandsinformationen in Routern zu kontrollieren, wenn viele Empfänger gleichzeitig beitreten.
Shared Versus Source Trees
PIM Sparse Mode (PIM-SM) kann sowohl Shared Trees (über den RP) als auch Source Trees (für eine effiziente direkte Zustellung entlang des „kürzesten“ Pfades von der Quelle zum Empfänger) verwenden. In der Regel kann er beides verwenden. Wenn eine effiziente Zustellung für Sie weniger wichtig ist und die Verringerung der Menge an Zustandsinformationen, die von den Routern aufbewahrt werden, wichtiger ist, dann kann PIM so konfiguriert werden, dass nur ein Shared Tree verwendet wird.
Wenn ein PIM-SM-Router ein Multicast-Paket empfängt, prüft er den Source Tree für diese bestimmte Quelladresse und Multicast-Gruppe (Zieladresse). Wenn kein Eintrag vorhanden ist, sucht er nach einem Eintrag im Shared Tree (*, G) für die Multicast-Gruppe. Wenn Einträge für beide Bäume vorhanden sind, teilt die Eingangsschnittstelle dem Router mit, welcher Baum verwendet werden soll. Wenn beide Bäume die gleiche Eingangsschnittstelle haben, dann verhindert das RP-Bit für einen (S, G)-Eintrag doppelte Pakete: dies zeigt an, dass die RPF-Schnittstelle entlang des Gemeinsamen Baums liegt.
Für einen Multicast-Fluss mit mindestens einem aktiven Empfänger wird der Pfad zwischen der Quelle und dem RP Teil des Quellbaums sein. (Beachten Sie, dass „der Pfad zwischen“ hier etwas vage ist, ich versuche, nicht zu viele Details zu geben.)
Shared Tree-Einträge verbinden den RP mit einigen der Empfänger. Die RPF-Schnittstelle für den (*, G) Shared Tree ist die Schnittstelle in Richtung des RP, nicht die Multicast-Gruppenquelle. Deshalb besteht die Möglichkeit, dass der (S, G) Quellbaum und der (*, G) Gemeinsame Baum unterschiedliche RPF-Schnittstellen haben.
Die Einträge des Gemeinsamen Baums (*, G) zeigen Schnittstellen, an denen ein Join zum RP empfangen wurde, oder Schnittstellen mit direkt verbundenen Gruppenmitgliedern (konfiguriert oder IGMP empfangen). Die Source Tree (S, G) Einträge zeigen, wo ein Join oder ein Prune oder ein Register empfangen wurde.
PIM Sparse Mode konfigurieren
Der grundlegende Teil dessen, was man braucht, ist:
ip multicast-routing
interface ethernet 0
ip address 10.1.1.1 255.255.255.0
ip pim sparse-mode
interface ethernet 1
ip address 10.1.2.1 255.255.255.0
ip pim sparse-mode
Sie müssen auch jedem Router den RP mitteilen, entweder für alle Gruppen oder für ausgewählte Gruppen (unter Verwendung von Zugriffslisten, um anzugeben, welcher RP für welche Gruppen gilt). Dies kann statisch geschehen mit:
ip pim rp-address 1.2.3.4
Wir werden uns im nächsten Artikel die anderen Optionen für die Verwaltung von RP ansehen.
Schlussfolgerung
Nächsten Monat werden wir uns die verschiedenen Möglichkeiten der Arbeit mit Rendezvous-Punkten ansehen. Wir werden vielleicht auch ein paar andere fortgeschrittene IP-Multicast-Themen anschneiden.