PDF(5.1 MB) Mit Adobe Reader auf verschiedenen Geräten anzeigen
ePub(5.3 MB) In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
Mobi (Kindle)(3.0 MB) Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen
Aktualisiert:12. Januar 2018
Dokument-ID:212639
Inklusive Sprache
In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Informationen zu dieser Übersetzung
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument wird der Paketfluss des Any-Source Multicast (ASM)-Modells beschrieben.
Hintergrundinformationen
In diesem Dokument werden der detaillierte Paketfluss des Native Multicast-Paketflusses und die Analyse seiner Ausgabe beschrieben. Dabei werden die detaillierte Analyseausgabe und der Paketfluss auf der Kontroll- und Weiterleitungsebene beschrieben.
Das ASM ist das Modell, bei dem der Empfänger nicht über die Kenntnis des Absenders verfügt. Es bedeutet, dass es Datenverkehr von jeder Quelle empfangen kann. Der Empfänger erkennt nur die Multicast-Gruppe, die der Absender verwendet, und das Internet Group Management Protocol (IGMP), um den gesamten für diese Adresse bestimmten Datenverkehr abonnieren zu können.
All dies wird in diesem Dokument behandelt:
1. Was passiert, wenn der Empfänger aktiv ist?
2. Was passiert, wenn die Quelle aktiv ist?
3. Was geschieht, wenn Register bei Rendezvous Point (RP) empfangen wird?
4. Wie (S,G) gebildet wurde. Bis First Hop Router (FHR).
5. Welchen Pfad er für den ersten Multicast-Stream verwendet.
6. Was passiert, wenn zwei Streams auf dem Last Hop Router (LHR) empfangen werden?
7. Wie der SPT (Shortest Path Tree) über den Shared Tree gebildet wird. Was genau passiert und warum die Umstellung stattfindet.
Protocol Independent Multicast (PIM) wird als Multicast-Routing-Protokoll zwischen Quelle und Empfänger verwendet, um den Multicast-Tree zu erstellen. In ASM wird ein (*,G)-Multicast-Eintrag verwendet, wobei * für eine beliebige Quelle steht und G für den Adressempfänger der Multicast-Gruppe steht, der für den Empfang des Datenverkehrs interessiert ist.
Schritt 1: Wenn der Empfänger aktiv ist, sendet er eine IGMP-Berichtsmeldung.
Wenn der Interessensausdruck des Empfängers empfangen wird, sendet der designierte Router (DR) dann eine PIM Join-Nachricht an den RP für diese Multicast-Gruppe.
Diese Join-Nachricht wird als (*,G) Join bezeichnet, da sie der Gruppe G für alle Quellen dieser Gruppe beitritt.
Die (*,G)-Join-Route verläuft Hop-für-Hop zum RP für die Gruppe, und in jedem Router, den sie passiert, wird der Multicast-Tree-Status für Gruppe G instanziiert.
LHR wird als Last-Hop-Router angesehen, da er das C-Flag im (*,G)-Eintrag hat, was bedeutet, dass er direkt mit dem Empfänger verbunden ist (in diesem Fall ist er es selbst mit der Verwendung des igmp join group-Befehls).
Schritt 2: Wenn die Quelle aktiv ist
Bevor der DR die Registrierungsmeldung sendet, muss er, kurz gesagt, in der mroute-Tabelle nachsehen, um sicherzustellen, dass es sich nicht um den RP handelt und dass er über RP-Set-Informationen verfügt. Bei allen Prüfungen muss PIM zwischen DR und RP-Router aktiviert sein.
Sowohl der FHR- als auch der RP-Tunnel müssen über eine Tunnelkapselung und -entkapselung auf Softwareebene verfügen.
Die Nachricht registrieren enthält die Informationen zur Quellgruppe und zum Vorhandensein der Quelle.
Das gekapselte Multicast-Paket wird extrahiert, und der RP überprüft, ob für die Zieladresse ein (*,G)-Status vorliegt.
Wenn kein Zustand (*,G) vorliegt, wird PIM Register-Stopp sofort zurückgesendet.
Schritt 3. Formular für freigegebenen Baum
Bevor der DR die Registrierungsmeldung sendet, muss er, kurz gesagt, in der mroute-Tabelle nachsehen, um sicherzustellen, dass es sich nicht um den RP handelt und dass er über RP-Set-Informationen verfügt. Bei allen Prüfungen muss PIM zwischen DR und RP-Router aktiviert sein.
Sowohl der FHR- als auch der RP-Tunnel müssen über eine Tunnelkapselung und -entkapselung auf Softwareebene verfügen.
Registrieren Nachricht liefert die Informationen Quellgruppe und Existenz, wenn Quelle.
Das gekapselte Multicast-Paket wird extrahiert, und der RP überprüft, ob für die Zieladresse ein (*,G)-Status vorliegt.
Wenn kein Zustand (*,G) vorliegt, wird PIM Register-Stopp sofort zurückgesendet.
Schritt 4. (S,G) Paket erreicht die FHR
Nur das Vorhandensein von REGISTERNACHRICHT bei RP (S,G) PIM JOIN reist zur FHR. So erstellen Sie den Weiterleitungsstatus:
Nach der PIM-TEILNAHME wird der Prozess zur Erstellung eines Hardware-Weiterleitungsstatus für den Multicast-Datenverkehrsfluss abgeschlossen.
Wenn (*,G) Listener vorhanden sind, beginnt der RP mit der Erstellung des SPT zur Multicast-Quell-IP-Adresse. An dieser Stelle wird die RPF-Prüfung durchgeführt, um die Upstream-Schnittstelle zu ermitteln, an die die PIM-Join-Nachricht gesendet werden soll.
Schritt 5: Erster Multicast-Paketstrom, Erreichen des Empfängers über Shared Tree
Ein Router leitet Multicast-Stream nur weiter, wenn er über die INC-/RFP-Schnittstelle empfangen wurde.
Die Quelladresse für Multicast-Pakete wird mit dem Unicast-RT abgeglichen.
Bestimmen Sie die Schnittstelle und den nächsten Hop-Multicast-Router in Richtung der Quelle, an die der Join gesendet wurde.
Der RP ist dabei, dem quellspezifischen Tree für S beizutreten. Die Datenpakete werden weiterhin für den RP gekapselt. Wenn Pakete von S ebenfalls nativ beim RP eingehen, erhält der RP zwei Kopien von jedem dieser Pakete.
An diesem Punkt beginnt der RP, die gekapselte Kopie dieser Pakete zu verwerfen, und sendet eine REGISTER STOP-Nachricht zurück an S's DR, um zu verhindern, dass der DR die Pakete unnötig kapselt.
Sobald der RP den Quell-Datenverkehr über den Quell-Tree empfängt. Der Pfad zur Hardwarequelle ist eingerichtet. Setzen Sie die "T"-Markierung und der Baum wird erstellt.
Der RP sendet REGISTER STOP, um den Tunnel nach Empfang des Quelldatenverkehrs von der FHR an den RP zu entfernen.
Um diesen Registerprozess zu stoppen, sendet der RP eine PIM-Registerstoppmeldung.
Schritt 6: LHR empfängt Datenverkehr von SPT und sendet Prune-Nachricht an den Shared Tree
Nach Empfang von zwei Multicast-Datenverkehrsströmen beginnt der LHR, den Datenverkehr vom SPT zu empfangen, und sendet eine Bereinigungsmeldung an den Shared Tree.
Das J-Flag bedeutet, dass der jeweilige (*,G)-Status den SPT über den Leaf-Router schaltet.
Das "F"-Flag wird in der Regel für die am PIM DR-Router erstellten Status erkannt. Es signalisiert die Weiterleitungsstatus, die den beim RP registrierten Flows entsprechen. Besteht das "F"-Flag fort, kann der Router höchstwahrscheinlich die PIM-Register-Stopp-Meldungen nicht vom RP empfangen. Es gibt also Quellen, die nicht auf den SPT umgestellt haben.