Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Architektur

Welche Änderungen werden mit RFC 6513/6514 vorgenommen?

Konfigurationsänderungen

Routenankündigung

Beispiele

Beispiel 1: Profil 12: Standard-MDT - mLDP - P2MP - BGP-AD - BGP C-mcast Signaling

Konfiguration

Fehlerbehebung

Eingangsgrenzrouter

Ausgangs-Border-Router

Beispiel 2: Profil 20 Standard-MDT - P2MP-TE - BGP-AD - PIM - C-Multicast-Signalisierung

Konfiguration

Fehlerbehebung

Eingangsgrenzrouter

Ausgangs-Border-Router

Beispiel 3: Wie in Beispiel 1, aber es gibt iBGP zwischen PE und Border Router

Beispiel 4: Nahtloses MPLS

Einleitung

Dieses Dokument beschreibt die nicht segmentierte Global Table Multicast (GTM) für mVPN.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle verstehen.

Hintergrundinformationen

NG mVPN (RFC 6513/6514) hat viele Profile. Die meisten Profile verfügen über Virtual Private Network (VPN) oder Virtual Routing/Forwarding (VRF) an den PE-Routern. Einige Profile (Profile 7 und befinden sich im globalen Kontext. Für diese bereits globalen Profile wird BGP Auto Discovery (AD) mit GTM eingeführt. Für die Profile, die sich im VRF-Kontext befinden, sind die Profile jetzt im globalen Kontext mit dem Multicast Distribution Tree (MDT) verfügbar. Dies sind alle nicht segmentierten GTM-Modelle. Die von nicht segmentiertem GTM verwendeten Verfahren werden in IETF draft-ietf-bess-mvpn-global-table-mcast beschrieben.

RFC 7524 und Draft-ietf-bess-mvpn-global-table-mcast (RFC 7716) erfordern, dass die GTM-Quelladressen über BGP-Unicast-Routen erreichbar sind (entweder address-family ipv4 unicast oder address-family ipv4 multicast).

Der Vorteil des Draft-ietf-bess-mvpn-global-table-mcast gegenüber RFC 7524 besteht darin, dass die gleichen Verfahren wie für reguläres NG mVPN (RFC 6514) verwendet werden.

Mit GTM kann das mVPN nicht segmentiert oder segmentiert werden.

Architektur

In diesem Artikel wird der Begriff Border Router für einen ABR, ASBR oder Aggregation Router verwendet, der zwei Segmente des Netzwerks verbindet. Typischerweise befindet sich der ABR in nahtlosen MPLS-Netzwerken. Der ASBR wird bei Verwendung eines Inter-AS MPLS VPN verwendet. Der Aggregation Router wird verwendet, wenn ein nicht segmentierter GTM-Overlay-Router die beiden Teile des Core-Netzwerks verbindet, wenn beide Teile ein anderes Multicast Core Tree-Protokoll ausführen. Der Aggregation Router kann beispielsweise den PIM-Teil des Core-Netzwerks mit dem mLDP-Teil des Core-Netzwerks verbinden.

Für jedes Modell kann SAFI 2 verwendet werden. Der Vorteil besteht darin, dass SAFI 2 eine andere Topologie als SAFI 1 haben kann. Daher kann die RPF für Multicast geändert werden, ohne die Unicast-Weiterleitung zu ändern.

Ein Border Router unterstützt keine Dual-Kapselung. Dies bedeutet, dass der Router Multicast nicht auf zwei oder Modi gleichzeitig Core-Tree-Protokolle weiterleiten kann. Dies kann normalerweise verwendet werden, wenn Sie von einem Core-Tree zu einem anderen migrieren. Während der Migration wird der Eingangs-PE an beide Core-Trees weitergeleitet. Bei Grenzroutern ist dies nicht möglich.

Die GTM-Architektur unterstützt nicht segmentierte und segmentierte GTM. In diesem Dokument wird nur das nicht segmentierte Segment Translation Memory (GTM) behandelt.

Die Verfahren für nicht segmentiertes GTM-Overlay sind in draft-ietf-bess-mvpn-global-table-mcast beschrieben. Es werden die gleichen Verfahren wie in RFC 6513/6514 mit einigen Änderungen befolgt.

Welche Änderungen werden mit RFC 6513/6514 vorgenommen?

Mit GTM gelten die nächsten Punkte. Einige sind identisch mit RFC 6513/6514, andere wiederum unterschiedlich.

- SFS (Single Forwarding Selection) wird nicht unterstützt.

- AF IPv6 wird unterstützt.

- Die C-PIM- und C-BGP-Signalisierung wird unterstützt.

- An den zum Netzwerk-Edge gerichteten Schnittstellen der PE-Router ist kein VRF vorhanden. Diese Schnittstellen sind jetzt global. Diese Router werden im Draft-ietf-bess-mvpn-global-table-mcast als Protocol Boundary Router (PBR) bezeichnet. Diese Router sind mit einem LSM-Core-Tree-Protokoll und PIM verbunden. Wir nennen diese Router die Grenzrouter.

- Im Core-Netzwerk wird ein LSM-Core-Protokoll (Label Switched Multicast) ausgeführt.

- mLDP, P2MP TE (statisch und dynamisch) und IR werden unterstützt.

- Standard-, partitionierte und Daten-MDTs werden unterstützt.

- Da GTM keine VPNv4/6-Präfixe enthält, sind VRF Route-Import EC und Source-AS EC mit den IPv4-Unicast- (SAFI 1) oder Multicast- (SAFI 2) Präfixen verbunden.

Die Routen-Typen 1, 3 und 5 verfügen über RTs. In Cisco IOS® XR müssen diese RTs für GTM vorhanden sein, auch wenn dies laut Entwurf nicht erforderlich ist. Damit GTM verwendet werden kann, müssen die RTs unter BGP konfiguriert werden. Diese RTs ähneln den RTs, die in den VRFs für reguläre mVPNs verwendet werden. Sie gelten jedoch jetzt für den globalen Kontext.

Die Routentypen 4, 6 und 7 übertragen ein RT, das den Upstream-PE-Router identifiziert. Das Feld für den globalen Administrator ist die IP-Adresse des Upstream-PE. Das Feld für den lokalen Administrator ist für GTM auf 0 gesetzt (es identifiziert die VRF-Instanz in einem nicht GTM-fähigen oder regulären mVPN).

Die PE-Router werden zu verbindenden Routern zwischen einem Label Switched Multicast (LSM) Core Tree Protocol (mLDP, P2MP Traffic Engineering, Ingress Replication (IR)) und PIM. Es gibt also einen Teil des Core-Netzwerks, der LSM ausführt, und einen Teil des Core-Netzwerks, der PIM ausführt. Rufen wir die Core-Router an, die als Schnittstelle zwischen dem LSM-Teil des Netzwerks und dem PIM-Teil des Netzwerks fungieren, den Border Router. In einigen der folgenden Beispiele werden sie als C-PE-Router (C für Core) bezeichnet.

Bei diesen Grenzroutern handelt es sich um die Router mit der für GTM erforderlichen Konfiguration. Keiner der anderen Router ist GTM-fähig.

Die Konfiguration für GTM ähnelt der für die regulären mVPN-Profile erforderlichen Konfiguration. Es ist lediglich so, dass sich die Schnittstellen zum Edge nicht in einer VRF-Instanz befinden.

Es gibt keinen regulären Route Distinguisher, da es keine VRFs gibt. Da es keine regulären Route Distinguishers (RDs) gibt, aber RDs für die Signalisierung mit BGP verwendet werden, werden für die Signalisierung in GTM RDs mit Nullen und RDs mit Einsen verwendet. Damit diese Funktion genutzt werden kann, muss der BGP-Befehl "global-table-multicast" konfiguriert werden.

Bei GTM befinden sich die Unicast-Routen nicht in VPNv4/6. Daher muss die Unicast-Erreichbarkeit im BGP in AF IPv4 oder AF IPv6 und SAFI 1 oder SAFI 2 bereitgestellt werden. Das bedeutet, dass zwischen den Grenzroutern (PE-Router ohne VRF) weiterhin BGP verwendet werden muss.Siehe Abbildung 1.

Bild 1

Zwischen den Border und den CE-Routern befindet sich kein BGP. Der Border Router fügt die Multicast-Attribute hinzu, wenn er die Routen im iBGP den anderen Border Routern ankündigt.

Dabei ist zu beachten, dass zwischen den CE- und PE-Routern BGP vorhanden sein kann. Siehe Bild 2.

Bild 2

In diesem Fall fügt der PE-Router die Multicast-Attribute hinzu, wenn er die Unicast-Routen vom eBGP in das iBGP zu den anderen PE-Routern weiterleitet. Wenn der CE dem PE-Router die Unicast-Routen mit Multicast-Attributen bereits angekündigt hat, behält der PE-Router die Multicast-Attribute unverändert bei und leitet die Unicast-Routen an die anderen PE-Router weiter. Standardmäßig werden bei eBGP-Sitzungen die Multicast-Attribute entfernt. Wenn die PE-Routen den CE-Routen also die Unicast-Routen vom iBGP im eBGP ankündigen, gibt es keine Multicast-Attribute.

Wenn der PE-Router das Unicast-Präfix über iBGP ankündigt, fügt er den Extended Community (EC) VRF Route Import (VRF-RI) und das EC Source-AS an. Diese werden vom anderen PE-Router entfernt, bevor diese Routen im eBGP propagiert werden.

Wenn sich die eBGP-Sitzung zwischen zwei ASBRs befindet, gibt es Inter-AS MPLS VPN und Inter-AS mVPN. Die Multicast-Attribute können dann beibehalten werden. Da das Standardverhalten darin besteht, sie in einer eBGP-Sitzung zu entfernen, müssen Sie den Befehl send-multicast-attribute in der eBGP-Sitzung zwischen den beiden ASBRs konfigurieren.

Wenn ein RR vorhanden ist, kann eine Übertragung vom iBGP zum iBGP erfolgen. Dies ist beim Inline-ABR (Next-Hop-Self) von Seamless MPLS der Fall. Da das Standardverhalten darin besteht, die Multicast-Attribute für iBPG-Sitzungen beizubehalten, muss der Inline-ABR den Befehl send-multicast-attribute-disable aufweisen, um sie zu entfernen.

Konfigurationsänderungen

Sie müssen Global-Table-Multicast unter der Adressfamilie (AF) ipv4 mVPN unter Router BGP konfigurieren. Dies ermöglicht den Betrieb von RDs mit Nullen und RDs mit Einsen.

Sie müssen import-rt und export-rt unter Multicast-Routing für AF ipv4 im globalen Kontext konfigurieren. Dies liegt daran, dass keine RTs mehr für die VRFs konfiguriert sind, da GTM keine VRFs hat. Diese RTs dürfen sich nicht mit den RTs überschneiden, die für reguläre mVPNs verwendet werden.

Die Router-PIM-Befehle (rpf topology und mdt-Befehle) werden jetzt im globalen Kontext konfiguriert.

Die Multicast-Routing-Befehle (bgp auto-discovery- und mdt-Befehle) werden jetzt im globalen Kontext konfiguriert.

Routenankündigung

Zwischen den Grenzroutern befindet sich das iBGP, das die Quellpräfixe ankündigt. Wie kann der Eingangsgrenzrouter das Quellpräfix erlernen? Es gibt drei Möglichkeiten.

Abbildung 3 zeigt diese drei möglichen Szenarien.

Bild 3

1. Der Border Router hat die Präfixe vom PE als Nicht-BGP-Präfixe empfangen. Der Border Router muss diese Präfixe im BGP neu verteilen. Dieser Border Router fügt die Multicast-Attribute hinzu.

2. Die Grenzrouter senden eine eBGP-Sitzung zu den PE-Routern. Der Border Router fügt die Multicast-Attribute hinzu, bevor er das Präfix über iBGP an die anderen Border Router weitergibt. Wenn die über die eBGP-Sitzung empfangenen Präfixe bereits über die Multicast-Attribute verfügen, werden diese beibehalten und weitergeleitet. Der Border Router überschreibt sie nicht.

3. Der Ingress Border Router bezieht das Source-Präfix vom iBGP. In diesem Fall ist der Ingress Border Router ein RR. Dieses Szenario wird in nahtlosem MPLS verwendet, bei dem die Grenz-Router ABRs sind.

Wenn der Border Router ein empfangenes iBGP-Präfix von einem anderen Border Router ankündigt, entfernt er die Multicast-Attribute, bevor er das Präfix an den PE-Router sendet. Dazu muss der Befehl send-multicast-attribute auf den Grenzroutern unter dem Router-BGP deaktiviert sein.

Beispiele

Hier einige Beispiele. Das erste Beispiel beginnt mit der Transformation von Profil 12 in eine GTM-Bereitstellung.

Beispiel 1: Profil 12: Standard-MDT - mLDP - P2MP - BGP-AD - BGP C-mcast Signaling

Abbildung 4 zeigt dieses Netzwerk. Auf dem PE-Router zum CE-Router ist keine VRF-Instanz vorhanden.

Bild 4

Beachten Sie, dass im inneren Core-Netzwerk mLDP ausgeführt wird. Auf dem äußeren Core-Netzwerk wird PIM ausgeführt. Daher müssen die Grenzrouter, die den PIM mit dem mLDP-Core verbinden, PIM in mLDP umwandeln und umgekehrt.

Die Quelle kann nicht als IGP-Route auf dem Grenzrouter, Router C-PE2, ermittelt werden. Die IGP ist hier ISIS. Wenn dies der Fall ist, verwendet der RPF auf dem Grenz-Router die ISIS-Route, die auf P1 verweist. In diesem Fall schlägt der RPF fehl, da keine PIM-Nachbarschaft besteht. Der C-PE2-Router soll RPF für 10.2.1.8 verwenden und auf den MDT als RPF-Schnittstelle verweisen. Hierbei kann es sich um einen MDT handeln, der auf mLDP, P2MP oder IR basiert.

Die Lösung ist die Verwendung von SAFI 2. Sie wird verwendet, damit die Quelle im BGP als AFI 2-Route erfasst wird. Der Border Router (C-PE2) hat die Quelle daher als BGP-SAFI-2-Route (zeigt Route IPv4 Multicast). Die RPF für die Quelle verweist auf die MDT-Schnittstelle.

Bei Verwendung von SAFI 2 wird die RPF geändert, und bei RPF für alle Quellen wird jetzt SAFI 2 verwendet. Das bedeutet, dass RPF für alle Quellen weltweit SAFI 2 verwendet, d. h. RPF für den Eingangs-PE, z. B. für den VPN-Service. Nach der Aktivierung von SAFI 2 erfolgen alle RPF nur über SAFI 2. Da sich nur die Quellen in SAFI 2 befinden, schlägt die RPF für die Eingangs-PE-Router fehl. Damit dies funktioniert, können Sie den Befehl rump always-replicate unter der Router-Rippe konfigurieren. Da nur RPF für die Source-Präfixe global und RPF für die PE-Router funktionieren müssen, können Sie eine Zugriffsliste für den Befehl rump always-replicate konfigurieren und nur die Sources global und die Ingress-PE-Router in der Zugriffsliste angeben. Wenn also auf dem Border Router bereits BGP für SAFI 1 ausgeführt wird und dieses SAFI 1 eine große Anzahl von Präfixen enthält, werden diese Präfixe nicht alle in die SAFI 2 RIB umverteilt und verwenden den Speicher unnötig.

Alternativ dazu können Sie für die Adressfamilie "ipv4 multicast" unter Router-BGP die Distanz "bgp 20 20 20" konfigurieren. Dadurch wird sichergestellt, dass, wenn die Quellen auf globaler Ebene auch über AFI 2 des IGP erfasst werden, die vom BGP ermittelten Quellen aufgrund der geringeren Entfernung des iBGP im Vergleich zur Entfernung des IGP bevorzugt werden.

Konfiguration

Dies ist die Konfiguration des Border Routers.

hostname C-PE1

router rib

address-family ipv4

rump always-replicate

!

route-policy global-one

set core-tree mldp-default

end-policy

!

route-policy sources-in-ISIS

if destination in (10.2.1.0/24) then

pass

endif

end-policy

!

router isis 1

is-type level-1

net 49.0001.0000.0000.0003.00

address-family ipv4 unicast

metric-style wide

mpls traffic-eng level-1

mpls traffic-eng router-id Loopback0

!

interface Loopback0

address-family ipv4 unicast

!

address-family ipv4 multicast

!

!

interface GigabitEthernet0/0/0/0

address-family ipv4 unicast

!

address-family ipv4 multicast

!

!

interface GigabitEthernet0/0/0/1

address-family ipv4 unicast

!

address-family ipv4 multicast

!

!

!

router bgp 1

address-family ipv4 unicast

!

address-family ipv4 multicast

redistribute connected route-policy loopback

redistribute isis 1 route-policy sources-in-ISIS

!

address-family ipv4 mvpn

global-table-multicast

!

neighbor 10.100.1.5

remote-as 1

update-source Loopback0

address-family ipv4 multicast

next-hop-self

!

address-family ipv4 mvpn

!

!

mpls ldp

mldp

address-family ipv4

rib unicast-always

!

!

router-id 10.100.1.3

address-family ipv4

!

interface GigabitEthernet0/0/0/0

address-family ipv4

!

!

interface GigabitEthernet0/0/0/1

address-family ipv4

!

!

!

multicast-routing

address-family ipv4

interface Loopback0

enable

!

interface GigabitEthernet0/0/0/1

enable

!

mdt source Loopback0

export-rt 1:1

import-rt 1:1

bgp auto-discovery mldp

!

mdt default mldp p2mp

mdt data mldp 10 immediate-switch

!

!

router pim

address-family ipv4

rpf topology route-policy global-one

mdt c-multicast-routing bgp

interface Loopback0

enable

!

interface GigabitEthernet0/0/0/1

!

!

!

Hinweis: Anstelle von GTM mit mLDP können Sie auch globales In-Band-mLDP verwenden. Gründe dafür, dies nicht zu tun, sind die Verwendung von BGP als Overlay-Signalisierungsprotokoll oder die Verwendung des Standard-MDT für die Aggregation von Datenflüssen. Beim GTM-Modell können Sie Standard- und Daten-MDTs verwenden, während es beim globalen In-Band-mLDP einen Multicast-Fluss pro mLDP-Status gibt. Außerdem ist es mit GTM viel einfacher, den Sparse Mode zu unterstützen, während es bei In-Band-mLDP Einschränkungen gibt (z. B. wo der RP platziert wird). Der Sparse-Mode wird am einfachsten mit PIM als Overlay-Signalisierungsprotokoll unterstützt.

Sie müssen die nächste Konfiguration auf den Grenzroutern vornehmen:

- BGP mit AF IPv4 MVPN konfiguriert

- BGP-AD aktiviert

- ein MDT angegeben

- import-rt und export-rt, konfiguriert unter Router-BGP

- Global-Table-Multicast, konfiguriert unter Router BGP AF IPv4/6 MVPN

Optional muss SAFI 2 unter Router-BGP aktiviert werden.

Fehlerbehebung

- Zunächst müssen die Grenzrouten die Routenart 1 aufweisen.

- Überprüfen Sie den Core-Baum im inneren Kern. Das ist mLDP. Ist die mLDP-Signalisierung in Ordnung? Überprüfen Sie die mLDP-Datenbankeinträge auf den Standard-MDT und mögliche Daten-MDTs.

- Überprüfen der Quellroute im BGP

- Prüfen Sie die RPF am Egress Border Router.

- Überprüfen Sie die C-Multicast-Signalisierung in BGP (Routing-Typ 6 und 7) an den Grenzroutern.

Eingangsgrenzrouter

Die Ausgangsschnittstelle am Ingress Border Router ist die Lmdt-Schnittstelle.

RP/0/0/CPU0:C-PE1#show mrib route 203.0.113.1 10.2.1.8

IP Multicast Routing Information Base

Entry flags: L - Domain-Local Source, E - External Source to the Domain,

C - Directly-Connected Check, S - Signal, IA - Inherit Accept,

IF - Inherit From, D - Drop, ME - MDT Encap, EID - Encap ID,

MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle

CD - Conditional Decap, MPLS - MPLS Decap, EX - Extranet

MoFE - MoFRR Enabled, MoFS - MoFRR State, MoFP - MoFRR Primary

MoFB - MoFRR Backup, RPFID - RPF ID Set, X - VXLAN

Interface flags: F - Forward, A - Accept, IC - Internal Copy,

NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,

II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,

LD - Local Disinterest, DI - Decapsulation Interface

EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,

EX - Extranet, A2 - Secondary Accept, MT - MDT Threshold Crossed,

MA - Data MDT Assigned, LMI - mLDP MDT Interface, TMI - P2MP-TE MDT Interface

IRMI - IR MDT Interface

(10.2.1.8,203.0.113.1) RPF nbr: 10.1.2.2 Flags: RPF

Up: 00:08:58

Incoming Interface List

GigabitEthernet0/0/0/1 Flags: A, Up: 00:08:58

Outgoing Interface List

Lmdtdefault Flags: F LMI MA, Up: 00:08:58

RP/0/0/CPU0:C-PE1#show mfib route 203.0.113.1 10.2.1.8

IP Multicast Forwarding Information Base

Entry flags: C - Directly-Connected Check, S - Signal, D - Drop,

IA - Inherit Accept, IF - Inherit From, EID - Encap ID,

ME - MDT Encap, MD - MDT Decap, MT - MDT Threshold Crossed,

MH - MDT interface handle, CD - Conditional Decap,

DT - MDT Decap True, EX - Extranet, RPFID - RPF ID Set,

MoFE - MoFRR Enabled, MoFS - MoFRR State, X - VXLAN

Interface flags: F - Forward, A - Accept, IC - Internal Copy,

NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,

EG - Egress, EI - Encapsulation Interface, MI - MDT Interface,

EX - Extranet, A2 - Secondary Accept

Forwarding/Replication Counts: Packets in/Packets out/Bytes out

Failure Counts: RPF / TTL / Empty Olist / Encap RL / Other

(10.2.1.8,203.0.113.1),   Flags:

Up: 01:47:24

Last Used: 00:00:00

SW Forwarding Counts: 1197/1197/239400

SW Replication Counts: 1197/0/0

SW Failure Counts: 0/0/0/0/0

Lmdtdefault Flags:  F LMI, Up:01:47:24

GigabitEthernet0/0/0/1 Flags:  A, Up:01:47:24

RP/0/0/CPU0:C-PE1#show route ipv4 multicast

Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, su - IS-IS summary null, * - candidate default

U - per-user static route, o - ODR, L - local, G  - DAGR, l - LISP

A - access/subscriber, a - Application route

M - mobile route, r - RPL, (!) - FRR Backup path

Gateway of last resort is not set

i L1 10.1.1.0/24 [255/20] via 10.1.2.2, 1d21h, GigabitEthernet0/0/0/1

C    10.1.2.0/24 is directly connected, 1d21h, GigabitEthernet0/0/0/1

L    10.1.2.3/32 is directly connected, 3d19h, GigabitEthernet0/0/0/1

i L1 10.1.3.0/24 [115/20] via 10.1.3.4, 3d13h, GigabitEthernet0/0/0/0

L    10.1.3.3/32 is directly connected, 3d19h, GigabitEthernet0/0/0/0

i L1 10.1.4.0/24 [115/20] via 10.1.3.4, 3d13h, GigabitEthernet0/0/0/0

i L1 10.1.5.0/24 [115/30] via 10.1.3.4, 3d12h, GigabitEthernet0/0/0/0

i L1 10.1.6.0/24 [255/40] via 10.1.3.4, 1d21h, GigabitEthernet0/0/0/0

i L1 10.2.1.0/24 [255/30] via 10.1.2.2, 1d21h, GigabitEthernet0/0/0/1

i L1 10.2.2.0/24 [255/50] via 10.1.3.4, 1d21h, GigabitEthernet0/0/0/0

i L1 10.100.1.1/32 [255/30] via 10.1.2.2, 1d21h, GigabitEthernet0/0/0/1

i L1 10.100.1.2/32 [255/20] via 10.1.2.2, 1d21h, GigabitEthernet0/0/0/1

L    10.100.1.3/32 is directly connected, 1d21h, Loopback0

i L1 10.100.1.4/32 [115/20] via 10.1.3.4, 3d13h, GigabitEthernet0/0/0/0

i L1 10.100.1.5/32 [115/30] via 10.1.3.4, 3d12h, GigabitEthernet0/0/0/0

i L1 10.100.1.6/32 [255/40] via 10.1.3.4, 1d21h, GigabitEthernet0/0/0/0

i L1 10.100.1.7/32 [255/50] via 10.1.3.4, 1d21h, GigabitEthernet0/0/0/0

RP/0/0/CPU0:C-PE1#show pim rpf 10.2.1.8

Table: IPv4-Multicast-default

* 10.2.1.8/32 [255/30]

via GigabitEthernet0/0/0/1 with rpf neighbor 10.1.2.2

Ausgangs-Border-Router

Für die Quellroute werden die VRF-Route-Import-EC und die Source-AS-EC an das IPv4-Unicast- oder Multicast-Präfix angefügt. Hierbei handelt es sich um eine IPv4-Multicast-Route:

RP/0/0/CPU0:C-PE2#show bgp ipv4 multicast 10.2.1.0/24

BGP routing table entry for 10.2.1.0/24

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 32          32

Last Modified: Sep 12 08:34:56.441 for 15:09:58

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

Local

10.100.1.3 (metric 30) from 10.100.1.3 (10.100.1.3)

Origin incomplete, metric 30, localpref 100, valid, internal, best, group-best

Received Path ID 0, Local Path ID 1, version 32

Extended community: VRF Route Import:10.100.1.3:0 Source AS:1:0

Hinweis: Wenn die VRF-RI-EC und die Quell-AS-EC aus irgendeinem Grund nicht vorhanden sind, schlägt die RPF am Egress Border Router fehl.

Ein Beispiel, wenn die Route nicht über diese ECs verfügt:

RP/0/0/CPU0:C-PE2#show bgp ipv4 multicast 10.2.1.0/24

BGP routing table entry for 10.2.1.0/24

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                277         277

Last Modified: Sep 13 04:08:37.441 for 00:00:02

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

Local

10.100.1.3 (metric 30) from 10.100.1.3 (10.100.1.1)

Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best

Received Path ID 0, Local Path ID 1, version 277

Originator: 10.100.1.1, Cluster list: 10.100.1.3

Aus diesem Grund schlägt der RPF fehl:

RP/0/0/CPU0:C-PE2#show pim rpf 10.2.1.8

Table: IPv4-Multicast-default

* 10.2.1.8/32 [200/30]

via Null with rpf neighbor 0.0.0.0

RP/0/0/CPU0:C-PE2#show bgp ipv4 mvpn

BGP router identifier 10.100.1.5, local AS number 1

BGP generic scan interval 60 secs

Non-stop routing is enabled

BGP table state: Active

Table ID: 0x0   RD version: 0

BGP main routing table version 56

BGP NSR Initial initsync version 4 (Reached)

BGP NSR/ISSU Sync-Group versions 0/0

Global table multicast is enabled

BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale, N Nexthop-discard

Origin codes: i - IGP, e - EGP, ? - incomplete

Network            Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 0:0:0

*>i[1][10.100.1.3]/40 10.100.1.3                    100      0 i

*> [1][10.100.1.5]/40 0.0.0.0                                0 i

*>i[3][32][10.2.1.8][32][203.0.113.1][10.100.1.3]/120

10.100.1.3                    100      0 i

*> [7][0:0:0][1][32][10.2.1.8][32][203.0.113.1]/184

0.0.0.0                                0 i

Processed 4 prefixes, 4 paths

Der Befehl kann mit den Schlüsselwörtern rd all-zero-rd angegeben werden. Es werden dann alle Einträge mit dem RD mit den Nullen angezeigt.

RP/0/0/CPU0:C-PE2#show bgp ipv4 mvpn rd all-zero-rd

BGP router identifier 10.100.1.5, local AS number 1

BGP generic scan interval 60 secs

Non-stop routing is enabled

BGP table state: Active

Table ID: 0x0   RD version: 0

BGP main routing table version 56

BGP NSR Initial initsync version 4 (Reached)

BGP NSR/ISSU Sync-Group versions 0/0

Global table multicast is enabled

BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale, N Nexthop-discard

Origin codes: i - IGP, e - EGP, ? - incomplete

Network            Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 0:0:0

*>i[1][10.100.1.3]/40 10.100.1.3                    100      0 i

*> [1][10.100.1.5]/40 0.0.0.0                                0 i

*>i[3][32][10.2.1.8][32][203.0.113.1][10.100.1.3]/120

10.100.1.3                    100      0 i

*> [7][0:0:0][1][32][10.2.1.8][32][203.0.113.1]/184

0.0.0.0                                0 i

Processed 4 prefixes, 4 paths

Route vom Typ 1:

RP/0/0/CPU0:C-PE2#show bgp ipv4 mvpn rd all-zero-rd [1][10.100.1.3]/40

BGP routing table entry for [1][10.100.1.3]/40, Route Distinguisher: 0:0:0

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 43          43

Last Modified: Sep  8 07:42:43.786 for 1d17h

Paths: (1 available, best #1, not advertised to EBGP peer)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

Local

10.100.1.3 (metric 30) from 10.100.1.3 (10.100.1.3)

Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 43

Community: no-export

Extended community: RT:1:1

PMSI: flags 0x00, type 2, label 0, ID 0x060001040a640103000701000400000001

Source AFI: IPv4 MVPN, Source VRF: default, Source Route Distinguisher: 0:0:0

Die PMSI-Dekodierung:

PMSI: Flags 0x00, Typ 2, Label 0, ID 0x060001040a640103000701000400000001

Die decodierte PMSI aus dem vorherigen Befehl lautet:

The PMSI Tunnel Type is : 2 : mLDP P2MP LSP

The PMSI Tunnel ID is : 0x060001040a640103000701000400000001

FEC Element

FEC Element Type : 6 : P2MP

AF Type : 1

Address Length : 4

Root Node Address : 10.100.1.3

MP Opaque Length : 7

MP Opaque Value Element

Opaque Type : 1 : LSP ID Global

Opaque Length : 4

Global ID (Generic LSP Identifier) : 1

Der Daten-MDT wird von einer AD-Route vom Routing-Typ 3 von C-PE1 signalisiert.

RP/0/0/CPU0:C-PE2#show bgp ipv4 mvpn rd all-zero-rd [3][32][10.2.1.8] [32][203.0.113.1][10.100.1.3]/120

BGP routing table entry for [3][32][10.2.1.8][32][203.0.113.1][10.100.1.3]/120, Route Distinguisher: 0:0:0

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 56          56

Last Modified: Sep 10 00:51:52.786 for 00:04:57

Paths: (1 available, best #1, not advertised to EBGP peer)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

Local

10.100.1.3 (metric 30) from 10.100.1.3 (10.100.1.3)

Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 56

Community: no-export

Extended community: RT:1:1

PMSI: flags 0x00, type 2, label 0, ID 0x060001040a640103000701000400000007

Source AFI: IPv4 MVPN, Source VRF: default, Source Route Distinguisher: 0:0:0

Die decodierte PMSI gibt an, dass der Global LSP Identifier gleich 7 ist. Diese wird dann für den mLDP-Datenbankeintrag für diesen Daten-MDT verwendet.

PMSI: Flags 0x00, Typ 2, Label 0, ID 0x060001040a640103000701000400000007

Die decodierte PMSI aus dem vorherigen Befehl lautet:

The PMSI Tunnel Type is : 2 : mLDP P2MP LSP

The PMSI Tunnel ID is : 0x060001040a640103000701000400000007

FEC Element

FEC Element Type : 6 : P2MP

AF Type : 1

Address Length : 4

Root Node Address : 10.100.1.3

MP Opaque Length : 7

MP Opaque Value Element

Opaque Type : 1 : LSP ID Global

Opaque Length : 4

Global ID (Generic LSP Identifier) : 7

Mit den nächsten Befehlen können Sie überprüfen, was der Eingangs-PE über den Daten-MDT ankündigt. Beachten Sie, dass es sich um GTM handelt, sodass im nächsten Befehl keine VRF-Instanz vorhanden ist.

RP/0/0/CPU0:C-PE2#show pim mdt mldp remote

Core                   MDT              Cache Max DIP Local VRF Routes

Identifier             Source           Count Agg     Entry Using Cache

[global-id 7]          10.100.1.3       1     255 N   N     1

RP/0/0/CPU0:C-PE2#show pim mdt mldp cache

Core Source      Cust (Source, Group)                Core Data        Expires

10.100.1.3       (10.2.1.8, 203.0.113.1)               [global-id 7]    never

Dem Routing-Typ 7 ist kein PMSI angefügt:

RP/0/0/CPU0:C-PE2#show bgp ipv4 mvpn rd all-zero-rd [7][0:0:0][1][32][10.2.1.8][32][203.0.113.1]/184

BGP routing table entry for [7][0:0:0][1][32][10.2.1.8][32][203.0.113.1]/184, Route Distinguisher: 0:0:0

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 52          52

Last Modified: Sep 10 00:51:51.786 for 00:07:37

Paths: (1 available, best #1)

Advertised to peers (in unique update groups):

10.100.1.3

Path #1: Received by speaker 0

Advertised to peers (in unique update groups):

10.100.1.3

Local

0.0.0.0 from 0.0.0.0 (10.100.1.5)

Origin IGP, localpref 100, valid, redistributed, best, group-best, import-candidate

Received Path ID 0, Local Path ID 1, version 52

Extended community: RT:10.100.1.3:0

Das RT identifiziert den Upstream-PE-Router. Das Feld für den globalen Administrator ist die IP-Adresse des Upstream-PE. Das Feld "Lokaler Administrator" ist für GTM auf 0 gesetzt.

RP/0/0/CPU0:C-PE2#show mrib route 203.0.113.1 10.2.1.8

IP Multicast Routing Information Base

Entry flags: L - Domain-Local Source, E - External Source to the Domain,

C - Directly-Connected Check, S - Signal, IA - Inherit Accept,

IF - Inherit From, D - Drop, ME - MDT Encap, EID - Encap ID,

MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle

CD - Conditional Decap, MPLS - MPLS Decap, EX - Extranet

MoFE - MoFRR Enabled, MoFS - MoFRR State, MoFP - MoFRR Primary

MoFB - MoFRR Backup, RPFID - RPF ID Set, X - VXLAN

Interface flags: F - Forward, A - Accept, IC - Internal Copy,

NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,

II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,

LD - Local Disinterest, DI - Decapsulation Interface

EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,

EX - Extranet, A2 - Secondary Accept, MT - MDT Threshold Crossed,

MA - Data MDT Assigned, LMI - mLDP MDT Interface, TMI - P2MP-TE MDT Interface

IRMI - IR MDT Interface

(10.2.1.8,203.0.113.1) RPF nbr: 10.100.1.3 Flags: RPF

Up: 00:52:34

Incoming Interface List

Lmdtdefault Flags: A LMI, Up: 00:52:34

Outgoing Interface List

GigabitEthernet0/0/0/0 Flags: F NS, Up: 00:52:34

Bei der eingehenden Schnittstelle muss es sich um eine Lmdt-Schnittstelle handeln.

RP/0/0/CPU0:C-PE2#show mfib route 203.0.113.1 10.2.1.8

IP Multicast Forwarding Information Base

Entry flags: C - Directly-Connected Check, S - Signal, D - Drop,

IA - Inherit Accept, IF - Inherit From, EID - Encap ID,

ME - MDT Encap, MD - MDT Decap, MT - MDT Threshold Crossed,

MH - MDT interface handle, CD - Conditional Decap,

DT - MDT Decap True, EX - Extranet, RPFID - RPF ID Set,

MoFE - MoFRR Enabled, MoFS - MoFRR State, X - VXLAN

Interface flags: F - Forward, A - Accept, IC - Internal Copy,

NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,

EG - Egress, EI - Encapsulation Interface, MI - MDT Interface,

EX - Extranet, A2 - Secondary Accept

Forwarding/Replication Counts: Packets in/Packets out/Bytes out

Failure Counts: RPF / TTL / Empty Olist / Encap RL / Other

(10.2.1.8,203.0.113.1),   Flags:

Up: 02:31:00

Last Used: never

SW Forwarding Counts: 0/2037/407400

SW Replication Counts: 0/2037/407400

SW Failure Counts: 0/0/0/0/0

Lmdtdefault Flags:  A LMI, Up:02:31:00

GigabitEthernet0/0/0/0 Flags:  NS EG, Up:02:31:00

Prüfen Sie die SAFI 2 Routen:

RP/0/0/CPU0:C-PE2#show route ipv4 multicast

Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, su - IS-IS summary null, * - candidate default

U - per-user static route, o - ODR, L - local, G  - DAGR, l - LISP

A - access/subscriber, a - Application route

M - mobile route, r - RPL, (!) - FRR Backup path

Gateway of last resort is not set

i L1 10.1.2.0/24 [115/30] via 10.1.4.4, 3d12h, GigabitEthernet0/0/0/1

i L1 10.1.3.0/24 [115/20] via 10.1.4.4, 3d12h, GigabitEthernet0/0/0/1

C    10.1.4.0/24 is directly connected, 1d21h, GigabitEthernet0/0/0/1

L    10.1.4.5/32 is directly connected, 3d12h, GigabitEthernet0/0/0/1

C    10.1.5.0/24 is directly connected, 1d21h, GigabitEthernet0/0/0/0

L    10.1.5.5/32 is directly connected, 3d12h, GigabitEthernet0/0/0/0

B    10.2.1.0/24 [200/30] via 10.100.1.3, 1d17h

i L1 10.100.1.3/32 [115/30] via 10.1.4.4, 3d12h, GigabitEthernet0/0/0/1

i L1 10.100.1.4/32 [115/20] via 10.1.4.4, 3d12h, GigabitEthernet0/0/0/1

L    10.100.1.5/32 is directly connected, 1d21h, Loopback0

Beachten Sie, dass die Route für die Quelle SAFI 2 (in AF IPv4 Multicast) ist, da sie sich im RIB AF IPv4 Multicast befindet.

Beachten Sie, dass der Next-Hop 10.100.1.3 ist, das Loopback von C-PE1, da dieser Router Next-Hop-Self unter AF ipv4 Multicast unter Router BGP hat.

RP/0/0/CPU0:C-PE2#show bgp ipv4 multicast 10.2.1.0/24

BGP routing table entry for 10.2.1.0/24

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 34          34

Last Modified: Sep  8 07:42:18.786 for 1d17h

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

Local

10.100.1.3 (metric 30) from 10.100.1.3 (10.100.1.3)

Origin incomplete, metric 30, localpref 100, valid, internal, best, group-best

Received Path ID 0, Local Path ID 1, version 34

Extended community: VRF Route Import:10.100.1.3:0 Source AS:1:0

Die RPF für die Quelle verweist auf die Lmdt-Schnittstelle und den PIM-Nachbarn darüber. Die RPF wird in der IPv4-Multicast-Tabelle durchgeführt.

RP/0/0/CPU0:C-PE2#show pim rpf 10.2.1.8

Table: IPv4-Multicast-default

* 10.2.1.8/32 [200/30]

via Lmdtdefault with rpf neighbor 10.100.1.3

Überprüfen Sie, ob der Ingress Border Router als PE-Router erkannt wird.

RP/0/0/CPU0:C-PE2#show pim pe

MVPN Provider Edge Router information

PE Address : 10.100.1.3 (0x1071da64)

RD: 0:0:0 (valid), RIB_HLI 0, RPF-ID 3, Remote RPF-ID 0, State: 1, S-PMSI: 2

PPMP_LABEL: 0, MS_PMSI_HLI: 0x00000, Bidir_PMSI_HLI: 0x00000, MLDP-added: [RD 0, ID 0, Bidir ID 0, Remote Bidir ID 0], Counts(SHR/SRC/DM/DEF-MD): 0, 1, 0, 0, Bidir: GRE RP Count 0, MPLS RP Count 0RSVP-TE added: [Leg 0, Ctrl Leg 0, Part tail 0 Def Tail 0, IR added: [Def Leg 0, Ctrl Leg 0, Part Leg 0, Part tail 0, Part IR Tail Label 0

bgp_i_pmsi: 1,0/0 , bgp_ms_pmsi/Leaf-ad: 0/0, bgp_bidir_pmsi: 0, remote_bgp_bidir_pmsi: 0, PMSIs: I 0x106a2d50, 0x0, MS 0x0, Bidir Local: 0x0, Remote: 0x0, BSR/Leaf-ad 0x0/0, Autorp-disc/Leaf-ad 0x0/0, Autorp-ann/Leaf-ad 0x0/0

IIDs: I/6: 0x1/0x0, B/R: 0x0/0x0, MS: 0x0, B/A/A: 0x0/0x0/0x0

Bidir RPF-ID: 4, Remote Bidir RPF-ID: 0

I-PMSI:   MLDP-P2MP, Opaque: [global-id 1] (0x106a2d50)

I-PMSI rem:  (0x0)

MS-PMSI:  (0x0)

Bidir-PMSI:  (0x0)

Remote Bidir-PMSI:  (0x0)

BSR-PMSI:  (0x0)

A-Disc-PMSI:  (0x0)

A-Ann-PMSI:  (0x0)

RIB Dependency List: 0x1016446c

Bidir RIB Dependency List: 0x0

Sources: 1, RPs: 0, Bidir RPs: 0

Die Inklusive PMSI (I-PMSI) ist da.

In der mLDP-Datenbank werden die beiden P2MP-mLDP-Einträge angezeigt, die den Standard-MDT zwischen den beiden Grenzroutern bilden. Es gibt auch einen P2MP mLDP-Eintrag mit C-PE1 als Root für den Daten-MDT.

RP/0/0/CPU0:C-PE2#show mpls mldp database brief

LSM ID   Type    Root              Up Down Decoded Opaque Value

0x00007  P2MP    10.100.1.3        1  1    [global-id 1]

0x00008  P2MP    10.100.1.5        0  2    [global-id 1]

0x0000B  P2MP    10.100.1.3        1  1    [global-id 7]

Beispiel 2: Profil 20 Standard-MDT - P2MP-TE - BGP-AD - PIM - C-Multicast-Signalisierung

Dies ist dem Beispiel 1 sehr ähnlich. Im Core befindet sich jetzt P2MP TE. Die Tunnel werden als Autotunnel eingerichtet. Die Tail-End-Router werden über BGP AD erkannt. Ein weiterer Unterschied zu Beispiel 1 besteht darin, dass das Overlay-Protokoll jetzt PIM ist. Schauen Sie sich Bild 5 an.

Bild 5

Konfiguration

Dies ist die Konfiguration des Border Routers:

hostname C-PE1

logging console debugging

router rib

address-family ipv4

rump always-replicate

!

!

line default

timestamp disable

exec-timeout 0 0

!

ipv4 unnumbered mpls traffic-eng Loopback0

interface Loopback0

ipv4 address 10.100.1.3 255.255.255.255

!

interface MgmtEth0/0/CPU0/0

shutdown

!

interface GigabitEthernet0/0/0/0

ipv4 address 10.1.3.3 255.255.255.0

load-interval 30

!

interface GigabitEthernet0/0/0/1

ipv4 address 10.1.2.3 255.255.255.0

!

interface GigabitEthernet0/0/0/2

shutdown

!

interface GigabitEthernet0/0/0/3

shutdown

!

interface GigabitEthernet0/0/0/4

shutdown

!

interface GigabitEthernet0/0/0/5

shutdown

!

interface GigabitEthernet0/0/0/6

shutdown

!

interface GigabitEthernet0/0/0/7

shutdown

!

interface GigabitEthernet0/0/0/8

shutdown

!

route-policy loopback

if destination in (10.100.1.3/32) then

pass

endif

end-policy

!

route-policy global-one

set core-tree p2mp-te-default

end-policy

!

route-policy sources-in-ISIS

if destination in (10.2.1.0/24) then

pass

endif

end-policy

!

router isis 1

is-type level-1

net 49.0001.0000.0000.0003.00

address-family ipv4 unicast

metric-style wide

mpls traffic-eng level-1

mpls traffic-eng router-id Loopback0

!

interface Loopback0

address-family ipv4 unicast

!

address-family ipv4 multicast

!

!

interface GigabitEthernet0/0/0/0

address-family ipv4 unicast

!

address-family ipv4 multicast

!

!

interface GigabitEthernet0/0/0/1

address-family ipv4 unicast

!

address-family ipv4 multicast

!

!

!

router bgp 1

address-family ipv4 unicast

!

address-family ipv4 multicast

redistribute connected route-policy loopback

redistribute ospf 1

redistribute isis 1 route-policy sources-in-ISIS

!

address-family ipv4 mvpn

global-table-multicast

!

neighbor 10.100.1.5

remote-as 1

update-source Loopback0

address-family ipv4 multicast

next-hop-self

!

address-family ipv4 mvpn

!

!

!

mpls oam

!

rsvp

interface GigabitEthernet0/0/0/0

bandwidth 1000000

!

interface GigabitEthernet0/0/0/1

bandwidth 1000000

!

!

mpls traffic-eng

interface GigabitEthernet0/0/0/0

auto-tunnel backup

!

!

interface GigabitEthernet0/0/0/1

auto-tunnel backup

!

!

auto-tunnel p2mp

tunnel-id min 1000 max 2000

!

!

mpls ldp

log

neighbor

!

mldp

logging notifications

address-family ipv4

rib unicast-always

!

!

router-id 10.100.1.3

address-family ipv4

!

interface GigabitEthernet0/0/0/0

address-family ipv4

!

!

interface GigabitEthernet0/0/0/1

address-family ipv4

!

!

!

multicast-routing

address-family ipv4

interface Loopback0

enable

!

interface GigabitEthernet0/0/0/1

enable

!

mdt source Loopback0

export-rt 1:1

import-rt 1:1

bgp auto-discovery p2mp-te

!

mdt default p2mp-te

mdt data p2mp-te 100 immediate-switch

!

!

router pim

address-family ipv4

rpf topology route-policy global-one

interface Loopback0

enable

!

interface GigabitEthernet0/0/0/1

!

!

!

Fehlerbehebung

Eingangsgrenzrouter

Überprüfen Sie, ob die RD-Null vorhanden ist. Die Routen vom Routing-Typ 1 müssen vorhanden sein, damit P2MP TE auf der Basis von P2MP TE-Tunneln erstellt werden kann.

RP/0/0/CPU0:C-PE1#show bgp ipv4 mvpn rd all-zero-rd

BGP router identifier 10.100.1.3, local AS number 1

BGP generic scan interval 60 secs

Non-stop routing is enabled

BGP table state: Active

Table ID: 0x0   RD version: 0

BGP main routing table version 140

BGP NSR Initial initsync version 4 (Reached)

BGP NSR/ISSU Sync-Group versions 0/0

Global table multicast is enabled

BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale, N Nexthop-discard

Origin codes: i - IGP, e - EGP, ? - incomplete

Network            Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 0:0:0

*> [1][10.100.1.3]/40 0.0.0.0                                0 i

*>i[1][10.100.1.5]/40 10.100.1.5                    100      0 i

Processed 2 prefixes, 2 paths

Prüfen Sie die Route Typ 1 genauer:

RP/0/0/CPU0:C-PE1#show bgp ipv4 mvpn rd all-zero-rd [1][10.100.1.5]/40

BGP routing table entry for [1][10.100.1.5]/40, Route Distinguisher: 0:0:0

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                135         135

Last Modified: Sep 12 08:21:42.207 for 00:20:14

Paths: (1 available, best #1, not advertised to EBGP peer)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

Local

10.100.1.5 (metric 30) from 10.100.1.5 (10.100.1.5)

Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 135

Community: no-export

Extended community: RT:1:1

PMSI: flags 0x00, type 1, label 0, ID 0x000003e8000003e80a640105

Source AFI: IPv4 MVPN, Source VRF: default, Source Route Distinguisher: 0:0:0

Überprüfen Sie die PIM-Nachbarn auf dem MDT-Standard:

RP/0/0/CPU0:C-PE1#show pim neighbor

PIM neighbors in VRF default

Flag: B - Bidir capable, P - Proxy capable, DR - Designated Router,

E - ECMP Redirect capable

* indicates the neighbor created for this router

Neighbor Address             Interface              Uptime    Expires  DR pri   Flags

10.1.2.2                     GigabitEthernet0/0/0/1 6d02h     00:01:16 1      B

10.1.2.3*                    GigabitEthernet0/0/0/1 6d02h     00:01:15 1 (DR) B E

10.100.1.3*                  Loopback0              6d02h     00:01:32 1 (DR) B E

10.100.1.3*                  Tmdtdefault            00:36:21  00:01:40 1

10.100.1.5                   Tmdtdefault            00:17:37  00:01:26 1 (DR)

Überprüfen Sie die MRIB-Route. Die ausgehende Schnittstelle muss Tmdt sein:

RP/0/0/CPU0:C-PE1#show mrib route 203.0.113.1

IP Multicast Routing Information Base

Entry flags: L - Domain-Local Source, E - External Source to the Domain,

C - Directly-Connected Check, S - Signal, IA - Inherit Accept,

IF - Inherit From, D - Drop, ME - MDT Encap, EID - Encap ID,

MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle

CD - Conditional Decap, MPLS - MPLS Decap, EX - Extranet

MoFE - MoFRR Enabled, MoFS - MoFRR State, MoFP - MoFRR Primary

MoFB - MoFRR Backup, RPFID - RPF ID Set, X - VXLAN

Interface flags: F - Forward, A - Accept, IC - Internal Copy,

NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,

II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,

LD - Local Disinterest, DI - Decapsulation Interface

EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,

EX - Extranet, A2 - Secondary Accept, MT - MDT Threshold Crossed,

MA - Data MDT Assigned, LMI - mLDP MDT Interface, TMI - P2MP-TE MDT Interface

IRMI - IR MDT Interface

(10.2.1.8,203.0.113.1) RPF nbr: 10.1.2.2 Flags: RPF

Up: 00:09:10

Incoming Interface List

GigabitEthernet0/0/0/1 Flags: A, Up: 00:09:10

Outgoing Interface List

Tmdtdefault Flags: F NS TMI, Up: 00:09:10

Prüfen Sie, ob pro Grenz-Router ein P2MP TE-Tunnel als Head-End-Router vorhanden ist:

RP/0/0/CPU0:C-PE1#show mpls traffic-eng tunnels tabular

Tunnel   LSP     Destination          Source           FRR  LSP  Path

Name    ID         Address         Address  State  State Role  Prot

----------------- ----- --------------- --------------- ------ ------ ---- -----

^tunnel-mte1001 10004      10.100.1.5      10.100.1.3     up  Inact Head

auto_C-PE2_mt1000 10005      10.100.1.3      10.100.1.5     up  Inact Tail

^ = automatically created P2MP tunnel

Nach der Auslösung des Daten-MDT werden die Routen vom Typ 3 und 4 festgelegt:

RP/0/0/CPU0:C-PE1#show bgp ipv4 mvpn rd all-zero-rd

BGP router identifier 10.100.1.3, local AS number 1

BGP generic scan interval 60 secs

Non-stop routing is enabled

BGP table state: Active

Table ID: 0x0   RD version: 0

BGP main routing table version 143

BGP NSR Initial initsync version 4 (Reached)

BGP NSR/ISSU Sync-Group versions 0/0

Global table multicast is enabled

BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale, N Nexthop-discard

Origin codes: i - IGP, e - EGP, ? - incomplete

Network            Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 0:0:0

*> [1][10.100.1.3]/40 0.0.0.0                                0 i

*>i[1][10.100.1.5]/40 10.100.1.5                    100      0 i

*> [3][32][10.2.1.8][32][203.0.113.1][10.100.1.3]/120

0.0.0.0                                0 i

*>i[4][3][0:0:0][32][10.2.1.8][32][203.0.113.1][10.100.1.3][10.100.1.5]/224

10.100.1.5                    100      0 i

Processed 4 prefixes, 4 paths

Routing-Typ 3 signalisiert allen Tail-End-Routern, dass ein Daten-MDT signalisiert wird:

RP/0/0/CPU0:C-PE1#show bgp ipv4 mvpn rd all-zero-rd [3][32][10.2.1.8][32][203.0.113.1][10.100.1.3]/120

BGP routing table entry for [3][32][10.2.1.8][32][203.0.113.1][10.100.1.3]/120, Route Distinguisher: 0:0:0

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                141         141

Last Modified: Sep 12 08:46:17.207 for 00:00:41

Paths: (1 available, best #1, not advertised to EBGP peer)

Advertised to peers (in unique update groups):

10.100.1.5

Path #1: Received by speaker 0

Advertised to peers (in unique update groups):

10.100.1.5

Local

0.0.0.0 from 0.0.0.0 (10.100.1.3)

Origin IGP, localpref 100, valid, redistributed, best, group-best, import-candidate

Received Path ID 0, Local Path ID 1, version 141

Community: no-export

Extended community: RT:1:1

PMSI: flags 0x01, type 1, label 0, ID 0x000003ed000003ed0a640103

Die PMSI-Dekodierung:

PMSI: Flags 0x01, Typ 1, Label 0, ID 0x000003ed000003ed0a640103

Die decodierte PMSI aus dem vorherigen Befehl lautet:

The PMSI Tunnel Type is : 1 : RSVP-TE P2MP LSP

The PMSI Tunnel ID is : 0x000003ed000003ed0a640103

Extended Tunnel ID : 1005

Reserved part (should be zero): 0X0000

Tunnel ID : 1005

P2MP ID : 10.100.1.3

Dies ist auch hier zu sehen:

RP/0/0/CPU0:C-PE1#show pim mdt cache

Core Source      Cust (Source, Group)                Core Data        Expires

10.100.1.3       (10.2.1.8, 203.0.113.1)               [p2mp 6]         never

Leaf AD:   10.100.1.5

Der Routing-Typ 4 signalisiert dem Head-End-Router, welcher Router das Tail-End ist:

RP/0/0/CPU0:C-PE1#show bgp ipv4 mvpn rd all-zero-rd [4][3][0:0:0][32][10.2.1.8][32][203.0.113.1][10.100.1.3][10.100.1.5]/224

BGP routing table entry for [4][3][0:0:0][32][10.2.1.8][32][203.0.113.1][10.100.1.3][10.100.1.5]/224, Route Distinguisher: 0:0:0

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                143         143

Last Modified: Sep 12 08:46:17.207 for 00:01:25

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

Local

10.100.1.5 (metric 30) from 10.100.1.5 (10.100.1.5)

Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 143

Extended community: SEG-NH:10.100.1.5:0 RT:10.100.1.3:0

Source AFI: IPv4 MVPN, Source VRF: default, Source Route Distinguisher: 0:0:0

Überprüfen Sie, ob der Daten-MDT des P2MP TE-Tunnels eingerichtet ist:

RP/0/0/CPU0:C-PE1#show mpls traffic-eng tunnels tabular

Tunnel   LSP     Destination          Source           FRR  LSP  Path

Name    ID         Address         Address  State  State Role  Prot

----------------- ----- --------------- --------------- ------ ------ ---- -----

^tunnel-mte1001 10004      10.100.1.5      10.100.1.3     up  Inact Head

^tunnel-mte1005 10002      10.100.1.5      10.100.1.3     up  Inact Head

auto_C-PE2_mt1000 10005      10.100.1.3      10.100.1.5     up  Inact Tail

^ = automatically created P2MP tunnel

Ausgangs-Border-Router

Überprüfen Sie, ob die eingehende Schnittstelle die Tmdt-Schnittstelle ist:

RP/0/0/CPU0:C-PE2#show mrib route 203.0.113.1

IP Multicast Routing Information Base

Entry flags: L - Domain-Local Source, E - External Source to the Domain,

C - Directly-Connected Check, S - Signal, IA - Inherit Accept,

IF - Inherit From, D - Drop, ME - MDT Encap, EID - Encap ID,

MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle

CD - Conditional Decap, MPLS - MPLS Decap, EX - Extranet

MoFE - MoFRR Enabled, MoFS - MoFRR State, MoFP - MoFRR Primary

MoFB - MoFRR Backup, RPFID - RPF ID Set, X - VXLAN

Interface flags: F - Forward, A - Accept, IC - Internal Copy,

NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,

II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,

LD - Local Disinterest, DI - Decapsulation Interface

EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,

EX - Extranet, A2 - Secondary Accept, MT - MDT Threshold Crossed,

MA - Data MDT Assigned, LMI - mLDP MDT Interface, TMI - P2MP-TE MDT Interface

IRMI - IR MDT Interface

(10.2.1.8,203.0.113.1) RPF nbr: 10.100.1.3 Flags: RPF

Up: 00:18:03

Incoming Interface List

Tmdtdefault Flags: A TMI, Up: 00:18:00

Outgoing Interface List

GigabitEthernet0/0/0/0 Flags: F NS, Up: 00:18:03

Die RPF des Egress Border Routers verweist auf den Ingress Border Router. Die Eingangsschnittstelle ist Tmdtdefault. Beachten Sie das T für den TE-Tunnel:

RP/0/0/CPU0:C-PE2#show pim rpf 10.2.1.8

Table: IPv4-Multicast-default

* 10.2.1.8/32 [200/30]

via Tmdtdefault with rpf neighbor 10.100.1.3

Beispiel 3: Wie in Beispiel 1, aber es gibt iBGP zwischen PE und Border Router

Schauen Sie sich Bild 6 an.

Bild 6

Es gibt eine asymmetrische Konfiguration, bei der ein Core-Netzwerk mit mLDP auf der einen Seite und PIM noch auf der anderen Seite und GTM vorhanden ist. Dies kann bei der Migration von Core Trees auftreten. Der C-PE1-Router muss ein RR für BGP IPv4-Multicast und BGP IPv4-mVPN sein. Die Konfiguration für PIM und Multicast-Routing, die wir in Beispiel 1 für C-PE1 hatten, ist jetzt für PE1 erforderlich.

Beispiel 4: Nahtloses MPLS

Wir setzen GTM über Seamless MPLS (Unified MPLS) ein. Der PE-Router muss GTM verstehen, wozu nur ein Cisco IOS XR-Router in der Lage ist, und der PE-Router muss den PIM RPF-Proxy-Vektor in der PIM-Domäne generieren. Dieser PIM-RPF-Proxy-Vektor wird benötigt, damit die P-Router eine RPF an die Proxy-IP-Adresse (den ABR) senden können. Seit Cisco IOS XR 5.3.2 kann Cisco IOS XR den RPF-Proxy-Vektor im globalen Kontext generieren. GTM kann also den RPF-Proxy-Vektor haben.

Um den PIM-RPF-Proxy-Vektor zu generieren, muss der PE-Router wie folgt konfiguriert sein:

router pim

address-family [ipv4|ipv6]

rpf-vector

!

!

Hinweis: Die Unterstützung für die Interpretation des PIM RPF-Proxy-Vektors (diese Vorgehensweise muss der IP-Router durchführen) wurde in früheren Versionen von Cisco IOS XR eingeführt.

Dies ermöglicht die Bereitstellung von GTM über Seamless MPLS.