Download-Optionen

PDF (488.5 KB)
Mit Adobe Reader auf verschiedenen Geräten anzeigen
ePub (240.5 KB)
In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
Mobi (Kindle) (271.7 KB)
Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen

Aktualisiert:19. Mai 2021

Dokument-ID:217155

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Inhalt

Einleitung

Migration von Core-Tree-Protokollen

C-Multicast-Protokollmigration

Szenario 1.

Szenario 2.

Szenario 3.

Szenario 4.

Das Problem

Die Lösung

Schlussfolgerung

Einleitung

Dieses Dokument beschreibt die Migration von Multicast VPN (mVPN) Protocol Independent Multicast (PIM) Core Tree-basierten Multicast Distribution Trees (MDTs) zu Multipoint Label Distribution Protocol (mLDP) Core Tree-basierten MDTs. Details dazu, wie Daten-MDTs zum Zeitpunkt der Migration signalisiert werden. In diesem Dokument wird die Migration nur für den PE-Router (Ingress Provider Edge) mit Cisco IOS®-XR beschrieben.

Migration von Core-Tree-Protokollen

Dual-Encap bezeichnet einen Eingangs-Router, der einen Kunden-(C)-Multicast-Stream gleichzeitig an verschiedene Core-Trees weiterleiten kann. Der Eingangs-PE-Router leitet beispielsweise einen C-Multicast-Stream gleichzeitig an einen PIM-basierten Core-Tree und einen mLDP-basierten Core-Tree weiter. Dies ist eine Voraussetzung für die erfolgreiche Migration von einem Core-Tree-Typ auf einen anderen.

Dual-Encap wird für PIM und mLDP unterstützt.

Dual-Encap wird für Multiprotocol Label Switching (MPLS) P2MP Traffic Engineering (TE) nicht unterstützt.

Die Standard-MDT-Migration oder -Koexistenz mit Generic Routing Encapsulation (GRE) und Standard-MDT-mLDP beruht darauf, dass der Eingangs-PE-Router einen C-Multicast-Stream gleichzeitig an einen PIM-basierten Core-Tree und einen mLDP-basierten Core-Tree weiterleitet. Während der Eingangs-PE an beide MDTs weitergeleitet wird, können die Ausgangs-PE-Router einzeln von einem Core-Tree-Typ zu einem anderen migriert werden.

In der Regel werden PE-Routen vom ältesten mVPN-Bereitstellungsmodell mit PIM-basierten Core Trees zu einem mVPN-Bereitstellungsmodell mit mLDP-basierten Trees migriert. Die älteste mVPN-Implementierung ist Profile 0. Hierbei handelt es sich um PIM-basierte Core Trees, keine Border Gateway Protocol (BGP) Auto-Discovery (AD) und PIM in der Overlay-Signalisierung. Die Migration kann aber auch umgekehrt erfolgen.

Betrachten wir dieses Migrationsszenario, da es sich um die häufigste Migration handelt: von GRE im Core (Profil 0) zu einem Standard-MDT-mLDP-Profil.

Es gibt einige mögliche Standard-mLDP-Profile.

Sehen wir uns diese an:

mLDP ohne BGP AD
mLDP mit BGP AD- und PIM C-Signalisierung
mLDP mit BGP AD- und BGP C-Signalisierung

Im letzteren Fall erfolgt auch eine Migration des C-Signalisierungsprotokolls.

Bei Verwendung von BGP AD muss u. a. beachtet werden, dass der Daten-MDT standardmäßig vom BGP signalisiert wird. Wenn kein BGP AD vorhanden ist, kann der Daten-MDT nicht vom BGP signalisiert werden.

Auf jeden Fall muss auf dem Eingangs-PE Profil 0 und das mLDP-Profil konfiguriert sein. Der Eingangs-PE leitet den C-Multicast-Datenverkehr an beide MDTs (Standard oder Daten) der beiden Core-Baumprotokolle weiter. Daher müssen beide Standard-MDTs auf dem Eingangs-PE konfiguriert werden.

Wenn der Ausgangs-PE die Core-Tree-Protokolle PIM und mLDP ausführen kann, kann er entscheiden, von welchem Tree der C-Multicast-Datenverkehr abgerufen werden soll. Hierzu wird die Reverse Path Forwarding (RPF)-Richtlinie auf dem Ausgangs-PE konfiguriert.

Wenn der Egress-PE-Router nur Profil 0 unterstützen kann, tritt dieser PE nur dem PIM-Tree im Core bei und empfängt den C-Multicast-Stream im PIM-basierten Tree.

Hinweis: Bei Verwendung des PIM Sparse Mode müssen RP-PE und S-PE über den GRE- und den mLDP-basierten MDT erreichbar sein.

C-Multicast-Protokollmigration

Das C-Multicast-Protokoll kann von PIM zu BGP oder umgekehrt migriert werden. Hierzu wird der Ausgangs-PE so konfiguriert, dass er entweder PIM oder BGP als Overlay-Protokoll auswählt. Dabei handelt es sich um den Egress-PE, der eine Verbindung entweder per PIM oder BGP sendet. Der Eingangs-PE kann beide in einem Migrationsszenario empfangen und verarbeiten.

Dies ist ein Migrationsbeispiel für das C-Multicast-Protokoll, das auf dem Ausgangs-PE konfiguriert wurde:

router pim
  vrf one
   address-family ipv4
    rpf topology route-policy rpf-for-one
    mdt c-multicast-routing bgp
    !
    interface GigabitEthernet0/1/0/0
     enable
    !
   !
  !
 !
 
route-policy rpf-for-one
   set core-tree mldp-default
 end-policy
 !

BGP wird als Overlay-Signalisierungsprotokoll aktiviert. Der Standardwert ist "PIM".

Szenarien

Schauen Sie in Abbildung 1 nach, um die für die Szenarien verwendete Konfiguration zu sehen.

Abbildung 1.

In diesen Szenarien verfügen Sie über mindestens einen Legacy-PE-Router als Receiver-PE-Router. Dieser Router führt nur Profile 0 aus (Standard-MDT - GRE - PIM C-mcast Signaling).

Auf diesem Router muss BGP IPv4 MDT konfiguriert sein.

Es gibt mindestens einen Receiver-PE-Router mit einem mLDP-basierten Profil. Dies sind alle Standard-MDT-mLDP-Profile (1, 9, 13, 12, 17), alle partitionierten MDT-mLDP-Profile (2, 4, 5, 14, 15) und Profil 7. Profil 8 für P2MP TE wird ebenfalls unterstützt.

Der Eingangs-PE-Router ist ein Dual-Encap-Router, auf dem Profil 0 und ein mLDP-basiertes Profil ausgeführt werden.

Dieser Eingangs-PE-Router muss den Datenverkehr stets sowohl über den/die PIM-basierten MDT(s) als auch über den/die mLDP-basierten MDT(s) weiterleiten. Diese MDTs können die Standard- und Daten-MDTs sein.

Als Legacy-Router sollte ein Router mit IOS verwendet werden, auf dem nur Profile 0 ausgeführt werden kann. Dies ist die Konfiguration des Legacy-Routers.

vrf definition one
 rd 1:3
 vpn id 1:1
 route-target export 1:1
 route-target import 1:1
 !
 address-family ipv4
  mdt default 232.1.1.1
 exit-address-family

BGP-IPv4-MDT muss konfiguriert werden:

router bgp 1
…
address-family ipv4 mdt
 neighbor 10.1.100.7 activate
 neighbor 10.1.100.7 send-community extended
 exit-address-family
 !
…

Szenario 1.

Es gibt einen oder mehrere Legacy-PE-Router als Receiver-PE-Router.

Es gibt einen oder mehrere PE-Router als Receiver-PE-Router, auf denen Profil 1 ausgeführt wird (Standard-MDT - mLDP MP2MP PIM C-mcast Signaling).

Es gibt überhaupt keine BGP AD- oder BGP C-Multicast-Signalisierung.

