Migrazione dei protocolli della struttura principale su un router IOS-XR PE in reti mVPN
Sommario
Introduzione
In questo documento viene descritta la migrazione di MDT basati su albero multicast basati su albero del protocollo Multicast VPN (mVPN) Multicast indipendente (PIM) su albero del protocollo Multipoint Label Distribution Protocol (mLDP). Inoltre, la modalità di segnalazione dettagliata dei Data MDT al momento della migrazione. Questo documento descrive la migrazione solo per il router Ingress Provider Edge (PE) con Cisco IOS®-XR.
Migrazione dei protocolli della struttura principale
Il termine dual-encap si riferisce a un router in ingresso in grado di inoltrare un flusso multicast cliente (C) a diversi tipi di strutture centrali contemporaneamente. Ad esempio, il router PE in ingresso inoltra un flusso multicast C su un albero principale basato su PIM e un albero principale basato su mLDP contemporaneamente. Questo è un requisito per migrare correttamente mVPN da un tipo di albero core a un altro.
La doppia crittografia è supportata per PIM e mLDP.
La doppia crittografia non è supportata per Multiprotocol Label Switching (MPLS) P2MP Traffic Engineering (TE).
La migrazione o la coesistenza di MDT Generic Routing Encapsulation (GRE) e MDT mLDP predefinito si basa sul fatto che il router PE in ingresso inoltra un flusso multicast C su un albero principale basato su PIM e uno basato su mLDP contemporaneamente. Mentre il PE in ingresso viene inoltrato su entrambi gli MDT, è possibile eseguire la migrazione dei router PE in uscita uno per uno da un tipo di albero principale a un altro.
In genere, le route PE eseguono la migrazione dal modello di distribuzione mVPN meno recente utilizzando strutture ad albero principali basate su PIM a un modello di distribuzione mVPN utilizzando strutture basate su mLDP. L'implementazione mVPN più vecchia è Profile 0, che è una struttura ad albero basata su PIM, no Border Gateway Protocol (BGP) Auto-Discovery (AD) e PIM nella segnalazione di sovrapposizione. Tuttavia, la migrazione può avvenire anche in modo opposto.
Esaminiamo questo scenario di migrazione in quanto si tratta della migrazione più comune che si verifica: dal GRE nel core (profilo 0) a un profilo MDT mLDP predefinito.
Sono possibili alcuni profili mLDP predefiniti.
Diamo un'occhiata a questi:
- mLDP senza BGP AD
- mLDP con segnalazione BGP AD e PIM C
- mLDP con segnalazione BGP AD e BGP C
In quest'ultimo caso, c'è anche una migrazione del protocollo di segnalazione C.
Uno degli aspetti da tenere presente è che quando si utilizza BGP AD, l'MDT dei dati viene segnalato da BGP per impostazione predefinita. Se non è presente BGP AD, l'MDT dati non può essere segnalato da BGP.
In ogni caso, il file PE in ingresso deve avere sia il profilo 0 che il profilo mLDP configurato. Il PE in ingresso inoltrerà il traffico multicast C su entrambi i MDT (predefiniti o dati) di entrambi i protocolli della struttura principale. Pertanto, entrambi gli MDT predefiniti devono essere configurati nel file PE in ingresso.
Se il PE in uscita è in grado di eseguire i protocolli PIM e mLDP dell'albero principale, può decidere da quale albero prelevare il traffico multicast C. A tale scopo, è necessario configurare il criterio Reverse Path Forwarding (RPF) nell'PE in uscita.
Se il router PE in uscita è in grado di supportare solo il profilo 0, tale router si unirà solo alla struttura PIM nel core e riceverà il flusso multicast C nella struttura basata su PIM.
Migrazione protocollo multicast C
Il protocollo multicast C può essere migrato da PIM a BGP o viceversa. A tale scopo, è necessario configurare l'uscita PE in modo da scegliere PIM o BGP come protocollo di overlay. È l'Egress PE che invia un join da PIM o BGP. Il PE in ingresso può ricevere ed elaborare entrambi in uno scenario di migrazione.
Questo è un esempio di migrazione del protocollo multicast C, configurato sul PE in uscita:
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 abilitato come protocollo di segnalazione overlay. Il valore di default è PIM.
Scenari
Vedere la Figura 1. per verificare l'impostazione utilizzata per gli scenari.
Figura 1.
In questi scenari, si dispone di almeno un router PE legacy come router PE ricevitore. Questo è un router che esegue solo il profilo 0 (impostazione predefinita, MDT - GRE - PIM e segnalazione multicast).
Su questo router deve essere configurato BGP IPv4 MDT.
È presente almeno un router Receiver-PE con un profilo basato su mLDP. Si tratta di tutti i profili MDT mLDP predefiniti (1, 9, 13, 12, 17), di tutti i profili MDT mLDP partizionati (2, 4, 5, 14, 15) e del profilo 7. È supportato anche il profilo 8 per P2MP TE.
Il router PE in ingresso è un router a doppia crittografia: esegue il profilo 0 e un profilo basato su mLDP.
Il router PE in ingresso deve inoltrare in qualsiasi momento il traffico sugli MDT basati su PIM e sugli MDT basati su mLDP. Questi MDT possono essere predefiniti e MDT dati.
Come router legacy, accettare un router con IOS, che può eseguire solo il profilo 0. La configurazione del router legacy è la seguente.
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
È necessario configurare la MDT BGP IPv4:
router bgp 1
…
address-family ipv4 mdt
neighbor 10.1.100.7 activate
neighbor 10.1.100.7 send-community extended
exit-address-family
!
…
Scenario 1.
Uno o più router PE legacy come router Receiver-PE.
Uno o più router PE come router Receiver-PE eseguono il profilo 1 (MDT predefinito - mLDP MP2MP PIM C-mcast Signaling).
Non sono presenti segnali BGP AD o BGP C-multicast.
Configurazione del router Receiver-PE con profilo 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
Configurazione del router PE in ingresso:
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
!
!
!
Il router PE in entrata deve avere una famiglia di indirizzi BGP IPv4 MDT, corrispondente a quella del router PE legacy.
Il file PE in ingresso deve essere inoltrato su entrambi i tipi di MDT:
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
Il file PE in entrata dovrebbe vedere il file PE legacy sul segnale modale dell'interfaccia e il file PE del profilo 1 sull'interfaccia Lmdtone come router adiacente PIM:
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" sul file PE in ingresso:
Viene inviato un TLV di unione PIM di tipo 1 (PIM core tree) e di tipo 2 (mLDP core tree). Il primo su mdtone e il secondo su 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
Il sistema PE legacy in uscita:
"debug ip pim vrf one 232.10.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
Il file PE legacy memorizza nella cache il TLV di unione PIM:
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
Il file PE legacy unisce l'MDT dei dati nel core:
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
Il ricevitore-PE Profile 1 riceve anche il TLV di aggiunta PIM, ma per il Data MDT basato su mLDP:
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
Scenario 2.
Sono presenti uno o più router PE legacy come router Receiver-PE.
Uno o più router PE come router Receiver-PE eseguono il profilo 9 (MDT predefinito - mLDP MP2MP BGP-AD PIM C-mcast Signaling).
È coinvolto BGP AD, ma non è presente alcuna segnalazione multicast BGP C.
Configurazione del router Receiver-PE con profilo 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
!
!
!
Il router PE in entrata deve avere una famiglia di indirizzi BGP IPv4 MDT, corrispondente a quella del router PE legacy. Il router PE in entrata deve avere una VPN IPv4 della famiglia di indirizzi BGP, corrispondente a quella del router PE in uscita Profile 9.
Configurazione del router PE in ingresso:
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
!
!
!
Senza il comando "notice-pim-join-tlv", il router PE in ingresso non invia i messaggi TLV di aggiunta PIM sugli MDT predefiniti, se è abilitato il rilevamento automatico BGP (AD). Senza questo comando, il router PE in ingresso invia solo un aggiornamento del tipo di route 3 mvpn BGP IPv4. Il router Profile 9 Egress PE non riceve l'aggiornamento BGP e installa il messaggio Data MDT nella sua cache. Il router PE legacy non esegue BGP AD e pertanto non viene in grado di apprendere il messaggio di join MDT dati tramite BGP.
Il PE in ingresso deve inoltrare il traffico multicast C su entrambi i tipi di MDT:
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
Il file PE in entrata dovrebbe vedere il file PE legacy sul segnale modale dell'interfaccia e il file PE Profile 9 sull'interfaccia Lmdtone come router adiacente PIM:
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)
Il server PE di uscita Profile 9 riceve il messaggio Data MDT come aggiornamento BGP per una route di tipo 3 nella VPN IPv4 della famiglia di indirizzi:
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
Questa route BGP è una route di tipo 3, per il protocollo tunnel di tipo 2, che è LSP P2MP m mLDP (Data MDT basato su LSP mLSP P2MP). Nessuna voce BGP route-type 3 per alcuna struttura PIM, poiché BGP AD non è abilitato per PIM.
"debug pim vrf one mdt data" sul file PE in ingresso:
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
Il file PE in ingresso invia un TLV di unione PIM per l'MDT dei dati basato su PIM e su mLDP.
Nella versione precedente di PE:
"debug ip pim vrf one 232.10.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
Il file PE legacy riceve e memorizza nella cache il TLV di unione PIM:
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
Il file PE legacy unisce l'MDT dei dati nel core:
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
Il ricevitore Profile 9-PE.
"debug pim vrf one mdt data" in Profile 9 Egress PE:
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)
Il ricevitore-PE Profile 9 riceve e memorizza nella cache il TLV di aggiunta del PIM. Il ricevitore-PE Profile 9 ha inoltre appreso l'MDT dei dati a causa della ricezione del messaggio di aggiornamento BGP per un tipo di route 3 dal modulo PE in ingresso. Il TLV di join PIM e il tipo di route del messaggio di aggiornamento BGP sono equivalenti e contengono le stesse informazioni relative al tunnel della struttura principale per il Data 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
Scenario 3.
Uno o più router PE legacy come router Receiver-PE.
Uno o più router PE come router Receiver-PE eseguono il profilo 13 (MDT predefinito - mLDP MP2MP BGP-AD BGP C-mcast Signaling).
Sono coinvolti BGP AD e la segnalazione multicast BGP C.
Configurazione del router Receiver-PE con profilo 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
!
!
!
Configurazione del router PE in ingresso:
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
!
!
!
Se BGP AD è abilitato, il router PE in ingresso non invia i messaggi TLV di aggiunta PIM tramite l'MDT predefinito senza il comando notice-pim-join-tlv. Senza questo comando, il router PE in ingresso invia solo un aggiornamento del tipo di route 3 mvpn BGP IPv4. Il router Profile 13 Egress PE non riceve l'aggiornamento BGP e installa il messaggio Data MDT nella sua cache. Il router PE legacy non esegue BGP AD e pertanto non viene in grado di apprendere il messaggio di join MDT dati tramite BGP.
Il file PE in ingresso deve essere inoltrato su entrambi i tipi di MDT:
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
Il file PE in entrata dovrebbe vedere il file PE legacy sul segnale modulare dell'interfaccia come un router adiacente PIM. Tuttavia, non è necessario che Profile 13 PE su Lmdtone di interfaccia sia adiacente a PIM, in quanto BGP è ora utilizzato come protocollo di segnalazione multicast C.
"debug pim vrf one mdt data" sul file PE in ingresso:
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 (-)
Il file PE in ingresso invia TLV di unione PIM per l'MDT dei dati basato su PIM e su mLDP.
"debug ip pim vrf one 232.100.1.1" sul sistema PE legacy:
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
Il file PE legacy memorizza nella cache il TLV di unione PIM:
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
Il file PE legacy unisce l'MDT dei dati nel core:
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
Il modulo Profile 13 Receiver-PE:
"debug pim vrf one mdt data" sul profilo 13 in uscita PE:
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
Il modulo Profile 13 Receiver-PE riceve e memorizza nella cache il valore TLV di aggiunta del PIM per l'MDT basato su mLDP. Il modulo Profile 13 Receiver-PE ha anche appreso della MDT dei dati a causa della ricezione del messaggio di aggiornamento BGP per un tipo di route 3 dal modulo PE in ingresso. Il TLV di join PIM e il tipo di route del messaggio di aggiornamento BGP sono equivalenti e contengono le stesse informazioni relative al tunnel della struttura principale per il Data 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
Questa route BGP è una route di tipo 3, per il protocollo tunnel di tipo 2, che è LSP P2MP m mLDP (Data MDT basato su LSP mLSP P2MP). Nessun tipo di route BGP 3 per alcun albero PIM, poiché BGP AD non è abilitato per PIM.
È disponibile anche un route-type 7 perché la segnalazione multicast C è attivata tra il Profile 13 Egress PE e il Ingress PE. L'aggiornamento BGP del tipo di route 7 viene inviato dal file PE di profilo 13 in uscita al file PE in entrata.
Scenario 4.
In questo scenario, nel contesto VPN è disponibile la modalità di sparsità PIM.
Uno o più router PE legacy come router Source-PE.
Uno o più router PE come router Receiver-PE eseguono il profilo 13 (MDT predefinito - mLDP MP2MP BGP-AD BGP C-mcast Signaling). Sono coinvolti BGP AD e la segnalazione multicast BGP C. Poiché questi router PE devono essere in grado di ricevere il traffico direttamente dal router PE di origine, ovvero il router PE legacy, devono eseguire anche il profilo 0.
L'RP-PE è un router PE che esegue il profilo 13 (MDT predefinito - mLDP MP2MP BGP-AD BGP C-mcast Signaling). Sono coinvolti BGP AD e la segnalazione multicast BGP C. Poiché il router RP-PE deve essere in grado di ricevere il traffico direttamente dal router Source-PE, ovvero il router PE legacy, è necessario che esegua anche il profilo 0.
Il routing multicast ha funzionato nello scenario 3, ma potrebbe funzionare solo per SSM (Source-Specific Multicast). Se la segnalazione C è in modalità sparse, il multicast potrebbe non riuscire. Ciò dipende dalla posizione del punto di Rendez-Vous (RP). Se la segnalazione nella sovrapposizione è solo (S, G), il routing multicast funzionerà come nello scenario 3. Ciò si verifica se l'RP si trova nella sede del ricevitore. Se l'RP si trova sul sito di un ricevitore, il ricevitore-PE non invierà un (*, G) Join in overlay, né da PIM né da BGP. Se invece l'RP si trova nella sorgente PE, o in un altro PE, nella sovrapposizione vi saranno (*, G) e (S, G) segnali. Il routing multicast potrebbe avere esito negativo se si esegue questa operazione con la configurazione come nello scenario 3.
Vedere la Figura 2. Mostra una rete con un Source-PE (Legacy-PE), un RP-PE (PE2) e un Receiver-PE (PE1).
Figura 2.
I router PE in uscita devono inviare join per (*,G). Il protocollo da utilizzare dipende dalla configurazione. Egress-PE utilizzerà BGP e il router Legacy-Source-PE utilizzerà PIM se ha anche un ricevitore. L'albero condiviso verrà quindi segnalato correttamente. Si verificherà un problema quando l'origine inizia l'invio: la struttura di origine non verrà segnalata.
Il problema
Una volta che l'origine ha iniziato l'invio, l'RP riceve i pacchetti di registro dal PIM First Hop Router (FHR). Potrebbe trattarsi del router Legacy-Source-PE. L'RP-PE dovrebbe quindi inviare un'unione PIM (S, G) verso il Legacy-Source-PE, poiché il Legacy-Source-PE non esegue BGP come protocollo di segnalazione di sovrapposizione. Tuttavia, l'RP-PE ha BGP configurato come protocollo di segnalazione overlay. Pertanto, Legacy-Source-PE non riceverà mai un messaggio PIM (S, G) Join dall'RP-PE e pertanto non è possibile segnalare l'albero di origine da Source a RP. L'installazione è bloccata nella fase di registrazione. L'elenco di interfacce in uscita (OIL) in Legacy-Source-PE sarà vuoto:
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
Per risolvere questo problema, è necessario che l'RP-PE invii un join PIM per (S, G) al Legacy-Source-PE, mentre l'RP-PE dispone ancora di BGP abilitato come protocollo di segnalazione sovrapposto per i router non legacy. Se un'origine è connessa dietro un router non legacy, l'RP-PE deve inviare un messaggio di aggiornamento BGP di tipo route 7 verso tale router non legacy.
L'RP-PE può utilizzare sia PIM che BGP come segnalazione di sovrimpressione. La scelta di uno dei due verrà determinata da una regola di route. È necessario disporre del comando di migrazione in PIM router per il VRF. Per la rete illustrata nella Figura 2, questa è la configurazione necessaria sull'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
!
!
!
Il parametro route-policy PIM-to-BGP specifica che se il router PE remoto è 10.1.100.3 (Legacy-Source-PE), utilizzare PIM come protocollo di segnalazione in sovrimpressione. In caso contrario (per il router PE non legacy), il protocollo BGP viene utilizzato come protocollo di segnalazione in sovrimpressione. In questo modo, l'RP-PE invia un'unione PIM (S, G) verso l'unità Legacy-Source-PE sull'MDT di default basato su PIM. Legacy-Source-PE include ora la voce (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
Il ricevitore può ricevere i pacchetti multicast se l'RP-PE li instrada: inoltra i pacchetti multicast ricevuti dall'MDT all'albero Lmdt.
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
Indipendentemente dal fatto che il router LHR (Last Hop Router) abbia o meno configurato lo switchover SPT, il traffico multicast continua a essere inoltrato attraverso la struttura condivisa, verso l'RP-PE. Vedere la Figura 3. per verificare come viene inoltrato il traffico multicast.
Figura 3.
L'Egress-PE non ha voce (S, G):
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
Se Egress-PE è l'LHR, non avrà una voce (S, G). Il motivo per cui l'uscita-PE non può passare alla voce (S, G) è che non ha ricevuto una route attiva all'origine BGP da un router PE. Il traffico multicast viene inoltrato come mostrato nella Figura 3.
Tuttavia, è possibile che l'Egress-PE non sia l'LHR, ma che un router CE sul sito Egress-PE sia l'LHR. Se il router CE non passa all'albero di origine, l'uscita PE riceve un'unione PIM (S, G) e installa la voce (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
Tuttavia, Egress-PE ora eseguirà il RPF sull'origine e troverà il router Legacy-Source-PE come router adiacente:
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
Poiché non esiste alcun MDT tra Egress-PE e Legacy-Source-PE, Egress-PE non può inviare un join a Legacy-Source-PE. Tenere presente che Egress-PE crea solo alberi mLDP e segnala i clienti BGP. Tenere presente che il sistema Legacy-Source-PE crea solo alberi basati su PIM e segnala solo i clienti PIM.
Tuttavia, poiché l'interfaccia Egress-PE dispone di informazioni RPF che puntano all'interfaccia in ingresso Lmdt e il traffico multicast arriva ancora su tale MDT dall'RP-PE, il traffico multicast verrà inoltrato verso il destinatario e non avrà esito negativo in RPF. Il motivo è che l'RPF non esegue un controllo rigoroso dell'RPF per verificare se il traffico multicast arriva effettivamente dal router 10.1.100.3 adiacente all'RPF, il router Legacy-PE. Si noti che non esiste alcuna adiacenza PIM per 10.1.100.3 in PE1 su Lmdt, poiché Legacy-PE non può avere Lmdt perché esegue PIM solo come protocollo dell'albero principale (Profilo 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)
Il motivo per cui PE1 sceglie Lmdt come interfaccia in ingresso è che si tratta delle informazioni ricevute dal comando di topologia RPF in PE1:
route-policy rpf-for-one
set core-tree mldp-default
end-policy
!
Se l'RPF è ancora accettabile in PE1, il traffico multicast può raggiungere il ricevitore dietro PE1. Tuttavia, il traffico non prende il percorso più breve da Legacy-PE a PE1 nel nucleo.
La soluzione
Per risolvere questo problema, è necessario configurare Egress-PE (PE1) in modo che segnali MDT e BGP basati su PIM anche come segnale di overlay. Questa configurazione è necessaria sul modulo Egress-PE in questo caso:
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
!
!
!
Vedere la Figura 4. Tra Legacy-PE ed Egress-PE è ora disponibile un MDT basato su PIM.
Figura 4.
Il modulo Egress-PE invia messaggi di unione PIM attraverso l'MDT basato su PIM verso il Legacy-Source-PE per (S, G) dopo lo switchover SPT. L'interfaccia in ingresso sul modulo Egress-PE è ora in formato mdtone. L'RP-PE non è più un router di risposta per il traffico multicast.
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
In PE1 sono disponibili le seguenti informazioni PIM RPF per l'origine:
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
Ciò significa che il traffico ora scorre direttamente da Legacy-Source-PE a Egress-PE nella rete principale attraverso l'MDT basato su PIM. Vedere la Figura 5.
Figura 5.
Conclusioni
Tutti i router PE non legacy, che sono router Receiver-PE o RP-PE, devono disporre della configurazione per la migrazione dei protocolli core-tree e la migrazione dei protocolli di segnalazione C.
In alternativa, per evitare lo switchover SPT, è possibile usare una soluzione alternativa. In questo caso, tuttavia, il routing del traffico multicast potrebbe non trovarsi sul percorso più breve nel nucleo della rete.
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
1.0 |
19-May-2021 |
Versione iniziale |
Feedback