Verwendung von nicht segmentiertem Global Table Multicast (GTM) für mVPN
Inhalt
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
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
- 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.
- 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.
- 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
!
!
!
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
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
!
!
Dies ermöglicht die Bereitstellung von GTM über Seamless MPLS.
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
14-Dec-2022 |
Erstveröffentlichung |
Feedback