Konfiguration des Receiver-PE-Routers mit Profil 1:

vrf one
  vpn id 1:1
  address-family ipv4 unicast
   import route-target
    1:1
   !
   export route-target
    1:1
   !
  !
 
 router pim
  vrf one
   address-family ipv4
    rpf topology route-policy rpf-for-one
    !
    interface GigabitEthernet0/1/0/0
     enable
    !
   !
  !
 !
 
 route-policy rpf-for-one
   set core-tree mldp-default
 end-policy
 !
 
 multicast-routing
  vrf one
   address-family ipv4
    mdt source Loopback0
    mdt default mldp ipv4 10.1.100.7
    mdt data 100
    rate-per-route
    interface all enable
    !
    accounting per-prefix
   !
  !
 !

 mpls ldp
  mldp
   logging notifications
   address-family ipv4
   !
  !
 !

route-policy rpf-for-one
  set core-tree mldp-default

Konfiguration des Eingangs-PE-Routers:

vrf one
 vpn id 1:1
 address-family ipv4 unicast
  import route-target
   1:1
  !
  export route-target
   1:1
  !
 !

router pim
 vrf one
  address-family ipv4
  !
  interface GigabitEthernet0/1/0/0
   enable
  !
 !
!

multicast-routing
 vrf one
 address-family ipv4
  mdt source Loopback0
  interface all enable
  !
  mdt default ipv4 232.1.1.1
  mdt default mldp ipv4 10.1.100.7
  mdt data 255
  mdt data 232.1.2.0/24
  !
 !
!

mpls ldp
 mldp
 logging notifications
 address-family ipv4
 !
 !
!

Der Eingangs-PE-Router muss über eine IPv4-MDT für die BGP-Adressfamilie verfügen, die mit dem des Legacy-PE-Routers übereinstimmt.

Der Eingangs-PE muss an beide Typen von MDT weitergeleitet werden:

Ingress-PE#show mrib vrf one route 232.100.1.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, MF - MPLS Encap, 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.2.9,232.100.1.1) RPF nbr: 10.2.2.9 Flags: RPF MT
MT Slot: 0/1/CPU0
Up: 00:56:09
Incoming Interface List
   GigabitEthernet0/1/0/0 Flags: A, Up: 00:56:09
Outgoing Interface List
   mdtone Flags: F NS MI MT MA, Up: 00:22:59      <<< PIM-based tree
   Lmdtone Flags: F NS LMI MT MA, Up: 00:56:09    <<< mLDP-based tree

Der Eingangs-PE sollte den Legacy-PE auf der Schnittstelle mdtone und den Profile 1-PE auf der Schnittstelle mdtone als PIM-Nachbarn sehen:

Ingress-PE#show pim vrf one neighbor
 
PIM neighbors in VRF one
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.100.1                   Lmdtone 6w1d     00:01:29 1     P
10.1.100.2*                  Lmdtone               6w1d     00:01:15 1 (DR) P
10.1.100.2*                  mdtone                 5w0d     00:01:30 1     P
10.1.100.3                   mdtone 00:50:20 00:01:30 1 (DR) P

"debug pim vrf one mdt data" auf dem Eingangs-PE:

Sie sehen, dass ein Typ 1 (PIM-Core-Tree) und ein Typ 2 (mLDP-Core-Tree) PIM Join TLV gesendet werden. Das erste auf midtone und das zweite auf lmdtone.

pim[1140]: [13] MDT Grp lookup: Return match for grp 232.1.2.4 src 10.1.100.2 in local list (-)
pim[1140]: [13] In mdt timers process...
pim[1140]: [13] Processing MDT JOIN SEND timer for MDT null core mldp pointer in one
pim[1140]: [13] In join_send_update_timer: route->mt_head 50c53b44
pim[1140]: [13] Create new MDT tlv buffer for one for type 0x1
pim[1140]: [13] Buffer allocated for one mtu 1348 size 0
pim[1140]: [13] TLV type set to 0x1
pim[1140]: [13] TLV added for one mtu 1348 size 16
pim[1140]: [13] MDT cache upd: pe 0.0.0.0, (10.2.2.9,232.100.1.1), mdt_type 0x1, core (10.1.100.2,232.1.2.4), for vrf one [local, -], mt_lc 0x11, mdt_if 'mdtone', cache NULL
pim[1140]: [13] Looked up cache pe 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x1 in one (found) - No error
pim[1140]: [13] Cache get: Found entry for 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x1 in one
pim[1140]: [13] pim_mvrf_mdt_cache_update:946, mt_lc 0x11, copied mt_mdt_ifname 'mdtone'
pim[1140]: [13] Create new MDT tlv buffer for one for type 0x2
pim[1140]: [13] Buffer allocated for one mtu 1348 size 0
pim[1140]: [13] TLV type set to 0x2, o_type 0x2
pim[1140]: [13] TLV added for one mtu 1348 size 36
pim[1140]: [13] MDT cache upd: pe 0.0.0.0, (10.2.2.9,232.100.1.1), mdt_type 0x2, core src 10.1.100.2, id [mdt 1:1 1], for vrf one [local, -], mt_lc 0x11, mdt_if 'Lmdtone', cache NULL
pim[1140]: [13] Looked up cache pe 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x2 in one (found) - No error
pim[1140]: [13] Cache get: Found entry for 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x2 in one
pim[1140]: [13] pim_mvrf_mdt_cache_update:946, mt_lc 0x11, copied mt_mdt_ifname 'Lmdtone'
pim[1140]: [13] Set next send time for core type (0x0/0x2) (v: 10.2.2.9,232.100.1.1) in one
pim[1140]: [13] 2. Flush MDT Join for one on Lmdtone(10.1.100.2) 6 (Cnt:1, Reached size 36 MTU 1348)
pim[1140]: [13] 2. Flush MDT Join for one (Lo0) 10.1.100.2
pim[1140]: [13] 2. Flush MDT Join for one on mdtone(10.1.100.2) 6 (Cnt:1, Reached size 16 MTU 1348)
pim[1140]: [13] 2. Flush MDT Join for one (Lo0) 10.1.100.2

Ingress-PE#show pim vrf one mdt cache        
 
Core Source     Cust (Source, Group)               Core Data       Expires
10.1.100.2       (10.2.2.9, 232.100.1.1)             232.1.2.4       00:02:36
10.1.100.2       (10.2.2.9, 232.100.1.1)             [mdt 1:1 1]     00:02:36

Hinweis: Der Wert für die Länge des PIM-Join-Typs (TLV) ist eine PIM-Nachricht, die über den Standard-MDT gesendet und zum Signalisieren des Daten-MDT verwendet wird. Es wird regelmäßig gesendet, einmal pro Minute.

Älterer Ausgangs-PE:

"debug ip pim vrf one 232.100.1.1":

PIM(1): Receive MDT Packet (55759) from 10.1.100.2 (Tunnel3), length (ip: 44, udp: 24), ttl: 1PIM(1): TLV type: 1 length: 16 MDT Packet length: 16

Der Legacy-PE-Cache für die PIM-Join-TLV:

Legacy-PE#show ip pim vrf one mdt receive

Joined MDT-data [group/mdt number : source] uptime/expires for VRF: one
[232.1.2.4 : 10.1.100.2] 00:01:10/00:02:45

Der Legacy-PE tritt dem Daten-MDT im Kern bei:

Legacy-PE#show ip mroute vrf one 232.100.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, 
       Z - Multicast Tunnel, z - MDT-data group sender, 
       Y - Joined MDT-data group, y - Sending to MDT-data group, 
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute, 
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed, 
       Q - Received BGP S-A Route, q - Sent BGP S-A Route, 
       V - RD & Vector, v - Vector, p - PIM Joins on route, 
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.2.2.9, 232.100.1.1), 00:08:48/00:02:34, flags: sTY
 Incoming interface: Tunnel3, RPF nbr 10.1.100.2, MDT:[10.1.100.2,232.1.2.4]/00:02:46
 Outgoing interface list:
 GigabitEthernet1/1, Forward/Sparse, 00:08:48/00:02:34

