Nativer Multicast-Fluss - Multicast-Modell für alle Quellen

Download-Optionen

  • PDF     (3.4 MB)
    Mit Adobe Reader auf verschiedenen Geräten anzeigen
  • ePub     (3.6 MB)
    In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
  • Mobi (Kindle)     (1.9 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.

    Einführung

    In diesem Dokument wird der Paketfluss des Any-Source Multicast (ASM)-Modells beschrieben.

    Hintergrundinformationen

    In diesem Dokument wird der detaillierte Paketfluss des nativen Multicast-Paketflusses und die Analyse seiner Ausgabe beschrieben. Dies beschreibt die Ausgabe der Detailanalyse und den Paketfluss auf Kontrollebene und Weiterleitungsebene.

    Das ASM ist das Modell, in dem der Empfänger nicht über die Kenntnisse 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, sowie das Internet Group Management Protocol (IGMP), um den gesamten für diese Adresse bestimmten Datenverkehr zu empfangen.

    All dies wird in diesem Dokument behandelt:

    1. Was geschieht, wenn Receiver aktiv ist?

    2. Was geschieht, wenn Source aktiv ist?

    3. Was geschieht, wenn Register bei Rendezvous Point (RP) eingegangen ist?

    4. Wie (S,G) gebildet. Bis zum First Hop Router (FHR).

    5. Welcher Pfad wird für den ersten Multicast-Stream verwendet?

    6. Was geschieht, wenn zwei Streams am Last Hop Router (LHR) empfangen werden?

    7. Wie Shortest Path Tree (SPT) über Shared Tree gebildet wird. Was genau passiert und warum der Switchover 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 der Multicast-Eintrag (*,G) verwendet, wobei * für jede Quelle und G für den Multicast-Gruppen-Adressempfänger 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 Empfänger den Ausdruck von Interesse erhält, sendet der Designated Router (DR) eine PIM Join-Nachricht an den RP für diese Multicast-Gruppe.
    • Diese Join-Nachricht wird als Join-Nachricht (*,G) bezeichnet, da sie der Gruppe G für alle Quellen dieser Gruppe beitritt.
    • Die (*,G)-Join-Route verläuft Hop-by-Hop zum RP für die Gruppe, und in jedem Router durchläuft sie den Multicast-Tree-Status für die Gruppe G.

    LHR wird als Last-Hop-Router angesehen, da er im (*,G)-Eintrag die C-Markierung hat, was bedeutet, dass er direkt mit dem Empfänger verbunden ist (in diesem Fall ist er selbst der Befehl igmp join group).

    212639-native-multicast-flow-any-source-multi-00.png

    212639-native-multicast-flow-any-source-multi-01.png

    212639-native-multicast-flow-any-source-multi-02.png

    Schritt 2: Wenn Quelle aktiv ist

    • Bevor der DR die Registrierungsnachricht sendet, muss er kurz und bündig die mroute-Tabelle konsultieren, um sicherzustellen, dass es sich nicht um den RP handelt und über RP-Set-Informationen verfügt. Bei allen Prüfungen muss PIM zwischen dem DR-Router und dem RP-Router aktiviert werden.
    • Sowohl der FHR- als auch der RP-Tunnel müssen Tunnelkapselung und -entkapselung auf Softwareebene enthalten.
    • Die Registrierungsnachricht enthält die Informationsquellengruppe und das Vorhandensein von Quelle.
    • Das gekapselte Multicast-Paket wird extrahiert, und der RP überprüft, ob der Status (*,G) für die Zieladresse vorhanden ist.
    • Wenn kein Status (*,G) vorhanden ist, wird PIM Register-Stop sofort zurückgesendet.

    212639-native-multicast-flow-any-source-multi-03.png

    212639-native-multicast-flow-any-source-multi-04.png

    212639-native-multicast-flow-any-source-multi-05.png

    Schritt 3: Gemeinsamer Formularbaum

    • Bevor der DR die Registrierungsnachricht sendet, muss er kurz und bündig die Weiterleitungstabelle konsultieren, um sicherzustellen, dass es sich nicht um den RP handelt und über RP-Set-Informationen verfügt. Bei allen Prüfungen muss PIM zwischen dem DR-Router und dem RP-Router aktiviert werden.
    • Sowohl der FHR- als auch der RP-Tunnel müssen über Tunnelkapselung und -entkapselung auf Softwareebene verfügen.
    • Register Message stellt die Informationsquellengruppe und das Vorhandensein if Source bereit.
    • Das gekapselte Multicast-Paket wird extrahiert, und der RP überprüft, ob der Status (*,G) für die Zieladresse vorhanden ist.
    • Wenn kein Status (*,G) vorhanden ist, wird PIM Register-Stop sofort zurückgesendet.

    212639-native-multicast-flow-any-source-multi-06.png

    212639-native-multicast-flow-any-source-multi-07.png

    Schritt 4: (S,G) Paketreaching zum FHR

    • Nur das Vorhandensein einer REGISTERNACHRICHT bei RP (S,G) PIM JOIN reist zum FHR. So erstellen Sie den Weiterleitungsstatus.
    • Nach Abschluss des PIM-JOIN-Vorgangs wird ein Hardware-Weiterleitungsstatus für den Multicast-Datenverkehrsfluss erstellt.
    • Gibt es (*,G)-Listener, beginnt der RP mit der Erstellung der SPT in Richtung der IP-Adresse der Multicast-Quelle. An dieser Stelle wird die RPF-Prüfung durchgeführt, um die Upstream-Schnittstelle zu ermitteln, an die die PIM-Join-Nachricht gesendet wird.

    212639-native-multicast-flow-any-source-multi-08.png

    Schritt 5: Erster Stream von Multicast-Paketen; Erreichen zum Empfänger über Shared Tree

    • Ein Router leitet Multicast-Stream nur weiter, wenn er an der INC/RFP-Schnittstelle empfangen wird.
    • Die Quelladresse von Multicast-Paketen wird mit der Unicast-RT abgeglichen.
    • Bestimmen Sie die Schnittstelle und den nächsten Hop-Multicast-Router in Richtung der Quelle, an die die Join gesendet wird.
    • Der RP ist dabei, den Source-Specific Tree für S zu verbinden. Die Datenpakete werden weiterhin in den RP gekapselt. Wenn Pakete von S auch nativ am RP eingehen, erhält der RP zwei Kopien jedes dieser Pakete.
    • An diesem Punkt beginnt der RP, die gekapselte Kopie dieser Pakete zu verwerfen, und sendet eine REGISTER STOP-Nachricht an S DR, um zu verhindern, dass der DR die Pakete unnötig kapselt.

    212639-native-multicast-flow-any-source-multi-09.png

    212639-native-multicast-flow-any-source-multi-10.png

    • Sobald der RP den Quelldatenverkehr über den Source Tree empfängt. Der Hardwarequellpfad wird festgelegt. Legen Sie das "T"-Flag fest, und der Baum wird erstellt.
    • RP sendet REGISTER STOP, um den Tunnel nach Erhalt des Quelldatenverkehrs vom FHR zum RP abzubrechen.
    • Um diesen Registrierungsprozess zu stoppen, sendet der RP eine PIM-Registerstopp-Nachricht. 

    212639-native-multicast-flow-any-source-multi-11.png

    212639-native-multicast-flow-any-source-multi-12.png

    212639-native-multicast-flow-any-source-multi-13.png

    212639-native-multicast-flow-any-source-multi-14.png

    Schritt 6: LHR empfängt Datenverkehr von SPT und sendet Prune-Nachricht an die Shared Tree

    Nach Erhalt von zwei Streams von Multicast-Datenverkehr empfängt der LHR den Datenverkehr von SPT und sendet eine Prune-Nachricht an den Shared Tree.

    Die J-Flag bedeutet, dass der jeweilige (*,G) Status darin besteht, die SPT durch den Leaf-Router zu wechseln. 

    LHR-Nummer

    (10.0.12.1, 239.1.1.1), 00:00:38/00:02:21, Flaggen: LJT

      Eingehende Schnittstelle: FastEthernet0/0, RPF nbr 10.0.78.7

      Liste ausgehender Schnittstellen:

        GigabitEthernet1/0, Forward/Sparse, 00:00:38/00:02:21

    Die "F"-Markierung wird in der Regel für die beim PIM DR-Router erstellten Zustände verwendet. Sie signalisiert die Weiterleitungsstatus, die den beim RP registrierten Flüssen entsprechen. Wenn das "F"-Flag erhalten bleibt, kann Ihr Router die PIM-Register-Stopp-Nachrichten höchstwahrscheinlich nicht vom RP erhalten, und es gibt Quellen, die nicht zum SPT gewechselt haben.

    212639-native-multicast-flow-any-source-multi-15.png212639-native-multicast-flow-any-source-multi-16.png

    212639-native-multicast-flow-any-source-multi-17.png

    212639-native-multicast-flow-any-source-multi-18.png

    212639-native-multicast-flow-any-source-multi-19.png212639-native-multicast-flow-any-source-multi-20.png

    TAC Authored

    Beiträge von Cisco Ingenieuren

    • Sabyasachi Kar
      Cisco TAC-Techniker

    War dieses Dokument hilfreich?

    FeedbackFeedback

    Cisco kontaktieren