MULTICAST-In-Band-Signalisierung der nächsten Generation (VRF MLDP: Profil 6)
Inhalt
Einführung
Dieses Dokument beschreibt das In-Band-Signaling-VRF-MLDP, Profile 6 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
Multicast Label Distribution Protocol (MLDP)-In-Band-Signalisierung, um dem MLDP-Core die Erstellung des Status (S,G) oder (*,G) zu ermöglichen, ohne dass Out-of-Band-Signalisierung wie Border Gateway Protocol (BGP) oder Protocol Independent Multicast (PIM) verwendet wird.
MLDP-unterstütztes Multicast VPN (MVPN) ermöglicht die Aggregation von VPN-Multicast-Streams über einen VPN-spezifischen Tree.
Im MLDP-Core wird kein Kundenstatus erstellt. Es gibt den einzigen Status für Standard- und Daten-Multicast-Distribution Trees (MDTs).
In bestimmten Szenarien ist der für VPN-Streams erstellte Zustand begrenzt und scheint kein Risiko- oder Begrenzungsfaktor zu sein. In diesen Szenarien kann MLDP In-Band-MDTs erstellen, die Transit Label Switched Paths (LSPs) sind.
In einem VPN-Raum verwendete Strukturen sind MDTs. Die in der globalen Tabelle verwendeten Strukturen sind Transit Point-to-Multipoint (P2MP)- oder Multipoint-to-Multipoint (MP2MP)-LSPs.
In beiden Fällen wird ein einzelner Multicast-Stream (VPN oder nicht) einem einzelnen LSP im MPLS-Core zugeordnet. Die Streaminformationen werden in der Forwarding Equivalence Class (FEC) des LSP kodiert. Dies ist die In-Band-Signalisierung.
LSM bietet Vorteile im Vergleich zu GRE-Core-Tunneln, die derzeit für die Übertragung des Kundendatenverkehrs im Core verwendet werden, und nutzt die MPLS-Infrastruktur für die Übertragung von IP-Multicast-Paketen, um eine gemeinsame Datenebene für Unicast und Multicast bereitzustellen.
MLDP-Signalisierung
Die MLDP-Signalisierung bietet zwei Funktionen:
- So suchen Sie den FEC (und den zugehörigen Opak Value) für einen MP LSP
- So weisen Sie einem MP LSP Multicast Flow zu
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.
Overlay- oder Out-of-Band-Signalisierung
- Verwendet ein Overlay-Protokoll, um einen MP LSP einem IP-Multicast-Fluss zuzuordnen.
- Opak-Wert kann vom Eingangs-Root-PE zugewiesen oder statisch konfiguriert werden.
- MP LSP wird bei Bedarf erstellt oder kann vorkonfiguriert werden.
- Ermöglicht das Aggregieren von Multicast-Streams auf einem einzigen MP LSP.
Label Distribution Protocol (LDP) Typed Wildcard Forward Equivalence Class (FEC) # RFC5918
Das Typed Wildcard FEC-Element bezieht sich auf alle FECs des angegebenen Typs, die die Einschränkung erfüllen. Es gibt einen 'FEC Element Type' und eine optionale Einschränkung an, die zusätzliche Informationen bereitstellen soll.
Das Format des Typed Wildcard FEC-Elements ist:
Typisierte Wildcard: Ein Oktett FEC-Elementtyp (0x05).
LDP [RFC5036] verteilt Label für Forwarding Equivalence Classes (FECs). LDP verwendet FEC TLVs in LDP-Nachrichten, um FECs anzugeben.
Ein LDP-FEC-TLV umfasst ein oder mehrere FEC-Elemente. Ein FEC-Element umfasst einen FEC-Typ und einen optionalen typabhängigen Wert.
RFC 5036 gibt zwei FEC-Typen an (Präfix und Wildcard), und in anderen Dokumenten werden zusätzliche FEC-Typen angegeben. Siehe z. B. [RFC447] und [MLDP].
Wie in RFC 5036 angegeben, bezieht sich das Wildcard FEC-Element auf alle FECs bezogen auf eine optionale Einschränkung.
Die einzige Einschränkung, die RFC 5036 angibt, ist eine, die den Gültigkeitsbereich des Wildcard FEC-Elements auf "alle FECs, die an ein bestimmtes Label gebunden sind" beschränkt.
Die RFC 5036-Spezifikation des Wildcard FEC-Elements weist folgende Mängel auf, die dessen Verwendung einschränken:
- Das Wildcard FEC-Element ist nicht typisiert. Es gibt Situationen, in denen es sinnvoll wäre, auf alle FECs eines bestimmten Typs (als eine andere Einschränkung) verweisen zu können.
- Die Verwendung des Wildcard FEC-Elements ist auf Label Withdraw und Label Release-Nachrichten beschränkt. Es gibt Situationen, in denen es nützlich wäre, ein Wildcard FEC-Element mit Typeinschränkung in Label Request-Meldungen zu haben.
Topologie
Overlay-Signalisierung
Konfiguration
Schritt 1: Aktivieren Sie MPLS-MLDP in Core-Knoten.
Anzahl mpls mldp-Protokollierung
Schritt 2: Aktivieren Sie MLDP-INBAND-SIGNALING im CORE.
Auf PE1, PE2 und PE3
# ip multicast vrf INBAND-MLDP mpls mldp
# ip pim vrf INBAND-MLDP mpls source loopback 0
Schritt 3: Aktivieren Sie PIM SM an allen CE-Schnittstellen und an allen PE-VRF-Schnittstellen.
Auf CE1, CE2, CE3 und allen VRF-Schnittstellen PE1, PE2 und PE3
# Schnittstelle x/x
# ip pim sparse-mode
# Interface Loopback x/x
# ip pim sparse-mode
Schritt 4: Aktivieren Sie Multicast in der VRF-Instanz.
Auf PE1, PE2 und PE3
# ip multicast routing vrf INBAND-MLDP
Schritt 5: Aktivieren Sie VRF auf der PE-CE-Schnittstelle x/x des PE-Routers.
# Schnittstelle x/x
# ip vrf Forwarding INBAND-MLDP
Schritt 6: Konfigurieren Sie den Modus SSM in CE- und PE-Knoten (nur VRF).
Auf CE-Knoten
# ip pim ssm default
Auf PE1, PE2, PE3 unter VRF
# ip pim vrf INBAND-MLDP-SSM-Standard
Schritt 7: Konfigurieren Sie die IGMP-Gruppe SSM 232.1.1.1 (Empfänger).
Auf Empfänger 2 und 3
CE #Interface x/x
# ip pim join-group 232.1.1.1 source 10.1.0.2
Überprüfen
IGP, MPLS LDP, BGP läuft durchgängig im gesamten Netzwerk fehlerfrei.
In diesem Abschnitt wird die VPN AF-Adjacency im Core-/Aggregationsnetzwerk überprüft. Die Adjazenz wird zwischen CE-PE geprüft, und die Kontrollebene wird zusammen mit der Datenebene auf VPN-Datenverkehr über das MPLS-Netzwerk überprüft.
So überprüfen Sie, ob die lokalen und Remote-CE-Geräte über den MPLS-Core (Multiprotocol Label Switching) kommunizieren können:
Aufgabe 1: Überprüfen der physischen Verbindung
- Überprüfen Sie, ob alle angeschlossenen Schnittstellen UP sind.
Aufgabe 2: VPNv4-Unicast der BGP-Adressfamilie überprüfen.
- Überprüfen Sie, ob BGP auf allen Routern für AF-VPNv4-Unicast und BGP-Nachbarn UP aktiviert ist.
- Überprüfen Sie, ob die BGP VPNv4-Unicast-Tabelle über alle Kundenpräfixe verfügt.
Aufgabe 3: Überprüfung des gesamten Multicast-Datenverkehrs.
- Überprüfen Sie die PIM-Nachbarschaft mit dem verbundenen PIM-Nachbarn.
- Überprüfen Sie, ob der Multicast-Status in der VRF-Instanz erstellt wird.
Beim PE-VRF-mRIB-Eintrag auf PE1, PE2 und PE3
- Überprüfen Sie, ob der VRF-mFIB-Eintrag (S, G), der die Paketweiterleitung erhöht, aktiviert wird.
- Ü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
- Überprüfen Sie, ob der MPLS P2MP LSP-Ping funktioniert.
Erstellen einer Kontrollebene
Überprüfen Sie die Kontrollebene, die bei der Label-Erstellung auftritt, wenn der PE-Router basierend auf dem IP-Header weiterleitet und dem Paket bei der Eingabe eines MPLS-Netzwerks ein MPLS-Label hinzufügt.
In Richtung Label-Bereitstellung schaltet der Router Pakete auf Basis einer CEF-Tabellensuche 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 das 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 Beschriftungen zwischen PE-Routern. Am Werbe-PE weist BGP Labels für die lokal gelernten VPN-Präfixe zu und installiert diese im LFIB, der MPLS-Weiterleitungstabelle.
Schritt 1: Sobald Sie das MLDP im Core konfigurieren. Diese Nachrichten werden ausgetauscht.
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-MFI: Enabled MLDP MFI client on Lspvif0; status = ok LDP Peer 11.11.11.11:0 re-announced MLDP-NBR: 11.11.11.11:0 UP sess_hndl: 1, (old ID: 0.0.0.0:0) mLDP-RW: Sending RW notification message to process: mLDP Process mLDP-RW: RW Tracking started for: 11.11.11.11 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: [id 0] Wildcard label request from: 11.11.11.11:0 label: 0 root: 8.2.0.0 Opaque_len: 0 sess_hndl: 0x1 Neighbor 11.11.11.11 request for the label request to PE1.
Verwenden Sie diese Debugging-Methode, um die vorherige Einrichtung zu überprüfen:
# debug mpls mldp all
Schritt 2: Aktivieren Sie die INBAND-SIGNALISIERUNG in VRF.
PE1 # Config t # ip pim vrf MLDP-INBAND mpls source loopback 0 # ip multicast vrf MLDP-INBAND mpls mldp MLDP: Enabled IPv4 on Lspvif0 unnumbered with Loopback0 MLDP-MFI: Enable lsd on int failed; not registered; MLDP: Enable pim on lsp vif: Lspvif0 MLDP: Add success lsp vif: Lspvif0 address: 0.0.0.0 application: MLDP vrf_id: 1 MLDP-DB: Replaying database events for opaque type value: 250 %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up PIM(1): Check DR after interface: Lspvif0 came up! PIM(1): Changing DR for Lspvif0, from 0.0.0.0 to 1.1.1.1 (this system) %PIM-5-DRCHG: VRF MLDP-INBAND: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Lspvif0 Use this Debug to check the preceding establishment # debug ip pim vrf LDP-INBAND6 PE1#sh interfaces 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
Wenn der Empfänger online ist:
Empfänger 3 wird online gestellt und sendet PIM JOIN (S,G)-Nachrichten an PE3.
PIM(1): Received v2 Join/Prune on Ethernet0/2 from 10.2.0.2, to us PIM(1): Join-list: (10.1.0.2/32, 232.1.1.1), S-bit set MRT(1): Create (*,232.1.1.1), RPF (unknown, 0.0.0.0, 2147483647/0) MLDP: Interface Lspvif1 moved from VRF (default) to VRF MLDP-INBAND MLDP: Enabled IPv4 on Lspvif1 unnumbered with Loopback0 MLDP-MFI: Enabled MLDP MFI client on Lspvif1; status = ok MRT(1): Add interface Lspvif1 MLDP: Enable pim on lsp vif: Lspvif1 MLDP: Add success lsp vif: Lspvif1 address: 1.1.1.1 application: MLDP vrf_id: 1 MLDP: LDP root 1.1.1.1 added mLDP-RW: Sending RW notification message to process: mLDP Process mLDP-RW: RW Tracking started for: 1.1.1.1 MLDP: Route watch started for 1.1.1.1 topology: base ipv4 MLDP-DB: Added [vpnv4 10.1.0.2 232.1.1.1 1:1] DB Entry MLDP-DB: [vpnv4 10.1.0.2 232.1.1.1 1:1] Added P2MP branch for MRIBv4(1) label %MLDP-5-ADD_BRANCH: [vpnv4 10.1.0.2 232.1.1.1 1:1] Root: 1.1.1.1, Add P2MP branch MRIBv4(1) remote label MLDP: nhop 10.0.2.2 added MLDP-NBR: 11.11.11.11:0 mapped to next_hop: 10.0.2.2 MLDP: Root 1.1.1.1 old paths: 0 new paths: 1 MLDP-DB: [vpnv4 10.1.0.2 232.1.1.1 1:1] Changing peer from none to 11.11.11.11:0 MLDP-DB: [vpnv4 10.1.0.2 232.1.1.1 1:1] Add accepting element nbr: 11.11.11.11:0 MLDP: [vpnv4 10.1.0.2 232.1.1.1 1:1] label mappping msg sent to 11.11.11.11:0 success MLDP-DB: [vpnv4 10.1.0.2 232.1.1.1 1:1] path to peer: 11.11.11.11:0 changed None:0.0.0.0 to Ethernet0/3:10.0.2.2
Jede Kommunikation vom Empfänger (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 verwendet wird, beginnt die Erstellung der MLDP-Datenbank vom Empfänger zur Quelle. Dies ist die Downstream-Label-Zuweisung für P2MP MLDP.
P2MP MLDP
Die P2MP-Paketübertragung wird mithilfe des Resource Reservation Protocol (RSVP) P2MP - Traffic Engineering (P2MP-TE) implementiert, und die M2M-Paketübertragung wird mithilfe von Multicast Label Distribution Protocol (MLDP) über IPv4 Multicast VPN (MVPN) implementiert.
Das Paket wird über drei Routertypen übertragen:
· Headend-Router: Kapselt das IP-Paket mit einem oder mehreren Labels.
· Midpoint-Router: Ersetzt das In-Label durch ein Out-Label.
· Tailend-Router: Entfernt das Label aus dem Paket.
Paketfluss im MLDP-basierten MVPN-Netzwerk Für jedes eingehende Paket erstellt MPLS mehrere Out-Labels. Pakete aus dem Quellnetzwerk werden entlang des Pfads zum Empfängernetzwerk repliziert. Der CE1-Router sendet den nativen IP-Multicast-Datenverkehr. Der PE1-Router stellt ein Label auf dem eingehenden Multicast-Paket bereit und repliziert das markierte Paket in das MPLS-Core-Netzwerk. Wenn das Paket den Core-Router (P) erreicht, wird das Paket mit den entsprechenden Labels für den MP2MP-Standard-MDT oder den P2MP-Daten-MDT repliziert und an alle Egress-PEs übertragen. Sobald das Paket den Ausgangs-PE erreicht hat, wird das Label entfernt und das IP-Multicast-Paket auf die VRF-Schnittstelle repliziert
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 : 1 Type: P2MP Uptime : 00:23:11 FEC Root : 1.1.1.1 (we are the root) Opaque decoded : [vpnv4 10.1.0.2 232.1.1.1 1:1] Opaque length : 16 bytes Opaque value : FA 0010 0A010002E80101010000000100000001 Upstream client(s) : None Expires : N/A Path Set ID : 1 Replication client(s): 11.11.11.11:0 Uptime : 00:23:11 Path Set ID : None Out label (D) : 21 Interface : Ethernet0/1* Local label (U): None Next Hop : 10.0.1.2 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 : 2 Type: P2MP Uptime : 00:28:12 FEC Root : 1.1.1.1 Opaque decoded : [vpnv4 10.1.0.2 232.1.1.1 1:1] Opaque length : 16 bytes Opaque value : FA 0010 0A010002E80101010000000100000001 Upstream client(s) : 1.1.1.1:0 [Active] Expires : Never Path Set ID : 2 Out Label (U) : None Interface : Ethernet0/1* Local Label (D): 21 Next Hop : 10.0.1.1 Replication client(s): 3.3.3.3:0 Uptime : 00:28:12 Path Set ID : None Out label (D) : 26 Interface : Ethernet0/2* Local label (U): None Next Hop : 10.0.3.1 2.2.2.2:0 Uptime : 00:24:41 Path Set ID : None Out label (D) : 25 Interface : Ethernet0/3* Local label (U): None Next Hop : 10.0.2.1 RR-P#sh mpls forwarding-table labels 21 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 21 26 [vpnv4 10.1.0.2 232.1.1.1 1:1] \ 0 Et0/2 10.0.3.1 25 [vpnv4 10.1.0.2 232.1.1.1 1:1] \ 0 Et0/3 10.0.2.1
Auf PE-Geräten erstellte MRIB:
PE1#sh ip mroute vrf MLDP-INBAND 232.1.1.1 verbose IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet, U - URD, I - Received Source Specific Host Report, (10.1.0.2, 232.1.1.1), 00:00:17/00:02:42, flags: sTI Incoming interface: Ethernet0/2, RPF nbr 10.1.0.2 Outgoing interface list: Lspvif0, LSM ID: 1, Forward/Sparse, 00:00:17/00:02:42
Wenn die Quelle mit dem Streaming beginnt:
Wenn die Multicast-Quelle mit dem Senden von Datenverkehr beginnt, geschieht [10.1.0.2, 232.1.1.1], wie in diesem Bild gezeigt.
Datenverkehr vom Source 10.1.0.2-Streaming von 232.1.1.1. Wechselt über Ethernet0/2.
Das Paket wurde über Lspvif 0 weitergeleitet.
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
Dieses Paket wird in den LSPVIF 0 getunnelt.
Auf der Empfängerseite:
Auf der Empfängerseite die Paketreichweite am 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
Wenn das Paket den PE1 erreicht, überprüft es die LSM-ID, um den Datenverkehr weiterzuleiten, der im Multicast-Paket festgelegt werden soll.
Dieses Bild zeigt die Überprüfung der LSPVIF-Schnittstelle.
Für jedes eingehende Paket erstellt MPLS mehrere Out-Labels. Pakete aus dem Quellnetzwerk werden entlang des Pfads zum Empfängernetzwerk repliziert. Der CE1-Router sendet den nativen IP-Multicast-Datenverkehr. Der PE1-Router stellt ein Label auf dem eingehenden Multicast-Paket bereit und repliziert das markierte Paket in das MPLS-Core-Netzwerk.
Wenn das Paket den Core-Router (P) erreicht, wird das Paket mit den entsprechenden Labels für den MP2MP-Standard-MDT oder den P2MP-Daten-MDT repliziert und an alle Egress-PEs übertragen. Sobald das Paket den Ausgangs-PE erreicht hat, wird das Label entfernt und das IP-Multicast-Paket auf die VRF-Schnittstelle repliziert.
Zusammenfassung
Die MLDP-MVPN-Konfiguration ermöglicht die Bereitstellung von IPv4-Multicast-Paketen mithilfe von MPLS. Diese Konfiguration verwendet MPLS-Labels, um Standard- und Daten-Multicast Distribution Trees (MDTs) zu erstellen.
Die MPLS-Replikation wird als Weiterleitungsmechanismus im Core-Netzwerk verwendet. Damit die MLDP-MVPN-Konfiguration funktioniert, stellen Sie sicher, dass die globale MPLS-MLDP-Konfiguration aktiviert ist.
Feedback