Der Empfänger-PE von Profile 1 empfängt ebenfalls die PIM Join TLV, für den mLDP-basierten Daten-MDT jedoch:

Egress-PE#debug pim vrf one mdt data
 
pim[1161]: [13] Received MDT Packet on Lmdtone (vrf:one) from 10.1.100.2, len 36
pim[1161]: [13] Processing type 2 tlv
pim[1161]: [13] Received MDT Join TLV from 10.1.100.2 for cust route 10.2.2.9,232.100.1.1
MDT number 1 len 36
pim[1161]: [13] Looked up cache pe 10.1.100.2(10.2.2.9,232.100.1.1) mdt_type 0x2 in one
(found) - No error
pim[1161]: [13] MDT cache upd: pe 10.1.100.2, (10.2.2.9,232.100.1.1), mdt_type 0x2, core
src 10.1.100.2, id [mdt 1:1 1], for vrf one [remote, -], mt_lc 0xffffffff, mdt_if 'xxx',
cache NULL
pim[1161]: [13] Looked up cache pe 10.1.100.2(10.2.2.9,232.100.1.1) mdt_type 0x2 in one
(found) - No error
pim[1161]: [13] Cache get: Found entry for 10.1.100.2(10.2.2.9,232.100.1.1) mdt_type 0x2
in one
RP/0/RP1/CPU0:Nov 27 16:04:02.726 : Return match for [mdt 1:1 1] src 10.1.100.2 in remote
list (one)
pim[1161]: [13] Remote join: MDT [mdt 1:1 1] known in one. Refcount (1, 1)

Egress-PE#show pim vrf one mdt cache
 
Core Source     Cust (Source, Group)               Core Data       Expires
10.1.100.2       (10.2.2.9, 232.100.1.1)             [mdt 1:1 1]     00:02:12

Egress-PE#show mrib vrf one route 232.100.1.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, MF - MPLS Encap, 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.2.9,232.100.1.1) RPF nbr: 10.1.100.2 Flags: RPF
Up: 00:45:20
Incoming Interface List
   Lmdtone Flags: A LMI, Up: 00:45:20
Outgoing Interface List
   GigabitEthernet0/0/0/9 Flags: F NS LI, Up: 00:45:20

Szenario 2.

Es gibt einen oder mehrere ältere PE-Router als Receiver-PE-Router.

Es gibt einen oder mehrere PE-Router als Receiver-PE-Router, auf denen Profil 9 ausgeführt wird (Standard-MDT - mLDP MP2MP BGP-AD PIM C-mcast Signaling).

BGP AD ist beteiligt, aber keine BGP C-Multicast-Signalisierung.

Konfiguration des Receiver-PE-Routers mit Profil 9:

vrf one
  vpn id 1:1
  address-family ipv4 unicast
   import route-target
    1:1
   !
   export route-target
    1:1
   !
  !
 
 router pim
  vrf one
   address-family ipv4
    rpf topology route-policy rpf-for-one
    !
    interface GigabitEthernet0/1/0/0
     enable
    !
   !
  !
 !
 
 route-policy rpf-for-one
   set core-tree mldp-default
 end-policy
 !
 
multicast-routing
 vrf one
  address-family ipv4
   mdt source Loopback0
   rate-per-route
   interface all enable
   accounting per-prefix
   bgp auto-discovery mldp
   !
   mdt default mldp ipv4 10.1.100.7
!
!
!
 
router bgp 1
!
address-family vpnv4 unicast
!
!
 address-family ipv4 mvpn
!
!
neighbor 10.1.100.7     <<< iBGP neighbor
remote-as 1
update-source Loopback0

address-family vpnv4 unicast
!
 address-family ipv4 mvpn
!
!
vrf one
rd 1:1
address-family ipv4 unicast
   redistribute connected
!
 address-family ipv4 mvpn
!
!

 mpls ldp
  mldp
   logging notifications
   address-family ipv4
   !
  !
 !

Der Eingangs-PE-Router muss über eine IPv4-MDT für die BGP-Adressfamilie verfügen, die mit dem des Legacy-PE-Routers übereinstimmt. Der Eingangs-PE-Router muss über eine IPv4-MVPN-Adresse für die BGP-Adressfamilie verfügen, die mit dem IPv4-MVPN des Profile 9-Ausgangs-PE-Routers übereinstimmt.

Konfiguration des Eingangs-PE-Routers:

vrf one
 vpn id 1:1
 address-family ipv4 unicast
  import route-target
   1:1
  !
  export route-target
   1:1
  !
 !
 address-family ipv6 unicast
 !
!
 
router pim
 vrf one
 address-family ipv4
   mdt c-multicast-routing pim
   announce-pim-join-tlv
   !
   interface GigabitEthernet0/1/0/0
   enable
   !
  !
 !
!
 
multicast-routing
 vrf one
  address-family ipv4
   mdt source Loopback0
   interface all enable
   bgp auto-discovery mldp
   !
   mdt default ipv4 232.1.1.1
   mdt default mldp ipv4 10.1.100.7
   mdt data 255
   mdt data 232.1.2.0/24
 !
 !
!
 
router bgp 1
address-family vpnv4 unicast
!
 address-family ipv4 mdt
!
 address-family ipv4 mvpn
!
neighbor 10.1.100.7     <<< iBGP neighbor
remote-as 1
update-source Loopback0
address-family vpnv4 unicast
!
 address-family ipv4 mdt
!
 address-family ipv4 mvpn
!
!
vrf one
rd 1:2
address-family ipv4 unicast
   redistribute connected
!
 address-family ipv4 mvpn
!
 
mpls ldp
  mldp
   logging notifications
   address-family ipv4
   !
  !
 !

Ohne den Befehl "announce-pim-join-tlv" sendet der Eingangs-PE-Router keine PIM-Join-TLV-Nachrichten über die Standard-MDTs, wenn die BGP Auto-Discovery (AD) aktiviert ist. Ohne diesen Befehl sendet der Eingangs-PE-Router nur eine BGP-IPv4-MVPN-Routing-Typ-3-Aktualisierung. Der Profil-9-Egress-PE-Router empfängt das BGP-Update und installiert die Daten-MDT-Nachricht in seinem Cache. Der Legacy-PE-Router führt BGP AD nicht aus und empfängt daher die Data MDT Join-Nachricht nicht über BGP.

Der Eingangs-PE muss den C-Multicast-Datenverkehr an beide Typen von MDT weiterleiten:

Ingress-PE#show mrib vrf one route 232.100.1.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, MF - MPLS Encap, 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.2.9,232.100.1.1) RPF nbr: 10.2.2.9 Flags: RPF MT
MT Slot: 0/1/CPU0
Up: 05:03:56
Incoming Interface List
   GigabitEthernet0/1/0/0 Flags: A, Up: 05:03:56
Outgoing Interface List
   mdtone Flags: F NS MI MT MA, Up: 05:03:56
   Lmdtone Flags: F NS LMI MT MA, Up: 05:03:12

Der Eingangs-PE sollte den Legacy-PE auf der Schnittstelle mdtone und den Profile 9-PE auf der Schnittstelle mdtone als PIM-Nachbarn sehen:

Ingress-PE#show pim vrf one neighbor
 
PIM neighbors in VRF one
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.100.1                   Lmdtone               6w1d     00:01:18 1     P
10.1.100.2*                  Lmdtone               6w1d     00:01:34 1 (DR) P
10.1.100.2*                  mdtone                5w0d     00:01:18 1     P
10.1.100.3                   mdtone                06:00:03 00:01:21 1 (DR)

Der Ausgangs-PE-Router von Profil 9 empfängt die Daten-MDT-Nachricht als BGP-Update für den Routing-Typ 3 in der IPv4-MVPN-Adressfamilie:

