Inhalt

Einführung

Hintergrundinformationen

In-Band-Signalisierung

Opak-Wert, der in diesem Profil verwendet wird

MLDP-Core-Struktur

P2MP TREE

MP2MP TREE

Opaktischer Wert

Overlay-Signalisierung

MLDP-LSP-Typen

Label Switched Multicast

Topologie

Konfiguration

Überprüfen

Detaillierte Überprüfung

Erstellen einer Kontrollebene

Schritt 1: Dieser Nachrichtenaustausch findet nach der Konfiguration des MLDP im Core statt.

Schritt 2: Aktivieren Sie die INBAND SIGNALING-Funktion im Core in MLDP.

Empfänger kommt online

Quelle startet Streaming

Paketerfassung (PCAP)

LSPVIF-Verifizierung

Schlussfolgerung

Zugehörige Informationen

Einführung

Dieses Dokument beschreibt die globale In-Band-Signalisierung für MLDP, Profile 7 für Multicast over VPN (mVPN) der nächsten Generation. Es wird ein Beispiel und die Implementierung in Cisco IOS verwendet, um das Verhalten zu veranschaulichen.

Hintergrundinformationen

- P2MP mLDP In-Band-Struktur im Core; kein C-Multicast-Routing.

- Beim Kundendatenverkehr kann es sich um SM S, G oder SSM handeln.

- Unterstützung für die globale Tabelle (S, G) auf PE.

- PIM im Core ist für mLDP nicht erforderlich.

In-Band-Signalisierung

Opak Value wird verwendet, um einem IP-Multicast-Fluss einen MP-LSP zuzuordnen.

Der Inhalt des optischen Werts wird aus dem Multicast-Fluss abgeleitet.

Opak-Wert, der in diesem Profil verwendet wird

Die IPv4-PIM-SSM-Übertragung ermöglicht die Übertragung globaler PIM-SSM-Streams über den MPLS-Core (Multiprotocol Label Switch). Der Opak-Wert enthält den tatsächlichen Wert (S, G), der sich in der globalen Routing-Tabelle der Eingangs- und Ausgangs-PE-Router befindet.

Der Opak Value identifiziert nicht nur den MP-LSP eindeutig, sondern kann auch die (S,G)-Streaminformationen vom Edge-IP-Multicast-Netzwerk übertragen. P-Router im MP Label-Switched Path (LSP) müssen den Opak-Wert nicht analysieren, sondern verwenden den Wert als Index in ihrer lokalen MP LSP-Datenbank, um den nächsten Hop bzw. die nächsten Hosts zu bestimmen, an den das Multicast-Paket repliziert wird. Der Eingangs-PE-LSP (der der Quelle am nächsten liegt) dekodiert jedoch den Wert, sodass der richtige MP-LSP für den eingehenden (S, G)-Stream ausgewählt werden kann. Der Egress-PE kann den Status (S, G) mithilfe eines Werts in die lokale VRF- oder globale Routing-Tabelle einfügen.

1. LSM ermöglicht die Verwendung einer einzigen MPLS-Weiterleitungsebene für Unicast- und Multicast-Datenverkehr.

