Profil 0
Profil 1
Profil 3
Profil 11
Wie wir aus früheren Einträgen erfahren haben, gibt es im Backbone bei der Implementierung von mVPN immer ein Standard-MDT-Konstrukt, mit dem alle PE-Router verbunden sind. PIM-Servicemeldungen (z. B. Bootstrap, Auto-RP) sowie benutzerdefinierter Multicast-Verkehr werden in diesem MDT übertragen. Infolgedessen stellt sich heraus, dass einige PE-Geräte sogar den Datenverkehr empfangen, den sie nicht abonniert haben.
Wenn Sie wissen möchten, wie Sie damit umgehen sollen - willkommen unter dem Schnitt!
Um die Effizienz der Datenübertragung zu verbessern, wird eine zusätzliche Konstruktion verwendet, die als "Daten-MDT" bezeichnet wird. Die Idee dahinter ist wie folgt:
- Innerhalb des Baums wird nur C- (S, G) Verkehr verteilt
- Nur diejenigen Egress-PEs, die interessierte Empfänger haben, werden Mitglieder des Baums
- Das Root-Data-MDT-Gerät ist das Ingress PE (der Router, hinter dem sich die Quelle befindet).
Optisch sieht es so aus:
Wenn wir uns eine Situation vorstellen, in der die Quelle mit der Übertragung an die zweite Multicast-Gruppe (230.1.1.2) beginnt, für die sich die Empfänger nur hinter PE2 und PE3 befinden, wird ein zusätzlicher Daten-MDT erstellt und das Gesamtbild erhält die Form (Standard-MDT wird weggelassen):
Die Signalisierung für die Verkehrsumschaltung von Standard-MDT zu Daten-MDT erfolgt ausschließlich bei Bedarf, wenn ein vorgegebener Schwellenwert vom Ingress PE entweder mittels PIM oder mittels BGP überschritten wird .
Daten-MDT mit PIM
Wenn PIM für die Signalisierung verwendet wird, generiert das Eingangs-PE eine spezielle PIM-Daten-MDT-TLV-Nachricht und sendet sie als Teil des Standard-MDT, um sicherzustellen, dass alle PEs die Nachricht empfangen können. Gleichzeitig mit dem Senden des Data MDT TLV startet Ingress PE einen Timer, der drei Sekunden entspricht. Nach Ablauf des Timers werden alle Pakete innerhalb von Data MDT übertragen.
Es ist auch zu beachten, dass die im Data-MDT-TLV enthaltenen Informationen auf allen PEs zwischengespeichert werden. Der Grund dafür ist ziemlich trivial - selbst wenn es momentan keine interessierten Verkehrsempfänger in einem bestimmten PE gibt, können sie nach einer Weile dort erscheinen. Dementsprechend kann der PE beim Empfang eines PIM-Joins (innerhalb des C-VRF) sofort eine Verbindung zu dem bereits im Netzwerk vorhandenen Daten-MDT herstellen.
Ca. Daten-MDT-TLVs werden einmal pro Minute übertragen.
Jeder Daten-MDT ist für eine separate (S, G) Route innerhalb des VPN / VRF eingerichtet. Der Administrator muss explizit die maximale Anzahl von Daten-MDTs angeben, die auf dem Gerät generiert werden können. Wenn die Anzahl der neu installierten Bäume irgendwann die angegebene Grenze erreicht, werden die bereits installierten Bäume von den nächsten Bäumen wiederverwendet.
Ca. Zum jetzigen Zeitpunkt unterstützt Cisco IOS keine PIM-Signalisierung über Data MDT. Alle Profile mit diesem Alarm sind nur unter dem Betriebssystem IOS XR verfügbar.
Daten-MDT mit BGP
Bei Verwendung von BGP in einem Overlay-Netzwerk für die Daten-MDT-Signalisierung bleiben die Grundprinzipien dieselben (im Vergleich zu PIM):
- Eingangs-PE-Signale an alle PEs, dass der Verkehr für C- (S, G) innerhalb von Data MDT übertragen wird
- Egress PE tritt nach Erhalt eines BGP-Updates dem angegebenen Baum bei
- Die mVPN-Adressierungsfamilie (sAFI 129) wird zur Signalisierung verwendet.
Es stellt sich heraus, dass das Ingress PE eine spezielle BGP-Aktualisierungsnachricht bilden und diese an alle PEs innerhalb des mVPN senden muss. Hierzu wird eine Route des dritten Typs verwendet.
Profil 14
Betrachten wir den beschriebenen Übergang am Beispiel unseres Labors. Insbesondere ist die als "Profil 14" bekannte Konfiguration anwendbar. Dieses Profil ist durch die Verwendung von BGP mVPN AD zum Erstellen von P2MP-MLDP-LSPs gekennzeichnet.
Auf PE verwenden wir die folgende Konfigurationsvorlage:
ip vrf C-ONE mdt auto-discovery mldp mdt partitioned mldp p2mp mdt overlay use-bgp mdt strict-rpf interface ! router bgp 1 address-family ipv4 mvpn neighbor 8.8.8.8 activate neighbor 8.8.8.8 send-community extended exit-address-family
Ca. Wir
mdt strict-rpf
werden in der nächsten Ausgabe über den Zweck des Befehls interface sprechen.
Automatische Erkennung
Mal sehen, was auf PE1 passiert:
Auf jedem PE wird eine Lspvif0-Schnittstelle erstellt, auf der C-PIM aktiviert ist.
*Dec 3 10:04:54.450: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up
Im Moment gibt es keine Nachbarn:
PE1#show ip pim vrf C-ONE int Address Interface Ver/ Nbr Query DR DR Mode Count Intvl Prior 172.1.11.1 GigabitEthernet2.111 v2/S 1 30 1 172.1.11.11 172.1.15.1 GigabitEthernet2.115 v2/S 1 30 1 172.1.15.15 1.1.1.1 Lspvif0 v2/S 0 30 1 1.1.1.1
Sehen wir uns die BGP-Tabelle an:
PE1#show bgp ipv4 mvpn all BGP table version is 39, local router ID is 1.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, t secondary path, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1.1.1.1:1 (default for vrf C-ONE) *> [1][1.1.1.1:1][1.1.1.1]/12 0.0.0.0 32768 ? *>i [1][1.1.1.1:1][2.2.2.2]/12 2.2.2.2 0 100 0 ? *>i [1][1.1.1.1:1][3.3.3.3]/12 3.3.3.3 0 100 0 ? *>i [1][1.1.1.1:1][4.4.4.4]/12 4.4.4.4 0 100 0 ? Route Distinguisher: 2.2.2.2:1 *>i [1][2.2.2.2:1][2.2.2.2]/12 2.2.2.2 0 100 0 ? Route Distinguisher: 3.3.3.3:1 Network Next Hop Metric LocPrf Weight Path *>i [1][3.3.3.3:1][3.3.3.3]/12 3.3.3.3 0 100 0 ? Route Distinguisher: 4.4.4.4:1 *>i [1][4.4.4.4:1][4.4.4.4]/12 4.4.4.4 0 100 0 ? Route Distinguisher: 1.1.1.1:1 (default for vrf C-ONE) *> [3][1.1.1.1:1][*][*][1.1.1.1]/14 0.0.0.0 32768 ? *>i [3][1.1.1.1:1][*][*][2.2.2.2]/14 2.2.2.2 0 100 0 ? *>i [3][1.1.1.1:1][*][*][3.3.3.3]/14 3.3.3.3 0 100 0 ? *>i [3][1.1.1.1:1][*][*][4.4.4.4]/14 4.4.4.4 0 100 0 ? *> [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/18 0.0.0.0 32768 ? Route Distinguisher: 2.2.2.2:1 *>i [3][2.2.2.2:1][*][*][2.2.2.2]/14 2.2.2.2 0 100 0 ? Route Distinguisher: 3.3.3.3:1 *>i [3][3.3.3.3:1][*][*][3.3.3.3]/14 3.3.3.3 0 100 0 ? Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 4.4.4.4:1 *>i [3][4.4.4.4:1][*][*][4.4.4.4]/14 4.4.4.4 0 100 0 ?
Wie Sie sehen können, werden zusätzlich zu den Routen des ersten Typs, die bereits zuvor betrachtet wurden, die Routen des dritten Typs S-PMSI AD hinzugefügt, mit denen PE als Ingress-Router für eine bestimmte C- (S, G) -Gruppe angekündigt wird. Im Moment ist die Gruppe (*, *). Dies zeigt, dass PE bereit ist, sich am Aufbau von partitioniertem MDT zu beteiligen.
Damit die Datenübertragung funktioniert, müssen die Rendezvous-Punktinformationen in der VRF bekannt sein. In unserem Fall fungiert CE15 als RP und BSR.
C-RP#sh run | i pim ip pim bsr-candidate Loopback0 0 ip pim rp-candidate Loopback0
Da der C-RP mit PE1 eine PIM-Nachbarschaft aufgebaut hat, sind die Informationen zu RP auch auf diesem PE1 bekannt:
PE1#show ip pim vrf C-ONE rp mapping Auto-RP is not enabled PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 15.15.15.15 (?), v2 Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150 Uptime: 01:25:50, expires: 00:01:26
Es ist notwendig, diese Informationen an alle anderen PE / CEs weiterzuleiten. Wie kann man das machen? Um das Prinzip besser zu verstehen, schlage ich vor, vom Gegenteil auszugehen und die bereits bekannten Informationen zu CE2 zu betrachten:
CE2#show ip pim rp mapping Auto-RP is not enabled PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 15.15.15.15 (?), v2 Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150 Uptime: 01:27:54, expires: 00:02:26
Wie Sie sehen können, haben sich die PIM-BSR-Nachrichten über die mVPN-Infrastruktur verteilt. Sehen wir uns den Traffic Dump auf PE1 an:
Wie Sie sehen können, kapselt PE1 die PIM-BSR-Nachricht in MPLS und kennzeichnet sie mit 28. Woher kommt sie? Wir können davon ausgehen, dass dieses Paket CE2 (und damit PE2) erreicht hat, dh einige LSP vor PE2.
PE2#show 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 : 04:17:40 FEC Root : 2.2.2.2 (we are the root) Opaque decoded : [gid 65536 (0x00010000)] Opaque length : 4 bytes Opaque value : 01 0004 00010000 Upstream client(s) : None Expires : N/A Path Set ID : 1 Replication client(s): > MDT (VRF C-ONE) Uptime : 04:17:40 Path Set ID : None Interface : Lspvif0 RPF-ID : * LSM ID : 3 Type: P2MP Uptime : 01:30:06 FEC Root : 1.1.1.1 Opaque decoded : [gid 131071 (0x0001FFFF)] Opaque length : 4 bytes Opaque value : 01 0004 0001FFFF Upstream client(s) : 6.6.6.6:0 [Active] Expires : Never Path Set ID : 3 Out Label (U) : None Interface : GigabitEthernet2.26* Local Label (D): 34 Next Hop : 10.2.6.6 Replication client(s): MDT (VRF C-ONE) Uptime : 01:30:06 Path Set ID : None Interface : Lspvif0 RPF-ID : *
Aus der Analyse der mLDP-Datenbank ist ersichtlich, dass auf PE2 ein bestimmter Baum (LSM ID: 3) vorhanden ist, dessen Wurzel PE1 (IP = 1.1.1.1), Opaque = 01 0004 0001FFFF ist, und für diesen Baum wurde ein lokales Label 34 generiert, das an den Nachbarn R6 gesendet wurde ( P2).
Woher wusste PE2 von dem Baum, dessen Wurzel PE1 ist, und bekam sogar eine Undurchsichtigkeit dafür? Die Antwort ist einfach - mit BGP-Routentyp 3.
Als PE1 das PIM-BSR empfing, wurde eine zusätzliche BGP-Route generiert, die die Gruppe beschreibt (*, 224.0.0.13) (denken Sie daran, dass dies eine reservierte Adresse zum Senden aller PIM-Dienstnachrichten ist). Diese Route dient dazu, einen neuen mLDP-Multicast-Baum anzukündigen. Innerhalb des PTA befindet sich der undurchsichtige Wert, der für die Signalisierung über mLDP verwendet werden soll.
PE1#show bgp ipv4 mvpn all route-type 3 * 224.0.0.13 1.1.1.1 BGP routing table entry for [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/18, version 116 Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer) Advertised to update-groups: 1 Refresh Epoch 1 Local 0.0.0.0 from 0.0.0.0 (1.1.1.1) Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best Community: no-export Extended Community: RT:65001:1 PMSI Attribute: Flags: 0x0, Tunnel type: 2, length 17, label: exp-null, tunnel parameters: 0600 0104 0101 0101 0007 0100 0400 01FF FF rx pathid: 0, tx pathid: 0x0
Durch den Import dieser Route kann PE2 somit die mLDP-Signalisierung in Richtung PE1 für den Baum initiieren (*, 224.0.0.13). Für das von PE2 empfangene Etikett generiert P2 (R6) ein eigenes lokales (29) und sendet es an P1 (R5):
P2#show 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 : 01:40:24 FEC Root : 1.1.1.1 Opaque decoded : [gid 131071 (0x0001FFFF)] Opaque length : 4 bytes Opaque value : 01 0004 0001FFFF Upstream client(s) : 5.5.5.5:0 [Active] Expires : Never Path Set ID : 2 Out Label (U) : None Interface : GigabitEthernet2.56* Local Label (D): 29 Next Hop : 10.5.6.5 Replication client(s): 2.2.2.2:0 Uptime : 01:40:24 Path Set ID : None Out label (D) : 34 Interface : GigabitEthernet2.26* Local label (U): None Next Hop : 10.2.6.2
P1 (R5) macht dasselbe, generiert seine lokale Bezeichnung für den Baum und sendet sie an PE1:
P1#show 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 : 01:41:24 FEC Root : 1.1.1.1 Opaque decoded : [gid 131071 (0x0001FFFF)] Opaque length : 4 bytes Opaque value : 01 0004 0001FFFF Upstream client(s) : 1.1.1.1:0 [Active] Expires : Never Path Set ID : 2 Out Label (U) : None Interface : GigabitEthernet2.15* Local Label (D): 28 Next Hop : 10.1.5.1 Replication client(s): 4.4.4.4:0 Uptime : 01:41:24 Path Set ID : None Out label (D) : 34 Interface : GigabitEthernet2.45* Local label (U): None Next Hop : 10.4.5.4 7.7.7.7:0 Uptime : 01:41:24 Path Set ID : None Out label (D) : 30 Interface : GigabitEthernet2.57* Local label (U): None Next Hop : 10.5.7.7 6.6.6.6:0 Uptime : 01:41:24 Path Set ID : None Out label (D) : 29 Interface : GigabitEthernet2.56* Local label (U): None Next Hop : 10.5.6.6
Visuell ist der gesamte Prozess in der folgenden Abbildung dargestellt:
Beitreten zu einem freigegebenen Baum und Erstellen eines P2MP-Stammbaums (ROOT = RP-PE)
Schritt 2. Im Netzwerk wird ein Verkehrsempfänger angezeigt. Nachdem Egress PE (PE2) einen PIM-Join von CE für C - (*, G) erhalten hat, führt PE2 eine RPF-Prüfung durch, um BGP Next-Hop in Richtung C-RP zu finden. Found Next-Hop (1.1.1.1) wird als partitionierter MDT-ROOT für mLDP verwendet.
Zusätzlich erstellt PE2 eine Lspvif-Schnittstelle innerhalb des C-VRF:
PE2# *Dec 3 14:46:21.606: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif1, changed state to up PE2# *Dec 3 14:46:22.310: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 2.2.2.2 on interface Lspvif1
Schritt 3. Egress PE (PE2) generiert eine mLDP-Zuordnungsnachricht in Richtung RP-PE (ROOT P2MP MDT) unter Verwendung des undurchsichtigen Werts aus dem BGP-Update.
PE2#show mpls mldp database summary LSM ID Type Root Decoded Opaque Value Client Cnt. 4 P2MP 1.1.1.1 [gid 65536 (0x00010000)] 1 1 P2MP 2.2.2.2 [gid 65536 (0x00010000)] 1 3 P2MP 1.1.1.1 [gid 131071 (0x0001FFFF)] 1 PE2# PE2#show mvpn ipv4 vrf C-ONE auto-discovery s-pmsi * * detail I-PMSI - Intra-AS Inclusive-PMSI, S-PMSI - Selective-PMSI * - Indicates Wildcard source or group address [S-PMSI][1.1.1.1:1][*][*][1.1.1.1], Joined Orig: Remote Uptime: 04:44:27 Type: MLDP P2MP Root: 1.1.1.1 Fec-Opq: 1 Global-Id: 65536 (0x10000) [S-PMSI][3.3.3.3:1][*][*][3.3.3.3], Orig: Remote Uptime: 04:44:22 Type: MLDP P2MP Root: 3.3.3.3 Fec-Opq: 1 Global-Id: 65536 (0x10000) [S-PMSI][4.4.4.4:1][*][*][4.4.4.4], Orig: Remote Uptime: 04:44:20 Type: MLDP P2MP Root: 4.4.4.4 Fec-Opq: 1 Global-Id: 65536 (0x10000) [S-PMSI][2.2.2.2:1][*][*][2.2.2.2], Joined Orig: Local Uptime: 04:44:24 Type: MLDP P2MP Root: 2.2.2.2 Fec-Opq: 1 Global-Id: 65536 (0x10000) PE2#show mpls mldp database opaque_type gid 65536 LSM ID : 4 Type: P2MP Uptime : 00:03:43 FEC Root : 1.1.1.1 Opaque decoded : [gid 65536 (0x00010000)] Opaque length : 4 bytes Opaque value : 01 0004 00010000 Upstream client(s) : 6.6.6.6:0 [Active] Expires : Never Path Set ID : 4 Out Label (U) : None Interface : GigabitEthernet2.26* Local Label (D): 35 Next Hop : 10.2.6.6 Replication client(s): MDT (VRF C-ONE) Uptime : 00:03:43 Path Set ID : None Interface : Lspvif1 RPF-ID : 0x1
Schritt 4. Egress PE generiert eine BGP-Route des sechsten Typs (Verbinden des gemeinsamen Baums in Richtung RP-PE). Diese Route wird nur in RP-PE importiert.
PE2#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 230.1.1.1 BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][230.1.1.1/32]/22, version 130 Paths: (1 available, best #1, table MVPNv4-BGP-Table) Advertised to update-groups: 1 Refresh Epoch 1 Local 0.0.0.0 from 0.0.0.0 (2.2.2.2) Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best Extended Community: RT:1.1.1.1:1 rx pathid: 1, tx pathid: 0x0
Schritt 5. RP-PE übersetzt die empfangene BGP-Route des sechsten Typs im PIM-Join in Richtung RP. Zu diesem Zeitpunkt ist der RP bereit, Multicast-Verkehr in Richtung Egress PE zu senden. Sie müssen Datenverkehr von der Quelle zum RP liefern.
PE1#show ip mroute vrf C-ONE | b \( (*, 230.1.1.1), 00:07:08/stopped, RP 15.15.15.15, flags: SG Incoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.15 Outgoing interface list: Lspvif0, Forward/Sparse, 00:07:08/stopped
Schritt 6. Wenn S-PE (PE4) das erste Multicast-Paket von der Quelle (CE4) empfängt, wird der Datenverkehr in die PIM-Registernachricht eingekapselt und als Unicast-Paket an das C-RP gesendet (unter Verwendung normaler MPLS L3-VPN-Regeln).
Schritt 7. Nach Erhalt des PIM-Registers beginnt der C-RP mit dem Erstellen des C-Baums (14.14.14.14, 230.1.1.1). RP-PE erhält PIM Join für C- (14.14.14.14, 230.1.1.1) von C-RP. Diese Nachricht wird in den BGP-Routentyp 7 übersetzt. Vor dem Senden an die Quellseite müssen Sie jedoch einen neuen partitionierten MDT-Baum mit PE als ROOT erstellen.
Schritt 8. RP-PE führt RPF-Überprüfungen durch, um BGP Next-Hop in Richtung der Quelle zu finden. Diese Adresse wird als partitionierter MDT-ROOT für mLDP verwendet.
Schritt 9. Unter Verwendung der empfangenen BGP Next-Hop- und BGP-Route des dritten Typs von Ingress PE generiert RP-PR eine mLDP-Zuordnungsnachricht zur Ingress PE-IP-Adresse, wodurch der P2MP-Stammbaum für Ingress PE erstellt wird.
Schritt 10. RP-PE sendet die BGP-Route Typ 7 (Join from RP) in Richtung Ingress PE.
Schritt 11. Ingress PE konvertiert die empfangene BGP-Route des siebten Typs in PIM Join und sendet sie an die Verkehrsquelle.
An den Quellbaum anhängen und P2MP erstellen (ROOT = S-PE)
Schritt 12. Das Ingress PE sendet auch eine BGP-Route vom Typ 5 an alle mVPN-PEs, um sie darüber zu informieren, dass eine aktive Quelle im Netzwerk vorhanden ist. Diese Route ist ein Auslöser für den Wechsel zum SPT-Baum.
Schritt 13. Egress PE verwendet den empfangenen BGP-Routentyp 5, um eine mLDP-Zuordnungsnachricht in Richtung Ingress PE zu generieren (MDT-Informationen stammen aus BGP-Routentyp 3).
Somit kann der Datenverkehr jetzt mithilfe von mpls (mLDP) -Tags optimal von der Quelle zum Ziel umgeleitet werden.