Egress-PE#show bgp ipv4 mvpn vrf one                                                  
BGP router identifier 10.1.100.1, local AS number 1
BGP generic scan interval 60 secs
BGP table state: Active
Table ID: 0x0   RD version: 1367879340
BGP main routing table version 92
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: 1:1 (default for vrf one)
*> [1][10.1.100.1]/40 0.0.0.0                               0 i
*>i[1][10.1.100.2]/40 10.1.100.2                   100     0 i
*>i[3][32][10.2.2.9][32][232.100.1.1][10.1.100.2]/120
                     10.1.100.2                   100     0 i
 
Processed 3 prefixes, 3 paths

Egress-PE#show bgp ipv4 mvpn vrf one [3][32][10.2.2.9][32][232.100.1.1][10.1.100.2]/120
BGP routing table entry for [3][32][10.2.2.9][32][232.100.1.1][10.1.100.2]/120, Route
Distinguisher: 1:1
Versions:
Process           bRIB/RIB SendTblVer
Speaker                 92         92
Last Modified: Nov 27 20:25:32.474 for 00:44:22
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.1.100.2 (metric 12) from 10.1.100.7 (10.1.100.2)
     Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate,
imported
     Received Path ID 0, Local Path ID 1, version 92
     Community: no-export
     Extended community: RT:1:1
     Originator: 10.1.100.2, Cluster list: 10.1.100.7
     PMSI: flags 0x00, type 2, label 0, ID
0x060001040a016402000e02000b0000010000000100000001
     Source VRF: default, Source Route Distinguisher: 1:2

"debug pim vrf one mdt data" auf dem Eingangs-PE:

pim[1140]: [13] In mdt timers process...
pim[1140]: [13] Processing MDT JOIN SEND timer for MDT null core mldp pointer in one
pim[1140]: [13] In join_send_update_timer: route->mt_head 50c53b44
pim[1140]: [13] Create new MDT tlv buffer for one for type 0x1
pim[1140]: [13] Buffer allocated for one mtu 1348 size 0
pim[1140]: [13] TLV type set to 0x1
pim[1140]: [13] TLV added for one mtu 1348 size 16
pim[1140]: [13] MDT cache upd: pe 0.0.0.0, (10.2.2.9,232.100.1.1), mdt_type 0x1, core
(10.1.100.2,232.1.2.5), for vrf one [local, -], mt_lc 0x11, mdt_if 'mdtone', cache NULL
pim[1140]: [13] Looked up cache pe 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x1 in one
(found) - No error
pim[1140]: [13] Cache get: Found entry for 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x1 in
one
pim[1140]: [13] pim_mvrf_mdt_cache_update:946, mt_lc 0x11, copied mt_mdt_ifname 'mdtone'
pim[1140]: [13] Create new MDT tlv buffer for one for type 0x2
pim[1140]: [13] Buffer allocated for one mtu 1348 size 0
pim[1140]: [13] TLV type set to 0x2, o_type 0x2
pim[1140]: [13] TLV added for one mtu 1348 size 36
pim[1140]: [13] MDT cache upd: pe 0.0.0.0, (10.2.2.9,232.100.1.1), mdt_type 0x2, core src
10.1.100.2, id [mdt 1:1 1], for vrf one [local, -], mt_lc 0x11, mdt_if 'Lmdtone', cache
NULL
: pim[1140]: [13] Looked up cache pe 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x2 in one
(found) - No error
pim[1140]: [13] Cache get: Found entry for 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x2 in
one
pim[1140]: [13] pim_mvrf_mdt_cache_update:946, mt_lc 0x11, copied mt_mdt_ifname 'Lmdtone'
pim[1140]: [13] Set next send time for core type (0x0/0x2) (v: 10.2.2.9,232.100.1.1) in
one
pim[1140]: [13] 2. Flush MDT Join for one on Lmdtone(10.1.100.2) 6 (Cnt:1, Reached size
36 MTU 1348)
pim[1140]: [13] 2. Flush MDT Join for one (Lo0) 10.1.100.2
pim[1140]: [13] 2. Flush MDT Join for one on mdtone(10.1.100.2) 6 (Cnt:1, Reached size 16
MTU 1348)
pim[1140]: [13] 2. Flush MDT Join for one (Lo0) 10.1.100.2

Der Eingangs-PE sendet eine PIM-Join-TLV für den PIM- und den mLDP-basierten Daten-MDT.

Auf dem Legacy-PE:

"debug ip pim vrf one 232.100.1.1":

PIM(1): Receive MDT Packet (56333) from 10.1.100.2 (Tunnel3), length (ip: 44, udp: 24), ttl: 1
PIM(1): TLV type: 1 length: 16 MDT Packet length: 16

Der Legacy-PE empfängt und zwischenspeichert die PIM-Join-TLV:

Legacy-PE#show ip pim vrf one mdt receive  
 
Joined MDT-data [group/mdt number : source] uptime/expires for VRF: one
[232.1.2.5 : 10.1.100.2] 00:23:30/00:02:33

Der Legacy-PE tritt dem Daten-MDT im Kern bei:

Legacy-PE#show ip mroute vrf one 232.100.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
 
(10.2.2.9, 232.100.1.1), 05:13:35/00:03:02, flags: sTY
Incoming interface: Tunnel3, RPF nbr 10.1.100.2, MDT:[10.1.100.2,232.1.2.5]/00:02:37
Outgoing interface list:
   GigabitEthernet1/1, Forward/Sparse, 05:13:35/00:03:02

Der Profile 9 Receiver-PE.

"debug pim vrf one mdt data" auf dem Ausgangs-PE von Profil 9:

pim[1161]: [13] Received MDT Packet on Lmdtone (vrf:one) from 10.1.100.2, len 36
pim[1161]: [13] Processing type 2 tlv
pim[1161]: [13] Received MDT Join TLV from 10.1.100.2 for cust route 10.2.2.9,232.100.1.1
MDT number 1 len 36
pim[1161]: [13] Looked up cache pe 10.1.100.2(10.2.2.9,232.100.1.1) mdt_type 0x2 in one
(found) - No error
pim[1161]: [13] MDT cache upd: pe 10.1.100.2, (10.2.2.9,232.100.1.1), mdt_type 0x2, core
src 10.1.100.2, id [mdt 1:1 1], for vrf one [remote, -], mt_lc 0xffffffff, mdt_if 'xxx',
cache NULL
pim[1161]: [13] Looked up cache pe 10.1.100.2(10.2.2.9,232.100.1.1) mdt_type 0x2 in one
(found) - No error
pim[1161]: [13] Cache get: Found entry for 10.1.100.2(10.2.2.9,232.100.1.1) mdt_type 0x2
in one
pim[1161]: [13] MDT lookup: Return match for [mdt 1:1 1] src 10.1.100.2 in remote list
(one)
pim[1161]: [13] Remote join: MDT [mdt 1:1 1] known in one. Refcount (1, 1)

Der Profile 9-Empfänger-PE empfängt und zwischenspeichert die PIM-Join-TLV. Der Empfangs-PE für Profil 9 hat ebenfalls vom Daten-MDT erfahren, weil er vom Eingangs-PE die BGP-Update-Nachricht für den Routing-Typ 3 erhalten hat. Die PIM-Join-TLV und der Routing-Typ der BGP-Update-Nachricht sind identisch und enthalten dieselben Informationen in Bezug auf den Core-Tree-Tunnel für den Daten-MDT.

Egress-PE#show pim vrf one mdt cache
 
Core Source     Cust (Source, Group)               Core Data       Expires
10.1.100.2       (10.2.2.9, 232.100.1.1)             [mdt 1:1 1]     00:02:35

Egress-PE#show mrib vrf one route 232.100.1.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, MF - MPLS Encap, 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.2.9,232.100.1.1) RPF nbr: 10.1.100.2 Flags: RPF
Up: 05:10:22
Incoming Interface List
   Lmdtone Flags: A LMI, Up: 05:10:22
Outgoing Interface List
   GigabitEthernet0/0/0/9 Flags: F NS LI, Up: 05:10:22

Szenario 3.