2. LSM ermöglicht die Verwendung vorhandener MPLS-Schutzmechanismen (z. B. MPLS (TE/RSVP) und MPLS (OAM) für Multicast-Datenverkehr.

3. LSM reduziert die betriebliche Komplexität, da kein PIM im MPLS-Core-Netzwerk erforderlich ist.

MLDP-Core-Struktur

P2MP TREE

Empfänger-Treiber und Root-gelernt signalisiert mit MLDP P2MP FEC.

Einzigartig identifiziert:

- Stammknoten-Adresse

- P2MP LSP-ID [32 Bit]

MP2MP TREE

Configuration Driven und Root werden manuell konfiguriert.

Einzigartig identifiziert:

- Stammknoten-Adresse

- MP2MP LSP-ID [32 Bit]

Opaktischer Wert

Wird zum Übertragen von Multicast-Stream-Informationen verwendet, die Root und Blätter bedeuten.

- (S,G) Inband-Signalisierung

- LSPID (Standard/Daten)

Typ 1: Definiert durch MDLP, enthält LSP-ID zum Verwalten von ID-Space für P2MP/MP2MP LSPs.

Typ 2: Definiert für die Bereitstellung von MP-LDP-Tunneln und wird für BGP-MVPN ohne Überlappung verwendet.

Overlay-Signalisierung

MLDP-LSP-Typen

Label Switched Multicast

MPLS-Technologieerweiterungen zur Unterstützung von Multicast mithilfe von Labels:

- Point-to-Multipoint LSPs

- Multipoint-to-Multipoint LSPs

P2MP

MP2MP

Label

Upstream-Zuweisung

Upstream und Downstream

Datenverkehr

Downstream

Upstream und Downstream

Wurzel

Eingangs-Router

Bereitstellung/Bereitstellung von Edge

Datenverkehrstyp

Control-Router

Nur Datenverkehr kontrollieren

LSP-Typ

Root to Many Leaves

Viele Roots zu vielen Leaves

Topologie

Konfiguration

Schritt 1: Aktivieren Sie MPLS-MLDP in Core-Knoten.

Auf PE1, PE2 und PE3:

Anzahl mpls mldp-Protokollierung

Schritt 2: Aktivieren Sie MLDP-INBAND-SIGNALING im CORE.

Auf PE1, PE2 und PE3:

# ip multicast mpls mldp

# ip pim mpls source loopback 0

Schritt 3: Aktivieren Sie Multicast-Routing.

Auf allen Knoten:

# IP-Multicast-Routing

Schritt 4: Aktivieren Sie Protocol Independent Multicast (PIM) SSM im Customer Edge (CE).

Auf CE-Knoten:

# ip pim ssm default

Schritt 5: Aktivieren Sie PIM SM in allen CE-Schnittstellen und der Provider Edge (PE)-Schnittstelle.

Auf CE1-, CE2-, CE3- und allen CE-seitigen PE-Schnittstellen:

# Schnittstelle x/x

# ip pim sparse-mode

# Interface Loopback x/x

# ip pim sparse-mode

Hinweis: x steht für die Schnittstellennummer, die PE mit CE verbunden ist und umgekehrt.

Überprüfen

Aufgabe 1: Überprüfen der physischen Verbindung

- Überprüfen Sie, ob alle angeschlossenen Schnittstellen UP sind.

Aufgabe 2: IPv4-Unicast der BGP-Adressfamilie überprüfen

- Stellen Sie sicher, dass Border Gateway Protocol (BGP) auf allen Routern für AF-IPv4-Unicast aktiviert ist, und dass BGP-Nachbarn UP sind.

- Überprüfen Sie, ob die BGP IPv4-Tabelle alle Kundenpräfixe enthält.

Aufgabe 3: Überprüfung des gesamten Multicast-Datenverkehrs.

- Überprüfen Sie die PIM-Nachbarschaft mit dem verbundenen PIM-Nachbarn.

- Überprüfen der Erstellung des Multicast-Status

- PE-mRIB-Eintrag auf PE1, PE2 und PE3

- Stellen Sie sicher, dass der mFIB-Eintrag (S, G) und der Paketabruf in der Software-Weiterleitung erhöht werden.

- Überprüfen der Reichweite von ICMP-Paketen zwischen CE und CE

Aufgabe 4: Überprüfen Sie den MPLS-CORE.

- Überprüfen Sie den MPLS LSP-Core.

- Überprüfung der MPLS-Weiterleitung innerhalb des Core gemäß Design

- MPLS P2MP LSP Ping für IPv4.

Detaillierte Überprüfung

Interior Gateway Protocol (IGP), MPLS LDP und Border Gateway Protocol (BGP) werden durchgängig im gesamten Netzwerk eingesetzt.

Überprüfen Sie in diesem Abschnitt, ob das Kern-/Aggregationsnetzwerk aktiviert ist. Überprüfen Sie die Adjacency sowie die Kontroll- und Datenebene auf den Datenverkehr über das MPLS-Netzwerk.

So überprüfen Sie, ob die lokalen und Remote-CE-Geräte über den MPLS-Core (Multiprotocol Label Switching) kommunizieren können:

Erstellen einer Kontrollebene

Überprüfen Sie die Kontrollebene, auf der die Label-Erstellung erfolgt, wenn der PE-Router den IP-Header weiterleitet, und fügen Sie dem Paket ein MPLS-Label hinzu, wenn es in ein MPLS-Netzwerk gelangt.

In Richtung Label-Bereitstellung schaltet der Router Pakete auf der Grundlage einer CEF-Tabellensuche (Cisco Express Forwarding) um, um den nächsten Hop zu finden, und fügt die entsprechenden Label-Informationen hinzu, die in der FIB für das Ziel gespeichert sind. Wenn ein Router einen Label-Austausch im Core mit einem MPLS-Paket durchführt, führt der Router eine Suche in der MPLS-Tabelle durch. Der Router leitet diese MPLS-Tabelle (LFIB) von den Informationen in der CEF-Tabelle und der Label Information Base (LIB) ab.

Die Einstufung des Labels erfolgt, wenn der PE-Router ein MPLS-Paket empfängt, eine Weiterleitungsentscheidung basierend auf dem MPLS-Label trifft, das Label entfernt und ein IP-Paket sendet. Der PE-Router verwendet den LFIB für die Pfadbestimmung eines Pakets in diese Richtung. Wie bereits erwähnt, ermöglicht eine spezielle iBGP-Sitzung die Anzeige von VPNv4-Präfixen und deren Labels zwischen PE-Routern. Am Werbe-PE weist BGP Labels für die lokal gelernten VPN-Präfixe zu und installiert diese in der Label Forwarding Information Base (LFIB), der MPLS-Weiterleitungstabelle.

Schritt 1: Dieser Nachrichtenaustausch findet nach der Konfiguration des MLDP im Core statt.

MLDP-MFI: Enabled MLDP MFI client on Ethernet0/0; status =  ok

MLDP-MFI: Enabled MLDP MFI client on Ethernet0/1; status =  ok

MLDP: P2MP Wildcard label request sent to 11.11.11.11:0 success

MLDP: MP2MP Wildcard label request sent to 11.11.11.11:0 success

MLDP-NBR: 11.11.11.11:0 ask LDP for adjacencies

Hinweis: Verwenden Sie # debug mpls mldp all, um die vorherige Einrichtung zu überprüfen.

PE1#sh mpls mldp neighbors

MLDP peer ID    : 11.11.11.11:0, uptime 00:02:05 Up,

Target Adj     : No

Session hndl   : 1

Upstream count : 0

Branch count   : 0

Path count     : 1

Path(s)        : 10.0.1.2          LDP Ethernet0/1

Nhop count     : 0

Schritt 2: Aktivieren Sie die INBAND SIGNALING-Funktion im Core in MLDP.

ip pim mpls source loopback 0

ip multicast mpls mldp

MLDP: Enabled IPv4 on Lspvif0 unnumbered with Loopback0

MLDP-MFI: Enabled MLDP MFI client on Lspvif0; status =  ok

PIM(*): PIM subblock added to Lspvif0

MLDP: Enable pim on lsp vif: Lspvif0

MLDP: Add success lsp vif: Lspvif0 address: 0.0.0.0 application: MLDP vrf_id: 0

MLDP-DB: Replaying database events for opaque type value: 3

%LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up

PIM(0): Check DR after interface: Lspvif0 came up!

%PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Lspvif0

Hinweis: Verwenden Sie # debug mpls mldp all, um die vorherige Einrichtung zu überprüfen.

PE1#sh int lspvif 0

Lspvif0 is up, line protocol is up

Hardware is

Interface is unnumbered. Using address of Loopback0 (1.1.1.1)

MTU 17940 bytes, BW 8000000 Kbit/sec, DLY 5000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation LOOPBACK, loopback not set

Hinweis: MPLS MLDP wurde noch nicht erstellt, da der Empfänger noch nicht online ist.

Empfänger 3 wird online gestellt und sendet PIM JOIN (S,G)-Nachrichten an PE3.

Empfänger kommt online

PIM(0): Received v2 Join/Prune on Ethernet0/2 from 10.2.0.2, to us

PIM(0): Join-list: (10.1.0.2/32, 232.1.1.1), S-bit set

MRT(0): Create (*,232.1.1.1), RPF (unknown, 0.0.0.0, 2147483647/0)

MRT(0): RPF Track start on 10.1.0.2 for (10.1.0.2, 232.1.1.1)

MRT(0): Reset the z-flag for (10.1.0.2, 232.1.1.1)

MLDP: Enabled IPv4 on Lspvif1 unnumbered with Loopback0

MLDP-MFI: Enable lsd on int failed; not registered;

PIM(*): PIM subblock added to Lspvif1

MLDP: Enable pim on lsp vif: Lspvif1

MLDP: Add success lsp vif: Lspvif1 address: 1.1.1.1 application: MLDP vrf_id: 0

MLDP-MRIB-IP: (10.1.0.2,232.1.1.1/32) update (t=0) RPF: 0.0.0.0

MLDP-MRIB-IP: (10.1.0.2,232.1.1.1/32) set rpf nbr: 0.0.0.0

MLDP-MRIB-IP: wavl insert success (10.1.0.2, 232.1.1.1)

MLDP-MRIB-IP: no RPF neighbor, done!

MLDP-MRIB-IP: (10.1.0.2,232.1.1.1/32) update (t=1) RPF: 1.1.1.1

MLDP-MRIB-IP: (10.1.0.2,232.1.1.1/32) set rpf nbr: 1.1.1.1

MLDP-MRIB-IP: Change RPF neighbor from 0.0.0.0 to 1.1.1.1

MLDP-MRIB-IP: (10.1.0.2,232.1.1.1/32) update idb = Lspvif1, (f=2,c=2)

MLDP-MRIB-IP: add accepting interface: Lspvif1 root: 1.1.1.1

MLDP-MRIB-IP: change interface from NULL to Lspvif1

%LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif1, changed state to up

PIM(0): Check DR after interface: Lspvif1 came up!

PIM(0): Changing DR for Lspvif1, from 0.0.0.0 to 2.2.2.2 (this system)

%PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 2.2.2.2 on interface Lspvif1

Hinweis: Verwenden Sie # debug mpls mldp all und # debug ip bgp ipv4 mvpn updates Debugs, um die peceding-Einrichtung zu überprüfen.

Jede Kommunikation von der Receiver-Join-Nachricht (S,G) wird in MLDP konvertiert, und alle Nachrichten werden in Richtung Lspvif 1 übertragen.

Da PIM JOIN (S,G) als MLDP empfängerorientiertes Protokoll fungiert, wird die MLDP-Datenbank vom Empfänger zur Quelle erstellt. Dies ist die Downstream-Label-Zuweisung für P2MP MLDP.

Hinweis: Bei der In-Band-Signalisierung werden für jeden Eingangs-PE Label Switched Path Virtual Interfaces (LSPVIFs) erstellt, um die strikte RPF-Implementierung zu implementieren, d. h. ein (S,G)-Paket nur zu akzeptieren, wenn es vom erwarteten Remote-PE kommt; Dies ist in Ihrem Fall LSPVIF1. Als Quell-PE wird das Standard-LSPVIF für die Weiterleitung an den Core verwendet. Beachten Sie, dass keine Zeichen für LSPVIF-Schnittstellennummern vorhanden sind, d. h. lspvif0 ist nicht immer die Standardschnittstelle und lspvif1 ist nicht immer die PE-spezifische Schnittstelle. Diese Nummern werden nach Bedarf zugewiesen.

PE3#sh ip mroute 232.1.1.1 verbose

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

T - SPT-bit set, p - PIM Joins on route,

(10.1.0.2, 232.1.1.1), 00:19:28/00:02:42, flags: sTp

Incoming interface: Lspvif1, RPF nbr 1.1.1.1

Outgoing interface list:

Ethernet0/0, Forward/Sparse, 00:19:28/00:02:42, p

PE3#sh mpls mldp database

* For interface indicates MLDP recursive forwarding is enabled

* For RPF-ID indicates wildcard value

> Indicates it is a Primary MLDP MDT Branch

LSM ID : 1   Type: P2MP   Uptime : 00:28:02

FEC Root           : 1.1.1.1

Opaque decoded     : [ipv4 10.1.0.2 232.1.1.1]

Opaque length      : 8 bytes

Opaque value       : 03 0008 0A010002E8010101

Upstream client(s) :

11.11.11.11:0    [Active]

Expires        : Never         Path Set ID  : 1

Out Label (U)  : None          Interface    : Ethernet0/3*

Local Label (D): 24            Next Hop     : 10.0.3.2

Replication client(s):

MRIBv4(0)

Uptime         : 00:28:02      Path Set ID  : None

Interface      : Lspvif1

RR-P #sh mpls mldp database

* For interface indicates MLDP recursive forwarding is enabled

* For RPF-ID indicates wildcard value

> Indicates it is a Primary MLDP MDT Branch

LSM ID : A   Type: P2MP   Uptime : 00:40:52

FEC Root           : 1.1.1.1

Opaque decoded     : [ipv4 10.1.0.2 232.1.1.1]

Opaque length      : 8 bytes

Opaque value       : 03 0008 0A010002E8010101

Upstream client(s) :

1.1.1.1:0    [Active]

Expires        : Never         Path Set ID  : A

Out Label (U)  : None          Interface    : Ethernet0/1*

Local Label (D): 24            Next Hop     : 10.0.1.1

Replication client(s):

2.2.2.2:0

Uptime         : 00:40:52      Path Set ID  : None

Out label (D)  : 23            Interface    : Ethernet0/3*

Local label (U): None          Next Hop     : 10.0.2.1

3.3.3.3:0

Uptime         : 00:40:52      Path Set ID  : None

Out label (D)  : 24            Interface    : Ethernet0/2*

Local label (U): None          Next Hop     : 10.0.3.1

Die im Quell-PE empfangenen Informationen basieren auf der RPF-Suche für den nächsten Hop.

MLDP-LDP: [ipv4 10.1.0.2 232.1.1.1] label mapping from: 11.11.11.11:0 label: 23 root: 1.1.1.1 Opaque_len: 11 sess_hndl: 0x1

MLDP: LDP root 1.1.1.1 added

MLDP-DB: Added [ipv4 10.1.0.2 232.1.1.1] DB Entry

MLDP-DB: [ipv4 10.1.0.2 232.1.1.1] Changing branch 11.11.11.11:0 from Null/0.0.0.0 to Ethernet0/1/10.0.1.2

MLDP-MFI: Could not add Path type: PKT, Label: 23, Next hop: 11.11.11.11, Interface: NULL to set: 3, error 1

MLDP-DB: [ipv4 10.1.0.2 232.1.1.1] Added P2MP branch for 11.11.11.11:0 label 23

MLDP-MRIB-IP: [ipv4 10.1.0.2 232.1.1.1] client update: We are root

MLDP-MRIB-IP: wavl insert success (10.1.0.2, 232.1.1.1)

MLDP-MRIB-IP: [ipv4 10.1.0.2 232.1.1.1] Created: Lspvif0 for: 0.0.0.0

MLDP-MRIB: Created adjacency for LSM ID 3

MLDP-MRIB-IP: [ipv4 10.1.0.2 232.1.1.1] Created adjacency on Lspvif0

MLDP: nhop 1.1.1.1 added

MRT(0): Set the T-flag for (10.1.0.2, 232.1.1.1)

MRT(0): (10.1.0.2,232.1.1.1), RPF install from  /0.0.0.0 to Ethernet0/2/10.1.0.2

PIM(0): Insert (10.1.0.2,232.1.1.1) join in nbr 10.1.0.2's queue

MLDP-MRIB-IP: (10.1.0.2,232.1.1.1/32) update (t=1) RPF: 10.1.0.2

MLDP-MRIB-IP: (10.1.0.2,232.1.1.1/32) set rpf nbr: 10.1.0.2

MLDP-MRIB-IP: ignoring interface Ethernet0/2, no LS

Hinweis: Verwenden Sie # debug mpls mldp all und # debug ip bgp ipv4 mvpn-Aktualisierungen, um die vorherige Einrichtung zu überprüfen.

PE1#sh ip mroute 232.1.1.1 verbose

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

L - Local, P - Pruned, R - RP-bit set, F - Register flag,

T - SPT-bit set, I - Received Source Specific Host Report,

(10.1.0.2, 232.1.1.1), 00:25:14/stopped, flags: sTI

Incoming interface: Ethernet0/2, RPF nbr 10.1.0.2

Outgoing interface list:

Lspvif0, LSM ID: 4, Forward/Sparse, 00:25:14/00:01:45

PE1# sh mpls mldp database

* For interface indicates MLDP recursive forwarding is enabled

* For RPF-ID indicates wildcard value

> Indicates it is a Primary MLDP MDT Branch

LSM ID : 4   Type: P2MP   Uptime : 00:25:25

FEC Root           : 1.1.1.1 (we are the root)

Opaque decoded     : [ipv4 10.1.0.2 232.1.1.1]

Opaque length      : 8 bytes

Opaque value       : 03 0008 0A010002E8010101

Upstream client(s) :

None

Expires        : N/A           Path Set ID  : 4

Replication client(s):

11.11.11.11:0

Uptime         : 00:25:25      Path Set ID  : None

Out label (D)  : 24            Interface    : Ethernet0/1*

Local label (U): None          Next Hop     : 10.0.1.2

MLDP-LDP: [id 0] Wildcard label request from: 11.11.11.11:0 label: 0 root: 6.2.0.0 Opaque_len: 0 sess_hndl: 0x1

MLDP-LDP: [ipv4 10.1.0.2 232.1.1.1] label mapping from: 11.11.11.11:0 label: 23 root: 1.1.1.1 Opaque_len: 11 sess_hndl: 0x1

Neighbor 11.11.11.11 request for the label request to PE1.

Hinweis: Antworten Sie auf typisierte Wildcard Label-Anforderungen, die vom Peer empfangen wurden, indem Sie die Label-Datenbank für Präfixe erneut abspielen. Verwenden Sie Typed Wildcard Label Requests an Peers, um eine Wiederholung der Peer-Label-Datenbank für Präfixe anzufordern.

MLDP-LDP: [ipv4 10.1.0.2 232.1.1.1] label mapping from: 11.11.11.11:0 label: 24 root: 1.1.1.1 Opaque_len: 11 sess_hndl: 0x1

MLDP: LDP root 1.1.1.1 added

MLDP-DB: Added [ipv4 10.1.0.2 232.1.1.1] DB Entry

MLDP-DB: [ipv4 10.1.0.2 232.1.1.1] Changing branch 11.11.11.11:0 from Null/0.0.0.0 to Ethernet0/1/10.0.1.2

%MLDP-5-ADD_BRANCH: [ipv4 10.1.0.2 232.1.1.1] Root: 1.1.1.1, Add P2MP branch 11.11.11.11:0 remote label 24

debug ip mfib pak

debug ip mfib mrib

Quelle startet Streaming

Traffic from Source 10.1.0.2 streaming from 232.1.1.1. Enters through ethernet0/2.

The packet got forwarded via Lspvif 0.

PIM(0): Insert (10.1.0.2,232.1.1.1) join in nbr 10.1.0.2's queue

PIM(0): Building Join/Prune packet for nbr 10.1.0.2

PIM(0):  Adding v2 (10.1.0.2/32, 232.1.1.1), S-bit Join

PIM(0): Send v2 join/prune to 10.1.0.2 (Ethernet0/2)

MFIBv4(0x0): Pkt (10.1.0.2,232.1.1.1) from Ethernet0/2 (FS) accepted for forwarding

MFIBv4(0x0): Pkt (10.1.0.2,232.1.1.1) from Ethernet0/2 (FS) sent on Lspvif0, LSM NBMA/4

Paketerfassung (PCAP)

Dieses Paket wird in den LSPVIF 0 getunnelt.

At the receiver Side:

At the receiver side the packet reach at the Lspvif 1.

MFIBv4(0x0): Pkt (10.1.0.2,232.1.1.1) from Lspvif1 (FS) accepted for forwarding

MFIBv4(0x0): Pkt (10.1.0.2,232.1.1.1) from Lspvif1 (FS) sent on Ethernet0/0

PIM(0): Received v2 Join/Prune on Ethernet0/0 from 10.3.0.2, to us

PIM(0): Join-list: (10.1.0.2/32, 232.1.1.1), S-bit set

PIM(0): Update Ethernet0/0/10.3.0.2 to (10.1.0.2, 232.1.1.1), Forward state, by PIM SG Join

LSPVIF-Verifizierung

Wenn das Paket den PE1 erreicht, überprüft es die LSM-ID, um den Datenverkehr weiterzuleiten, der im Multicast-Paket festgelegt werden soll.

Schlussfolgerung

Die In-Band-Signalisierung für Multipoint LDP (M-LDP) ermöglicht die Übertragung von Multicast-Datenverkehr über einen bestehenden IP/MPLS-Backbone, während die Verwendung von PIM im Provider-Core vermieden wird.

Aktivieren Sie auf dem Label-Edge-Router (LER) PIM, um die In-Band-Signalisierung M-LDP für die Upstream-Nachbarn zu verwenden, wenn der LER keinen PIM-Upstream-Nachbarn erkennt.

Zugehörige Informationen

- https://tools.ietf.org/html/rfc4760

- https://tools.ietf.org/html/rfc4447

- https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti_lsm/configuration/15-sy/imc-lsm-15-sy-book

- Technischer Support und Dokumentation - Cisco Systems