Es gibt einen oder mehrere Legacy-PE-Router als Receiver-PE-Router.
Es gibt einen oder mehrere PE-Router als Receiver-PE-Router, auf denen Profil 13 ausgeführt wird (Standard-MDT - mLDP MP2MP BGP-AD BGP C-mcast Signaling).
Es gibt BGP AD und BGP C-Multicast-Signalisierung.

Konfiguration des Receiver-PE-Routers mit Profil 13:

vrf one
 vpn id 1:1
 address-family ipv4 unicast
  import route-target
   1:1
  !
  export route-target
   1:1
  !
 !

router pim
 vrf one
  address-family ipv4
   rpf topology route-policy rpf-for-one
   mdt c-multicast-routing bgp
   !
   interface GigabitEthernet0/1/0/0
    enable
   !
  !
 !
!

route-policy rpf-for-one
  set core-tree mldp-default
end-policy
!

multicast-routing
 vrf one
  address-family ipv4
   mdt source Loopback0
   rate-per-route
   interface all enable
   accounting per-prefix
   bgp auto-discovery mldp
   !
   mdt default mldp ipv4 10.1.100.7
  !
 !
! 

router bgp 1
!
 address-family vpnv4 unicast
 !
!
address-family ipv4 mvpn
 !
!
 neighbor 10.1.100.7     <<< iBGP neighbor
  remote-as 1
  update-source Loopback0
  !
  address-family vpnv4 unicast
  !
  address-family ipv4 mvpn
  !
 !
vrf one
  rd 1:1
  address-family ipv4 unicast
   redistribute connected
  !
  address-family ipv4 mvpn
  !
 !

mpls ldp
 mldp
  logging notifications
  address-family ipv4
  !
 !
!

Konfiguration des Eingangs-PE-Routers:

vrf one
 vpn id 1:1
 address-family ipv4 unicast
  import route-target
   1:1
  !
  export route-target
   1:1
  !
 !
 address-family ipv6 unicast
 !
!

router pim
 vrf one
  address-family ipv4
   mdt c-multicast-routing bgp
    announce-pim-join-tlv
   !
   interface GigabitEthernet0/1/0/0
    enable
   !
  !
 !
!

multicast-routing
 vrf one
  address-family ipv4
   mdt source Loopback0
   interface all enable
   mdt default ipv4 232.1.1.1
   mdt default mldp ipv4 10.1.100.7
   mdt data 255
   mdt data 232.1.2.0/24
  !
 !
!

router bgp 1
 address-family vpnv4 unicast
 !
 address-family ipv4 mdt
 !
 address-family ipv4 mvpn
 !
 neighbor 10.1.100.7      <<< iBGP neighbor
  remote-as 1
  update-source Loopback0
  address-family vpnv4 unicast
  !
  address-family ipv4 mdt
  !
  address-family ipv4 mvpn
  !
 !
 vrf one
  rd 1:2
  address-family ipv4 unicast
   redistribute connected
  !
  address-family ipv4 mvpn
  !

mpls ldp
 mldp
  logging notifications
  address-family ipv4
  !
 !
!

Ohne den Befehl announce-pim-join-tlv sendet der Eingangs-PE-Router keine PIM-Join-TLV-Nachrichten über den Standard-MDT, wenn BGP AD aktiviert ist. Ohne diesen Befehl sendet der Eingangs-PE-Router nur eine BGP-IPv4-MVPN-Routing-Typ-3-Aktualisierung. Der Profil 13-Egress-PE-Router empfängt das BGP-Update und installiert die Daten-MDT-Nachricht in seinem Cache. Der Legacy-PE-Router führt BGP AD nicht aus und empfängt daher die Data MDT Join-Nachricht nicht über BGP.

Der Eingangs-PE muss an beide Typen von MDT weitergeleitet werden:

Ingress-PE#show mrib vrf one route 232.100.1.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, MF - MPLS Encap, 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.2.9,232.100.1.1) RPF nbr: 10.2.2.9 Flags: RPF MT
MT Slot: 0/1/CPU0
Up: 19:49:27
Incoming Interface List
   GigabitEthernet0/1/0/0 Flags: A, Up: 19:49:27
Outgoing Interface List
   mdtone Flags: F MI MT MA, Up: 19:49:27
   Lmdtone Flags: F LMI MT MA, Up: 01:10:15

Der Eingangs-PE sollte den Legacy-PE auf dem Schnittstellen-MidTone als PIM-Nachbarn sehen. Der Profile 13-PE-Router an der Schnittstelle Lmdtone muss jedoch nicht unbedingt als PIM-Nachbar vorhanden sein, da BGP jetzt als C-Multicast-Signalisierungsprotokoll verwendet wird.

"debug pim vrf one mdt data" auf dem Eingangs-PE:

pim[1140]: [13] In mdt timers process...
pim[1140]: [13] Processing MDT JOIN SEND timer for MDT null core mldp pointer in one
pim[1140]: [13] In join_send_update_timer: route->mt_head 50c53b44
pim[1140]: [13] Create new MDT tlv buffer for one for type 0x1
pim[1140]: [13] Buffer allocated for one mtu 1348 size 0
pim[1140]: [13] TLV type set to 0x1
pim[1140]: [13] TLV added for one mtu 1348 size 16
pim[1140]: [13] MDT cache upd: pe 0.0.0.0, (10.2.2.9,232.100.1.1), mdt_type 0x1, core (10.1.100.2,232.1.2.5), for vrf one [local, -], mt_lc 0x11, mdt_if 'mdtone', cache NULL
pim[1140]: [13] Looked up cache pe 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x1 in one (found) - No error
pim[1140]: [13] Cache get: Found entry for 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x1 in one
pim[1140]: [13] pim_mvrf_mdt_cache_update:946, mt_lc 0x11, copied mt_mdt_ifname 'mdtone'
pim[1140]: [13] Create new MDT tlv buffer for one for type 0x2
pim[1140]: [13] Buffer allocated for one mtu 1348 size 0
pim[1140]: [13] TLV type set to 0x2, o_type 0x2
pim[1140]: [13] TLV added for one mtu 1348 size 36
pim[1140]: [13] MDT cache upd: pe 0.0.0.0, (10.2.2.9,232.100.1.1), mdt_type 0x2, core src 10.1.100.2, id [mdt 1:1 1], for vrf one [local, -], mt_lc 0x11, mdt_if 'Lmdtone', cache NULL
pim[1140]: [13] Looked up cache pe 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x2 in one (found) - No error
pim[1140]: [13] Cache get: Found entry for 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x2 in one
pim[1140]: [13] pim_mvrf_mdt_cache_update:946, mt_lc 0x11, copied mt_mdt_ifname 'Lmdtone'
pim[1140]: [13] Set next send time for core type (0x0/0x2) (v: 10.2.2.9,232.100.1.1) in one
pim[1140]: [13] 2. Flush MDT Join for one on Lmdtone(10.1.100.2) 6 (Cnt:1, Reached size 36 MTU 1348)
pim[1140]: [13] 2. Flush MDT Join for one (Lo0) 10.1.100.2
pim[1140]: [13] 2. Flush MDT Join for one on mdtone(10.1.100.2) 6 (Cnt:1, Reached size 16 MTU 1348)
pim[1140]: [13] 2. Flush MDT Join for one (Lo0) 10.1.100.2
pim[1140]: [13] MDT Grp lookup: Return match for grp 232.1.2.5 src 10.1.100.2 in local list (-)

Der Eingangs-PE sendet PIM-Join-TLV für den PIM-basierten und den mLDP-basierten Daten-MDT.

"debug ip pim vrf one 232.100.1.1" auf dem älteren PE:

PIM(1): Receive MDT Packet (57957) from 10.1.100.2 (Tunnel3), length (ip: 44, udp: 24), ttl: 1
PIM(1): TLV type: 1 length: 16 MDT Packet length: 16

Der Legacy-PE-Cache für die PIM-Join-TLV:

Legacy-PE#show ip pim vrf one mdt receive

Joined MDT-data [group/mdt number : source]  uptime/expires for VRF: one
 [232.1.2.5 : 10.1.100.2]  00:03:36/00:02:24

Der Legacy-PE tritt dem Daten-MDT im Kern bei:

Legacy-PE#show ip mroute vrf one 232.100.1.1  
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, 
       Z - Multicast Tunnel, z - MDT-data group sender, 
       Y - Joined MDT-data group, y - Sending to MDT-data group, 
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute, 
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed, 
       Q - Received BGP S-A Route, q - Sent BGP S-A Route, 
       V - RD & Vector, v - Vector, p - PIM Joins on route, 
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.2.2.9, 232.100.1.1), 18:53:53/00:02:50, flags: sTY
  Incoming interface: Tunnel3, RPF nbr 10.1.100.2, MDT:[10.1.100.2,232.1.2.5]/00:02:02
  Outgoing interface list:
    GigabitEthernet1/1, Forward/Sparse, 18:53:53/00:02:50

Profil 13 Receiver-PE:
"debug pim vrf one mdt data" auf dem Ausgangs-PE von Profile 13:

pim[1161]: [13] Received MDT Packet on Lmdtone (vrf:one) from 10.1.100.2, len 36
pim[1161]: [13] Processing type 2 tlv
pim[1161]: [13] Received MDT Join TLV from 10.1.100.2 for cust route 10.2.2.9,232.100.1.1 MDT number 1 len 36
pim[1161]: [13] Looked up cache pe 10.1.100.2(10.2.2.9,232.100.1.1) mdt_type 0x2 in one (found) - No error
pim[1161]: [13] MDT cache upd: pe 10.1.100.2, (10.2.2.9,232.100.1.1), mdt_type 0x2, core src 10.1.100.2, id [mdt 1:1 1], for vrf one [remote, -], mt_lc 0xffffffff, mdt_if 'xxx', cache NULL
pim[1161]: [13] Looked up cache pe 10.1.100.2(10.2.2.9,232.100.1.1) mdt_type 0x2 in one (found) - No error
pim[1161]: [13] Cache get: Found entry for 10.1.100.2(10.2.2.9,232.100.1.1) mdt_type 0x2 in one
pim[1161]: [13] MDT lookup: Return match for [mdt 1:1 1] src 10.1.100.2 in remote list (one)
pim[1161]: [13] Remote join: MDT [mdt 1:1 1] known in one. Refcount (1, 1)

RP/0/RP1/CPU0:Legacy-PE#show pim vrf one mdt cache 

Core Source      Cust (Source, Group)                Core Data        Expires
10.1.100.2       (10.2.2.9, 232.100.1.1)             [mdt 1:1 1]      00:02:21

Der Empfangs-PE-Router Profile 13 empfängt und speichert die PIM Join TLV für den mLDP-basierten MDT. Der Empfangs-PE für Profile 13 hat außerdem vom Daten-MDT erfahren, weil er vom Eingangs-PE die BGP-Update-Nachricht für den Routing-Typ 3 erhalten hat. Die PIM-Join-TLV und der Routing-Typ der BGP-Update-Nachricht sind identisch und enthalten dieselben Informationen in Bezug auf den Core-Tree-Tunnel für den Daten-MDT.

Ingress-PE#show bgp ipv4 mvpn vrf one 
BGP router identifier 10.1.100.1, local AS number 1
BGP generic scan interval 60 secs
BGP table state: Active
Table ID: 0x0   RD version: 1367879340
BGP main routing table version 93
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: 1:1 (default for vrf one)
*> [1][10.1.100.1]/40 0.0.0.0                                0 i
*>i[1][10.1.100.2]/40 10.1.100.2                    100      0 i
*>i[3][32][10.2.2.9][32][232.100.1.1][10.1.100.2]/120
                      10.1.100.2                    100      0 i
*> [7][1:2][1][32][10.2.2.9][32][232.100.1.1]/184
                      0.0.0.0                                0 i

Processed 4 prefixes, 4 paths

Egress-PE#show bgp ipv4 mvpn vrf one [3][32][10.2.2.9][32][232.100.1.1][10.1.100.2]/120
BGP routing table entry for [3][32][10.2.2.9][32][232.100.1.1][10.1.100.2]/120, Route Distinguisher: 1:1
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 92          92
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.1.100.2 (metric 12) from 10.1.100.7 (10.1.100.2)
      Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 0, Local Path ID 1, version 92
      Community: no-export
      Extended community: RT:1:1 
      Originator: 10.1.100.2, Cluster list: 10.1.100.7
      PMSI: flags 0x00, type 2, label 0, ID 0x060001040a016402000e02000b0000010000000100000001
      Source VRF: default, Source Route Distinguisher: 1:2

Bei dieser BGP-Route handelt es sich um den Routing-Typ 3 für den Protokolltunneltyp 2, d. h. den mLDP P2MP LSP (den Daten-MDT, der auf einem P2MP mLSP basiert). Es gibt keinen BGP-Routing-Typ 3 für einen PIM-Tree, da BGP AD für PIM nicht aktiviert ist.

Es gibt auch den Routing-Typ 7, da die C-Multicast-Signalisierung zwischen dem Ausgangs-PE von Profile 13 und dem Eingangs-PE aktiviert ist. Das BGP-Update für Routing-Typ 7 wird vom Egress-PE-Profil 13 an den Egress-PE-Router gesendet.

Szenario 4.

In diesem Szenario gibt es im VPN-Kontext den PIM Sparse Mode.

Es gibt einen oder mehrere Legacy-PE-Router als Source-PE-Router.

Es gibt einen oder mehrere PE-Router als Receiver-PE-Router, auf denen Profil 13 ausgeführt wird (Standard-MDT - mLDP MP2MP BGP-AD BGP C-mcast Signaling). Es gibt BGP AD und BGP C-Multicast-Signalisierung. Da diese PE-Router den Datenverkehr direkt vom Quell-PE (dem alten PE-Router) empfangen müssen, müssen sie auch Profil 0 ausführen.

Der RP-PE ist ein PE-Router, der Profile 13 ausführt (Standard-MDT - mLDP MP2MP BGP-AD BGP C-mcast Signaling). Es gibt BGP AD und BGP C-Multicast-Signalisierung. Da der RP-PE-Router in der Lage sein muss, Datenverkehr direkt vom Quell-PE (dem älteren PE-Router) zu empfangen, muss auch Profil 0 ausgeführt werden.

Das Multicast-Routing funktionierte in Szenario 3, dies funktioniert jedoch möglicherweise nur für Source-Specific Multicasting (SSM). Wenn die C-Signalisierung im Sparse Mode ist, schlägt Multicast möglicherweise fehl. Dies kann davon abhängen, wo sich der Rendez-Vous Point (RP) befindet. Wenn die Signalisierung im Overlay nur (S, G) möglich ist, funktioniert das Multicast-Routing wie in Szenario 3. Befindet sich der RP am Receiver-Standort, Befindet sich der RP am Standort eines Receivers, sendet der Receiver-PE weder per PIM noch per BGP eine (*,G) Join-In-Overlay-Nachricht. Befindet sich der RP jedoch am Quell-PE oder an einem anderen PE, sind (*,G)- und (S,G)-Signalisierungen im Overlay vorhanden. Wenn dies mit der Konfiguration gemäß Szenario 3 erfolgt, schlägt das Multicast-Routing möglicherweise fehl.

Schauen Sie sich Abbildung 2 an. Es zeigt ein Netzwerk mit einem Source-PE (Legacy-PE), einem RP-PE (PE2) und einem Receiver-PE (PE1).

Abbildung 2.

Die Egress-PE-Router müssen Joins für (*,G) senden. Welches Protokoll verwendet wird, hängt von der Konfiguration ab. Der Egress-PE-Router verwendet BGP und der Legacy-Source-PE-Router verwendet PIM, sofern ein Receiver vorhanden ist. Der Shared Tree wird daher fehlerfrei signalisiert. Beim Senden der Quelle tritt ein Problem auf: Der Quellbaum wird nicht signalisiert.

Das Problem

Sobald die Quelle mit dem Senden beginnt, empfängt der RP die Registrierungspakete vom PIM First Hop Router (FHR). Hierbei kann es sich um den Legacy-Source-PE-Router handeln. Der RP-PE müsste dann eine PIM-Join-Nachricht (S,G) an den Legacy-Source-PE senden, da auf dem Legacy-Source-PE BGP nicht als Overlay-Signalisierungsprotokoll ausgeführt wird. Auf dem RP-PE ist jedoch BGP als Overlay-Signalisierungsprotokoll konfiguriert. Der Legacy-Source-PE empfängt daher nie eine PIM-Join-Nachricht (S,G) vom RP-PE, sodass der Source Tree von Source zu RP nicht signalisiert werden kann. Die Konfiguration befindet sich noch in der Registrierungsphase. Die Liste der ausgehenden Schnittstellen (OIL) auf dem Legacy-Source-PE ist leer:

Legacy-PE#show ip mroute vrf one 225.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
 
(*, 225.1.1.1), 00:05:47/stopped, RP 10.2.100.9, flags: SPF
Incoming interface: Tunnel3, RPF nbr 10.1.100.2
Outgoing interface list: Null
 
(10.2.3.10, 225.1.1.1), 00:05:47/00:02:42, flags: PFT
Incoming interface: GigabitEthernet1/1, RPF nbr 10.2.3.10
Outgoing interface list: Null

Um dieses Problem zu beheben, muss der RP-PE eine PIM-Join-Nachricht für (S, G) an den Legacy-Source-PE senden, während auf dem RP-PE BGP als Overlay-Signalisierungsprotokoll für die nicht-Legacy-Router aktiviert ist. Wenn eine Quelle hinter einem nicht älteren Router online geht, muss der RP-PE eine BGP-Update-Nachricht vom Routing-Typ 7 an diesen nicht älteren Router senden.

Der RP-PE kann sowohl PIM als auch BGP als Overlay-Signalisierung verwenden. Die Wahl eines dieser beiden Optionen wird durch eine Routenrichtlinie bestimmt. Sie benötigen den Migrationsbefehl für die VRF-Instanz unter Router PIM. Für das in Abbildung 2 dargestellte Netzwerk ist dies die erforderliche Konfiguration auf dem RP-PE:

router pim
 vrf one
 address-family ipv4
   rpf topology route-policy rpf-for-one
   mdt c-multicast-routing bgp
    migration route-policy PIM-to-BGP
    announce-pim-join-tlv
   !
   interface GigabitEthernet0/1/0/0
    enable
   !
  !
 !
!
route-policy rpf-for-one
 if next-hop in (10.1.100.3/32) then
   set core-tree pim-default
else
   set core-tree mldp-default
endif
end-policy
!
 
route-policy PIM-to-BGP
 if next-hop in (10.1.100.3/32) then
   set c-multicast-routing pim
 else
   set c-multicast-routing bgp
 endif
end-policy
!
 
multicast-routing
 vrf one
  address-family ipv4
   mdt source Loopback0
   rate-per-route
   interface all enable
   accounting per-prefix
   bgp auto-discovery mldp
   !
   mdt default ipv4 232.1.1.1
   mdt default mldp ipv4 10.1.100.7
  !
 !
!

Die Route-Policy PIM-to-BGP legt fest, dass der Remote-PE-Router PIM als Overlay-Signalisierungsprotokoll verwendet, wenn es sich um den Router 10.1.100.3 (Legacy-Source-PE) handelt. Ansonsten wird BGP als Overlay-Signalisierungsprotokoll verwendet (nicht für ältere PE-Router). Daher sendet der RP-PE jetzt eine PIM-Join-Nachricht (S,G) an den Legacy-Source-PE auf dem PIM-basierten Standard-MDT. Der Legacy-Source-PE hat jetzt den Eintrag (S, G):

Legacy-PE#show ip mroute vrf one 225.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
     N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
 
(*, 225.1.1.1), 00:11:56/stopped, RP 10.2.100.9, flags: SPF
 Incoming interface: Tunnel3, RPF nbr 10.1.100.2
 Outgoing interface list: Null
 
(10.2.3.10, 225.1.1.1), 00:11:56/00:03:22, flags: FT
 Incoming interface: GigabitEthernet1/1, RPF nbr 10.2.3.10
 Outgoing interface list:
   Tunnel3, Forward/Sparse, 00:00:11/00:03:18

Der Empfänger kann die Multicast-Pakete empfangen, wenn die RP-PE-U die Pakete umdreht: Er leitet die vom MDT empfangenen Multicast-Pakete an den Lmdt-Tree weiter.

Hinweis: Überprüfen Sie, ob der RP-PE-Router die PE-Turnaround-Funktion auf dieser Plattform und Software unterstützt.

RP/0/3/CPU1:PE2#show mrib vrf one route 225.1.1.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, MF - MPLS Encap, 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
 
(*,225.1.1.1) RPF nbr: 10.2.2.9 Flags: C RPF
 Up: 00:53:59
 Incoming Interface List
   GigabitEthernet0/1/0/0 Flags: A, Up: 00:53:59
 Outgoing Interface List
   Lmdtone Flags: F LMI, Up: 00:53:59
 
(10.2.3.10,225.1.1.1) RPF nbr: 10.1.100.3 Flags: RPF
 Up: 00:03:00
 Incoming Interface List
   mdtone Flags: A MI, Up: 00:03:00
 Outgoing Interface List
   Lmdtone Flags: F NS LMI, Up: 00:03:00

Unabhängig davon, ob auf dem Last Hop Router (LHR) ein SPT-Switchover konfiguriert ist oder nicht, wird der Multicast-Verkehr weiterhin über den Shared Tree an den RP-PE weitergeleitet. Abbildung 3 zeigt, wie der Multicast-Datenverkehr weitergeleitet wird.

Abbildung 3:

Der Ausgangs-PE hat keinen (S,G)-Eintrag:

RP/0/RP1/CPU0:PE1#show mrib vrf one route 225.1.1.1
IP Multicast Routing Information Bas
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, MF - MPLS Encap, 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
 
(*,225.1.1.1) RPF nbr: 10.1.100.2 Flags: C RPF
 Up: 04:35:36
 Incoming Interface List
   Lmdtone Flags: A LMI, Up: 03:00:24
 Outgoing Interface List
   GigabitEthernet0/0/0/9 Flags: F NS, Up: 04:35:36

Wenn der Egress-PE der LHR ist, hat er keinen (S,G)-Eintrag. Der Grund dafür, dass der Egress-PE keinen Switchover zum (S,G)-Eintrag durchführen kann, ist, dass er keine aktive BGP-Source-Route von einem PE-Router erhalten hat. Der Multicast-Datenverkehr wird wie in Abbildung 3 weitergeleitet.

Es ist jedoch möglich, dass der Egress-PE nicht der LHR, sondern ein CE-Router am Egress-PE-Standort der LHR ist. Wenn dieser CE-Router zum Source Tree wechselt, erhält der Egress-PE eine PIM-Join-Nachricht (S,G) und installiert den Eintrag (S,G).

RP/0/RP1/CPU0:PE1#show mrib vrf one route 225.1.1.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, MF - MPLS Encap, 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
 
 
(*,225.1.1.1) RPF nbr: 10.1.100.2 Flags: C RPF
 Up: 00:04:51
 Incoming Interface List
   Lmdtone Flags: A LMI, Up: 00:04:51
 Outgoing Interface List
   GigabitEthernet0/0/0/9 Flags: F NS, Up: 00:04:51
 
(10.2.3.10,225.1.1.1) RPF nbr: 10.1.100.3 Flags: RPF
 Up: 00:00:27
 Incoming Interface List
   Lmdtone Flags: A LMI, Up: 00:00:27
 Outgoing Interface List
   GigabitEthernet0/0/0/9 Flags: F NS, Up: 00:00:27

Der Egress-PE verbindet nun RPF mit der Quelle und findet den Router Legacy-Source-PE als RPF-Nachbarn:

RP/0/RP1/CPU0:PE1#show pim vrf one rpf 10.2.3.10
 
Table: IPv4-Unicast-default
* 10.2.3.10/32 [200/0]
   via Lmdtone with rpf neighbor 10.1.100.3
   Connector: 1:3:10.1.100.3, Nexthop: 10.1.100.3

Da zwischen dem Egress-PE und dem Legacy-Source-PE kein MDT vorhanden ist, kann der Egress-PE keine Join-Nachricht an den Legacy-Source-PE senden. Beachten Sie, dass der Egress-PE nur mLDP-Trees erstellt und BGP-Kundensignale sendet. Denken Sie daran, dass die Legacy-Source-PEs nur PIM-basierte Trees erstellen und nur PIM-Kundensignale senden.

Da der Egress-PE jedoch über RPF-Informationen verfügt, die auf die eingehende Schnittstelle Lmdt verweisen, und der Multicast-Datenverkehr weiterhin vom RP-PE über diesen MDT eingeht, wird der Multicast-Datenverkehr an den Empfänger weitergeleitet und fällt nicht beim RPF aus. Der Grund hierfür ist, dass die RPF keine strenge RPF-Prüfung durchführt, um zu überprüfen, ob der Multicast-Verkehr tatsächlich vom RPF-Nachbarn 10.1.100.3, dem Legacy-PE-Router, eingeht. Beachten Sie, dass für 10.1.100.3 auf PE1 auf Lmdt keine PIM-Adjacency vorhanden ist, da Lmdt vom Legacy-PE nicht verwendet werden kann, da PIM nur als Core-Tree-Protokoll ausgeführt wird (Profil 0):

RP/0/RP1/CPU0:PE1#show pim vrf one neighbor                    
PIM neighbors in VRF one
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.100.1*                  Lmdtone               01:32:46 00:01:32 100 (DR) P
10.1.100.2                   Lmdtone               01:30:46 00:01:16 1     P
10.1.100.4                   Lmdtone               01:30:38 00:01:24 1     P
10.1.100.1*                  mdtone                 01:32:46 00:01:34 100 (DR) P
10.1.100.2                   mdtone                 01:32:45 00:01:29 1     P
10.1.100.3                   mdtone                 01:32:17 00:01:29 1     P
10.1.100.4                   mdtone                 01:32:43 00:01:20 1     P
10.2.1.1*                    GigabitEthernet0/0/0/9 01:32:46 00:01:18 100     B P E
10.2.1.8                     GigabitEthernet0/0/0/9 01:32:39 00:01:16 100 (DR)

PE1 wählt Lmdt als eingehende Schnittstelle aus, weil dies die vom RPF-Topologiebefehl für PE1 empfangenen Informationen sind:

route-policy rpf-for-one
 set core-tree mldp-default
end-policy
!

Wenn die RPF für PE1 weiterhin in Ordnung ist, kann der Multicast-Verkehr den Empfänger hinter PE1 erreichen. Der Datenverkehr verläuft jedoch nicht über den kürzesten Pfad vom Legacy-PE zum PE1 im Core.

Die Lösung

Um dieses Problem zu beheben, muss der Egress-PE (PE1) so konfiguriert werden, dass er PIM-basierten MDT und BGP auch als Overlay-Signalisierung signalisiert. Diese Konfiguration ist auf dem Egress-PE in diesem Fall erforderlich:

router pim
 vrf one
  address-family ipv4
   rpf topology route-policy rpf-for-one
   mdt c-multicast-routing bgp
    migration route-policy PIM-to-BGP
    announce-pim-join-tlv
   !
   rp-address 10.2.100.9 override
   !
   interface GigabitEthernet0/0/0/9
    enable
   !
  !
 !
!
 
route-policy rpf-for-one
 if next-hop in (10.1.100.3/32) then
    set core-tree pim-default
 else
   set core-tree mldp-default
 endif
end-policy
! 

route-policy PIM-to-BGP
 if next-hop in (10.1.100.3/32) then
   set c-multicast-routing pim
 else
   set c-multicast-routing bgp
 endif
end-policy
!

multicast-routing
 vrf one
 address-family ipv4
   mdt source Loopback0
   rate-per-route
   interface all enable
   accounting per-prefix
   bgp auto-discovery mldp
   !
   mdt default ipv4 232.1.1.1
   mdt default mldp ipv4 10.1.100.7
  !
 !
!

Schauen Sie sich Abbildung 4 an. Es gibt nun einen PIM-basierten MDT zwischen dem Legacy-PE und dem Egress-PE.

Abbildung 4:

Der Egress-PE sendet nach dem SPT-Switchover PIM-Join-Nachrichten über den PIM-basierten MDT an den Legacy-Source-PE für (S, G). Die Eingangsschnittstelle am Egress-PE ist jetzt Mid-Tone. Der RP-PE ist kein Turnaround-Router für Multicast-Verkehr mehr.

RP/0/RP1/CPU0:PE1#show mrib vrf one route 225.1.1.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, MF - MPLS Encap, 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
 
(*,225.1.1.1) RPF nbr: 10.1.100.2 Flags: C RPF
Up: 00:09:59
Incoming Interface List
   Lmdtone Flags: A LMI, Up: 00:09:59
Outgoing Interface List
   GigabitEthernet0/0/0/9 Flags: F NS, Up: 00:09:59
 
(10.2.3.10,225.1.1.1) RPF nbr: 10.1.100.3 Flags: RPF
Up: 00:14:29
Incoming Interface List
    mdtone Flags: A MI, Up: 00:14:29
Outgoing Interface List
   GigabitEthernet0/0/0/9 Flags: F NS, Up: 00:14:29

PE1 verfügt über diese PIM-RPF-Informationen für die Quelle:

RP/0/RP1/CPU0:PE1#show pim vrf one rpf 10.2.3.10            
 
Table: IPv4-Unicast-default
* 10.2.3.10/32 [200/0]
   via mdtone with rpf neighbor 10.1.100.3
   RT:1:1 ,Connector: 1:3:10.1.100.3, Nexthop: 10.1.100.3

Das bedeutet, dass der Datenverkehr jetzt direkt vom Legacy-Source-PE zum Egress-PE im Core-Netzwerk über den PIM-basierten MDT fließt. Siehe Abbildung 5.

Abbildung 5:

Schlussfolgerung

Bei allen nicht älteren PE-Routern, bei denen es sich um Receiver-PE- oder RP-PE-Router handelt, muss die Konfiguration für die Migration der Core-Tree-Protokolle und der C-Signalisierungsprotokolle vorhanden sein.

Alternativ besteht eine Problemumgehung darin, sicherzustellen, dass der SPT-Switchover nicht stattfindet. In diesem Fall erfolgt das Routing des Multicast-Verkehrs jedoch möglicherweise nicht über den kürzesten Pfad im Core des Netzwerks.

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
1.0	19-May-2021	Erstveröffentlichung

Beiträge von Cisco Ingenieuren

Luc De Ghein
Cisco TAC Engineer

War dieses Dokument hilfreich?

Feedback

Cisco kontaktieren

Eine Supportanfrage öffnen
(Erfordert einen Cisco Servicevertrag)

Migration von Core-Tree-Protokollen auf einem IOS-XR PE-Router in mVPN-Netzwerken

Download-Optionen

Inklusive Sprache

Informationen zu dieser Übersetzung

Inhalt

Einleitung

Migration von Core-Tree-Protokollen

C-Multicast-Protokollmigration

Szenarien

Szenario 1.

Szenario 2.

Szenario 3.

Szenario 4.

Das Problem

Die Lösung

Schlussfolgerung

Revisionsverlauf

Beiträge von Cisco Ingenieuren

War dieses Dokument hilfreich?

Cisco kontaktieren